Search NASA⌕ Search

SEARCH · Search NASA

Results for “automated command”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide single button intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system on-board the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System [1] , along with the execution component design from within the HAL 9000 Space Operating System [2] , this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA s Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie↗
NASA NTRS2012

Automated Sequence Processor: Something Old, Something New

High productivity required for operations teams to meet schedules Risk must be minimized. Scripting used to automate processes. Scripts perform essential operations functions. Automated Sequence Processor (ASP) was a grass-roots task built to automate the command uplink process System engineering task for ASP revitalization organized. ASP is a set of approximately 200 scripts written in Perl, C Shell, AWK and other scripting languages.. ASP processes/checks/packages non-interactive commands automatically.. Non-interactive commands are guaranteed to be safe and have been checked by hardware or software simulators.. ASP checks that commands are non-interactive.. ASP processes the commands through a command. simulator and then packages them if there are no errors.. ASP must be active 24 hours/day, 7 days/week..

Automated↗
NASA NTRS1996

Tools for automating spacecraft ground systems: The Intelligent Command and Control (ICC) approach

The practical application of scripting languages and World Wide Web tools to the support of spacecraft ground system automation, is reported on. The mission activities and the automation tools used at the Goddard Space Flight Center (MD) are reviewed. The use of the Tool Command Language (TCL) and the Practical Extraction and Report Language (PERL) scripting tools for automating mission operations is discussed together with the application of different tools for the Compton Gamma Ray Observatory ground system.

Stoffel, A. William↗
NASA NTRS1990

Real-time piloted simulation of fully automatic guidance and control for rotorcraft nap-of-the-earth (NOE) flight following planned profiles

Developing a single-pilot all-weather NOE capability requires fully automatic NOE navigation and flight control. Innovative guidance and control concepts are being investigated to (1) organize the onboard computer-based storage and real-time updating of NOE terrain profiles and obstacles; (2) define a class of automatic anticipative pursuit guidance algorithms to follow the vertical, lateral, and longitudinal guidance commands; (3) automate a decision-making process for unexpected obstacle avoidance; and (4) provide several rapid response maneuvers. Acquired knowledge from the sensed environment is correlated with the recorded environment which is then used to determine an appropriate evasive maneuver if a nonconformity is observed. This research effort has been evaluated in both fixed-base and moving-base real-time piloted simulations thereby evaluating pilot acceptance of the automated concepts, supervisory override, manual operation, and reengagement of the automatic system.

Clement, Warren F.↗
NASA NTRS1991

Executive system software design and expert system implementation

The topics are presented in viewgraph form and include: software requirements; design layout of the automated assembly system; menu display for automated composite command; expert system features; complete robot arm state diagram and logic; and expert system benefits.

Cheryl L Allen↗
NASA NTRS2011

Autorotation flight control system

The present invention provides computer implemented methodology that permits the safe landing and recovery of rotorcraft following engine failure. With this invention successful autorotations may be performed from well within the unsafe operating area of the height-velocity profile of a helicopter by employing the fast and robust real-time trajectory optimization algorithm that commands control motion through an intuitive pilot display, or directly in the case of autonomous rotorcraft. The algorithm generates optimal trajectories and control commands via the direct-collocation optimization method, solved using a nonlinear programming problem solver. The control inputs computed are collective pitch and aircraft pitch, which are easily tracked and manipulated by the pilot or converted to control actuator commands for automated operation during autorotation in the case of an autonomous rotorcraft. The formulation of the optimal control problem has been carefully tailored so the solutions resemble those of an expert pilot, accounting for the performance limitations of the rotorcraft and safety concerns.

Bachelder, Edward N.↗
NASA NTRS2010

Coordinating Multiple Spacecraft Assets for Joint Science Campaigns

This paper describes technology to support a new paradigm of space science campaigns. These campaigns enable opportunistic science observations to be autonomously coordinated between multiple spacecraft. Coordinated spacecraft can consist of multiple orbiters, landers, rovers, or other in-situ vehicles (such as an aerobot). In this paradigm, opportunistic science detections can be cued by any of these assets where additional spacecraft are requested to take further observations characterizing the identified event or surface feature. Such coordination will enable a number of science campaigns not possible with present spacecraft technology. Examples from Mars include enabling rapid data collection from multiple craft on dynamic events such as new Mars dark slope streaks, dust-devils or trace gases. Technology to support the identification of opportunistic science events and/or the re-tasking of a spacecraft to take new measurements of the event is already in place on several individual missions such as the Mars Exploration Rover (MER) Mission and the Earth Observing One (EO1) Mission. This technology includes onboard data analysis techniques as well as capabilities for planning and scheduling. This paper describes how these techniques can be cue and coordinate multiple spacecraft in observing the same science event from their different vantage points.

