Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “command and control”

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 523 records · Page 29

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↗

Ada software productivity prototypes: A case study

A case study of the impact of Ada on a Command and Control project completed at the Jet Propulsion Laboratory (JPL) is given. The data for this study was collected as part of a general survey of software costs and productivity at JPL and other NASA sites. The task analyzed is a successful example of the use of rapid prototyping as applied to command and control for the U.S. Air Force and provides the U.S. Air Force Military Airlift Command with the ability to track aircraft, air crews and payloads worldwide. The task consists of a replicated database at several globally distributed sites. The local databases at each site can be updated within seconds after changes are entered at any one site. The system must be able to handle up to 400,000 activities per day. There are currently seven sites, each with a local area network of computers and a variety of user displays; the local area networks are tied together into a single wide area network. Using data obtained for eight modules, totaling approximately 500,000 source lines of code, researchers analyze the differences in productivities between subtasks. Factors considered are percentage of Ada used in coding, years of programmer experience, and the use of Ada tools and modern programming practices. The principle findings are the following. Productivity is very sensitive to programmer experience. The use of Ada software tools and the use of modern programming practices are important; without such use Ada is just a large complex language which can cause productivity to decrease. The impact of Ada on development effort phases is consistent with earlier reports at the project level but not at the module level.

Hihn, Jairus M.↗

Drag-Free Control and Drag Force Recovery of Small Satellites

Drag-free satellites provide autonomous precision orbit determination, accurately map the static and time varying components of Earth's mass distribution, aid in our understanding of the fundamental force of gravity, and will ultimately open up a new window to our universe through the detection and observation of gravitational waves. At the heart of this technology is a gravitational reference sensor, which (a) contains and shields a free-floating proof mass from all non-gravitational forces, and (b) precisely measures the position of the test mass inside the sensor. Thus, both test mass and spacecraft follow a pure geodesic in spacetime. By tracking the position of a low Earth orbiting drag-free satellite we can directly determine the detailed shape of geodesics and through analysis, the higher order harmonics of the Earths geopotential. This paper explores two different drag-free control systems on small satellites. The first drag-free control system is a continuously compensated single thruster 3-unit CubeSat with a suspension-free spherical proof-mass. A feedback control system commands the thruster and Attitude and Determination Control System to fly the tender spacecraft with respect to the test mass. The spheres position is sensed with a LED-based differential optical shadow sensor, its electric charge controlled by photoemission using UV LEDs, and the spacecraft position is maintained with respect to the sphere using an ion electrospray propulsion system. This configuration is the most fuel-efficient drag-free system possible today. The second drag-free control system is an electro-statically suspended cubical proof-mass that is operated with a low duty cycle, limiting suspension force noise over brief, known time intervals on a small GRACE-II -like satellite. The readout is performed using a laser interferometer, which is immune to the dynamic range limitations of voltage references. This system eliminates the need for a thruster, enabling drag-free control systems for passive satellites. In both cases, the test mass position, GPS tracking data, and commanded actuation, either thrust or suspension system, can be analyzed to estimate the 3-axis drag forces acting on the satellite. The data produces the most precise maps of upper atmospheric drag forces and with additional information, detailed models that describe the dynamics of the upper atmosphere and its impact on all satellites that orbit the Earth. This paper highlights the history, applications, design, laboratory technology development and highly detailed simulation results of each control system.

Small Satellites↗

XML in an Adaptive Framework for Instrument Control

NASA Goddard Space Flight Center is developing an extensible framework for instrument command and control, known as Instrument Remote Control (IRC), that combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML). A key aspect of the architecture is software that is driven by an instrument description, written using the Instrument Markup Language (IML). IML is an XML dialect used to describe interfaces to control and monitor the instrument, command sets and command formats, data streams, communication mechanisms, and data processing algorithms.

Ames, Troy J.↗

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗

Experimental results with a six-degree-of-freedom force-reflecting hand controller

Control experiments performed using an isotonic joystick connected to a six degree-of-freedom manipulator equipped with a six dimensional force-torque sensor at the base of the manipulator end effector are described. The preliminary control experiments were aimed at the investigation of the human operators' ability to command and control forces in different directions by varying the information conditions and the values of the feedforward and feedback command gains in the bilateral control loop. The main conclusions are: (1) a quantified graphic display of force-torque information can considerably enhance the operator's ability to perform a quantitatively sharp force-torque control, and (2) there seems to be a task dependent optimal combination of the feedforward and feedback command gain values which provide a dynamically smooth and stable bilateral control performance.

