SEARCH · Search NASA

Results for “adaptive structures response to external stimulation remote or automatic 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.

SourceResearch connectionFrom yearThrough year

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

377 records · Page 21

All sources NASA NTRS DOE OSTI

NASA NTRS1990

A manned maneuvering unit proximity operations planning and flight guidance display and control system

This task concerns the design, development, testing, and evaluation of a new proximity operations planning and flight guidance display and control system for manned space operations. A forecast, derivative manned maneuvering unit (MMU) was identified as a candidate for the application of a color, highway-in-the-sky display format for the presentation of flight guidance information. A silicon graphics 4D/20-based simulation is being developed to design and test display formats and operations concepts. The simulation includes the following: (1) real-time color graphics generation to provide realistic, dynamic flight guidance displays and control characteristics; (2) real-time graphics generation of spacecraft trajectories; (3) MMU flight dynamics and control characteristics; (4) control algorithms for rotational and translational hand controllers; (5) orbital mechanics effects for rendezvous and chase spacecraft; (6) inclusion of appropriate navigation aids; and (7) measurement of subject performance. The flight planning system under development provides for: (1) selection of appropriate operational modes, including minimum cost, optimum cost, minimum time, and specified ETA; (2) automatic calculation of rendezvous trajectories, en route times, and fuel requirements; (3) and provisions for manual override. Man/machine function allocations in planning and en route flight segments are being evaluated. Planning and en route data are presented on one screen composed of two windows: (1) a map display presenting a view perpendicular to the orbital plane, depicting flight planning trajectory and time data attitude display presenting attitude and course data for use en route; and (2) an attitude display presenting local vertical-local horizontal attitude data superimposed on a highway-in-the-sky or flight channel representation of the flight planned course. Both display formats are presented while the MMU is en route. In addition to these displays, several original display elements are being developed, including a 3DOF flight detector for attitude commanding, a different flight detector for translation commands, and a pictorial representation of velocity deviations.

Gershzohn, Gary R.↗

NASA NTRS2006

Notional Airspace Operations Demonstration Plan

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.

Trongale, Nicholas A.↗

NASA NTRS2006

Estimation of Stability and Control Derivatives of an F-15

A technique for real-time estimation of stability and control derivatives (derivatives of moment coefficients with respect to control-surface deflection angles) was used to support a flight demonstration of a concept of an indirect-adaptive intelligent flight control system (IFCS). Traditionally, parameter identification, including estimation of stability and control derivatives, is done post-flight. However, for the indirect-adaptive IFCS concept, parameter identification is required during flight so that the system can modify control laws for a damaged aircraft. The flight demonstration was carried out on a highly modified F-15 airplane (see Figure 1). The main objective was to estimate the stability and control derivatives of the airplane in nearly real time. A secondary goal was to develop a system to automatically assess the quality of the results, so as to be able to tell a learning neural network which data to use. Parameter estimation was performed by use of Fourier-transform regression (FTR) a technique developed at NASA Langley Research Center. FTR is an equation- error technique that operates in the frequency domain. Data are put into the frequency domain by use of a recursive Fourier transform for a discrete frequency set. This calculation simplifies many subsequent calculations, removes biases, and automatically filters out data beyond the chosen frequency range. FTR as applied here was tailored to work with pilot inputs, which produce correlated surface positions that prevent accurate parameter estimates, by replacing half the derivatives with predicted values. FTR was also set up to work only on a recent window of data, to accommodate changes in flight condition. A system of confidence measures was developed to identify quality-parameter estimates that a learning neural network could use. This system judged the estimates primarily on the basis of their estimated variances and of the level of aircraft response. The resulting FTR system was implemented in the Simulink software system and auto-coded in the C programming language for use on the Airborne Research Test System (ARTS II) computer installed in the F-15 airplane. The Simulink model was also used in a control room that utilizes the Ring Buffered Network Bus hardware and software, making it possible to evaluate test points during flights. In-flight parameter estimation was done for piloted and automated maneuvers, primarily at three test conditions. Figure 2 shows results for pitching moment due to symmetric stabilator actuations for a series of three pitch doublet maneuvers (in a doublet maneuver, a command to change attitude in a given direction by a given amount is followed immediately by a command to change attitude in the opposite direction by the same amount). A time window of 5 seconds was used. The portions of the curves shown in red are those that passed the confidence tests. The technique showed good convergence for most derivatives for both kinds of maneuvers - typically within a few seconds. The confidence tests were marginally successful, and it would be necessary to refine them for use in an IFCS.

