Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Commanding”

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 775 records · Page 43
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

MPST Software: grl_pef_check

This innovation is a tool used to verify and validate spacecraft sequences at the predicted events file (PEF) level for the GRAIL (Gravity Recovery and Interior Laboratory, see http://www.nasa. gov/mission_pages/grail/main/index. html) mission as part of the Multi-Mission Planning and Sequencing Team (MPST) operations process to reduce the possibility for errors. This tool is used to catch any sequence related errors or issues immediately after the seqgen modeling to streamline downstream processes. This script verifies and validates the seqgen modeling for the GRAIL MPST process. A PEF is provided as input, and dozens of checks are performed on it to verify and validate the command products including command content, command ordering, flight-rule violations, modeling boundary consistency, resource limits, and ground commanding consistency. By performing as many checks as early in the process as possible, grl_pef_check streamlines the MPST task of generating GRAIL command and modeled products on an aggressive schedule. By enumerating each check being performed, and clearly stating the criteria and assumptions made at each step, grl_pef_check can be used as a manual checklist as well as an automated tool. This helper script was written with a focus on enabling the user with the information they need in order to evaluate a sequence quickly and efficiently, while still keeping them informed and active in the overall sequencing process. grl_pef_check verifies and validates the modeling and sequence content prior to investing any more effort into the build. There are dozens of various items in the modeling run that need to be checked, which is a time-consuming and errorprone task. Currently, no software exists that provides this functionality. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗
NASA NTRS2013

Towards Human-Friendly Efficient Control of Multi-Robot Teams

This paper explores means to increase efficiency in performing tasks with multi-robot teams, in the context of natural Human-Multi-Robot Interfaces (HMRI) for command and control. The motivating scenario is an emergency evacuation by a transport convoy of unmanned ground vehicles (UGVs) that have to traverse, in shortest time, an unknown terrain. In the experiments the operator commands, in minimal time, a group of rovers through a maze. The efficiency of performing such tasks depends on both, the levels of robots' autonomy, and the ability of the operator to command and control the team. The paper extends the classic framework of levels of autonomy (LOA), to levels/hierarchy of autonomy characteristic of Groups (G-LOA), and uses it to determine new strategies for control. An UGVoriented command language (UGVL) is defined, and a mapping is performed from the human-friendly gesture-based HMRI into the UGVL. The UGVL is used to control a team of 3 robots, exploring the efficiency of different G-LOA; specifically, by (a) controlling each robot individually through the maze, (b) controlling a leader and cloning its controls to followers, and (c) controlling the entire group. Not surprisingly, commands at increased G-LOA lead to a faster traverse, yet a number of aspects are worth discussing in this context.

multi-robot control↗
NASA NTRS2014

ULSGEN (Uplink Summary Generator)

Uplink is an important part of spacecraft operations. Ensuring the accuracy of uplink content is essential to mission success. Before commands are radiated to the spacecraft, the command and sequence must be reviewed and verified by various teams. In most cases, this process requires collecting the command data, reviewing the data during a command conference meeting, and providing physical signatures by designated members of various teams to signify approval of the data. If commands or sequences are disapproved for some reason, the whole process must be restarted. Recording data and decision history is important for traceability reasons. Given that many steps and people are involved in this process, an easily accessible software tool for managing the process is vital to reducing human error which could result in uplinking incorrect data to the spacecraft. An uplink summary generator called ULSGEN was developed to assist this uplink content approval process. ULSGEN generates a web-based summary of uplink file content and provides an online review process. Spacecraft operations personnel view this summary as a final check before actual radiation of the uplink data. .

Wang, Y.-F.↗
NASA NTRS2016

Using Natural Language to Enhance Mission Effectiveness

The availability of highly capable, yet relatively cheap, unmanned aerial vehicles (UAVs) is opening up new areas of use for hobbyists and for professional-related activities. The driving function of this research is allowing a non-UAV pilot, an operator, to define and manage a mission. This paper describes the preliminary usability measures of an interface that allows an operator to define the mission using speech to make inputs. An experiment was conducted to begin to enumerate the efficacy and user acceptance of using voice commands to define a multi-UAV mission and to provide high-level vehicle control commands such as "takeoff." The primary independent variable was input type - voice or mouse. The primary dependent variables consisted of the correctness of the mission parameter inputs and the time needed to make all inputs. Other dependent variables included NASA-TLX workload ratings and subjective ratings on a final questionnaire. The experiment required each subject to fill in an online form that contained comparable required information that would be needed for a package dispatcher to deliver packages. For each run, subjects typed in a simple numeric code for the package code. They then defined the initial starting position, the delivery location, and the return location using either pull-down menus or voice input. Voice input was accomplished using CMU Sphinx4-5prealpha for speech recognition. They then inputted the length of the package. These were the option fields. The subject had the system "Calculate Trajectory" and then "Takeoff" once the trajectory was calculated. Later, the subject used "Land" to finish the run. After the voice and mouse input blocked runs, subjects completed a NASA-TLX. At the conclusion of all runs, subjects completed a questionnaire asking them about their experience in inputting the mission parameters, and starting and stopping the mission using mouse and voice input. In general, the usability of voice commands is acceptable. With a relatively well-defined and simple vocabulary, the operator can input the vast majority of the mission parameters using simple, intuitive voice commands. However, voice input may be more applicable to initial mission specification rather than for critical commands such as the need to land immediately due to time and feedback constraints. It would also be convenient to retrieve relevant mission information using voice input. Therefore, further on-going research is looking at using intent from operator utterances to provide the relevant mission information to the operator. The information displayed will be inferred from the operator's utterances just before key phrases are spoken. Linguistic analysis of the context of verbal communication provides insight into the intended meaning of commonly heard phrases such as "What's it doing now?" Analyzing the semantic sphere surrounding these common phrases enables us to predict the operator's intent and supply the operator's desired information to the interface. This paper also describes preliminary investigations into the generation of the semantic space of UAV operation and the success at providing information to the interface based on the operator's utterances.

Trujillo, Anna C.↗
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗
NASA NTRS2017

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↗
NASA NTRS2021

Waypoint Following Dynamics of a Quaternion Error Feedback Attitude Control System

Closed-loop attitude steering can be used to implement alternative attitude maneuvers by using a conventional attitude control system to track a non-standard attitude profile sampled as a series of sequential commands. The idea has been employed in practice to perform zero-propellant maneuvers on the International Space Station and minimum time maneuvers on NASA’s TRACE space telescope. A challenge for operational implementation of the idea is the finite capacity of a space vehicle’s command storage buffer. One approach to mitigate the problem is to downsample-and-hold the attitude commands so that the attitude control system to follows a set of waypoints. This paper explores the waypoint following dynamics of a quaternion error feedback control law for downsample-and-hold. It is shown that downsample-and-hold induces a ripple between downsamples that causes the satellite angular rate to significantly overshoot the desired limit. Analysis in the z-domain is carried out in order to understand the phenomenon. An interpolating Chebyshev-type filter is proposed that allows attitude commands to be encoded in terms of a small set of filter coefficients. Using the interpolating filter, commands can be issued at the ACS rate but with significantly reduced memory requirements. The attitude control system of NASA’s Lunar Reconnaissance Orbiter is used as an example to illustrate the behavior of a practical attitude control system.

Mark Karpenko↗
NASA NTRS2017

Sharing Telemetry across Organizations and Systems

The XTCE (XML Telemetric and Command Exchange) standard provides a way to describe space mission telemetry and command “databases” (or dictionaries) to be exchanged across centers and space agencies. Having a standard format for describing the telemetry and command formats allows for the development or adoption of compatible tools and significantly reduces the amount of custom software development often needed to ensure all system components have access to consistent format definitions. The main objective of this paper is to show how powerful XTCE is in terms of interoperability across organizations. This paper summarizes work which entailed converting the mission telemetry database for a current NASA mission, in XTCE format, into several target mission operation databases associated with different telemetry and command toolchains, and then, comparing the results of the telemetry processing and display. The target toolchains selected were Ball Aerospace/COSMOS, NASA-GSFC/ITOS (Goddard Space Flight Center/Integrated Test and Operations System), and NASA-AMMOS/AMPCS (Advanced Multi-Mission Operations System/Mission Data Processing and Control System) – all real-time telemetry and command processing systems.

Jones, Ron↗
NASA NTRS2022

Europa Clipper Payload Verification and Validation: Avionics-Instrument Interface Test Campaign

NASA's Europa Clipper mission will investigate Jupiter's icy moon Europa using a payload suite consisting of nine instruments to address a range of scientific objectives concerning Europa's habitability. As the project proceeds past its Critical Design Review, confidence is being built in the system's ability to achieve mission objectives through the implementation of a rigorous payload verification and validation (V&V) program. As part of this payload V&V program, instrument box-level testing was performed by the payload team to verify select instrument-avionics interface requirements. This testing was performed at JPL using the avionics testbed's Bulk Data Storage Emulator (BDSEM) with visiting instrument Test Models. This paper summarizes the Data Link test campaign involving roughly four days of functional testing per instrument, including planning, testing methods, types of issues found, and the requirement closure process. Detail is also provided on the development, deployment, and validation of a standardized analysis tool used in data reviews. This testing verified requirements related to commanding rates, loss of link, packet format, clock counters, loopback test capability, and SpaceWire jitter and skew margins. Additional risk reduction testing of basic commanding, counter behavior, science data collection and transfer, and interface swapping was also performed. Because the BDSEM venue was not originally designed to be a run for record venue, the process of characterizing venue fidelity and establishing suitability for requirement closure using data collected in this venue will also be addressed.In order to close requirements, an extensible tool was developed to post-process instrument command and telemetry data from their original binary to a human-readable format and give visibility to errors detected within the data, such as packets with Cyclic Redundancy Check errors. This tool, called payload-packet-parser, is a Python 3.9 command line tool built using a variety of open-source Python libraries. Payload-packet-parser was designed to support parsing command and telemetry packets for all Europa Clipper instruments and additional analysis tools were developed for verification of specific information interface requirements. This test campaign, including post-processing using a single parsing and verification toolset, allowed for early interface testing, alleviating testing burdens on instrument teams and buying down risk on the instrument-avionics interface by finding hardware and software issues and idiosyncrasies prior to integration with system test venues. Over twenty issues were discovered across the payload, resulting in software updates and instrument rework well in advance of any system impacts. This paper concludes with an assessment of benefits and costs of this type of testing and lessons learned.

Montanez, Leticia↗
NASA NTRSDate not supplied

Astrobee Operations on the Iss: Gui’S Impact on the Operators’ Cognitive Load

The Astrobee free-flying robots have completed their fifth successful year of operations housed in the Japanese Experimental Module (JEM) on the International Space Station (ISS). In this paper, we introduce two Graphical User Interfaces (GUI) used to operate and monitor in real-time the Astrobee free-flying robots onboard the ISS and report on the impact these GUIs have in the operator’s cognitive load. A review of the state-of-the-art GUI design for remotely teleoperated scenarios with minimal time delay is presented and the study’s conclusion used to determine the elements and recommendations to create an interface that minimizes its impact on the overall performance of an operator during an activity at the ISS. The Ground Data System (GDS) is one of the two GUIs in the study: it contains several tabs, each of which displays a different set of controls for specific tasks e.g. Overview, Run Plan, Teleoperate, Guest Science; some also display video and a three-dimensional (3D) representation of the ISS and robot based on the Astrobee’s telemetry. Most tabs enable a single operator-robot connection, however some of its tabs are capable to monitor and control up to three Astrobees simultaneously. The GDS Helper is a text-based user interface created to facilitate commanding and monitoring of an Astrobee robot directly from an SSH session. In full interactive mode it displays a maximum of 5 sections: general commanding, feedback/ack, telemetry, guest science commanding, and data, all in one view. In batch mode, it enables complex command scripting while retaining some interactive capabilities. A comparative analysis between these GUIs is carried out at an analogous ISS environment at the NASA Ames Research Center’s Granite Lab and its results presented. While GDS is able to provide an operator with control and situational awareness via its video and 3D displays, its several tabs may introduce an overwhelming amount of information confusing and delaying the operator especially during time-sensitive maneuvers where the operator may need to switch back and forth between them. GDS helper in the other hand does not provide video or 3D displays thus not allowing an operator to attain situational awareness, however it provides the operator with a design displaying commonly used data in a single window, enabling the operator to understand the state of the robot at a glance and control it through a commands entered via keyboard instead of a combination of mouse clicks and keyboard input. The results of the experiments measure the cognitive load across several operators maneuvering Astrobee to accomplish tasks ranging from fully manual to supervised activities. A GUI combining a single window displaying data along video and a 3D display is expected to reduce the operator’s cognitive load.

Astrobee↗
DOE OSTI2022

Technologies for providing secure emergency power control of high voltage direct current transmission system

Technologies for providing secure emergency power control of a high voltage direct current transmission (HVDC) system include a controller. The controller includes circuitry configured to receive status data indicative of a present physical status of a power system. The circuitry is also configured to obtain an emergency power control command triggered by a remote source. The emergency power control command is to be executed by an HVDC transmission system of the power system. Further, the circuitry is configured to determine, as a function of the status data, whether the emergency power control command is consistent with the present physical status of the power system and block, in response to a determination that the emergency power control command is not consistent with the present physical status of the power system, execution of the emergency power control command by the HVDC transmission system.

Pan, Jiuping↗
DOE OSTI2023

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 ↗
NASA NTRS2012

Improving operations: Metrics to Results

As a result of the mission failure of the Mars Climate Orbiter (MCO) spacecraft in 1999, the Jet Propulsion Laboratory (JPL) initiated the development of a Mission Operations Assurance (MOA) program to be implemented across all flight projects managed by JPL. One of the initiatives undertaken in 2001 was the collection of data on command file errors occurring in the operational phase of the mission. This paper defines command file errors and how and where they occur in the operations process. It also describes the problem reporting system (PRS) in use for mission operations at JPL. We examine the recent modifications to the PRS that enable the collection of metrics, specifically on command file errors. This paper discusses what the data show us since metrics have been collected for the operational missions conducted by JPL. We examine the evolution of an operational working group initiative to evaluate proximate, contributing, and root causes for the errors. As part of this discussion we see what the metrics have indicated over a decade. At the macro level, we can say that the aggregate command file error rate has been cut to roughly one third of the initial 2001 level by the end of 2011. Additionally, we explore efficient and innovative means to continually integrate the findings and recommendations from the working group back into the flight operations environment.

command file errors↗
DOE OSTI2020

Decentralized Control of Cascaded H-Bridge Inverters for Medium-Voltage Grid Integration: Preprint

This paper introduces a fully decentralized control strategy that allows for individualized active and reactive power control of H-bridge inverters connected in series. After formulating a model of the system power flows, we outline a communications-free approach where each inverter can act on independent commands. Inverter-level feedback is accomplished locally via a measurement of current flowing through the stack. A key feature is the lack of any centralized control routines or phase-locked loop. In this framework, the reactive power control loops achieve voltage synchronization among the converters and the grid, and the active power control loops modulate the terminal voltage amplitudes that influence power delivery. Furthermore, pole placement via state feedback is used to ensure stability of voltage synchronization while also enabling tracking of bidirectional power commands. Simulations are presented to validate the proposed approach.

communication-free modular converter control↗
DOE OSTI2022

Mooring Load Monitoring of a Wave Energy Converter Using a Self-Synchronizing Underwater Acoustic Network

A self-synchronizing underwater acoustic network, designed for remote monitoring of mooring loads in Wave Energy Converters (WEC), has been developed and tested. This network uses Time Division Multiple Access and operates self-contained with the ability for users to remotely transmit commands to the network as needed. Each node is a self-contained unit, consisting of a protocol adaptor board, an underwater acoustic modem and a battery pack. A node can be connected to a load cell, to a topside user or to the WEC. Every node is swapable. The protocol adaptor board, named Protocol Adaptor for Digital LOad Cell (PADLOC) supports a variety of digital load cell message formats (CAN, MODBUS, custom ASCII) and underwater acoustic modem serial formats. PADLOC enables topside users to connect to separate load cells through a user-specific command.

acoustic↗
DOE OSTI2023

AI & Physics-Based Bad Command/Data Detection in Large Power Electronics Systems: Multi-Port Autonomous Reconfigurable Solar Power Plant (MARS)

Detection of bad data from measurement sensors and bad commands from control centers need to be carried out to avoid instabilities within large power electronics systems. Towards the same, in this paper, model and data driven methods are proposed to identify anomalies in measured data and commands received by large power electronics systems. The large power electronics system considered in this paper is a multi-port autonomous reconfigurable solar power plant (MARS), which consists of photovoltaic (PV) and energy storage systems (ESSs) that connect to high-voltage direct current (HVdc) system and transmission ac power grid. The proposed algorithms in the MARS power plant to detect bad data from measurements and bad commands from control centers are evaluated in simulations and hardware-in-the-loop (HIL) tests. Furthermore, it has been observed that the proposed algorithms are able to detect bad measurements and commands in all the use cases evaluated.

14 SOLAR ENERGY↗
DOE OSTI2025

User-based I/O Profiling for Leadership Scale HPC Workloads

I/O constitutes a significant portion of most of the application run-time. Spawning many such applications concurrently on an HPC system leads to severe I/O contention. Thus, understanding and subsequently reducing I/O contention induced by such multi-tenancy is critical for the efficient and reliable performance of the HPC system. In this study, we demonstrate that an application’s performance is influenced by the command line arguments passed to the job submission. We model an application’s I/O behavior based on two factors: past I/O behavior within a time window and user-configured I/O settings via command-line arguments. We conclude that I/O patterns for well-known HPC applications like E3SM and LAMMP are predictable, with an average uncertainty below 0.25 (A probability of 80%) and near zero (A probability of 100%) within a day. However, I/O pattern variance increases as the study time window lengthens. Additionally, we show that for 38 users and at least 50 applications constituting approximately 93000 job submissions, there is a high correlation between a submitted command line and the past command lines made within 1 to 10 days submitted by the user. We claim the length of this time window is unique per user.

Yazdani, Ahmad Hossein [Virginia Tech, Blacksburg]↗
DOE OSTI2024

Nodeman: A Node Management Tool For Hpc Clusters

NodeMan is a command line tool to manage nodes in an HPC cluster. At it's core, it is an extensible framework composed of bash scripting and GNU parallel. HPC System Administrator will find it useful in that it encapsulates desired functions and allows them to be assembled in a way familiar to administrators - through pipes. In fact, NodeMan functions can work with common command line tools as long as they use stdin/stdout. System Administrators can construct moderately complex logic and filtering on a compact command line that would normally require a substantial shell script. In the spirit of clush and pdsh, it is able to run commands remotely on nodes. Additionally, NodeMan is more flexible. For example, it can interact with IPMI and naturally processes node lists for orchestrating different tools. The library of useful pre-built functions is growing. System administrators can easily create new functions and make it their own.

Serr, ScottM↗