automated commanding↗
NASA NTRS1984

Automated CPX support system preliminary design phase

The development of the Distributed Command and Control System (DCCS) is discussed. The development of an automated C2 system stimulated the development of an automated command post exercise (CPX) support system to provide a more realistic stimulus to DCCS than could be achieved with the existing manual system. An automated CPX system to support corps-level exercise was designed. The effort comprised four tasks: (1) collecting and documenting user requirements; (2) developing a preliminary system design; (3) defining a program plan; and (4) evaluating the suitability of the TRASANA FOURCE computer model.

Bordeaux, T. A.↗
NASA NTRS2010

Automation of Cassini Support Imaging Uplink Command Development

"Support imaging" is imagery requested by other Cassini science teams to aid in the interpretation of their data. The generation of the spacecraft command sequences for these images is performed by the Cassini Instrument Operations Team. The process initially established for doing this was very labor-intensive, tedious and prone to human error. Team management recognized this process as one that could easily benefit from automation. Team members were tasked to document the existing manual process, develop a plan and strategy to automate the process, implement the plan and strategy, test and validate the new automated process, and deliver the new software tools and documentation to Flight Operations for use during the Cassini extended mission. In addition to the goals of higher efficiency and lower risk in the processing of support imaging requests, an effort was made to maximize adaptability of the process to accommodate uplink procedure changes and the potential addition of new capabilities outside the scope of the initial effort.

Ly-Hollins, Lisa↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRSDate not supplied

Command and Control Concepts for an Lift Plus Cruise Electric Vertical Takeoff and Landing Vehicle

Electric Vertical Takeoff and Landing (eVTOL) vehicles have the potential to enable cost effective Urban Air Mobility (UAM) applications. Many of these vehicle concepts will takeoff vertically like a helicopter, transition to fly like an airplane, and then transition back to land vertically like a helicopter. However, these concepts may also pose several challenging handling and control problems, which must be addressed prior to safe and reliable urban operations. This study investigates some of these challenges by evaluating different command and control concepts for a conceptual Lift Plus Cruise vehicle designed by NASA’s Revolutionary Vertical Lift Technology (RVLT) project. Four different command concepts with increasing levels of automation are developed. The command and control architecture for these concepts is presented along with findings from the evaluation of these concepts in a series of three piloted studies in the Vertical Motion Simulator at NASA Ames Research Center, where pilots flew operationally relevant flight test maneuvers specifically designed to expose potential deficiencies. The higher-level control systems and the associated pilot interfaces were shown to improve performance and handling in many cases, especially for higher precision and lower to moderate aggression maneuvers. The benefits were limited for higher aggression tasks in environmentally stressing conditions, due to the slower response of the automation and inherent limitations of the vehicle design, which highlights the potential need for tradeoffs between concept of operations and vehicle capabilities

Thomas Lombaerts↗
NASA NTRS1989

Applications of artificial intelligence to space station and automated software techniques: High level robot command language

The objective is to develop a system that will allow a person not necessarily skilled in the art of programming robots to quickly and naturally create the necessary data and commands to enable a robot to perform a desired task. The system will use a menu driven graphical user interface. This interface will allow the user to input data to select objects to be moved. There will be an imbedded expert system to process the knowledge about objects and the robot to determine how they are to be moved. There will be automatic path planning to avoid obstacles in the work space and to create a near optimum path. The system will contain the software to generate the required robot instructions.

Mckee, James W.↗
NASA NTRS1993

RACE pulls for shared control

Maintaining and supporting an aircraft fleet, in a climate of reduced manpower and financial resources, dictates effective utilization of robotics and automation technologies. To help develop a winning robotics and automation program the Air Force Logistics Command created the Robotics and Automation Center of Excellence (RACE). RACE is a command wide focal point. Race is an organic source of expertise to assist the Air Logistic Center (ALC) product directorates in improving process productivity through the judicious insertion of robotics and automation technologies. RACE is a champion for pulling emerging technologies into the aircraft logistic centers. One of those technology pulls is shared control. Small batch sizes, feature uncertainty, and varying work load conspire to make classic industrial robotic solutions impractical. One can view ALC process problems in the context of space robotics without the time delay. The ALC's will benefit greatly from the implementation of a common architecture that supports a range of control actions from fully autonomous to teleoperated. Working with national laboratories and private industry, we hope to transition shared control technology to the depot floor. This paper provides an overview of the RACE internal initiatives and customer support, with particular emphasis on production processes that will benefit from shared control technology.

