Search NASA⌕ Search

SEARCH · Search NASA

Results for “automated command”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
DOE OSTI2023

Livermore Computing User and System Scripts

LCUSS is a collection of scripts used to improve productivity on HPC systems for both administrators and general users. It will include general scripts for user management, scripts for helping users interact with LC resource management software (e.g. SLURM and Flux), and scripts to automate common user command-line tasks on LC and other HPC machines. These scripts are intended to be made available to all LC users. Hosting them on GitHub will allow LC staff, users, and collaborators to work on them together.

Long, Jeffery↗
NASA NTRS1980

Space Experiments with Particle Accelerators (SEPAC), status review, 23 September 1980

The development responsibilities of SEPAC include: accelerator systems, diagnostic systems, power systems, dedicated experiment processor, interface unit, control panel, and all flight software. The operations of SEPAC, including automated experiments under DEP command control and SEPAC manual operations, are outlined. A diagram of the system configuration is presented.

Source record↗
DOE OSTI2026

The Art of Automation: Translating Electron Microscopy Workflows Into Automated Processes

Acquiring data using a scanning transmission electron microscope (STEM) is a complex, multi-step process. The intricacy of the process depends on the type of sample, composition of the material, desired results of the experiment, resolution requirement and other experimental factors. Each experiment presents unique complications, such as sample drift and contamination, that the microscopist must consider when acquiring data. All these challenges are handled fluidly and expertly by experienced microscopists, but to reach new levels of innovation in material development, including greater reproducibility, throughput, and precision, the automation of these workflows is essential. The initial phase of this work involved translating intuition-based workflows into discrete, programmable steps. Some common key stages in STEM workflows are the initial tuning, scanning the sample for areas of interest, and then acquiring the data. Each stage can be broken further into specific parameter adjustments, such as aberration correction and dwell time optimization, depending on the experiment. When deconstructing various experiments each step was assessed for automation feasibility based on the amount of real time operator decisions. There are steps that lend themselves to automation more readily than others, such as course focusing and sample screening, but there is potential for full automation of all stages with time. As an initial step, an automated montage routine was developed, allowing for the efficient acquisition of large portions of the sample without requiring continuous intervention from the operator. The automation of this small process of the procedure demonstrates the value of this capability. A major challenge in automation arises from discrepancies between commanded, reported and actual stage movements. Using systematic tests, stage movement was quantified. This error can be corrected algorithmically for more accurate workflows in the future. Expanding automation capabilities would result in larger, more efficient data acquisition which allows for more robust statistical analysis. Additionally, this work lays the groundwork for a closed loop system where machine learning algorithms would intake automatically acquired data and make real time decisions. By progressively automating this instrument, this work establishes the foundation for fully automated experimentation in transmission electron microscopy.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1986

Pilot vehicle interface on the advanced fighter technology integration F-16

This paper focuses on the work load aspects of the pilot vehicle interface in regard to the new technologies tested during AMAS Phase II. Subjects discussed in this paper include: a wide field-of-view head-up display; automated maneuvering attack system/sensor tracker system; master modes that configure flight controls and mission avionics; a modified helmet mounted sight; improved multifunction display capability; a voice interactive command system; ride qualities during automated weapon delivery; a color moving map; an advanced digital map display; and a g-induced loss-of-consciousness and spatial disorientation autorecovery system.

Dana, W. H.↗
NASA NTRS1994

Re-engineering the Multimission Command System at the Jet Propulsion Laboratory

The Operations Engineering Lab (OEL) at JPL has developed the multimission command system as part of JPL's Advanced Multimission Operations System. The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The command functions include real-time command generation, command translation and radiation, status reporting, some remote control of Deep Space Network antenna functions, and command file management. The mission-independent architecture has allowed easy adaptation to new flight projects and the system currently supports all JPL planetary missions (Voyager, Galileo, Magellan, Ulysses, Mars Pathfinder, and CASSINI). This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. The redesign has allowed streamlining of command operations with significant improvements in productivity and ease of use. In addition, the new system has provided a command capability that works equally well for real-time operations and within a spacecraft testbed. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

Alexander, Scott↗
NASA NTRS2014

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗
NASA NTRS2005

Survey of Command Execution Systems for NASA Spacecraft and Robots

NASA spacecraft and robots operate at long distances from Earth Command sequences generated manually, or by automated planners on Earth, must eventually be executed autonomously onboard the spacecraft or robot. Software systems that execute commands onboard are known variously as execution systems, virtual machines, or sequence engines. Every robotic system requires some sort of execution system, but the level of autonomy and type of control they are designed for varies greatly. This paper presents a survey of execution systems with a focus on systems relevant to NASA missions.

Verma, Vandi↗
NASA NTRS1975