Bejczy, A. K.↗

Phoenix Mars Scout UHF Relay-Only Operations

The Phoenix Mars Scout Lander will launch in August 2007 and land on the northern plains of Mars in May of 2008. In a departure from traditional planetary surface mission operations, it will have no direct-to-Earth communications capability and will rely entirely on Mars-orbiting relays in order to facilitate command and control as well as the return of science and engineering data. The Mars Exploration Rover missions have demonstrated the robust data-return capability using this architecture, and also have demonstrated the capability of using this method for command and control. The Phoenix mission will take the next step and incorporate this as the sole communications link. Operations for 90 Sols will need to work within the constraints of Odyssey and Mars Reconnaissance Orbiter communications availability, anomalies must be diagnosed and responded to through an intermediary and on-board fault responses must be tolerant to loss of a relay. These and other issues pose interesting challenges and changes in paradigm for traditional space operations and spacecraft architecture, and the approach proposed for the Phoenix mission is detailed herein.

fault protection↗

Real-Time Adaptive Control Allocation Applied to a High Performance Aircraft

Abstract This paper presents the development and application of one approach to the control of aircraft with large numbers of control effectors. This approach, referred to as real-time adaptive control allocation, combines a nonlinear method for control allocation with actuator failure detection and isolation. The control allocator maps moment (or angular acceleration) commands into physical control effector commands as functions of individual control effectiveness and availability. The actuator failure detection and isolation algorithm is a model-based approach that uses models of the actuators to predict actuator behavior and an adaptive decision threshold to achieve acceptable false alarm/missed detection rates. This integrated approach provides control reconfiguration when an aircraft is subjected to actuator failure, thereby improving maneuverability and survivability of the degraded aircraft. This method is demonstrated on a next generation military aircraft Lockheed-Martin Innovative Control Effector) simulation that has been modified to include a novel nonlinear fluid flow control control effector based on passive porosity. Desktop and real-time piloted simulation results demonstrate the performance of this integrated adaptive control allocation approach.

Davidson, John B.↗

Mission Operations Centers (MOCs): Integrating key spacecraft ground data system components

In an environment characterized by decreasing budgets, limited system development time, and user needs for increased capabilities, the Mission Operations Division (MOD) at the National Aeronautics and Space Administration Goddard Space Flight Center initiated a new, cost-effective concept in developing its spacecraft ground data systems: the Mission Operations Center (MOC). In the MOC approach, key components are integrated into a comprehensive and cohesive spacecraft planning, monitoring, command, and control system with a single, state-of-the-art graphical user interface. The MOD is currently implementing MOC's, which feature a common, reusable, and extendable system architecture, to support the X-Ray Timing Explorer (XTE), Tropical Rainfall Measuring Mission (TRMM), and Advanced Composition Explorer (ACE) missions. As a result of the MOC approach, mission operations are integrated, and users can, with a single system, perform real-time health and safety monitoring, real-time command and control, real-time attitude processing, real-time and predictive graphical spacecraft monitoring, trend analysis, mission planning and scheduling, command generation and management, network scheduling, guide star selection, and (using an expert system) spacecraft monitoring and fault isolation. The MOD is also implementing its test and training simulators under the new MOC management structure. This paper describes the MOC concept, the management approaches used in developing MOC systems, the technologies employed and the development process improvement initiatives applied in implementing MOC systems, and the expected benefits to both the user and the mission project in using the MOC approach.

Harbaugh, Randy↗

OpenPET Hardware, Firmware, Software, and Board Design Files