Smith, Mark↗

DOE OSTI2026

ACDC (Automated Campbell Diagram Code) [SWR-26-042]

This application provides a web-based graphical user interface to generating Campbell Diagrams and visualizing mode shapes for OpenFAST turbine models. Determining the aeroelastic stability and dynamic characteristics of wind turbines is a critical step in turbine design and analysis. Historically, extracting natural frequencies and mode shapes from OpenFAST—the industry-standard whole-turbine simulation code—has been a fragmented and tedious process. It required manual model configuration, command-line linearization execution, and complex post-processing via proprietary scripts to handle rotating-frame dynamics. To address these workflow bottlenecks, we present the Automated Campbell Diagram Code (ACDC), an open-source graphical software tool developed by the National Laboratory of the Rockies (NLR) under the DOE-funded Distributed Wind Aeroelastic Modeling (dWAM) project. ACDC streamlines the end-to-end linearization and stability analysis workflow into a single, intuitive cross-platform application. The software guides users through OpenFAST model configuration, definition of operating points, and the automated execution of steady-state trim and linearization simulations. Under the hood, ACDC automates the complex mathematical post-processing steps required for rotating systems, including Multi-Blade Coordinate (MBC) transformations, eigenanalysis, and advanced modal tracking utilizing the Modal Assurance Criterion (MAC) and spectral clustering. Finally, ACDC processes these results to automatically generate Campbell diagrams and features a robust 3D visualization engine to animate full-system mode shapes. By eliminating the reliance on external post-processing environments and manual data manipulation, ACDC significantly accelerates dynamic analysis and lowers the barrier to entry for wind energy researchers and engineers.

