Search NASA⌕ Search

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.

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

At least 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Patient ECG recording control for an automatic implantable defibrillator

An implantable automatic defibrillator includes sensors which are placed on or near the patient's heart to detect electrical signals indicative of the physiology of the heart. The signals are digitally converted and stored into a FIFO region of a RAM by operation of a direct memory access (DMA) controller. The DMA controller operates transparently with respect to the microprocessor which is part of the defibrillator. The implantable defibrillator includes a telemetry communications circuit for sending data outbound from the defibrillator to an external device (either a patient controller or a physician's console or other) and a receiver for sensing at least an externally generated patient ECG recording command signal. The patient recording command signal is generated by the hand held patient controller. Upon detection of the patient ECG recording command, DMA copies the contents of the FIFO into a specific region of the RAM.

Fountain, Glen H.↗
NASA NTRS2008

Displaying Composite and Archived Soundings in the Advanced Weather Interactive Processing System

In a previous task, the Applied Meteorology Unit (AMU) developed spatial and temporal climatologies of lightning occurrence based on eight atmospheric flow regimes. The AMU created climatological, or composite, soundings of wind speed and direction, temperature, and dew point temperature at four rawinsonde observation stations at Jacksonville, Tampa, Miami, and Cape Canaveral Air Force Station, for each of the eight flow regimes. The composite soundings were delivered to the National Weather Service (NWS) Melbourne (MLB) office for display using the National version of the Skew-T Hodograph analysis and Research Program (NSHARP) software program. The NWS MLB requested the AMU make the composite soundings available for display in the Advanced Weather Interactive Processing System (AWIPS), so they could be overlaid on current observed soundings. This will allow the forecasters to compare the current state of the atmosphere with climatology. This presentation describes how the AMU converted the composite soundings from NSHARP Archive format to Network Common Data Form (NetCDF) format, so that the soundings could be displayed in AWl PS. The NetCDF is a set of data formats, programming interfaces, and software libraries used to read and write scientific data files. In AWIPS, each meteorological data type, such as soundings or surface observations, has a unique NetCDF format. Each format is described by a NetCDF template file. Although NetCDF files are in binary format, they can be converted to a text format called network Common data form Description Language (CDL). A software utility called ncgen is used to create a NetCDF file from a CDL file, while the ncdump utility is used to create a CDL file from a NetCDF file. An AWIPS receives soundings in Binary Universal Form for the Representation of Meteorological data (BUFR) format (http://dss.ucar.edu/docs/formats/bufr/), and then decodes them into NetCDF format. Only two sounding files are generated in AWIPS per day. One file contains all of the soundings received worldwide between 0000 UTC and 1200 UTC, and the other includes all soundings between 1200 UTC and 0000 UTC. In order to add the composite soundings into AWIPS, a procedure was created to configure, or localize, AWIPS. This involved modifying and creating several configuration text files. A unique fourcharacter site identifier was created for each of the 32 soundings so each could be viewed separately. The first three characters were based on the site identifier of the observed sounding, while the last character was based on the flow regime. While researching the localization process for soundings, the AMU discovered a method of archiving soundings so old soundings would not get purged automatically by AWl PS. This method could provide an alternative way of localizing AWl PS for composite soundings. In addition, this would allow forecasters to use archived soundings in AWIPS for case studies. A test sounding file in NetCDF format was written in order to verify the correct format for soundings in AWIPS. After the file was viewed successfully in AWIPS, the AMU wrote a software program in the Tool Command Language/Tool Kit (Tcl/Tk) language to convert the 32 composite soundings from NSHARP Archive to CDL format. The ncgen utility was then used to convert the CDL file to a NetCDF file. The NetCDF file could then be read and displayed in AWIPS.

Barrett, Joe H., III↗
NASA NTRS2016

Biotube

Biotube was developed for plant gravitropic research investigating the potential for magnetic fields to orient plant roots as they grow in microgravity. Prior to flight, experimental seeds are placed into seed cassettes, that are capable of containing up to 10 seeds, and inserted between two magnets located within one of three Magnetic Field Chamber (MFC). Biotube is stored within an International Space Station (ISS) stowage locker and provides three levels of containment for chemical fixatives. Features include monitoring of temperature, fixative/ preservative delivery to specimens, and real-time video imaging downlink. Biotube's primary subsystems are: (1) The Water Delivery System that automatically activates and controls the delivery of water (to initiate seed germination). (2) The Fixative Storage and Delivery System that stores and delivers chemical fixative or RNA later to each seed cassette. (3) The Digital Imaging System consisting of 4 charge-coupled device (CCD) cameras, a video multiplexer, a lighting multiplexer, and 16 infrared light-emitting diodes (LEDs) that provide illumination while the photos are being captured. (4) The Command and Data Management System that provides overall control of the integrated subsystems, graphical user interface, system status and error message display, image display, and other functions.

Biotube↗
NASA NTRS1990

CLIPS enhanced with objects, backward chaining and explanation facilities

In this project we extend C Language Production System (CLIPS), an existing Expert System shell, by creating three new options. Specifically, first we create a compatible with CLIPS environment that allows for defining objects and object hierarchies, second we provide means to implement backward chaining in a pure forward chaining environment, and finally we give some simple explanation facilities for the derivations the system has made. Objects and object hierarchies are extended so that facts can be automatically inferred, and placed in the fact base. Backward chaining is implemented by creating run time data structures which hold the derivation process allowing for a depth first search. The backward chaining mechanism works not only with ground facts, but also creates bindings for every query that involves variables, and returns the truth value of such a query as well as the relevant variable bindings. Finally, the WHY and HOW explanation facilities allow for a complete examination of the derivation process, the rules triggered, and the bindings created. The entire system is integrated with the original CLIPS code, and all of its routines can be invoked as CLIPS commands.

Aldrobi, M.↗
NASA NTRS1987

Orbital Spacecraft Consumables Resupply System (OSCRS): Monopropellant application to space station and OMV automatic refueling impacts of an ELV launch, volume 4

The use of orbital spacecraft consumables resupply system (OSCRS) at the Space Station is investigated, its use with the orbital maneuvering vehicle, and launch of the OSCRS on an expendable launch vehicles. A system requirements evaluation was performed initially to identify any unique requirements that would impact the design of OSCRS when used at the Space Station. Space Station documents were reviewed to establish requirements and to identify interfaces between the OSCRS, Shuttle, and Space Station, especially the Servicing Facility. The interfaces between OSCRS and the Shuttle consists of an avionics interface for command and control and a structural interface for launch support and for grappling with the Shuttle Remote Manipulator System. For use of the OSCRS at the Space Station, three configurations were evaluated using the results of the interface definition to increase the efficiency of OSCRS and to decrease the launch weight by Station-basing specific OSCRS subsystems. A modular OSCRS was developed in which the major subsystems were Station-based where possible. The configuration of an OSCRS was defined for transport of water to the Space Station.

Source record↗
NASA NTRS1975

Results of the 1973 NASA/JPL balloon flight solar cell calibration program

High altitude balloon flights carried 37 standard solar cells for calibration above 99.5 percent of the earth's atmosphere. The cells were assembled into standard modules with appropriate resistors to load each cell at short circuit current. Each standardized module was mounted at the apex of the balloon on a sun tracker which automatically maintained normal incidence to the sun within 1.0 deg. The balloons were launched to reach a float altitude of approximately 36.6 km two hours before solar noon and remain at float altitude for two hours beyond solar noon. Telemetered calibration data on each standard solar cell was collected and recorded on magnetic tape. At the end of each float period the solar cell payload was separated from the balloon by radio command and descended via parachute to a ground recovery crew. Standard solar cells calibrated and recovered in this manner are used as primary intensity reference standards in solar simulators and in terrestrial sunlight for evaluating the performance of other solar cells and solar arrays with similar spectral response characteristics.

Yasui, R. K.↗
NASA NTRS1991

A geometric approach to regulator and tracker design for an aerospace plane

The paper presents a nonlinear design approach drawing from singular perturbations, feedback linearization, and variable structure control, that leads to regulators with automatic gain scheduling which exhibit similar dynamic behavior over the entire flight envelope of the aerospace plane. Additionally, design approach provides for a systematic way to counter disturbance effects as well as modeling uncertainties. The unifying feature of the three nonlinear feedback control methodologies is that they all have a geometric interpretation. First, the translational dynamics are decomposed into reduced-order slow and fast dynamics by way of a formal singular perturbation analysis. After feedback linearization the fast dynamics are robustly stabilized via a variable structure control approach. The slow dynamics are stabilized using conventional proportional-integral compensation based on the nominal slow dynamics. A number of sample command and disturbance responses at opposite ends of the flight envelope are presented for a nonlinear aerospace plane model.

Van Buren, Mark A.↗
NASA NTRS1982

Terminal area automatic navigation, guidance, and control research using the Microwave Landing System (MLS). Part 2: RNAV/MLS transition problems for aircraft

The problems in navigation and guidance encountered by aircraft in the initial transition period in changing from distance measuring equipment, VORTAC, and barometric instruments to the more precise microwave landing system data type navaids in the terminal area are investigated. The effects of the resulting discontinuities on the estimates of position and velocity for both optimal (Kalman type navigation schemes) and fixed gain (complementary type) navigation filters, and the effects of the errors in cross track, track angle, and altitude on the guidance equation and control commands during the critical landing phase are discussed. A method is presented to remove the discontinuities from the navigation loop and to reconstruct an RNAV path designed to land the aircraft with minimal turns and altitude changes.

Pines, S.↗
NASA NTRS2000

ICEG2D: An Integrated Software Package for Automated Prediction of Flow Fields for Single-Element Airfoils with Ice Accretion

An integrated software package, ICEG2D, was developed to automate computational fluid dynamics (CFD) simulations for single-element airfoils with ice accretion. ICEG2D is designed to automatically perform three primary functions: (1) generating a grid-ready, surface definition based on the geometrical characteristics of the iced airfoil surface, (2) generating a high-quality grid using the generated surface point distribution, and (3) generating the input and restart files needed to run the general purpose CFD solver NPARC. ICEG2D can be executed in batch mode using a script file or in an interactive mode by entering directives from a command line. This report summarizes activities completed in the first year of a three-year research and development program to address issues related to CFD simulations for aircraft components with ice accretion. Specifically, this document describes the technology employed in the software, the installation procedure, and a description of the operation of the software package. Validation of the geometry and grid generation modules of ICEG2D is also discussed.

Thompson, David S.↗
NASA NTRS2005

Automating CapCom Using Mobile Agents and Robotic Assistants

We have developed and tested an advanced EVA communications and computing system to increase astronaut self-reliance and safety, reducing dependence on continuous monitoring and advising from mission control on Earth. This system, called Mobile Agents (MA), is voice controlled and provides information verbally to the astronauts through programs called personal agents. The system partly automates the role of CapCom in Apollo-including monitoring and managing EVA navigation, scheduling, equipment deployment, telemetry, health tracking, and scientific data collection. EVA data are stored automatically in a shared database in the habitat/vehicle and mirrored to a site accessible by a remote science team. The program has been developed iteratively in the context of use, including six years of ethnographic observation of field geology. Our approach is to develop automation that supports the human work practices, allowing people to do what they do well, and to work in ways they are most familiar. Field experiments in Utah have enabled empirically discovering requirements and testing alternative technologies and protocols. This paper reports on the 2004 system configuration, experiments, and results, in which an EVA robotic assistant (ERA) followed geologists approximately 150 m through a winding, narrow canyon. On voice command, the ERA took photographs and panoramas and was directed to move and wait in various locations to serve as a relay on the wireless network. The MA system is applicable to many space work situations that involve creating and navigating from maps (including configuring equipment for local topology), interacting with piloted and unpiloted rovers, adapting to environmental conditions, and remote team collaboration involving people and robots.

Clancey, William J.↗
NASA NTRS2014

LADEE Multi-Domain Simulation

The Lunar Atmosphere Dust Environment Explorer (LADEE) was a small explorer class spacecraft that was launched on Sept 7, 2013 and that was de-orbited and successfully impacted the Moons surface on April 17, 2014 after completing all of the mission objectives. The low-cost rapidly prototyped hardware design used for the spacecraft was extend to the development of the software base. To achieve this goal, a Model Based Design approach was utilized to develop the onboard flight software, and out of this development a model based multipurpose simulator was created of the LADEE spacecraft and its mission environment. This simulator extended the traditional function of propagating the vehicle's kinematic and rotational states and included the electrical and thermal states propagation. Traditionally, these domains are handled by domain specific high fidelity simulations that use the states histories from other domains as input. By reducing the fidelity and abstracting the relevant features being monitored and controlled by the flight software, it was possible to model the coupling across these domains resulting in more accurate overall system behavior. A faster than real-time workstation (WSIM) version of the LADEE simulator was used to develop and test the software control algorithms in the Simulink environment. To maximize the performance of the simulation, modeling knobs were introduced to reduce the resolution of the some of the domains models when the effects of that domain were not significant for the scope of that simulation. The automatic code generation feature in Simulink was used to port the simulation to several real-time environments to support Processor-in-the-Loop (PIL) and Hardware-in-the-Loop (HIL) testing, verification and validation. The real-time environment required that the design of each of the domain models be deterministic as possible in the time required to perform all of the calculations to update its states. The simulation interface was designed to be compatible with the command interface employed by the LADEE mission operation team. The WSIM, PIL, and HIL simulators thus used a common interface and thus were used for flight software testing, for mission operations personnel training (nominal and off-nominal operations) prior to the mission and to perform command sequence verification during the mission. This presentation will look at the modeling strategies used to create a common interface to the simulator and to model and couple multiple domains within the simulation, the results of those strategies, and the lessons learned.

Multi-Domain↗
DOE OSTI2024

Mesh Computing Remote Automatic Workflow

The software suite uses a microservice architecture using Docker and `docker-compose`. The microservices are as follows: 1. User interface. This interface is written in JavaScript using the Svelte framework. It exposes form elements and a 3D visualizer to prompt the user through the definition of microstructure parameters, and setting parameters for mesh generation and refinement. 2. Mesh generator. This is a container running the Python package for DREAM3D to generate a voxelized mesh that represents a microstructure defined by the user in the interface. 3. Cubit runner. This is a secure shell protocol tool that makes the submitting the DREAM mesh to an HPC instance and starts to run Cubit shell commands to smooth the grain boundaries with its `sculpt` library, applies user-defined boundary node sets, and bundles and returns the simulation-ready meshes and input files as a zipped directory.

Harris, BrennanKay↗
NASA NTRS1976

Manual and automatic flight control during severe turbulence penetration

An analytical and experimental investigation of possible contributing factors in jet aircraft turbulence upsets was conducted. Major contributing factors identified included autopilot and display deficiencies, the large aircraft inertia and associated long response time, and excessive pilot workload. An integrated flight and thrust energy management director system was synthesized. The system was incorporated in a moving-base simulation and evaluated using highly experienced airline pilots. The evaluation included comparison of pilot workload and flight performance during severe turbulence penetration utilizing four control/display concepts: manual control with conventional full panel display, conventional autopilot (A/P-A) with conventional full panel display, improved autopilot (A/P-B) with conventional full panel display plus thrust director display, and longitudinal flight director with conventional full panel display plus thrust director display. Simulation results show improved performance, reduced pilot workload, and a pilot preference for the autopilot system controlling to the flight director command and manual control of thrust following the trim thrust director.

Johnston, D. E.↗
NASA NTRS2008

Automatic Testcase Generation for Flight Software

The TacSat3 project is applying Integrated Systems Health Management (ISHM) technologies to an Air Force spacecraft for operational evaluation in space. The experiment will demonstrate the effectiveness and cost of ISHM and vehicle systems management (VSM) technologies through onboard operation for extended periods. We present two approaches to automatic testcase generation for ISHM: 1) A blackbox approach that views the system as a blackbox, and uses a grammar-based specification of the system's inputs to automatically generate *all* inputs that satisfy the specifications (up to prespecified limits); these inputs are then used to exercise the system. 2) A whitebox approach that performs analysis and testcase generation directly on a representation of the internal behaviour of the system under test. The enabling technologies for both these approaches are model checking and symbolic execution, as implemented in the Ames' Java PathFinder (JPF) tool suite. Model checking is an automated technique for software verification. Unlike simulation and testing which check only some of the system executions and therefore may miss errors, model checking exhaustively explores all possible executions. Symbolic execution evaluates programs with symbolic rather than concrete values and represents variable values as symbolic expressions. We are applying the blackbox approach to generating input scripts for the Spacecraft Command Language (SCL) from Interface and Control Systems. SCL is an embedded interpreter for controlling spacecraft systems. TacSat3 will be using SCL as the controller for its ISHM systems. We translated the SCL grammar into a program that outputs scripts conforming to the grammars. Running JPF on this program generates all legal input scripts up to a prespecified size. Script generation can also be targeted to specific parts of the grammar of interest to the developers. These scripts are then fed to the SCL Executive. ICS's in-house coverage tools will be run to measure code coverage. Because the scripts exercise all parts of the grammar, we expect them to provide high code coverage. This blackbox approach is suitable for systems for which we do not have access to the source code. We are applying whitebox test generation to the Spacecraft Health INference Engine (SHINE) that is part of the ISHM system. In TacSat3, SHINE will execute an on-board knowledge base for fault detection and diagnosis. SHINE converts its knowledge base into optimized C code which runs onboard TacSat3. SHINE can translate its rules into an intermediate representation (Java) suitable for analysis with JPF. JPF will analyze SHINE's Java output using symbolic execution, producing testcases that can provide either complete or directed coverage of the code. Automatically generated test suites can provide full code coverage and be quickly regenerated when code changes. Because our tools analyze executable code, they fully cover the delivered code, not just models of the code. This approach also provides a way to generate tests that exercise specific sections of code under specific preconditions. This capability gives us more focused testing of specific sections of code.

