Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “COMMAND SYSTEM”

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 1,441 records · Page 80
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

Humanoid Robotics: Real-Time Object Oriented Programming

Programming of robots in today's world is often done in a procedural oriented fashion, where object oriented programming is not incorporated. In order to keep a robust architecture allowing for easy expansion of capabilities and a truly modular design, object oriented programming is required. However, concepts in object oriented programming are not typically applied to a real time environment. The Fujitsu HOAP-2 is the test bed for the development of a humanoid robot framework abstracting control of the robot into simple logical commands in a real time robotic system while allowing full access to all sensory data. In addition to interfacing between the motor and sensory systems, this paper discusses the software which operates multiple independently developed control systems simultaneously and the safety measures which keep the humanoid from damaging itself and its environment while running these systems. The use of this software decreases development time and costs and allows changes to be made while keeping results safe and predictable.

Newton, Jason E.↗
NASA NTRS2001

Autonomy technology at JPL

This paper and exhibit describes the on-going research activities, plans and products of the Autonomy Technology program at NASA Jet Propulsion Laboratory. In this paper, we briefly describe the areas of Mission Planning and Execution, Distributed Autonomous Systems, Science Data Understanding, and Autonomous Guidance and Control.

autonomous rovers distributed systems planning con↗
NASA NTRS2016

AAtS over AeroMACS Technology Trials on the Airport Surface

Air-Ground component of SWIM; Enables enhanced two-way information exchanges between flight operators, aircrew, and ATSP (TFM); Used in all flight domains including pre-departure and post-arrival; Aircrew active in CDM; For strategic planning, advisory information; Not for command control (data voice) Wireless communications system for airport surface; Family member of Mobile WiMAX: (IEEE802.16e), Band 5091-5150 MHz, Bandwidth 5 MHz - TDDOFDMA - Adaptive Modulation and Coding - Quality of Service (QoS)

Wireless Communications↗
NASA NTRS2019

Using XTCE on the GOES-R Series

This presentation provides an overview of the mechanisms and methods used to implement the XTCE (XML (eXtensible Markup Language) Telemetric and Command Exchange format) schema for Telemetry and Command databases for the GOES-R series satellites.

GOES-R↗
NASA NTRS2019

Goddard Modular SmallSat Architecture (GMSA) Hardware Presentation

In today's rapidly advancing technology roadmap for space applications there is an emphasis on completing missions faster and cheaper than previous large-scale missions at the National Aeronautics and Space Administration (NASA) such as the Magnetospheric Multiscale (MMS) mission. As part of this effort, focus has shifted from using mostly radiation-tolerant or radiation-hardened parts to more commercial-off-the-shelf (COTS) components for missions that can last at least one year in orbit. However, there are some portions of a spacecraft's avionics, such as the command and data handling (C&DH) system and the Electrical Power Systems (EPS) that need to have some level of predictable reliability that goes beyond the capabilities of currently available COTS parts. While there are a number of COTS components that can withstand a total ionizing dose (TID) of tens or hundreds of kilorads, there is still a great deal of concern about tolerance to and mitigation of single-event effects (SEE).

Fraction, James↗
NASA NTRS2021

Assessment of Biocide Impacts on Life Support (LS) and Extravehicular Activity (EVA) Architectures

The Project Manager for the Human Exploration and Operations Mission Directorate’s Advanced Exploration Systems Life Support Systems (LSS) project, requested a NASA Engineering and Safety Center (NESC) assessment to evaluate potable water system biocide options impacting Gateway, Human Lander Systems, Foundation Surface Habitat, and Exploration Command Module missions. The assessment focused on identifying feasible biocide options, evaluating the impacts of their implementation on crew health, extravehicular activity hardware, and LSS hardware, and conducting a trade on architecture options. This report contains the outcome of the NESC assessment.

Extravehicular Activity; Life Support; NASA Engine↗
NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗
NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗
DOE OSTI2012

Apparatus and method for modifying the operation of a robotic vehicle in a real environment, to emulate the operation of the robotic vehicle operating in a mixed reality environment

Apparatus and methods for modifying the operation of a robotic vehicle in a real environment to emulate the operation of the robotic vehicle in a mixed reality environment include a vehicle sensing system having a communications module attached to the robotic vehicle for communicating operating parameters related to the robotic vehicle in a real environment to a simulation controller for simulating the operation of the robotic vehicle in a mixed (live, virtual and constructive) environment wherein the affects of virtual and constructive entities on the operation of the robotic vehicle (and vice versa) are simulated. These effects are communicated to the vehicle sensing system which generates a modified control command for the robotic vehicle including the effects of virtual and constructive entities, causing the robot in the real environment to behave as if virtual and constructive entities existed in the real environment.

42 ENGINEERING↗
NASA NTRS2014

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

HALE UAS Command and Control Communications: Step 1 - Functional Requirements Document. Version 4.0

The High Altitude Long Endurance (HALE) unmanned aircraft system (UAS) communicates with an off-board pilot-in-command in all flight phases via the C2 data link, making it a critical component for the UA to fly in the NAS safely and routinely. This is a new requirement in current FAA communications planning and monitoring processes. This document provides a set of comprehensive C2 communications functional requirements and performance guidelines to help facilitate the future FAA certification process for civil UAS to operate in the NAS. The objective of the guidelines is to provide the ability to validate the functional requirements and in future be used to develop performance-level requirements.

Source record↗
NASA NTRS2008

Automatic Testcase Generation for Flight Software