Apollo experience report: Guidance and control systems: Automated control system for unmanned mission AS-201

The Apollo command module heat shield and Apollo command and service module/Saturn launch vehicle structural integrity were evaluated in an unmanned test flight. An automated control system was developed to provide the mission event sequencing, the real-time ground control interface, and the backup attitude reference system for the unmanned flight. The required mission events, the design logic, the redundancy concept, and the ground-support-equipment concept are described and some development problem areas are discussed. The mission event time line and the real-time ground command list are included to provide an outline of the control system capabilities and requirements. The mission was accomplished with the automated control system, which functioned without flight anomalies.

Holloway, G. F.↗
NASA NTRS2022

PAAV Concept Document

The Pathfinding for Airspace with Autonomous Vehicles (PAAV) Concept Document, version 1.0, lays out the key challenges and potential solutions for the use of uncrewed aircraft (UA) technology for future regional air cargo operations. The challenges and solutions described in this document were informed by communications with the UA industry community (e.g., RTCA, the Federal Aviation Administration, and regional air cargo business operators), as well as the PAAV team’s research activities during the last two years including four tabletop exercises, a human-in-the-loop simulation study, a numerical simulation study, a functional allocation study, and flight data analysis (Appendix A). This document first describes the expected operational context of PAAV (Section 2), such as the flight mission, baseline UAS components, nominal operations, m:N operations (i.e., "m" remote pilots per "N" aircraft), and off-nominal operations. This context sets the scope for the PAAV concept development work. PAAV concept development assumes that UA operations will be increasingly autonomous. Thus, near- and far-term assumptions are defined (Section 3). PAAV identified seven key challenges for UA operations (Section 4): - Flight route planning - Separation and flow management - Traffic pattern integration - Contingency management - Taxi, takeoff, and landing - m:N operations - Communications operations The following 13 potential solutions to these challenges are then described (Section 5): - Scalable communications architecture - Data link - Designated UAS corridors - Crew planning for m:N operations - Flight route optimization - Traffic load-level control - Trajectory solutions with data link - Automated hazard avoidance for m:N operations - Traffic pattern integration (TPI) tool - Standard lost command and control (C2) link (LC2L) procedures - Automated hazard avoidance under LC2L - Auto-taxi, auto-takeoff, and auto-land - Ground control station (GCS) user interface for m:N operations The document attempts to link each of these solutions to one or more of the challenge areas. Novel solutions involving numerous automation technologies are needed to mitigate traffic and airspace management challenges, especially for realizing m:N operations and ensuring safety under LC2L conditions. The purpose of this document is to help understand alternatives and tradeoffs among potential solutions and provide a foundation for a cohesive PAAV concept that will be described and refined in subsequent concept versions.

Unmanned aircraft, uncrewed aircraft, regional air↗
NASA NTRS2000

The Life Cycle Application of Intelligent Software Modeling for the First Materials Science Research Rack