Bushnell, David Henry↗
NASA NTRS2003

Keeping Communication Continuous

General Dynamics Decision Systems employees have played a role in supplying telemetry, tracking, and control (TT&C) and other communications systems to NASA and the U.S. Department of Defense for over 40 years. Providing integrated communication systems and subsystems for nearly all manned and unmanned U.S. space flights, the heritage of this Scottsdale, Arizona-based company includes S-band transceivers that enabled millions of Americans to see Neil Armstrong and hear his prophetic words from the Moon in 1969. More recently, Decision Systems has collaborated with NASA s Goddard Space Flight Center to develop transponders, wireless communications devices that pick up and automatically respond to an incoming signal, for NASA s Tracking and Data Relay Satellite System (TDRSS). Four generations of Decision Systems TDRSS transponders have been developed under Goddard s sponsorship. The company s Fourth Generation TDRSS User Transponder (TDRSS IV) allows low-Earth-orbiting spacecraft to communicate continuously with a single ground station at White Sands, New Mexico, through a constellation of geostationary relay satellites positioned at key locations around the Earth. In addition to the communications of forward link control commands and return link telemetry data, the TDRSS IV also supports spacecraft orbit tracking through coherent turn-around of a pseudo-noise ranging code and two-way Doppler tracking.When the NSBF adopted the use of global positioning system receivers for balloon position tracking, Decision Systems concluded that a simpler, noncoherent transceiver could provide the NSBF with the necessary TDRSS communications without the additional cost and complexity of a coherent transponder. The solution was to take the core design of the TDRSS IV Transponder, but remove the extra functionality that supported coherent turn-around. This would simplify the production effort, reduce the testing required, and result in a lower cost product with smaller size, weight, and power consumption. Once NSBF and Decision Systems agreed on a concept for this new product, known as the Multi-Mode Transceiver (MMT), the NSBF approached Goddard for approval and funding.

