SEARCH · Search NASA

Results for “Automation & Control Systems”

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.

SourceResearch connectionFrom yearThrough year

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

At least 19 records

All sources NASA NTRS DOE OSTI

NASA NTRS1975

Apollo experience report: Guidance and control systems: Automated control system for unmanned mission AS-201

The Apollo command module heat shield and Apollo command and service module/Saturn launch vehicle structural integrity were evaluated in an unmanned test flight. An automated control system was developed to provide the mission event sequencing, the real-time ground control interface, and the backup attitude reference system for the unmanned flight. The required mission events, the design logic, the redundancy concept, and the ground-support-equipment concept are described and some development problem areas are discussed. The mission event time line and the real-time ground command list are included to provide an outline of the control system capabilities and requirements. The mission was accomplished with the automated control system, which functioned without flight anomalies.

Holloway, G. F.↗

NASA NTRS2017

Spaceport Command and Control System Automated Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administrations (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires high quality testing that will properly measure the capabilities of the system. Automating the test procedures would save the project time and money. Therefore, the Electrical Engineering Division at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

LCS↗

NASA NTRS2017

Spaceport Command and Control System Automation Testing

Testing↗

NASA NTRS1991

Thermal Control System Automation Project (TCSAP)

Information is given in viewgraph form on the Space Station Freedom (SSF) Thermal Control System Automation Project (TCSAP). Topics covered include the assembly of the External Thermal Control System (ETCS); the ETCS functional schematic; the baseline Fault Detection, Isolation, and Recovery (FDIR), including the development of a knowledge based system (KBS) for application of rule based reasoning to the SSF ETCS; TCSAP software architecture; the High Fidelity Simulator architecture; the TCSAP Runtime Object Database (RODB) data flow; KBS functional architecture and logic flow; TCSAP growth and evolution; and TCSAP relationships.

Boyer, Roger L.↗

NASA NTRS2019

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation↗

NASA NTRS2017

Spaceport Command and Control System Automated Verification Software Development

For as long as we have walked the Earth, humans have always been explorers. We have visited our nearest celestial body and sent Voyager 1 beyond our solar system1 out into interstellar space. Now it is finally time for us to step beyond our home and onto another planet. The Spaceport Command and Control System (SCCS) is being developed along with the Space Launch System (SLS) to take us on a journey further than ever attempted. Within SCCS are separate subsystems and system level software, each of which have to be tested and verified. Testing is a long and tedious process, so automating it will be much more efficient and also helps to remove the possibility of human error from mission operations. I was part of a team of interns and full-time engineers who automated tests for the requirements on SCCS, and with that was able to help verify that the software systems are performing as expected.

Automation↗

NASA NTRS2017

Spaceport Command and Control System Automation Testing

The goal of automated testing is to create and maintain a cohesive infrastructure of robust tests that could be run independently on a software package in its entirety. To that end, the Spaceport Command and Control System (SCCS) project at the National Aeronautics and Space Administration's (NASA) Kennedy Space Center (KSC) has brought in a large group of interns to work side-by-side with full time employees to do just this work. Thus, our job is to implement the tests that will put SCCS through its paces.

Plano, Tom↗

NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the pre-launch and launch operations. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The display software of the LCS is responsible for visualizing the various data that can be received from the hardware and software components of the LCS. Since this system is providing critical information to engineers in the firing room, the visualization of data across the system must be easy to understand, but also reliable and accurate.

Software↗

NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.

Rebecca McFadden↗

NASA NTRS1985

Space infrared telescope pointing control system. Automated star pattern recognition

The Space Infrared Telescope Facility (SIRTF) is a free flying spacecraft carrying a 1 meter class cryogenically cooled infrared telescope nearly three oders of magnitude most sensitive than the current generation of infrared telescopes. Three automatic target acquisition methods will be presented that are based on the use of an imaging star tracker. The methods are distinguished by the number of guidestars that are required per target, the amount of computational capability necessary, and the time required for the complete acquisition process. Each method is described in detail.

Powell, J. D.↗

NASA NTRS1987

Automated Subsystem Control for Life Support System (ASCLSS)

The Automated Subsystem Control for Life Support Systems (ASCLSS) program has successfully developed and demonstrated a generic approach to the automation and control of space station subsystems. The automation system features a hierarchical and distributed real-time control architecture which places maximum controls authority at the lowest or process control level which enhances system autonomy. The ASCLSS demonstration system pioneered many automation and control concepts currently being considered in the space station data management system (DMS). Heavy emphasis is placed on controls hardware and software commonality implemented in accepted standards. The approach demonstrates successfully the application of real-time process and accountability with the subsystem or process developer. The ASCLSS system completely automates a space station subsystem (air revitalization group of the ASCLSS) which moves the crew/operator into a role of supervisory control authority. The ASCLSS program developed over 50 lessons learned which will aide future space station developers in the area of automation and controls..

Block, Roger F.↗

NASA NTRS1993

A survey of life support system automation and control

The level of automation and control necessary to support advanced life support systems for use in the manned space program is steadily increasing. As the length and complexity of manned missions increase, life support systems must be able to meet new space challenges. Longer, more complex missions create new demands for increased automation, improved sensors, and improved control systems. It is imperative that research in these key areas keep pace with current and future developments in regenerative life support technology. This paper provides an overview of past and present research in the areas of sensor development, automation, and control of life support systems for the manned space program, and it discusses the impact continued research in several key areas will have on the feasibility, operation, and design of future life support systems.

Finn, Cory K.↗

NASA NTRS1989

The automation of an inlet mass flow control system

The automation of a closed-loop computer controlled system for the inlet mass flow system (IMFS) developed for a wind tunnel facility at Langley Research Center is presented. This new PC based control system is intended to replace the manual control system presently in use in order to fully automate the plug positioning of the IMFS during wind tunnel testing. Provision is also made for communication between the PC and a host-computer in order to allow total animation of the plug positioning and data acquisition during the complete sequence of predetermined plug locations. As extensive running time is programmed for the IMFS, this new automated system will save both manpower and tunnel running time.

Supplee, Frank↗

NASA NTRS1994

Analysis And Control System For Automated Welding

Automated variable-polarity plasma arc (VPPA) welding apparatus operates under electronic supervision by welding analysis and control system. System performs all major monitoring and controlling functions. It acquires, analyzes, and displays weld-quality data in real time and adjusts process parameters accordingly. Also records pertinent data for use in post-weld analysis and documentation of quality. System includes optoelectronic sensors and data processors that provide feedback control of welding process.

Powell, Bradley W.↗

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 NTRS2016

Performance of an Automated System for Control of Traffic in Terminal Airspace

This paper examines the performance of a system that performs automated conflict resolution and arrival scheduling for aircraft in the terminal airspace around major airports. Such a system has the potential to perform separation assurance and arrival sequencing tasks that are currently handled manually by human controllers. The performance of the system is tested against several simulated traffic scenarios that are characterized by the rate at which air traffic is metered into the terminal airspace. For each traffic scenario, the levels of performance that are examined include: number of conflicts predicted to occur, types of resolution maneuver used to resolve predicted conflicts, and the amount of delay for all flights. The simulation results indicate that the percentage of arrivals that required a maneuver that changes the flight's horizontal route ranged between 11% and 15% in all traffic scenarios. That finding has certain implications if this automated system were to be implemented simply as a decision support tool. It is also found that arrival delay due to purely wake vortex separation requirements on final approach constituted only between 29% and 35% of total arrival delay, while the remaining major portion of it is mainly due to delay back propagation effects.

air traffic control↗

NASA NTRS1998

Formal Aspects of Human-Automation Interaction

While new versions of automated control systems such as flight guidance systems are introduced at a rapid pace, it is widely recognized that user interaction with these machines is increasingly problematic. One cause for this difficulty that is commonly cited in the literature, is the discrepancy between the machine's behavior and the operator's (e.g., pilot) expectations. This paper discusses a formal approach to the analysis of operator's interaction with complex automated control systems. We focus attention on the issue of interface correctness; that is, on the question whether the display provides adequate information about the machine's configurations (states, modes, and associated parameters) and transitions, so as to enable the operator to successfully perform the specified set of tasks. To perform the analysis several assumptions are made: (1) A complete formal model of the machine's behavior is available (e.g., as a state transition system, or as a hybrid-machine); (2) A specification of operator's tasks is available and can be formally described (e.g., the reliable and predictable transition between activities involved in executing a climb to a new altitude); (3) The pilot is well trained and has a correct 'mental' model of the machine's response-map. By 'comparing' the machine's model with the set of operator's tasks we formally (i.e., mathematically) evaluate two questions: 1) does the machine's output interface (display) enable the operator to determine, unambiguously, what the current configuration (e.g., mode) of the machine is, and 2) does the display enable the operator to determine, unambiguously, what the next configuration of the machine will be, in response to a specified interaction by the operator (e.g., engaging a mode or changing a parameter such as a speed or target altitude). This paper describes a methodology for conducting such an evaluation using examples from automated flight control systems of modem 'glass cockpit' jetliners. Taxonomy of the different types of discrepancies that lead to pilot inability to resolve the current and next configuration of the machine is suggested. Data from incident reports involving 'mode confusion' is used to corroborate these discrepancies. Finally, means for compensating, either by augmenting the display and/or the operator's 'mental model' are briefly mentioned.