The TacSat3 project is applying Integrated Systems Health Management (ISHM) technologies to an Air Force spacecraft for operational evaluation in space. The experiment will demonstrate the effectiveness and cost of ISHM and vehicle systems management (VSM) technologies through onboard operation for extended periods. We present two approaches to automatic testcase generation for ISHM: 1) A blackbox approach that views the system as a blackbox, and uses a grammar-based specification of the system's inputs to automatically generate *all* inputs that satisfy the specifications (up to prespecified limits); these inputs are then used to exercise the system. 2) A whitebox approach that performs analysis and testcase generation directly on a representation of the internal behaviour of the system under test. The enabling technologies for both these approaches are model checking and symbolic execution, as implemented in the Ames' Java PathFinder (JPF) tool suite. Model checking is an automated technique for software verification. Unlike simulation and testing which check only some of the system executions and therefore may miss errors, model checking exhaustively explores all possible executions. Symbolic execution evaluates programs with symbolic rather than concrete values and represents variable values as symbolic expressions. We are applying the blackbox approach to generating input scripts for the Spacecraft Command Language (SCL) from Interface and Control Systems. SCL is an embedded interpreter for controlling spacecraft systems. TacSat3 will be using SCL as the controller for its ISHM systems. We translated the SCL grammar into a program that outputs scripts conforming to the grammars. Running JPF on this program generates all legal input scripts up to a prespecified size. Script generation can also be targeted to specific parts of the grammar of interest to the developers. These scripts are then fed to the SCL Executive. ICS's in-house coverage tools will be run to measure code coverage. Because the scripts exercise all parts of the grammar, we expect them to provide high code coverage. This blackbox approach is suitable for systems for which we do not have access to the source code. We are applying whitebox test generation to the Spacecraft Health INference Engine (SHINE) that is part of the ISHM system. In TacSat3, SHINE will execute an on-board knowledge base for fault detection and diagnosis. SHINE converts its knowledge base into optimized C code which runs onboard TacSat3. SHINE can translate its rules into an intermediate representation (Java) suitable for analysis with JPF. JPF will analyze SHINE's Java output using symbolic execution, producing testcases that can provide either complete or directed coverage of the code. Automatically generated test suites can provide full code coverage and be quickly regenerated when code changes. Because our tools analyze executable code, they fully cover the delivered code, not just models of the code. This approach also provides a way to generate tests that exercise specific sections of code under specific preconditions. This capability gives us more focused testing of specific sections of code.

Bushnell, David Henry↗
NASA NTRS2018

Ground System Development at the Morehead State University for Interplanetary Smallsat Missions

As more small satellites are used for interplanetary research and exploration, more ground antennas with sufficiently large aperture are needed to support the increased demand in deep space communication. The 21-m ground antenna at the Morehead State University in Kentucky, United States is under development to upgrade its telemetry, tracking and command capability at X-band. The system architecture is based on a hybrid design that combines commercially available products with specialized equipment developed for the National Aeronautic and Aerospace Administration’s Deep Space Network. This architecture produces a low-cost and geographically diverse system, connecting elements at the Morehead State University and those of the DSN at the Jet Propulsion Laboratory in Pasadena, California. The architecture makes Morehead antenna appears as one of the DSN nodes, albeit with a different performance metrics due to difference in aperture size. Its operation is geared for automation, with automated data retrieval of information needed for configuring the ground station for spacecraft tracking. An incremental testing approach is used to verify system capabilities as various components are deployed into the system.

Kruth, Jeff↗
NASA NTRS1985

Expanding role for autonomy in military space

The Jet Propulsion Laboratory is currently transferring satellite on-board autonomy technology to the USAF for use in military spacecraft as a means of lowering the ground support requirements. The techniques were proven on the Viking and Voyager spacecraft and permitted on-board fault detection and correction. New military satellites will incorporate an autonomous redundancy and maintenance management subsystem in an on-board computer, while the system will still be subject to ground-based safing commands for situations demanding deeper analyses. A level 5 autonomy will need 256 kb memory, 10 Mb nonvolatile data storage and 50 W power and will weigh 20 kg. Systems will be periodically checked and compared with an ideal in the data base. Deviations detected will result in a rollback and redundant examination by two microprocessors, which can initiate correction commands until operational criteria are met. The development of the expert systems to the point that they satisfy military specifications is expected to take 10 yr.

Evans, D. D.↗
NASA NTRS2007

Noise-Canceling Helmet Audio System

A prototype helmet audio system has been developed to improve voice communication for the wearer in a noisy environment. The system was originally intended to be used in a space suit, wherein noise generated by airflow of the spacesuit life-support system can make it difficult for remote listeners to understand the astronaut s speech and can interfere with the astronaut s attempt to issue vocal commands to a voice-controlled robot. The system could be adapted to terrestrial use in helmets of protective suits that are typically worn in noisy settings: examples include biohazard, fire, rescue, and diving suits. The system (see figure) includes an array of microphones and small loudspeakers mounted at fixed positions in a helmet, amplifiers and signal-routing circuitry, and a commercial digital signal processor (DSP). Notwithstanding the fixed positions of the microphones and loudspeakers, the system can accommodate itself to any normal motion of the wearer s head within the helmet. The system operates in conjunction with a radio transceiver. An audio signal arriving via the transceiver intended to be heard by the wearer is adjusted in volume and otherwise conditioned and sent to the loudspeakers. The wearer s speech is collected by the microphones, the outputs of which are logically combined (phased) so as to form a microphone- array directional sensitivity pattern that discriminates in favor of sounds coming from vicinity of the wearer s mouth and against sounds coming from elsewhere. In the DSP, digitized samples of the microphone outputs are processed to filter out airflow noise and to eliminate feedback from the loudspeakers to the microphones. The resulting conditioned version of the wearer s speech signal is sent to the transceiver.

Seibert, Marc A.↗
NASA NTRS2007

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↗