Summerville, Brent [National Laboratory of the Roc↗

NASA NTRS1971

Project: Apollo 15

The 12-day Apollo 15 mission, scheduled for launch on July 26 to carry out the fourth United States manned exploration of the Moon, will: Double the time and extend tenfold the range of lunar surface exploration as compared with earlier missions; Deploy the third in a network of automatic scientific stations; Conduct a new group of experiments in lunar orbit; and Return to Earth a variety of lunar rock and soil samples. Scientists expect the results will greatly increase man's knowledge both of the Moon's history and composition and of the evolution and dynamic interaction of the Sun-Earth system. This is so because the dry, airless, lifeless Moon still bears records of solar radiation and the early years of solar system history that have been erased from Earth. Observations of current lunar events also may increase understanding of similar processes on Earth, such as earthquakes. The Apollo 15 Lunar module will make its descent over the Apennine peaks, one of the highest mountain ranges on the Moon, to land near the rim of the canyon-like Hadley Rille. From this Hadley-Apennine lunar base, between the mountain range and the rille, Commander David R. Scott and Lunar Module Pilot James B. Irwin will explore several kilometers from the lunar module, driving an electric-powered lunar roving vehicle for the first time on the Moon. Scott and Irwin will leave the lunar module for three exploration periods to emplace scientific experiments on the lunar surface and to make detailed geologic investigations of formations in the Apennine foothills, along the Hadley Rille rim, and to other geologic structures. The three previous manned landings were made by Apollo 11 at Tranquillity Base, Apollo 12 in the Ocean of Storms and Apollo 14 at Fra Mauro.

Source record↗

NASA NTRS1992

Registering and resampling images in STSDAS

Registering different images can be difficult, especially if the images to be registered are images at different wavelengths, where features in one image may look entirely different or be absent from the second image. Using two new packages soon to be added to the STSDAS package, REGISTER and RESAMPLE, this job is done automatically. The REGISTER package allows the user to determine the amount of translation, rotation, and/or magnification needed to make two images, spectra, or time series congruent. The methods implemented to compute the registration parameters use: a set of the pixel coordinates of the same features identified in two files, or the FITS coordinate transformation parameters in the headers of two data files, or a single feature identified as the peak of a cross-correlation between two vectors. The coefficients describing the registration are defined by the equations (for a two-dimensional image): x = a + bx + cy, y = d + ex + fy, where (X,Y) are the pixel coordinates of a feature in the reference image, (x,y) are the pixel coordinates of a feature in the secondary image, and the computed coefficients are a, b, c, d, e, and f. Results may be produced by linking the output of REGISTER to RESAMPLE in a command language procedure. The output from REGISTER and the input to RESAMPLE consists of a matrix of coefficients (a through f above) fully specifying the registration. The RESAMPLE package resamples simple vector or image data for a given amount of translation, rotation (images only), and magnification, or reflection of the science data. Specific options included are: image rotation about the FITS reference pixel; scale changes, i.e. magnification or demagnification (for images, independently on both axes); simple translation; reflection (for images, about one or both axes); and resampling and registration to a reference data set. Output from the RESAMPLE task is the resampled image which may then be displayed and compared with the reference image.

Williamson, R. L., II↗

NASA NTRS1993

High-performance mass storage system for workstations

Reduced Instruction Set Computer (RISC) workstations and Personnel Computers (PC) are very popular tools for office automation, command and control, scientific analysis, database management, and many other applications. However, when using Input/Output (I/O) intensive applications, the RISC workstations and PC's are often overburdened with the tasks of collecting, staging, storing, and distributing data. Also, by using standard high-performance peripherals and storage devices, the I/O function can still be a common bottleneck process. Therefore, the high-performance mass storage system, developed by Loral AeroSys' Independent Research and Development (IR&D) engineers, can offload a RISC workstation of I/O related functions and provide high-performance I/O functions and external interfaces. The high-performance mass storage system has the capabilities to ingest high-speed real-time data, perform signal or image processing, and stage, archive, and distribute the data. This mass storage system uses a hierarchical storage structure, thus reducing the total data storage cost, while maintaining high-I/O performance. The high-performance mass storage system is a network of low-cost parallel processors and storage devices. The nodes in the network have special I/O functions such as: SCSI controller, Ethernet controller, gateway controller, RS232 controller, IEEE488 controller, and digital/analog converter. The nodes are interconnected through high-speed direct memory access links to form a network. The topology of the network is easily reconfigurable to maximize system throughput for various applications. This high-performance mass storage system takes advantage of a 'busless' architecture for maximum expandability. The mass storage system consists of magnetic disks, a WORM optical disk jukebox, and an 8mm helical scan tape to form a hierarchical storage structure. Commonly used files are kept in the magnetic disk for fast retrieval. The optical disks are used as archive media, and the tapes are used as backup media. The storage system is managed by the IEEE mass storage reference model-based UniTree software package. UniTree software will keep track of all files in the system, will automatically migrate the lesser used files to archive media, and will stage the files when needed by the system. The user can access the files without knowledge of their physical location. The high-performance mass storage system developed by Loral AeroSys will significantly boost the system I/O performance and reduce the overall data storage cost. This storage system provides a highly flexible and cost-effective architecture for a variety of applications (e.g., realtime data acquisition with a signal and image processing requirement, long-term data archiving and distribution, and image analysis and enhancement).

Chiang, T.↗

NASA NTRSDate not supplied

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

NASA NTRS1999

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗

NASA NTRS2013

Wireless Integrated Microelectronic Vacuum Sensor System

NASA Stennis Space Center's (SSC's) large rocket engine test facility requires the use of liquid propellants, including the use of cryogenic fluids like liquid hydrogen as fuel, and liquid oxygen as an oxidizer (gases which have been liquefied at very low temperatures). These fluids require special handling, storage, and transfer technology. The biggest problem associated with transferring cryogenic liquids is product loss due to heat transfer. Vacuum jacketed piping is specifically designed to maintain high thermal efficiency so that cryogenic liquids can be transferred with minimal heat transfer. A vacuum jacketed pipe is essentially two pipes in one. There is an inner carrier pipe, in which the cryogenic liquid is actually transferred, and an outer jacket pipe that supports and seals the vacuum insulation, forming the "vacuum jacket." The integrity of the vacuum jacketed transmission lines that transfer the cryogenic fluid from delivery barges to the test stand must be maintained prior to and during engine testing. To monitor the vacuum in these vacuum jacketed transmission lines, vacuum gauge readings are used. At SSC, vacuum gauge measurements are done on a manual rotation basis with two technicians, each using a handheld instrument. Manual collection of vacuum data is labor intensive and uses valuable personnel time. Additionally, there are times when personnel cannot collect the data in a timely fashion (i.e., when a leak is detected, measurements must be taken more often). Additionally, distribution of this data to all interested parties can be cumbersome. To simplify the vacuum-gauge data collection process, automate the data collection, and decrease the labor costs associated with acquiring these measurements, an automated system that monitors the existing gauges was developed by Invocon, Inc. For this project, Invocon developed a Wireless Integrated Microelectronic Vacuum Sensor System (WIMVSS) that provides the ability to gather vacuum-gauge measurements automatically and wirelessly, in near-real time - using a low-maintenance, lowpower sensor mesh network. The WIMVSS operates by using a self-configuring mesh network of wireless sensor units. Mesh networking is a type of networking where each sensor or node can capture and disseminate its own data, but also serve as a relay to receive and transmit data from other sensors. Each sensor node can synchronize with adjacent sensors, and propagate data from one sensor to the next, until the destination is reached. In this case, the destination is a Network Interface Unit (NIU). The WIMVSS sensors are mounted on the existing vacuum gauges. Information gathered by the sensors is sent to the NIU. Because of the mesh networking, if a sensor cannot directly send the data to the NIU, it can be propagated through the network of sensors. The NIU requires antenna access to the sensor units, AC power, and an Ethernet connection. The NIU bridges the sensor network to a WIMVSS server via an Ethernet connection. The server is configured with a database, a Web server, and proprietary interface software that makes it possible for the vacuum measurements from vacuum jacketed fluid lines to be saved, retrieved, and then displayed from any Web-enabled PC that has access to the Internet. Authorized users can then simply access the data from any PC with Internet connection. Commands can also be sent directly from the Web interface for control and maintenance of the sensor network. The technology enabled by the WIMVSS decreases labor required for gathering vacuum measurements, increases access to vacuum data by making it available on any computer with access to the Internet, increases the frequency with which data points can be acquired for evaluating the system, and decreases the recurring cost of the sensors by using off-the-shelf components and integrating these with heritage vacuum gauges.