Source record↗
NASA NTRS2004

Development of a State Machine Sequencer for the Keck Interferometer: Evolution, Development and Lessons Learned using a CASE Tool Approach

This paper presents a discussion of the evolution of a sequencer from a simple EPICS (Experimental Physics and Industrial Control System) based sequencer into a complex implementation designed utilizing UML (Unified Modeling Language) methodologies and a CASE (Computer Aided Software Engineering) tool approach. The main purpose of the sequencer (called the IF Sequencer) is to provide overall control of the Keck Interferometer to enable science operations be carried out by a single operator (and/or observer). The interferometer links the two 10m telescopes of the W. M. Keck Observatory at Mauna Kea, Hawaii. The IF Sequencer is a high-level, multi-threaded, Hare1 finite state machine, software program designed to orchestrate several lower-level hardware and software hard real time subsystems that must perform their work in a specific and sequential order. The sequencing need not be done in hard real-time. Each state machine thread commands either a high-speed real-time multiple mode embedded controller via CORB A, or slower controllers via EPICS Channel Access interfaces. The overall operation of the system is simplified by the automation. The UML is discussed and our use of it to implement the sequencer is presented. The decision to use the Rhapsody product as our CASE tool is explained and reflected upon. Most importantly, a section on lessons learned is presented and the difficulty of integrating CASE tool automatically generated C++ code into a large control system consisting of multiple infrastructures is presented.