Marshall Space Flight Center (MSFC) has been funding development of intelligent software models to benefit payload ground operations for nearly a decade. Experience gained from simulator development and real-time monitoring and control is being applied to engineering design, testing, and operation of the First Material Science Research Rack (MSRR-1). MSRR-1 is the first rack in a suite of three racks comprising the Materials Science Research Facility (MSRF) which will operate on the International Space Station (ISS). The MSRF will accommodate advanced microgravity investigations in areas such as the fields of solidification of metals and alloys, thermo-physical properties of polymers, crystal growth studies of semiconductor materials, and research in ceramics and glasses. The MSRR-1 is a joint venture between NASA and the European Space Agency (ESA) to study the behavior of different materials during high temperature processing in a low gravity environment. The planned MSRR-1 mission duration is five (5) years on-orbit and the total design life is ten (IO) years. The MSRR-1 launch is scheduled on the third Utilization Flight (UF-3) to ISS, currently in February of 2003). The objective of MSRR-1 is to provide an early capability on the ISS to conduct material science, materials technology, and space product research investigations in microgravity. It will provide a modular, multi-user facility for microgravity research in materials crystal growth and solidification. An intelligent software model of MSRR-1 is under development and will serve multiple purposes to support the engineering analysis, testing, training, and operational phases of the MSRR-1 life cycle development. The G2 real-time expert system software environment developed by Gensym Corporation was selected as the intelligent system shell for this development work based on past experience gained and the effectiveness of the programming environment. Our approach of multi- uses of the simulation model and its intuitive graphics capabilities is providing a concurrent engineering environment for rapid prototyping and development. Operational schematics of the MSRR-1 electrical, thermal control, vacuum access, and gas supply systems, and furnace inserts are represented graphically in the environment. Logic to represent first order engineering calculations is coded into the knowledge base to simulate the operational behavior of the MSRR-1 systems. An example of engineering data provided includes electrical currents, voltages, operational power, temperatures, thermal fluid flow rates. pressures, and component status indications. These type of data are calculated and displayed at appropriate instrumentation points, and the schematics are animated to reflect the simulated operational status of the MSRR-1. The software control functions are also simulated to represent appropriate operational behavior based on automated control and response to commands received by the crew or ground controllers. The first benefit of this simulation environment is being realized in the high fidelity engineering analysis results from the electrical power system G2 model. Secondly, the MSRR-1 simulation model will be embedded with a hardware mock-up of the MSRR-1 to provide crew training on MSRR-1 integrated payload operations. G2 gateway code will output the simulated instrumentation values, termed as telemetry, in a flight-like data stream so that the crew has realistic and accurate simulated MSRR-1 data on the flight displays which will be designed for crew use. The simulation will also respond appropriately to crew or ground initiated commands, which will be part of normal facility operations. A third use of the G2 model is being planned; the MSRR-1 simulation will be integrated with additional software code as part of the test configuration of the primary onboard computer, or Master Controller, for MSRR-1. We will take advantage of the G2 capability to simulate the flight like data stream to test flight software responses and behavior. A fourth use of the G2 model will be to train the Ground Support Personnel that will monitor the MSRR-1 systems and payloads while they are operating aboard the ISS. The intuitive, schematic based environment will provide an excellent foundation for personnel to understand the integrated configuration and operation of the MSRR-1, and the anticipated telemetry feedback based on operational modes of the equipment. Expert monitoring features will be enhanced to provide a smart monitoring environment for the operators. These features include: (1) Animated, intuitive schematic-based displays which reflect telemetry values, (1) Real-time plotting of simulated or incoming sensor values, (3) High/Low exception monitoring for analog data, (4) Expected state monitoring for discrete data, (5) Data trending, (6) Automated malfunction procedure execution to diagnose problems, (7) Look ahead capability to planned MSRR-1 activities in the onboard timeline. And finally, the logic to calculate telemetry values will be deactivated, and the same environment will interface to the incoming data for the real-time telemetry stream to schematically represent the onboard hardware configuration. G2 will be the foundation for the real-time monitoring and control environment. In summary, our MSRR-1 simulation model spans many elements of the life cycle development of this project: Engineering Analysis, Test and Checkout, Training of Crew and Ground Personnel, and Real-time monitoring and control. By utilizing the unique features afforded by an expert system development environment, we have been able to synergize a powerful tool capable of addressing our project needs at every phase of project development.

Rice, Amanda↗
NASA NTRS2010

AutoGen Version 5.0

Version 5.0 of the AutoGen software has been released. Previous versions, variously denoted Autogen and autogen, were reported in two articles: Automated Sequence Generation Process and Software (NPO-30746), Software Tech Briefs (Special Supplement to NASA Tech Briefs), September 2007, page 30, and Autogen Version 2.0 (NPO- 41501), NASA Tech Briefs, Vol. 31, No. 10 (October 2007), page 58. To recapitulate: AutoGen (now signifying automatic sequence generation ) automates the generation of sequences of commands in a standard format for uplink to spacecraft. AutoGen requires fewer workers than are needed for older manual sequence-generation processes, and greatly reduces sequence-generation times. The sequences are embodied in spacecraft activity sequence files (SASFs). AutoGen automates generation of SASFs by use of another previously reported program called APGEN. AutoGen encodes knowledge of different mission phases and of how the resultant commands must differ among the phases. AutoGen also provides means for customizing sequences through use of configuration files. The approach followed in developing AutoGen has involved encoding the behaviors of a system into a model and encoding algorithms for context-sensitive customizations of the modeled behaviors. This version of AutoGen addressed the MRO (Mars Reconnaissance Orbiter) primary science phase (PSP) mission phase. On previous Mars missions this phase has more commonly been referred to as mapping phase. This version addressed the unique aspects of sequencing orbital operations and specifically the mission specific adaptation of orbital operations for MRO. This version also includes capabilities for MRO s role in Mars relay support for UHF relay communications with the MER rovers and the Phoenix lander.

Gladden, Roy E.↗
NASA NTRS1994

Automatic commanding of the Mars Observer Camera

