Designed for Autonomy: Remote Agent for the New Millennium Program
This paper describes a new approach to spacecraft commanding and control, called the Remote Agent.
SEARCH · Engineering Papers
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.
This paper describes a new approach to spacecraft commanding and control, called the Remote Agent.
This paper describes the development and validation of a new methodology for assessing the deleterious effects of spaceflight on crew health and performance. It is well known that microgravity results in various physiological alterations, e.g., headward fluid shifts which can impede physiological adaptation. Other factors that may affect crew operational efficiency include disruption of sleep-wake cycles, high workload, isolation, confinement, stress and fatigue. From an operational perspective, it is difficult to predict which individuals will be most or least affected in this unique environment given that most astronauts are first-time flyers. During future lunar and Mars missions space crews will include both men and women of multi-national origins, different professional backgrounds, and various states of physical condition. Therefore, new methods or technologies are needed to monitor and predict astronaut performance and health, and to evaluate the effects of various countermeasures on crew during long duration missions. This paper reviews several studies conducted in both laboratory and operational environments with men and women ranging in age between 18 to 50 years. The studies included the following: soldiers performing command and control functions during mobile operations in enclosed armored vehicles; subjects participating in laboratory tests of an anti-motion sickness medication; subjects exposed to chronic hypergravity aboard a centrifuge, and subject responses to 36-hours of sleep deprivation. Physiological measurements, performance metrics, and subjective self-reports were collected in each study. The results demonstrate that multivariate converging indicators provide a significantly more reliable method for assessing environmental effects on performance and health than any single indicator.
The 2009 Mars Science Laboratory (MSL) will attempt the first precision landing on Mars using a modified version of the Apollo Earth entry guidance program. The guidance routine, Entry Terminal Point Controller (ETPC), commands the deployment of a supersonic parachute after converging the range to the landing target. For very dispersed cases, ETPC may not converge the range to the target and safely command parachute deployment within Mach number and dynamic pressure constraints. A full-lift up abort can save 85% of these failed trajectories while abandoning the precision landing objective. Though current MSL requirements do not call for an abort capability, an autonomous abort capability may be desired, for this mission or future Mars precision landers, to make the vehicle more robust. The application of artificial neural networks (NNs) as an abort determination technique was evaluated by personnel at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC). In order to implement an abort, a failed trajectory needs to be recognized in real time. Abort determination is dependent upon several trajectory parameters whose relationships to vehicle survival are not well understood, and yet the lander must be trained to recognize unsafe situations. Artificial neural networks (NNs) provide a way to model these parameters and can provide MSL with the artificial intelligence necessary to independently declare an abort. Using the 2009 Mars Science Laboratory (MSL) mission as a case study, a non-adaptive NN was designed, trained and tested using Monte Carlo simulations of MSL descent and incorporated into ETPC. Neural network theory, the development history of the MSL NN, and initial testing with severe dust storm entry trajectory cases are discussed in Reference 1 and will not be repeated here. That analysis demonstrated that NNs are capable of recognizing failed descent trajectories and can significantly increase the survivability of MSL for very dispersed cases. NN testing was then broadened to evaluate fully dispersed entry trajectories. The NN correctly classified 99.7% of descent trajectories as abort or nonabort and reduced the probability of an unsafe parachute deployment by 83%. This second, broader testing phase is discussed in this paper.
This paper describes the system engineering approach used to develop distributed multi-purpose simulations. The multi-purpose simulation architecture focuses on user needs, operations, flexibility, cost and maintenance. This approach was used to develop an International Space Station (ISS) simulator, which is called the International Space Station Integrated Simulation (ISIS)1. The ISIS runs unmodified ISS flight software, system models, and the astronaut command and control interface in an open system design that allows for rapid integration of multiple ISS models. The initial intent of ISIS was to provide a distributed system that allows access to ISS flight software and models for the creation, test, and validation of crew and ground controller procedures. This capability reduces the cost and scheduling issues associated with utilizing standalone simulators in fixed locations, and facilitates discovering unknowns and errors earlier in the development lifecycle. Since its inception, the flexible architecture of the ISIS has allowed its purpose to evolve to include ground operator system and display training, flight software modification testing, and as a realistic test bed for Exploration automation technology research and development.
NASA Goddard Space Flight Center's Space Science Mission Operations (SSMO) Project is currently tackling the challenge of minimizing ground operations costs for multiple satellites that have surpassed their prime mission phase and are well into extended mission. These missions are being reengineered into a multi-mission operations center built around modern information technologies and a common ground system infrastructure. The effort began with the integration of four SMEX missions into a similar architecture that provides command and control capabilities and demonstrates fleet automation and control concepts as a pathfinder for additional mission integrations. The reengineered ground system, called the Multi-Mission Operations Center (MMOC), is now undergoing a transformation to support other SSMO missions, which include SOHO, Wind, and ACE. This paper presents the automation principles and lessons learned to date for integrating automation into an existing operations environment for multiple satellites.
Aircraft altitude, ground velocity, and altitude rate signals are input to a computer which, using a unique control law, generates a pitch control surface command signal suitable for guiding an aircraft on its flare path to a specified runway touchdown point despite varying wind conditions.
A spacecraft attitude control system uses at least four reaction wheels. In order to minimize reaction wheel speed and therefore power, a wheel speed management system is provided. The management system monitors the wheel speeds and generates a wheel speed error vector. The error vector is integrated, and the error vector and its integral are combined to form a correction vector. The correction vector is summed with the attitude control torque command signals for driving the reaction wheels.
Adaptive model-based control systems and methods are described so that performance and/or operability of a gas turbine in an aircraft engine, power plant, marine propulsion, or industrial application can be optimized under normal, deteriorated, faulted, failed and/or damaged operation. First, a model of each relevant system or component is created, and the model is adapted to the engine. Then, if/when deterioration, a fault, a failure or some kind of damage to an engine component or system is detected, that information is input to the model-based control as changes to the model, constraints, objective function, or other control parameters. With all the information about the engine condition, and state and directives on the control goals in terms of an objective function and constraints, the control then solves an optimization so the optimal control action can be determined and taken. This model and control may be updated in real-time to account for engine-to-engine variation, deterioration, damage, faults and/or failures using optimal corrective control action command(s).
The Assembly and Contingency Radio Frequency Group (ACRFG) onboard the International Space Station (ISS) is used for command and control communications and transmits (45 dBm or 32 watts) and receives at S-band. The system is nominally pressurized with gaseous helium (He) and nitrogen (N2) at 8 pounds per square inch absolute (psia). MacDonald, Dettwiler and Associates Ltd. (MDA) was engaged to analyze the operational characteristics of this unit in an effort to determine if the anomalous behavior was a result of a corona event. Based on this analysis, MDA did not recommend continued use of this ACRFG. The NESC was requested to provide expert support in the area of high-voltage corona and multipactoring in an S-Band RF system and to assess the probability of corona occurring in the ACRFG during the planned EVA. The NESC recommended minimal continued use of S/N 002 ACRFG until a replacement unit can be installed. Following replacement, S/N 002 will be subjected to destructive failure analysis in an effort to determine the proximate and root cause(s) of the anomalous behavior.
The National Aeronautics and Space Administration (NASA) Constellation Program (CxP) has identified a series of tests to provide insight into the design and development of the Ares I Crew Launch Vehicle (CLV) and the Orion Crew Exploration Vehicle (CEV). Ares I-X was created as the first suborbital development flight test to help meet CxP objectives. The Ares I-X flight vehicle is an early operational model of Ares, with specific emphasis on Ares I and ground operation characteristics necessary to meet Ares I-X flight test objectives. Ares I-X will encompass the design and construction of an entire system that includes the Flight Test Vehicle (FTV) and associated operations. The FTV will be a test model based on the Ares I design. Select design features will be incorporated in the FTV design to emulate the operation of the CLV in order to meet the flight test objectives. The operations infrastructure and processes will be customized for Ares I-X, while still providing data to inform the developers of the launch processing system for Ares/Orion. The FTV is comprised of multiple elements and components that will be developed at different locations. The components will be delivered to the launch/assembly site, Kennedy Space Center (KSC), for assembly of the elements and components into an integrated, flight-ready, launch vehicle. The FTV will fly a prescribed trajectory in order to obtain the necessary data to meet the objectives. Ares I-X will not be commanded or controlled from the ground during flight, but the FTV will be equipped with telemetry systems, a data recording capability and a flight termination system (FTS). The in-flight part of the test includes a trajectory to simulate maximum dynamic pressure during flight and perform a stage separation representative of the CLV. The in-flight test also includes separation of the Upper Stage Simulator (USS) from the First Stage and recovery of the First Stage. The data retrieved from the flight test will be analyzed and used in the design and development of the Ares I vehicle. This paper will discuss the challenges in developing a new launch vehicle in a very short timeframe. The duration from formal Authority to Proceed to launch is 32 months with launch scheduled for April, 2009. The discussion will include changes to organizational structure, system engineering approaches, and early lessons learned for a fast tracked and highly visible project.
The airspace operations demonstration (AOD) is intended to show that the Access 5 Step 1 functional requirements can be met. The demonstration will occur in two phases. The initial on-range phase will be carried out in restricted airspace to demonstrate the cooperative collision avoidance (CCA) functional requirements and to provide risk-reduction for the AOD by allowing the test team to rehearse some elements of the demonstration mission. The CCA system to be used in these flights is based on Automatic Dependent Surveillance-Broadcast (ADS-B) which is a commercially-available system by which airplanes constantly broadcast their current position and altitude to other aircraft and ground resources over a dedicated radio datalink. The final phase will occur in the national airspace (NAS) and will be the formal demonstration of the remainder of the proposed functional requirements. The general objectives of the AOD are as follows: (1) Demonstrate that the UAS can aviate in the NAS (2) Demonstrate that the UAS can navigate in the NAS (3) Demonstrate that the UAS can communicate with the NAS (4) Demonstrate that the UAS can perform selected collision avoidance functions in the NAS (5) Demonstrate that the UAS can evaluate and avoid weather conflicts in the NAS (6) Demonstrate that the UAS can provide adequate command and control in the NAS In addition to the stated objectives, there are a number of goals for the flight demonstration. The demo can be accomplished successfully without achieving these goals, but these goals are to be used as a guideline for preparing for the mission. The goals are: (1) Mission duration of at least 24 hours (2) Loiter over heavy traffic to evaluate the data block issue identified during the Access 5 Airspace Operations Simulations (3) Document the contingency management process and lessons learned (4) Document the coordination process for Ground Control Stations (GCS) handoff (5) Document lessons learned regarding the process of flying in the NAS Preliminary planning for a notional mission to achieve the objectives and goals has been prepared. The planning is intended to serve as a guide for detailed planning of the AOD.
This document provides a study of the technical literature related to Command and Control (C2) link security for Unmanned Aircraft Systems (UAS) for operation in the National Airspace System (NAS). Included is a preliminary set of functional requirements for C2 link security.
This report documents the design of network infrastructure to support testing and demonstrating network-centric operations and command and control of space-based assets, using IPv6 and IPsec. These tests were performed using the Cisco router in Low Earth Orbit (CLEO), an experimental payload onboard the United Kingdom – Disaster Monitoring Constellation (UKDMC) satellite built and operated by Surrey Satellite Technology Ltd (SSTL). On Thursday, 29 March 2007, NASA Glenn Research Center, Cisco Systems and SSTL performed the first configuration and demonstration of IPsec and IPv6 onboard a satellite in low Earth orbit. IPv6 is the next generation of the Internet Protocol (IP), designed to improve on the popular IPv4 that built the Internet, while IPsec is the protocol used to secure communication across IP networks. This demonstration was made possible in part by NASA’s Earth Science Technology Office (ESTO) and shows that new commercial technologies such as mobile networking, IPv6 and IPsec can be used for commercial, military and government space applications. This has direct application to NASA’s Vision for Space Exploration. The success of CLEO has paved the way for new space-based Internet technologies, such as the planned Internet Routing In Space (IRIS) payload at geostationary orbit, which will be a U.S. Department of Defense Joint Capability Technology Demonstration. This is a sanitized report for public distribution. All real addressing has been change to psueco addressing.
This paper discusses human spaceflight fault management operations. Fault detection and response capabilities available in current US human spaceflight programs Space Shuttle and International Space Station are described while emphasizing system design impacts on operational techniques and constraints. Preflight and inflight processes along with products used to anticipate, mitigate and respond to failures are introduced. Examples of operational products used to support failure responses are presented. Possible improvements in the state of the art, as well as prioritization and success criteria for their implementation are proposed. This paper describes how the architecture of a command and control system impacts operations in areas such as the required fault response times, automated vs. manual fault responses, use of workarounds, etc. The architecture includes the use of redundancy at the system and software function level, software capabilities, use of intelligent or autonomous systems, number and severity of software defects, etc. This in turn drives which Caution and Warning (C&W) events should be annunciated, C&W event classification, operator display designs, crew training, flight control team training, and procedure development. Other factors impacting operations are the complexity of a system, skills needed to understand and operate a system, and the use of commonality vs. optimized solutions for software and responses. Fault detection, annunciation, safing responses, and recovery capabilities are explored using real examples to uncover underlying philosophies and constraints. These factors directly impact operations in that the crew and flight control team need to understand what happened, why it happened, what the system is doing, and what, if any, corrective actions they need to perform. If a fault results in multiple C&W events, or if several faults occur simultaneously, the root cause(s) of the fault(s), as well as their vehicle-wide impacts, must be determined in order to maintain situational awareness. This allows both automated and manual recovery operations to focus on the real cause of the fault(s). An appropriate balance must be struck between correcting the root cause failure and addressing the impacts of that fault on other vehicle components. Lastly, this paper presents a strategy for using lessons learned to improve the software, displays, and procedures in addition to determining what is a candidate for automation. Enabling technologies and techniques are identified to promote system evolution from one that requires manual fault responses to one that uses automation and autonomy where they are most effective. These considerations include the value in correcting software defects in a timely manner, automation of repetitive tasks, making time critical responses autonomous, etc. The paper recommends the appropriate use of intelligent systems to determine the root causes of faults and correctly identify separate unrelated faults.
The field of Biology changed dramatically in 1953, with the determination by Francis Crick and James Dewey Watson of the double helix structure of DNA. This discovery changed Biology for ever, allowing the sequencing of the human genome, and the emergence of a "new Biology" focused on DNA, genes, proteins, data, and search. Computational Biology and Bioinformatics heavily rely on computing to facilitate research into life and development. Simultaneously, an understanding of the biology of living organisms indicates a parallel with computing systems: molecules in living cells interact, grow, and transform according to the "program" dictated by DNA. Moreover, paradigms of Computing are emerging based on modelling and developing computer-based systems exploiting ideas that are observed in nature. This includes building into computer systems self-management and self-governance mechanisms that are inspired by the human body's autonomic nervous system, modelling evolutionary systems analogous to colonies of ants or other insects, and developing highly-efficient and highly-complex distributed systems from large numbers of (often quite simple) largely homogeneous components to reflect the behaviour of flocks of birds, swarms of bees, herds of animals, or schools of fish. This new field of "Biologically-Inspired Computing", often known in other incarnations by other names, such as: Autonomic Computing, Pervasive Computing, Organic Computing, Biomimetics, and Artificial Life, amongst others, is poised at the intersection of Computer Science, Engineering, Mathematics, and the Life Sciences. Successes have been reported in the fields of drug discovery, data communications, computer animation, control and command, exploration systems for space, undersea, and harsh environments, to name but a few, and augur much promise for future progress.
ADROIT is a developmental computer program for real-time distribution of complex data streams for display on Web-enabled, portable terminals held by members of an operational team of a spacecraft-command-and-control center who may be located away from the center. Examples of such terminals include personal data assistants, laptop computers, and cellular telephones. ADROIT would make it unnecessary to equip each terminal with platform- specific software for access to the data streams or with software that implements the information-sharing protocol used to deliver telemetry data to clients in the center. ADROIT is a combination of middleware plus software specific to the center. (Middleware enables one application program to communicate with another by performing such functions as conversion, translation, consolidation, and/or integration.) ADROIT translates a data stream (voice, video, or alphanumerical data) from the center into Extensible Markup Language, effectuates a subscription process to determine who gets what data when, and presents the data to each user in real time. Thus, ADROIT is expected to enable distribution of operations and to reduce the cost of operations by reducing the number of persons required to be in the center.
In an effort to relieve summer-time congestion in the NY Terminal Radar Approach Control (TRACON) area, the FAA is testing an enhanced convective forecast (ECF) product. The test began in June 2008 and is scheduled to run through early September. The ECF is updated every two hours, right before the Air Traffic Control System Command Center (ATCSCC) national planning telcon. It is intended to be used by traffic managers throughout the National Airspace System (NAS) and airlines dispatchers to supplement information from the Collaborative Convective Forecast Product (CCFP) and the Corridor Integrated Weather System (CIWS). The ECF begins where the current CIWS forecast ends at 2 hours and extends out to 12 hours. Unlike the CCFP it is a detailed deterministic forecast with no aerial coverage limits. It is created by an ENSCO forecaster using a variety of guidance products including, the Weather Research and Forecast (WRF) model. This is the same version of the WRF that ENSCO runs over the Florida peninsula in support of launch operations at the Kennedy Space Center. For this project, the WRF model domain has been shifted to the Northeastern US. Several products from the NASA SPoRT group are also used by the ENSCO forecaster. In this paper we will provide examples of the ECF products and discuss individual cases of traffic management actions using ECF guidance.
A second generation optical communications demonstrator (OCD-2) intended for airborne applications like air-to-ground and air-to-air optical links is under development at JPL. This development provides the capability for unidirectional high data rate (2.5-Gbps) transmission at 1550-nm, with the ability to receive an 810-nm beacon to aid acquisition pointing and tracking. The transmitted beam width is nominally 200-(micro)rad. A 3x3 degree coarse field-of-view (FOV) acquisition sensor with a much smaller ~3-mrad FOV tracking sensor is incorporated. The OCD-2 optical head will be integrated to a high performance gimbal turret assembly capable of providing pointing stability of 5- microradians from an airborne platform. Other parts of OCD-2 include a cable harness, connecting the optical head in the gimbal turret assembly to a rugged electronics box. The electronics box will house: command and control processors, laser transmitter, data-generation-electronics, power conversion/distribution hardware and state-of-health monitors. The entire assembly will be integrated and laboratory tested prior to a planned flight demonstrations.