Krug, Eric↗

NASA NTRS2000

Intelligent Tutoring Systems for Procedural Task Training of Remote Payload Operations at NASA

Intelligent Tutoring Systems (ITSs) encode and apply the subject matter and teaching expertise of experienced instructors to provide students with individualized instruction automatically. ITSs complement training simulators by providing automated instruction when it is not economical or feasible to dedicate an instructor to each student during training simulations. Despite their proven training effectiveness and favorable operating cost, however, relatively few ITSs are in use. This is largely because it is usually costly and difficult to encode the task knowledge used by the ITS to evaluate the student's actions and assess the student's performance. Procedural tasks are tasks for which there exist procedures, guidelines, and strategies that determine the correct set of steps to be taken within each situation. To lower the cost and difficulty of creating tutoring systems for procedural task training, Stottler Henke Associates, Inc. (SHAI) worked closely with the Operations Training Group at NASA's Marshall Space Flight Center to develop the Task Tutor Toolkit (T (exp 3)), a generic tutoring system shell and scenario authoring tool. The Task Tutor Toolkit employs a case-based reasoning approach where the instructor creates a procedure template that specifies the range of student actions that are "correct" within each scenario. Because each procedure template is specific to a single scenario, the system can employ relatively simple reasoning methods to represent a correct set of actions and assess student performance. This simplicity enables a non-programmer to specify task knowledge quickly and easily by via graphical user interface, using a "demonstrate, generalize, and annotate" paradigm, that recognizes the range of possible valid actions and infers principles understood (or misunderstood) by the student when those actions are carried out. The Task Tutor Toolkit was also designed to be modular and general, so that it can be interfaced with a wide range of training simulators and support a variety of training domains. SHAI and NASA applied the Task Tutor Toolkit to create the Remote Payload Operations Tutor (RPOT). RPOT is a specific tutoring system application which lets scientists who are new to space mission operations learn to monitor and control their experiments aboard the International Space Station according to NASA payload regulations, guidelines, and procedures. The RPOT simulator lets students practice these skills by monitoring the telemetry variable values of a simple, hypothetical experiment, sending commands to the experiment, coordinating with NASA personnel via voice communication loops, and submitting and retrieving information via documents and forms. At the end of each scenario, RPOT displays the principles correctly or incorrectly demonstrated by the student, along with explanations and background information. The effectiveness of RPOT and the Task Tutor Toolkit are currently under evaluation at NASA.

Ong, James↗

NASA NTRS1994

Designing an autonomous environment for mission critical operation of the EUVE satellite

