Search NASASearch

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.

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

At least 37 records · Page 2

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.

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

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

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

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.

Automated Test Environment for a Real-Time Control System

An automated environment with hardware-in-the-loop has been developed by Rocketdyne Huntsville for test of a real-time control system. The target system of application is the man-rated real-time system which controls the Space Shuttle Main Engines (SSME). The primary use of the environment is software verification and validation, but it is also useful for evaluation and analysis of SSME avionics hardware and mathematical engine models. It provides a test bed for the integration of software and hardware. The principles and skills upon which it operates may be applied to other target systems, such as those requiring hardware-in-the-loop simulation and control system development. Potential applications are in problem domains demanding highly reliable software systems requiring testing to formal requirements and verifying successful transition to/from off-nominal system states.

Hall, Ronald O.

Automated Cryocooler Monitor and Control System Software

This software is used in an automated cryogenic control system developed to monitor and control the operation of small-scale cryocoolers. The system was designed to automate the cryogenically cooled low-noise amplifier system described in "Automated Cryocooler Monitor and Control System" (NPO-47246), NASA Tech Briefs, Vol. 35, No. 5 (May 2011), page 7a. The software contains algorithms necessary to convert non-linear output voltages from the cryogenic diode-type thermometers and vacuum pressure and helium pressure sensors, to temperature and pressure units. The control function algorithms use the monitor data to control the cooler power, vacuum solenoid, vacuum pump, and electrical warm-up heaters. The control algorithms are based on a rule-based system that activates the required device based on the operating mode. The external interface is Web-based. It acts as a Web server, providing pages for monitor, control, and configuration. No client software from the external user is required.

Britchcliffe, Michael J.

NASA develops new digital flight control system

This news release reports on the development and testing of a new integrated flight and propulsion automated control system that aerospace engineers at NASA's Ames Research Center have been working on. The system is being tested in the V/STOL (Vertical/Short Takeoff and Landing) Systems Research Aircraft (VSRA).

Mewhinney, Michael

Automation of Nanoparticle Synthesis Processes in a Plasma Environment Using LabVIEW

This work presents an automated control system for the synthesis of nanomaterials by plasma-enhanced chemical vapor deposition (PECVD), implemented using the LabVIEW software environment. The main objective of the study is to develop an integrated hardware-software platform that enables sequential control of the key stages of the PECVD process, including vacuum chamber preparation, pressure monitoring, working gas supply, plasma ignition, power matching, cyclic nanomaterial growth, and optical monitoring of nanoparticles in the plasma environment. The use of LabVIEW made it possible to integrate actuator control, experimental parameter acquisition, and realtime process visualization within a single automated system. The automated cycle begins with evacuation of the reaction chamber to a predefined base pressure. Transition to the next stage is permitted only after the specified pressure threshold has been reached, ensuring reproducible initial conditions for each experiment. The program then controls the supply of the working gas through mass flow controllers (MFCs). In this work, two gas-flow control modes were considered: analog control using a 0-5 V voltage signal and digital communication via RS-232 interface. It was shown that the analog approach requires accurate scaling of the control voltage, since applying 5 V corresponds to full-scale opening of the controller and results in the maximum gas flow. In contrast, the RS232 interface enables the gas flow rate to be specified directly in sccm, improving the accuracy, flexibility, and convenience of gas-environment control. After pressure stabilization, LabVIEW initiates RF plasma ignition and executes the RF matching algorithm aimed at minimizing reflected power and improving the stability of the plasma process. A separate software module implements the cyclic nanomaterial growth mode, in which the plasma-on time, plasma duration, and total number of synthesis cycles are predefined. This approach makes it possible to control material accumulation on the substrate and to correlate the process parameters with the morphological characteristics of the resulting nanostructures. The final module of the system is designed for optical monitoring of the nanoparticle cloud density in dusty plasma. For this purpose, the change in the intensity of laser radiation passing through the plasma region is recorded using a photodetector and a Keithley 2401 measuring unit connected to LabVIEW via RS-232 interface. The difference between the initial and modified optical signal intensity is used as a diagnostic parameter characterizing the formation and temporal evolution of nanoparticles. The developed system demonstrates that LabVIEW can be effectively applied not only for the automation of individual instruments, but also for the implementation of a complete digital control cycle for PECVD-based nanomaterial synthesis.

PECVD

Towards an Improved Pilot-Vehicle Interface for Highly Automated Aircraft: Evaluation of the Haptic Flight Control System