Mars Observer, launched in September 1992, was intended to be a 'survey-type' mission that acquired global coverage of Mars from a low, circular, near-polar orbit during an entire Martian year. As such, most of its instruments had fixed data rates, wide fields of view, and relatively low resolution, with fairly limited requirements for commanding. An exception is the Mars Observer Camera, or MOC. The MOC consists of a two-color Wide Angle (WA) system that can acquire both global images at low resolution (7.5 km/pixel) and regional images at commandable resolutions up to 250 m/pixel. Complementing the WA is the Narrow Angle (NA) system, that can acquire images at 8 resolutions from 12 m/pixel to 1.5 m/pixel, with a maximum crosstrack dimension of 3 km. The MOC also provides various forms of data compression (both lossless and lossy), and is designed to work at data rates from 700 bits per second (bps) to over 80k bps. Because of this flexibility, developing MOC command sequences is much more difficult than the routine mode-changing that characterizes other instrument operations. Although the MOC cannot be pointed (the spacecraft is fixed nadir-pointing and has no scan platform), the timing, downlink stream allocation, compression type and parameters, and image dimensions of each image must be commanded from the ground, subject to the constraints inherent in the MOC and the spacecraft. To minimize the need for a large operations staff, the entire command generation process has been automated within the MOC Ground Data System. Following the loss of the Mars Observer spacecraft in August 1993, NASA intends to launch a new spacecraft, Mars Global Surveyor (MGS), in late 1996. This spacecraft will carry the MOC flight spare (MOC 2). The MOC 2 operations plan will be largely identical to that developed for MOC, and all of the algorithms described here are applicable to it.

Caplinger, Michael↗
NASA NTRS2000

Operations and Range Technology Development

The Operations and Range Technology Project is responsible for the development of key technologies as part of the KSC Spaceport Technology Center Initiative to substantially reduce vehicle launch and processing operations costs and improve the systems safety and reliability. The topics include: 1) Spaceport Technology Areas; 2) Umbilical Systems Development; 3) Automated Payload Handling Systems; 4) Command, Control and Monitor Systems; 5) Intelligent Synthesis Environment; 6) Low TRL Development; 7) Second Generation Project Organization; and 8) ASTP (3rd Generation) Project Organization. This paper is presented in viewgraph form.

Taylor, Dave↗
NASA NTRS1998

TACT: A Set of MSC/PATRAN- and MSC/NASTRAN- based Modal Correlation Tools

This paper describes the functionality and demonstrates the utility of the Test Analysis Correlation Tools (TACT), a suite of MSC/PATRAN Command Language (PCL) tools which automate the process of correlating finite element models to modal survey test data. The initial release of TACT provides a basic yet complete set of tools for performing correlation totally inside the PATRAN/NASTRAN environment. Features include a step-by-step menu structure, pre-test accelerometer set evaluation and selection, analysis and test result export/import in Universal File Format, calculation of frequency percent difference and cross-orthogonality correlation results using NASTRAN, creation and manipulation of mode pairs, and five different ways of viewing synchronized animations of analysis and test modal results. For the PATRAN-based analyst, TACT eliminates the repetitive, time-consuming and error-prone steps associated with transferring finite element data to a third-party modal correlation package, which allows the analyst to spend more time on the more challenging task of model updating. The usefulness of this software is presented using a case history, the correlation for a NASA Langley Research Center (LaRC) low aspect ratio research wind tunnel model. To demonstrate the improvements that TACT offers the MSC/PATRAN- and MSC/DIASTRAN- based structural analysis community, a comparison of the modal correlation process using TACT within PATRAN versus external third-party modal correlation packages is presented.

Marlowe, Jill M.↗
NASA NTRS2009

Maneuver Automation Software

The Maneuver Automation Software (MAS) automates the process of generating commands for maneuvers to keep the spacecraft of the Cassini-Huygens mission on a predetermined prime mission trajectory. Before MAS became available, a team of approximately 10 members had to work about two weeks to design, test, and implement each maneuver in a process that involved running many maneuver-related application programs and then serially handing off data products to other parts of the team. MAS enables a three-member team to design, test, and implement a maneuver in about one-half hour after Navigation has process-tracking data. MAS accepts more than 60 parameters and 22 files as input directly from users. MAS consists of Practical Extraction and Reporting Language (PERL) scripts that link, sequence, and execute the maneuver- related application programs: "Pushing a single button" on a graphical user interface causes MAS to run navigation programs that design a maneuver; programs that create sequences of commands to execute the maneuver on the spacecraft; and a program that generates predictions about maneuver performance and generates reports and other files that enable users to quickly review and verify the maneuver design. MAS can also generate presentation materials, initiate electronic command request forms, and archive all data products for future reference.

Uffelman, Hal↗
NASA NTRS2007

Autogen Version 2.0

Version 2.0 of the autogen software has been released. "Autogen" (automated sequence generation) signifies both a process and software used to implement the process of automated generation of sequences of commands in a standard format for uplink to spacecraft. Autogen requires fewer workers than are needed for older manual sequence-generation processes and reduces sequence-generation times from weeks to minutes.

Gladden, Roy↗