Since the launch of NASA's Extreme Ultraviolet Explorer (EUVE) satellite in 1992, there has only been a handful of occurrences that have warranted manual intervention in the EUVE Science Operations Center (ESOC). So, in an effort to reduce costs, the current environment is being redesigned to utilize a combination of off-the-shelf packages and recently developed artificial intelligence (AI) software to automate the monitoring of the science payload and ground systems. The successful implementation of systemic automation would allow the ESOC to evolve from a seven day/week, three shift operation, to a seven day/week one shift operation. First, it was necessary to identify all areas considered mission critical. These were defined as follows: (1) The telemetry stream must be monitored autonomously and anomalies identified. (2) Duty personnel must be automatically paged and informed of the occurrence of an anomaly. (3) The 'basic' state of the ground system must be assessed. (4) Monitors should check that the systems and processes needed to continue in a 'healthy' operational mode are working at all times. (5) Network loads should be monitored to ensure that they stay within established limits. (6) Connectivity to Goddard Space Flight Center (GSFC) systems should be monitored as well, not just for connectivity of the network itself but also for the ability to transfer files. (7) All necessary peripheral devices should be monitored. This would include the disks, routers, tape drives, printers, tape carousel, and power supplies. (8) System daemons such as the archival daemon, the Sybase server, the payload monitoring software, and any other necessary processes should be monitored to ensure that they are operational. (9) The monitoring system needs to be redundant so that the failure of a single machine will not paralyze the monitors. (10) Notification should be done by means of looking though a table of the pager numbers for current 'on call' personnel. The software should be capable of dialing out to notify, sending email, and producing error logs. (11) The system should have knowledge of when real-time passes and tape recorder dumps will occur and should know that these passes and data transmissions are successful. Once the design criteria were established, the design team split into two groups: one that addressed the tracking, commanding, and health and safety of the science payload and another group that addressed the ground systems and communications aspects of the overall system.

Abedini, Annadiana↗

NASA NTRS2010

Template Matching Approach to Signal Prediction

A new approach to signal prediction and prognostic assessment of spacecraft health resolves an inherent difficulty in fusing sensor data with simulated data. This technique builds upon previous work that demonstrated the importance of physics-based transient models to accurate prediction of signal dynamics and system performance. While models can greatly improve predictive accuracy, they are difficult to apply in general because of variations in model type, accuracy, or intended purpose. However, virtually any flight project will have at least some modeling capability at its disposal, whether a full-blown simulation, partial physics models, dynamic look-up tables, a brassboard analogue system, or simple hand-driven calculation by a team of experts. Many models can be used to develop a predict, or an estimate of the next day s or next cycle s behavior, which is typically used for planning purposes. The fidelity of a predict varies from one project to another, depending on the complexity of the simulation (i.e. linearized or full differential equations) and the level of detail in anticipated system operation, but typically any predict cannot be adapted to changing conditions or adjusted spacecraft command execution. Applying a predict blindly, without adapting the predict to current conditions, produces mixed results at best, primarily due to mismatches between assumed execution of spacecraft activities and actual times of execution. This results in the predict becoming useless during periods of complicated behavior, exactly when the predict would be most valuable. Each spacecraft operation tends to show up as a transient in the data, and if the transients are misaligned, using the predict can actually harm forecasting performance. To address this problem, the approach here expresses the predict in terms of a baseline function superposed with one or more transient functions. These transients serve as signal templates, which can be relocated in time and space against the signal background. One then has the ability to reconstruct a signal regardless of the precise timing of the transients. During operation, one applies the actual start times of spacecraft activities as they occur, and produces a reconstructed, accurate predict in real-time. This general approach is valid under two important conditions. First, the transients themselves must be time-invariant. Second, the transients must be reasonably consistent with respect to different operating points. Both of these assumptions are generally valid, but in the case of a complicated system with numerous types of overlapping transients, this approach may not be effective. Fortunately, there tend to be few transients in spacecraft telemetry of sensor quantities or low-level health and status information because these signals rarely reflect multiple different types of operation. Furthermore, if the predict is at least reasonably close to actual operation, the shift either in time, or in the operating point when the transient occurs - is likely to be small. The proposed approach considers three ways to recognize a transient. The first and most reliable is to use a different signal that identifies operating mode - often the transient will be correlated to a change in operating mode, and this change can usually be detected positively from discrete signals in spacecraft telemetry. If there is no useful mode signal, the second option is to identify the transient template by hand, and detect the onset of the transient using a curve-fitting approach. Finally, if one elects not to choose by hand, there is an option for automatic selection. This technique has been applied to sensor data from several JPL missions and industrial applications, demonstrating an improvement in accurate prediction of future behavior and early detection of system problems. This technique is applicable to practically any time-varying, quantitative sensor measurement.