The control automation and interaction paradigm (e.g., manual, autopilot, flight management system) used on virtually all large highly automated aircraft has long been an exemplar of breakdowns in human factors and human-centered design. An alternative paradigm is the Haptic Flight Control System (HFCS) that is part of NASA Langley Research Center s Naturalistic Flight Deck Concept. The HFCS uses only stick and throttle for easily and intuitively controlling the actual flight of the aircraft without losing any of the efficiency and operational benefits of the current paradigm. Initial prototypes of the HFCS are being evaluated and this paper describes one such evaluation. In this evaluation we examined claims regarding improved situation awareness, appropriate workload, graceful degradation, and improved pilot acceptance. Twenty-four instrument-rated pilots were instructed to plan and fly four different flights in a fictitious airspace using a moderate fidelity desktop simulation. Three different flight control paradigms were tested: Manual control, Full Automation control, and a simplified version of the HFCS. Dependent variables included both subjective (questionnaire) and objective (SAGAT) measures of situation awareness, workload (NASA-TLX), secondary task performance, time to recognize automation failures, and pilot preference (questionnaire). The results showed a statistically significant advantage for the HFCS in a number of measures. Results that were not statistically significant still favored the HFCS. The results suggest that the HFCS does offer an attractive and viable alternative to the tactical components of today s FMS/autopilot control system. The paper describes further studies that are planned to continue to evaluate the HFCS.

Schutte, Paul

Some Formal Aspects of Human-Machine Interaction

While automated control systems such as autopilots and medical devices are introduced at a rapid pace, it is widely recognized that user interaction with these machines is problematic (Abbott, Slotte, & Stimson, 1996). One factor commonly cited in the literature is the discrepancy between the machine's behavior and the user's expectations. Design guidelines to reduce this discrepancy focus on two elements: (1) improvement of the "feedback" about what the automation is actually doing, and (2) improvement of the user's "mental model" of the automation (Norman, 1990; Sarter and Woods, 1995). This presentation describes a methodology for investigating these two elements via a formal (Le., mathematical) approach. The method involves two representations: (1) a finite state model of the machine's behavior (2) a finite state model of the user's knowledge and expectations about the machine's behavior. In the analysis phase we compare these two models and identify discrepancies. Such discrepancies can be compensated by augmenting the display and/or the user's model. A taxonomy of these discrepancies will be discussed using examples from automated Eight control systems of modern "glass cockpit" jetliners.

Degani, Asaf

2025 Intern Poster

The Hot Fuel Examination Facility (HFEF) at the Materials and Fuels Complex (MFC) houses the largest U.S. inert atmosphere hot cell for nuclear material research. Key features include the precision gamma scanning (PGS), Fuel Accident Condition Simulator (FACS), Neutron Radiography Reactor (NRAD), and the focus of this project, the Metallograph Loading Cell (MET Cell). The MET Cell performs tests on spent nuclear fuel, such as microhardness testing, microscopy, and neutron radiography. However, the MET Cell’s existing pressure and lighting control systems are outdated and inefficient, with inadequate documentation for system changes over time. This project aims to design a new automated control system for the MET Cell, ensuring longevity (minimum ten years), ease of troubleshooting/repair, and integration into the building monitoring system. The design process addressed challenges such as space restrictions, varied voltages within enclosures, sourcing new components, and security limitations. Compliance with NFPA 70, UL508A, MFC Physical Security, and INL Engineering standards was essential. The project involves repurposing an existing PLC to manage lighting and pressure control using digital and analog signals, simplifying wiring, and ensuring thorough documentation for future reference.

42 - ENGINEERING

Re-engineering Nascom's network management architecture

The development of Nascom systems for ground communications began in 1958 with Project Vanguard. The low-speed systems (rates less than 9.6 Kbs) were developed following existing standards; but, there were no comparable standards for high-speed systems. As a result, these systems were developed using custom protocols and custom hardware. Technology has made enormous strides since the ground support systems were implemented. Standards for computer equipment, software, and high-speed communications exist and the performance of current workstations exceeds that of the mainframes used in the development of the ground systems. Nascom is in the process of upgrading its ground support systems and providing additional services. The Message Switching System (MSS), Communications Address Processor (CAP), and Multiplexer/Demultiplexer (MDM) Automated Control System (MACS) are all examples of Nascom systems developed using standards such as, X-windows, Motif, and Simple Network Management Protocol (SNMP). Also, the Earth Observing System (EOS) Communications (Ecom) project is stressing standards as an integral part of its network. The move towards standards has produced a reduction in development, maintenance, and interoperability costs, while providing operational quality improvement. The Facility and Resource Manager (FARM) project has been established to integrate the Nascom networks and systems into a common network management architecture. The maximization of standards and implementation of computer automation in the architecture will lead to continued cost reductions and increased operational efficiency. The first step has been to derive overall Nascom requirements and identify the functionality common to all the current management systems. The identification of these common functions will enable the reuse of processes in the management architecture and promote increased use of automation throughout the Nascom network. The MSS, CAP, MACS, and Ecom projects have indicated the potential value of commercial-off-the-shelf (COTS) and standards through reduced cost and high quality. The FARM will allow the application of the lessons learned from these projects to all future Nascom systems.

Drake, Brian C.

Mode Transitions in Glass Cockpit Aircraft: Results of a Field Study