OpenPET is an open source, flexible, high-performance, and modular data acquisition system for a variety of applications. The OpenPET electronics are capable of reading analog voltage or current signals from a wide variety of sensors. The electronics boards make extensive use of field programmable gate arrays (FPGAs) to provide flexibility and scalability. Firmware and software for the FPGAs and computer are used to control and acquire data from the system. The command and control flow is similar to the data flow, however, the commands are initiated from the computer similar to a tree topology (i.e., from top-to-bottom). Each node in the tree discovers its parent and children, and all addresses are configured accordingly. A user (or a script) initiates a command from the computer. This command will be translated and encoded to the corresponding child (e.g., SB, MB, DB, etc.). Consecutively, each node will pass the command to its corresponding child(ren) by looking at the destination address. Finally, once the command reaches its desired destination(s) the corresponding node(s) execute(s) the command and send(s) a reply, if required. All the firmware, software, and the electronics board design files are distributed through the OpenPET website (http://openpet.lbl.gov).

Abu-Nimeh, Faisal↗

Spaceport Support

Command and Control Technologies (CCT) Corporation of Titusville, Florida, a Florida/NASA Business Incubator tenant, is commercializing technology based on Kennedy Space Center's (KSC's) spacecraft ground processing program known as the Control Monitor Unit (CMU). The CMU was developed by engineers with NASA and McDonnell Douglas Space & Defense Systems at KSC to prepare the International Space Station elements for launch. CCT is significantly expanding the commercial capability of the product, called the Command and Control Toolkit(TM) (CCTK), according to Kevin Brown, CCT vice president for business development. In fact, CCT is the only U.S. firm specializing in launch vehicle control systems design and development for spaceports and new launch vehicle programs.

Source record↗

Small Unmanned Aircraft Electromagnetic Interference (EMI) Initial Assessment

With many applications envisioned for small Unmanned Aircraft Systems (sUAS), and potentially millions of sUAS expected to be in operation in the future, the electromagnetic interference environment associated with the sUAS is of interest to understanding the potential performance impacts on the sUAS command and control communications link as well as the sUAS payload and payload links. As part of NASA's UAS Traffic Management (UTM) Project, flight experiments are planned to characterize the RF environment at altitudes up to 400 ft to better understand how UTM command and control links can be expected to perform. The flight experiments will use an RF channel sensing payload attached to an sUAS. In terms of the payload being capable of measuring relatively low level signals at altitude, electromagnetic interference (EMI) emanating from the sUAS vehicle itself could potentially complicate the measurement process. For this reason, NASA was interested in measuring the EMI performance of the sUAS planned for these flight experiments, a DJI model S1000. The S1000 was thus measured in a controlled EMI test chamber at the NASA Ames Research Center. The S1000 is a carbon fiber based platform with eight rotors. As such, the EMI test results represent potential performance of a number of similar sUAS types. sUAS platforms significantly different from the S1000 may also require EMI testing, and the method employed for NASA's S1000 EMI tests can be applied to other platforms. In this paper we describe the UTM project, the RF channel sensing payload, the EMI testing method and EMI test results for the S1000, and discuss the implications of these results.

Unmanned aircraft↗

Small Unmanned Aircraft Electromagnetic Interference (EMI) Initial Assessment

With many applications envisioned for small Unmanned Aircraft Systems (sUAS), and potentially millions of sUAS expected to be in operation in the future, the electromagnetic interference environment associated with the sUAS is of interest to understanding the potential performance impacts on the sUAS command and control communications link as well as the sUAS payload and payload links. As part of NASAâ€"TM"s UAS Traffic Management (UTM) Project, flight experiments are planned to characterize the RF environment at altitudes up to 400 ft to better understand how UTM command and control links can be expected to perform. The flight experiments will use an RF channel sensing payload attached to an sUAS. In terms of the payload being capable of measuring relatively low level signals at altitude, electromagnetic interference (EMI) emanating from the sUAS vehicle itself could potentially complicate the measurement process. For this reason, NASA was interested in measuring the EMI performance of the sUAS planned for these flight experiments, a DJI model S1000. The S1000 was thus measured in a controlled EMI test chamber at the NASA Ames Research Center. The S1000 is a carbon fiber based platform with eight rotors. As such, the EMI test results represent potential performance of a number of similar sUAS types. sUAS platforms significantly different from the S1000 may also require EMI testing, and the method employed for NASAâ€"TM"s S1000 EMI tests can be applied to other platforms. In this paper we describe the UTM project, the RF channel sensing payload, the EMI testing method and EMI test results for the S1000, and discuss the implications of these results.

traffic management↗

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile↗

Flair-fleet location and information reporting

The FLAIR system, as now produced, automatically updates each vehicle's location and corresponding officer's status once each two seconds and presents this information to police dispatchers in the command and control center. The position of all vehicles available for assignment is displayed on a color video map at each dispatcher's console to an accuracy of 50 feet. This gives the dispatcher a continuous picture of the deployment of the total available force and thus complete command and control of all police under his responsibility.