Leahy, M. B., Jr.↗
NASA NTRS1994

The development and validation of command schedules for SeaWiFS

An automated method for developing and assessing spacecraft and instrument command schedules is presented for the Sea-viewing Wide Field-of-view Sensor (SeaWiFS) project. SeaWiFS is to be carried on the polar-orbiting SeaStar satellite in 1995. The primary goal of the SeaWiFS mission is to provide global ocean chlorophyll concentrations every four days by employing onboard recorders and a twice-a-day data downlink schedule. Global Area Coverage (GAC) data with about 4.5 km resolution will be used to produce the global coverage. Higher resolution (1.1 km resolution) Local Area Coverage (LAC) data will also be recorded to calibrate the sensor. In addition, LAC will be continuously transmitted from the satellite and received by High Resolution Picture Transmission (HRPT) stations. The methods used to generate commands for SeaWiFS employ numerous hierarchical checks as a means of maximizing coverage of the Earth's surface and fulfilling the LAC data requirements. The software code is modularized and written in Fortran with constructs to mirror the pre-defined mission rules. The overall method is specifically developed for low orbit Earth-observing satellites with finite onboard recording capabilities and regularly scheduled data downlinks. Two software packages using the Interactive Data Language (IDL) for graphically displaying and verifying the resultant command decisions are presented. Displays can be generated which show portions of the Earth viewed by the sensor and spacecraft sub-orbital locations during onboard calibration activities. An IDL-based interactive method of selecting and testing LAC targets and calibration activities for command generation is also discussed.

Woodward, Robert H.↗
NASA NTRS1992

Domain specific software architectures: Command and control

GTE is the Command and Control contractor for the Domain Specific Software Architectures program. The objective of this program is to develop and demonstrate an architecture-driven, component-based capability for the automated generation of command and control (C2) applications. Such a capability will significantly reduce the cost of C2 applications development and will lead to improved system quality and reliability through the use of proven architectures and components. A major focus of GTE's approach is the automated generation of application components in particular subdomains. Our initial work in this area has concentrated in the message handling subdomain; we have defined and prototyped an approach that can automate one of the most software-intensive parts of C2 systems development. This paper provides an overview of the GTE team's DSSA approach and then presents our work on automated support for message processing.

Braun, Christine↗
NASA NTRS2017

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

Building Specifications

The building in the top photo is the new home of the National Permanent Savings Bank in Washington, D.C., designed by Hartman-Cox Architects. Its construction was based on a money-saving method of preparing building specifications which derived from NASA technology developed to obtain quality construction while holding down cost of launch facilities, test centers and other structures. Written technical specifications spell out materials and components to be used on construction projects and identify the quality tests each item must pass. Specifications can have major impact on construction costs. Poorly formulated specifications can lead to unacceptable construction which must be replaced, unnecessarily high materials costs, safety hazards, disputes and often additional costs due to delays and litigation. NASA's Langley Research Center developed a novel approach to providing accurate, uniform, cost-effective specifications which can be readily updated to incorporate new building technologies. Called SPECSINTACT, it is a computerized - system accessible to all NASA centers involved in construction programs. The system contains a comprehensive catalog of master specifications applicable to many types of construction. It enables designers of any structure to call out relevant sections from computer storage and modify them to fit the needs of the project at hand. Architects and engineers can save time by concentrating their efforts on needed modifications rather than developing all specifications from scratch. Successful use of SPECSINTACT has led to a number of spinoff systems. One of the first was MASTERSPEC, developed from NASA's experience by Production Systems for Architects and Engineers, Inc., an organization established by the American Institute of Architects. MASTERSPEC, used in construction of the bank building pictured, follows the same basic format as SPECSINTACT and can be used in either automated or manual modes. The striking appearance of the bank building shows that, while MASTERSPEC saves time and money, its use involves no sacrfice in architectural design freedom. The Naval Engineering Facilities Command employs an automated specifications system based on SPECSINTACT. The Public Buildings Service of the General Services Administration used SPECSINTACT as a starting point in a plan to make its guideline specifications available to architects and engineers on a nationwide computer network. Public Technology, Inc., a NASA Technology Application Team, is working with Production Systems for Architects and Engineers, Inc., to promote widespread use of the system by state and local governments for cost benefits to taxpayers.

Source record↗