One consequence of increased levels of automation in complex control systems is the presence of modes. A mode is a particular configuration of a control system that defines how human command inputs are interpreted. In complex systems, modes also often determine a specific allocation of control authority between the human and automated systems. Even in simple static devices (e.g., electronic watches, word processors), the presence of modes has been found to cause problems in either-the acquisition or production of skilled performance. Many of these problems arise due to the fact that the selection of a mode causes device behavior to be mediated by hidden internal state information. For these simple systems, many of these interaction problems can be solved by the design of appropriate feedback to communicate internal state information to the human operator. In complex dynamic systems, however, the design issues associated with modes seem to trancend the problem of merely communicating internal state information via displayed feedback. In complex supervisory control systems (e.g., aircraft, spacecraft, military command and control), a key function of modes is the selection of a particular configuration of control authority between the human operator and automated control systems. One mode may result in full manual control, another may result in a mix of manual and automatic control, while a third may result in full automatic control over the entire system. The human operator selects an appropriate mode as a function of current goals, operating conditions, and operating procedures. Thus, the operator is put in a position of essentially trying to control two coupled dynamic systems: the target system itself, and also a highly complex suite of automation controlling the target system. From a historical perspective, it should probably not come as a surprise that very little information is available to guide the design of mode-oriented control systems. The topic of function allocation (i.e., the proper division of control authority among human and computer) has a long history in human-machine systems research. Although this research has produced some relevant guidelines, a design approach capable of defining appropriate allocations of control function between the human and automation is not yet available. As a result, the function allocation decision itself has been allocated to the operator, to be performed in real-time, in the operation of mode-oriented control systems. A variety of documented aircraft accidents and incidents suggest that the real-time selection and monitoring of control modes is a weak link in the effective operation of complex supervisory control systems. Research in human-machine systems and human-computer interaction has barely scraped the surface of the problem of understanding how operators manage this task.The purpose of this paper is to present the results of a field study which examined how operators manage mode selection in a complex supervisory control system. Data on mode engagements using the Boeing B757/767 auto-flight system were collected during approach and descent into four major airports in the East Coast of the United States. Protocols documenting mode selection, automatic mode changes, pilot actions, quantitative records of flight-path variables, and verbal reports during and after mode engagements were collected by an observer from the jumpseat. Observations were conducted on two typical trips between three airports. Each trip was be replicated 11 times, which yielded a total of 22 trips and 66 legs on which data were collected. All data collected concerned the same flight numbers, and therefore, the same time of day, same type of aircraft, and identical operational environments (e.g., ATC facilities, weather patterns, traffic flow etc.)

Degani, Asaf

A Virtual Mission Operations Center: Collaborative Environment

The Virtual Mission Operations Center - Collaborative Environment (VMOC-CE) intent is to have a central access point for all the resources used in a collaborative mission operations environment to assist mission operators in communicating on-site and off-site in the investigation and resolution of anomalies. It is a framework that as a minimum incorporates online chat, realtime file sharing and remote application sharing components in one central location. The use of a collaborative environment in mission operations opens up the possibilities for a central framework for other project members to access and interact with mission operations staff remotely. The goal of the Virtual Mission Operations Center (VMOC) Project is to identify, develop, and infuse technology to enable mission control by on-call personnel in geographically dispersed locations. In order to achieve this goal, the following capabilities are needed: Autonomous mission control systems Automated systems to contact on-call personnel Synthesis and presentation of mission control status and history information Desktop tools for data and situation analysis Secure mechanism for remote collaboration commanding Collaborative environment for remote cooperative work The VMOC-CE is a collaborative environment that facilitates remote cooperative work. It is an application instance of the Virtual System Design Environment (VSDE), developed by NASA Goddard Space Flight Center's (GSFC) Systems Engineering Services & Advanced Concepts (SESAC) Branch. The VSDE is a web-based portal that includes a knowledge repository and collaborative environment to serve science and engineering teams in product development. It is a "one stop shop" for product design, providing users real-time access to product development data, engineering and management tools, and relevant design specifications and resources through the Internet. The initial focus of the VSDE has been to serve teams working in the early portion of the system/product lifecycle - concept development, proposal preparation, and formulation. The VMOC-CE expands the application of the VSDE into the operations portion of the system lifecycle. It will enable meaningful and real-time collaboration regardless of the geographical distribution of project team members. Team members will be able to interact in satellite operations, specifically for resolving anomalies, through access to a desktop computer and the Internet. Mission Operations Management will be able to participate and monitor up to the minute status of anomalies or other mission operations issues. In this paper we present the VMOC-CE project, system capabilities, and technologies.

Medina, Barbara

Implementing a real time reasoning system for robust diagnosis

The objective of the Thermal Control System Automation Project (TCSAP) is to develop an advanced fault detection, isolation, and recovery (FDIR) capability for use on the Space Station Freedom (SSF) External Active Thermal Control System (EATCS). Real-time monitoring, control, and diagnosis of the EATCS will be performed with a knowledge based system (KBS). Implementation issues for the current version of the KBS are discussed.

Hill, Tim

Models of Human-Automation Systems: Initial Analysis of the Boeing 737MAX Design

We describe a formal approach to identifying human factors design vulnerabilities and usability concerns in the context of automated control systems. We present an initial analysis of the design of the B737MAX that has suffered two fatal accidents. We highlight two main design vulnerabilities and one usability concern. Key formal generic properties used to identify these vulnerabilities and usability concerns are defined. These generic properties, and others referenced in the paper, can be applied to the analysis of any human-automation system.

HSI