Mackey, Ryan↗

NASA NTRS2010

360-Degree Visual Detection and Target Tracking on an Autonomous Surface Vehicle

This paper describes perception and planning systems of an autonomous sea surface vehicle (ASV) whose goal is to detect and track other vessels at medium to long ranges and execute responses to determine whether the vessel is adversarial. The Jet Propulsion Laboratory (JPL) has developed a tightly integrated system called CARACaS (Control Architecture for Robotic Agent Command and Sensing) that blends the sensing, planning, and behavior autonomy necessary for such missions. Two patrol scenarios are addressed here: one in which the ASV patrols a large harbor region and checks for vessels near a fixed asset on each pass and one in which the ASV circles a fixed asset and intercepts approaching vessels. This paper focuses on the ASV's central perception and situation awareness system, dubbed Surface Autonomous Visual Analysis and Tracking (SAVAnT), which receives images from an omnidirectional camera head, identifies objects of interest in these images, and probabilistically tracks the objects' presence over time, even as they may exist outside of the vehicle's sensor range. The integrated CARACaS/SAVAnT system has been implemented on U.S. Navy experimental ASVs and tested in on-water field demonstrations.

ASV (AUTONOMOUS SEA SURFACE VEHICLE)↗

NASA NTRS2004

Digital communication constraints in prior space missions

Digital communication is crucial for space endeavors. Jt transmits scientific and command data between earth stations and the spacecraft crew. It facilitates communications between astronauts, and provides live coverage during all phases of the mission. Digital communications provide ground stations and spacecraft crew precise data on the spacecraft position throughout the entire mission. Lessons learned from prior space missions are valuable for our new lunar and Mars missions set by our president s speech. These data will save our agency time and money, and set course our current developing technologies. Limitations on digital communications equipment pertaining mass, volume, data rate, frequency, antenna type and size, modulation, format, and power in the passed space missions are of particular interest. This activity is in support of ongoing communication architectural studies pertaining to robotic and human lunar exploration. The design capabilities and functionalities will depend on the space and power allocated for digital communication equipment. My contribution will be gathering these data, write a report, and present it to Communications Technology Division Staff. Antenna design is very carefully studied for each mission scenario. Currently, Phased array antennas are being developed for the lunar mission. Phased array antennas use little power, and electronically steer a beam instead of DC motors. There are 615 patches in the phased array antenna. These patches have to be modified to have high yield. 50 patches were created for testing. My part is to assist in the characterization of these patch antennas, and determine whether or not certain modifications to quartz micro-strip patch radiators result in a significant yield to warrant proceeding with repairs to the prototype 19 GHz ferroelectric reflect-array antenna. This work requires learning how to calibrate an automatic network, and mounting and testing antennas in coaxial fixtures. The purpose of this activity is to assist in the set-up of phase noise instrumentation, assist in the process of automated wire bonding, assist in the design and optimization of tunable microwave components, especially phase shifters, based on thin ferroelectric films, and learn how to use commercial electromagnetic simulation software.

Yassine, Nathan K.↗

NASA NTRS2010

A Comparison Between Orion Automated and Space Shuttle Rendezvous Techniques