interferometer↗
NASA NTRS1997

Pilot Non-Conformance to Alerting System Commands

This research project examined the effects of consonance between cockpit displays and alerting system as a technique to encourage pilots to conform to alerting system commands. An experiment used the task of collision avoidance during closely spaced parallel approaches as a case study, building upon previous experiments which identified instances of non-conformance and conflicts between the alerting criteria preferred by pilots, compared to that used by alerting systems. Using a workstation based, part-task simulator, each of 45 subjects completed 45 experiment runs. In each run, the subjects were told they were flying an approach. Their primary task was to keep their wings level despite turbulence through the use of a sidestick. The sidestick commands did not affect the path of the aircraft, however, so that consistent approach paths were be followed. Their secondary task was to indicate when an aircraft on a parallel approach is blundering towards them, as evidenced by the traffic display. Subjects were asked to press different buttons indicating whether they feel an avoidance maneuver is required by the traffic situation or not. At the completion of each run, subjects were asked to rate their confidence in their decision and, if appropriate, to rate the timeliness of automatic alerts when had been given. Three different automatic alert conditions were tested. The "No Automatic Alerts Given" condition is self-explanatory. In the "Automatic Alerts Based on NTZ Criteria" condition, an automatic alert was given when the NTZ criteria was triggered; this criteria is consistent with subject reactions in other studies, in which subjects were found to react, on average, when the other aircraft was 1350 min to the side of the own aircraft. In the "Automatic Alerts Based on MIT Criteria" condition, an automatic alert was given when the MIT criteria was triggered; this criteria was developed by Carpenter and Kuchar for parallel approaches to have better performance, at the cost of increased complexity and higher sensitivity to pilot non-conformance. Three displays were tested. The "Baseline Display" is based on a moving map display, with a top-down view, track-up orientation, iconic presentation of the other aircraft's positions and a text presentation of the other aircraft's altitude. The "NTZ Alert Criteria Shown" display added to the Baseline Display an explicit presentation on the display of the boundary delineating the NTZ criteria, allowing for quick comparison of the other aircraft's position relative to this alert criteria. Likewise, the "MIT Alert Criteria Shown" display added to the Baseline Display an explicit presentation on the display of the boundary delineating the MIT criteria, allowing for quick comparison of the other aircraft's position relative to this alert criteria The test matrix for this experiment was three dimensional, varying displays, alerts and traffic conflict scenarios.

Pritchett, Amy↗
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↗