Degani, Asaf↗

NASA NTRS1991

An Exploratory Exercise in Taguchi Analysis of Design Parameters: Application to a Shuttle-to-space Station Automated Approach Control System

The chief goals of the summer project have been twofold - first, for my host group and myself to learn as much of the working details of Taguchi analysis as possible in the time allotted, and, secondly, to apply the methodology to a design problem with the intention of establishing a preliminary set of near-optimal (in the sense of producing a desired response) design parameter values from among a large number of candidate factor combinations. The selected problem is concerned with determining design factor settings for an automated approach program which is to have the capability of guiding the Shuttle into the docking port of the Space Station under controlled conditions so as to meet and/or optimize certain target criteria. The candidate design parameters under study were glide path (i.e., approach) angle, path intercept and approach gains, and minimum impulse bit mode (a parameter which defines how Shuttle jets shall be fired). Several performance criteria were of concern: terminal relative velocity at the instant the two spacecraft are mated; docking offset; number of Shuttle jet firings in certain specified directions (of interest due to possible plume impingement on the Station's solar arrays), and total RCS (a measure of the energy expended in performing the approach/docking maneuver). In the material discussed here, we have focused on single performance criteria - total RCS. An analysis of the possibility of employing a multiobjective function composed of a weighted sum of the various individual criteria has been undertaken, but is, at this writing, incomplete. Results from the Taguchi statistical analysis indicate that only three of the original four posited factors are significant in affecting RCS response. A comparison of model simulation output (via Monte Carlo) with predictions based on estimated factor effects inferred through the Taguchi experiment array data suggested acceptable or close agreement between the two except at the predicted optimum point, where a difference outside a rule-of-thumb bound was observed. We have concluded that there is most likely an interaction effect not provided for in the original orthogonal array selected as the basis for our experimental design. However, we feel that the data indicates that this interaction is a mild one and that inclusion of its effect will not alter the location of the optimum.

Deal, Don E.↗