Norman, E. R.↗

Space Internet-Embedded Web Technologies Demonstration

The NASA Glenn Research Center recently demonstrated the ability to securely command and control space-based assets by using the Internet and standard Internet Protocols (IP). This is a significant accomplishment because future NASA missions will benefit by using Internet standards-based protocols. The benefits include reduced mission costs and increased mission efficiency. The Internet-Based Space Command and Control System Architecture demonstrated at the NASA Inspection 2000 event proved that this communications architecture is viable for future NASA missions.

Foltz, David A.↗

Autonomous Sciencecraft Experiment (ASE) Test Operations in 2003

NASA has identified the development of an autonomously operating spacecraft as a necessity for an expanded program of missions exploring the Solar System. The Autonomous Sciencecraft Experiment (ASE) has been selected for flight demonstration by NASA s New Millennium Program (NMP) as part of the Space Technology 6 (ST6) mission. ASE is scheduled to fly on the US Air Force Research Laboratory (AFRL) Techsat-21 constellation in 2006. Tech- Sat-21 consists of three satellites flying in a variable-geometry formation in Earth orbit. Each satellite is equipped with X-band Synthetic Aperture Radar, yielding high spatial resolution images (approx. 3 m) of the Earth s surface. The constellation will fly at an altitude of 550 km, in a 35.4 inclination circular orbit, yielding exact repeat-track observations every 13 days. Prior to full deployment, elements of the versatile ASE spacecraft command and control software, image formation software and science processing software will be utilized and tested on two very different platforms in 2003: AirSAR and EO-1 (described below). Advantages of Autonomous Operations: ASE will demonstrate advanced autonomous science data acquisition, processing, and product downlink prioritization, as well as autonomous spacecraft command and control, and fault detection. The advantages of spacecraft autonomy are to future missions include: (a) making the best use of reduced downlink; (b) the overcoming of communication delays through decisionmaking in situ, enabling fast reaction to dynamic events; (c) an increase of science content per byte of returned data; and (d) an avoidance of return of null (no-change/no feature) datasets: if there is no change detectable between two scenes of the same target, there is no need to return the second dataset.

Chien, S.↗

The NASA Spacecraft Transponding Modem

A new deep space transponder is being developed by the Jet Propulsion Laboratory for NASA. The Spacecraft Transponding Modem (STM) implements the standard transponder functions and the channel service functions that have previously resided in spacecraft Command/Data Subsystems. The STM uses custom ASICs, MMICs, and MCMs to reduce the active device parts count to 70, mass to I kg, and volume to 524 cc. The first STMs will be flown on missions launching in the 2003 time frame. The STM tracks an X-band uplink signal and provides both X-band and Ka-band downlinks, either coherent or non-coherent with the uplink. A NASA standard Command Detector Unit is integrated into the STM, along with a codeblock processor and a hardware command decoder. The decoded command codeblocks are output to the spacecraft command/data subsystem. Virtual Channel 0 (VC-0) (hardware) commands are processed and output as critical controller (CRC) commands. Downlink telemetry is received from the spacecraft data subsystem as telemetry frames. The STM provides the following downlink coding options: the standard CCSDS (7-1/2) convolutional coding, ReedSolomon coding with interleave depths one and five, (15-1/6) convolutional coding, and Turbo coding with rates 1/3 and 1/6. The downlink symbol rates can be linearly ramped to match the G/T curve of the receiving station, providing up to a 1 dB increase in data return. Data rates range from 5 bits per second (bps) to 24 Mbps, with three modulation modes provided: modulated subcarrier (3 different frequencies provided), biphase-L modulated direct on carrier, and Offset QPSK. Also, the capability to generate one of four non-harmonically related telemetry beacon tones is provided, to allow for a simple spacecraft status monitoring scheme for cruise phases of missions. Three ranging modes are provided: standard turn around ranging, regenerative pseudo-noise (PN) ranging, and Differential One-way Ranging (DOR) tones. The regenerative ranging provides the capability of increasing the ground received ranging SNR by up to 30 dB. Two different avionics interfaces to the command/data subsystem's data bus are provided: a MIL STD 1553B bus or an industry standard PCI interface. Digital interfaces provide the capability to control antenna selection (e.g., switching between high gain and low gain antennas) and antenna pointing (for future steered Ka-band antennas).

Berner, Jeff B.↗