The Orion spacecraft will replace the space shuttle and will be the first human spacecraft since the Apollo program to leave low earth orbit. This vehicle will serve as the cornerstone of a complete space transportation system with a myriad of mission requirements necessitating rendezvous to multiple vehicles in earth orbit, around the moon and eventually beyond . These goals will require a complex and robust vehicle that is, significantly different from both the space shuttle and the command module of the Apollo program. Historically, orbit operations have been accomplished with heavy reliance on ground support and manual crew reconfiguration and monitoring. One major difference with Orion is that automation will be incorporated as a key element of the man-vehicle system. The automated system will consist of software devoted to transitioning between events based on a master timeline. This effectively adds a layer of high level sequencing that moves control of the vehicle from one phase to the next. This type of automated control is not entirely new to spacecraft since the shuttle uses a version of this during ascent and entry operations. During shuttle orbit operations however many of the software modes and hardware switches must be manually configured through the use of printed procedures and instructions voiced from the ground. The goal of the automation scheme on Orion is to extend high level automation to all flight phases. The move towards automation represents a large shift from current space shuttle operations, and so these new systems will be adopted gradually via various safeguards. These include features such as authority-to-proceed, manual down modes, and functional inhibits. This paper describes the contrast between the manual and ground approach of the space shuttle and the proposed automation of the Orion vehicle. I will introduce typical orbit operations that are common to all rendezvous missions and go on to describe the current Orion automation architecture and contrast it with shuttle rendezvous techniques and circumstances. The shuttle rendezvous profile is timed to take approximately 3 days from orbit insertion to docking at the International Space Station (ISS). This process can be divided into 3 phases: far-field, mid-field and proximity operations. The far-field stage is characterized as the most quiescent phase. The spacecraft is usually too far to navigate using relative sensors and uses the Inertial Measurement Units (IMU s) to numerically solve for its position. The maneuvers are infrequent, roughly twice per day, and are larger than other burns in the profile. The shuttle uses this opportunity to take extensive ground based radar updates and keep high fidelity orbit states on the ground. This state is then periodically uplinked to the shuttle computers. The targeting solutions for burn maneuvers are also computed on the ground and uplinked. During the burn the crew is responsible for setting the shuttle attitude and configuring the propulsion system for ignition. Again this entire process is manually driven by both crew and ground activity. The only automatic processes that occur are associated with the real-time execution of the burn. The Orion automated functionality will seek to relieve the workload of both the crew and ground during this phase

Ruiz, Jose O,↗

NASA NTRS2015

Air Traffic Management Technology Demostration Phase 1 (ATD) Interval Management for Near-Term Operations Validation of Acceptability (IM-NOVA) Experiment

The Interval Management for Near-term Operations Validation of Acceptability (IM-NOVA) experiment was conducted at the National Aeronautics and Space Administration (NASA) Langley Research Center (LaRC) in support of the NASA Airspace Systems Program's Air Traffic Management Technology Demonstration-1 (ATD-1). ATD-1 is intended to showcase an integrated set of technologies that provide an efficient arrival solution for managing aircraft using Next Generation Air Transportation System (NextGen) surveillance, navigation, procedures, and automation for both airborne and ground-based systems. The goal of the IMNOVA experiment was to assess if procedures outlined by the ATD-1 Concept of Operations were acceptable to and feasible for use by flight crews in a voice communications environment when used with a minimum set of Flight Deck-based Interval Management (FIM) equipment and a prototype crew interface. To investigate an integrated arrival solution using ground-based air traffic control tools and aircraft Automatic Dependent Surveillance-Broadcast (ADS-B) tools, the LaRC FIM system and the Traffic Management Advisor with Terminal Metering and Controller Managed Spacing tools developed at the NASA Ames Research Center (ARC) were integrated into LaRC's Air Traffic Operations Laboratory (ATOL). Data were collected from 10 crews of current 757/767 pilots asked to fly a high-fidelity, fixed-based simulator during scenarios conducted within an airspace environment modeled on the Dallas-Fort Worth (DFW) Terminal Radar Approach Control area. The aircraft simulator was equipped with the Airborne Spacing for Terminal Area Routes (ASTAR) algorithm and a FIM crew interface consisting of electronic flight bags and ADS-B guidance displays. Researchers used "pseudo-pilot" stations to control 24 simulated aircraft that provided multiple air traffic flows into the DFW International Airport, and recently retired DFW air traffic controllers served as confederate Center, Feeder, Final, and Tower controllers. Analyses of qualitative data revealed that the procedures used by flight crews to receive and execute interval management (IM) clearances in a voice communications environment were logical, easy to follow, did not contain any missing or extraneous steps, and required the use of an acceptable workload level. The majority of the pilot participants found the IM concept, in addition to the proposed FIM crew procedures, to be acceptable and indicated that the ATD-1 procedures could be successfully executed in a nearterm NextGen environment. Analyses of quantitative data revealed that the proposed procedures were feasible for use by flight crews in a voice communications environment. The delivery accuracy at the achieve-by point was within +/-5 sec, and the delivery precision was less than 5 sec. Furthermore, FIM speed commands occurred at a rate of less than one per minute, and pilots found the frequency of the speed commands to be acceptable at all times throughout the experiment scenarios.

Kibler, Jennifer L.↗