Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “logic”

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 901 records · Page 50
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Filling the Assurance Gap on Complex Electronics

Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled by software, such as communication protocols. For example, the James Webb Space Telescope will use Field Programmable Gate Arrays (FPGAs), which can have over a million logic gates, to send telemetry. System-on-chip (SoC) devices, another type of complex electronics, can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, mature software methodologies have been proposed, with slight modifications, to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and bugs can be detected earlier in the development cycle, thus creating a development process for CE that can be easily maintained and configurable based on the device used.

Plastow, Richard A.↗
NASA NTRS2007

Software Process Assurance for Complex Electronics (SPACE)

Complex Electronics (CE) are now programmed to perform tasks that were previously handled in software, such as communication protocols. Many of the methods used to develop software bare a close resemblance to CE development. For instance, Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications in the development of these devices. Software Process Assurance for Complex Electronics (SPACE) is a research project that looks at using standardized S/W Assurance/Engineering practices to provide an assurance framework for development activities. Tools such as checklists, best practices and techniques can be used to detect missing requirements and bugs earlier in the development cycle creating a development process for CE that will be more easily maintained, consistent and configurable based on the device used.

Plastow, Richard A.↗
NASA NTRS1987

Pointing compensation system for spacecraft instruments

A closed loop system reduces pointing errors in one or more spacecraft instruments. Associated with each instrument is a electronics package (3) for commanding motion in that instrument and a pointing control system (5) for imparting motion in that instrument in response to a command (4) from the commanding package (3). Spacecraft motion compensation logic (25) compensates for instrument pointing errors caused by instrument-motion-induced spacecraft motion. Any finite number of instruments can be so compensated, by providing each pointing control system (5) and each commanding package (3), for the instruments desired to be compensated, with a link to the spacecraft motion compensation logic (25). The spacecraft motion compensation logic (25) is an electronic manifestation of the algebraic negative of a model of the dynamics of motion of the spacecraft. An example of a suitable model, and computer-simulated results, are presented.

Plescia, Carl T.↗
NASA NTRS1987

Method and apparatus for characterizing propagation delays of integrated circuit devices

Propagation delay of a signal through a channel is measured by cyclically generating a first step-wave signal for transmission through the channel to a two-input logic element and a second step-wave signal with a controlled delay to the second input terminal of the logic element. The logic element determines which signal is present first at its input terminals and stores a binary signal indicative of that determination for control of the delay of the second signal which is advanced or retarded for the next cycle until both the propagation delayed first step-wave signal and the control delayed step-wave signal are coincident. The propagation delay of the channel is then determined by measuring the time between the first and second step-wave signals out of the controlled step-wave signal generator.

Blaes, Brent R.↗
NASA NTRS1989

Multi-port, optically addressed RAM

A random access memory addressing system utilizing optical links between memory and the read/write logic circuits comprises addressing circuits including a plurality of light signal sources, a plurality of optical gates including optical detectors associated with the memory cells, and a holographic optical element adapted to reflect and direct the light signals to the desired memory cell locations. More particularly, it is a multi-port, binary computer memory for interfacing with a plurality of computers. There are a plurality of storage cells for containing bits of binary information, the storage cells being disposed at the intersections of a plurality of row conductors and a plurality of column conductors. There is interfacing logic for receiving information from the computers directing access to ones of the storage cells. There are first light sources associated with the interfacing logic for transmitting a first light beam with the access information modulated thereon. First light detectors are associated with the storage cells for receiving the first light beam, for generating an electrical signal containing the access information, and for conducting the electrical signal to the one of the storage cells to which it is directed. There are holographic optical elements for reflecting the first light beam from the first light sources to the first light detectors.

Johnston, Alan R.↗
NASA NTRS1990

High-speed dynamic domino circuit implemented with gaas mesfets

A dynamic logic circuit (AND or OR) utilizes one depletion-mode metal-semiconductor FET for precharging an internal node A, and a plurality of the same type of FETs in series, or a FET in parallel with one or more of the series connected FETs for implementing the logic function. A pair of FETs are connected to provide an output inverter with two series diodes for level shift. A coupling capacitor may be employed with a further FET to provide level shifting required between the inverter and the logic circuit output terminal. These circuits may be cascaded to form a domino chain.

Yang, Long↗
NASA NTRS2007

Circuit and Method for Communication Over DC Power Line

A circuit and method for transmitting and receiving on-off-keyed (OOK) signals with fractional signal-to-noise ratios uses available high-temperature silicon- on-insulator (SOI) components to move computational, sensing, and actuation abilities closer to high-temperature or high-ionizing radiation environments such as vehicle engine compartments, deep-hole drilling environments, industrial control and monitoring of processes like smelting, and operations near nuclear reactors and in space. This device allows for the networking of multiple, like nodes to each other and to a central processor. It can do this with nothing more than the already in-situ power wiring of the system. The device s microprocessor allows it to make intelligent decisions within the vehicle operational loop and to effect control outputs to its associated actuators. The figure illustrates how each node converts digital serial data to OOK 18-kHz in transmit mode and vice-versa in receive mode; though operations at lower frequencies or up to a megahertz are within reason using this method and these parts. This innovation s technique modulates a DC power bus with millivolt-level signals through a MOSFET (metal oxide semiconductor field effect transistor) and resistor by OOK. It receives and demodulates this signal from the DC power bus through capacitive coupling at high temperature and in high ionizing radiation environments. The demodulation of the OOK signal is accomplished by using an asynchronous quadrature detection technique realized by a quasi-discrete Fourier transform through use of the quadrature components (0 and 90 phases) of the carrier frequency as generated by the microcontroller and as a function of the selected crystal frequency driving its oscillator. The detected signal is rectified using an absolute-value circuit containing no diodes (diodes being non-operational at high temperatures), and only operational amplifiers. The absolute values of the two phases of the received signal are then summed and hard limited (digitized) by comparing them to a reference level and are then input into a microprocessor as a serial bit stream. The quasi-discrete Fourier transform is performed in high-temperature components (operational amplifiers, analog switches, resistors, and capacitors). The demodulated signal is a serial data stream that is input to the UART (universal asynchronous receiver transmitter) receiver pin of the microprocessor. The OOK of the carrier frequency uses the output of the UART pin as an enabling signal that drives the gate of the MOSFET. Logic low bits enable the carrier frequency (realized by using the 0 phase signal from the microcontroller, though either phase may be used) to be DC-coupled to the power supply bus through a current-limiting resistor mounted between the MOSFET drain and the supply rail. The presence of logic lows on the power supply rail is realized by carrier bursts while logic highs are realized by the absence of bursts.

Krasowski, Michael J.↗
NASA NTRS2010

Decision Engines for Software Analysis Using Satisfiability Modulo Theories Solvers

The area of software analysis, testing and verification is now undergoing a revolution thanks to the use of automated and scalable support for logical methods. A well-recognized premise is that at the core of software analysis engines is invariably a component using logical formulas for describing states and transformations between system states. The process of using this information for discovering and checking program properties (including such important properties as safety and security) amounts to automatic theorem proving. In particular, theorem provers that directly support common software constructs offer a compelling basis. Such provers are commonly called satisfiability modulo theories (SMT) solvers. Z3 is a state-of-the-art SMT solver. It is developed at Microsoft Research. It can be used to check the satisfiability of logical formulas over one or more theories such as arithmetic, bit-vectors, lists, records and arrays. The talk describes some of the technology behind modern SMT solvers, including the solver Z3. Z3 is currently mainly targeted at solving problems that arise in software analysis and verification. It has been applied to various contexts, such as systems for dynamic symbolic simulation (Pex, SAGE, Vigilante), for program verification and extended static checking (Spec#/Boggie, VCC, HAVOC), for software model checking (Yogi, SLAM), model-based design (FORMULA), security protocol code (F7), program run-time analysis and invariant generation (VS3). We will describe how it integrates support for a variety of theories that arise naturally in the context of the applications. There are several new promising avenues and the talk will touch on some of these and the challenges related to SMT solvers. Proceedings

Bjorner, Nikolaj↗
NASA NTRS2011

Interface Supports Multiple Broadcast Transceivers for Flight Applications

A wireless avionics interface provides a mechanism for managing multiple broadcast transceivers. This interface isolates the control logic required to support multiple transceivers so that the flight application does not have to manage wireless transceivers. All of the logic to select transceivers, detect transmitter and receiver faults, and take autonomous recovery action is contained in the interface, which is not restricted to using wireless transceivers. Wired, wireless, and mixed transceiver technologies are supported. This design s use of broadcast data technology provides inherent cross strapping of data links. This greatly simplifies the design of redundant flight subsystems. The interface fully exploits the broadcast data link to determine the health of other transceivers used to detect and isolate faults for fault recovery. The interface uses simplified control logic, which can be implemented as an intellectual-property (IP) core in a field-programmable gate array (FPGA). The interface arbitrates the reception of inbound data traffic appearing on multiple receivers. It arbitrates the transmission of outbound traffic. This system also monitors broadcast data traffic to determine the health of transmitters in the network, and then uses this health information to make autonomous decisions for routing traffic through transceivers. Multiple selection strategies are supported, like having an active transceiver with the secondary transceiver powered off except to send periodic health status reports. Transceivers can operate in round-robin for load-sharing and graceful degradation.

Block, Gary L.↗
NASA NTRS2006

Mercury Shopping Cart Interface

Mercury Shopping Cart Interface (MSCI) is a reusable component of the Power User Interface 5.0 (PUI) program described in another article. MSCI is a means of encapsulating the logic and information needed to describe an orderable item consistent with Mercury Shopping Cart service protocol. Designed to be used with Web-browser software, MSCI generates Hypertext Markup Language (HTML) pages on which ordering information can be entered. MSCI comprises two types of Practical Extraction and Report Language (PERL) modules: template modules and shopping-cart logic modules. Template modules generate HTML pages for entering the required ordering details and enable submission of the order via a Hypertext Transfer Protocol (HTTP) post. Shopping cart modules encapsulate the logic and data needed to describe an individual orderable item to the Mercury Shopping Cart service. These modules evaluate information entered by the user to determine whether it is sufficient for the Shopping Cart service to process the order. Once an order has been passed from MSCI to a deployed Mercury Shopping Cart server, there is no further interaction with the user.

Pfister, Robin↗
NASA NTRS2005

Training Software in Artificial-Intelligence Computing Techniques

The Artificial Intelligence (AI) Toolkit is a computer program for training scientists, engineers, and university students in three soft-computing techniques (fuzzy logic, neural networks, and genetic algorithms) used in artificial-intelligence applications. The program promotes an easily understandable tutorial interface, including an interactive graphical component through which the user can gain hands-on experience in soft-computing techniques applied to realistic example problems. The tutorial provides step-by-step instructions on the workings of soft-computing technology, whereas the hands-on examples allow interaction and reinforcement of the techniques explained throughout the tutorial. In the fuzzy-logic example, a user can interact with a robot and an obstacle course to verify how fuzzy logic is used to command a rover traverse from an arbitrary start to the goal location. For the genetic algorithm example, the problem is to determine the minimum-length path for visiting a user-chosen set of planets in the solar system. For the neural-network example, the problem is to decide, on the basis of input data on physical characteristics, whether a person is a man, woman, or child. The AI Toolkit is compatible with the Windows 95,98, ME, NT 4.0, 2000, and XP operating systems. A computer having a processor speed of at least 300 MHz, and random-access memory of at least 56MB is recommended for optimal performance. The program can be run on a slower computer having less memory, but some functions may not be executed properly.

Howard, Ayanna↗
NASA NTRS2005

Fast Algorithms for Model-Based Diagnosis

Two improved new methods for automated diagnosis of complex engineering systems involve the use of novel algorithms that are more efficient than prior algorithms used for the same purpose. Both the recently developed algorithms and the prior algorithms in question are instances of model-based diagnosis, which is based on exploring the logical inconsistency between an observation and a description of a system to be diagnosed. As engineering systems grow more complex and increasingly autonomous in their functions, the need for automated diagnosis increases concomitantly. In model-based diagnosis, the function of each component and the interconnections among all the components of the system to be diagnosed (for example, see figure) are represented as a logical system, called the system description (SD). Hence, the expected behavior of the system is the set of logical consequences of the SD. Faulty components lead to inconsistency between the observed behaviors of the system and the SD. The task of finding the faulty components (diagnosis) reduces to finding the components, the abnormalities of which could explain all the inconsistencies. Of course, the meaningful solution should be a minimal set of faulty components (called a minimal diagnosis), because the trivial solution, in which all components are assumed to be faulty, always explains all inconsistencies. Although the prior algorithms in question implement powerful methods of diagnosis, they are not practical because they essentially require exhaustive searches among all possible combinations of faulty components and therefore entail the amounts of computation that grow exponentially with the number of components of the system.

Fijany, Amir↗
NASA NTRS2005

Full-Circle Resolver-to-Linear-Analog Converter

A circuit generates sinusoidal excitation signals for a shaft-angle resolver and, like the arctangent circuit described in the preceding article, generates an analog voltage proportional to the shaft angle. The disadvantages of the circuit described in the preceding article arise from the fact that it must be made from precise analog subcircuits, including a functional block capable of implementing some trigonometric identities; this circuitry tends to be expensive, sensitive to noise, and susceptible to errors caused by temperature-induced drifts and imprecise matching of gains and phases. These disadvantages are overcome by the design of the present circuit. The present circuit (see figure) includes an excitation circuit, which generates signals Ksin(Omega(t)) and Kcos(Omega(t)) [where K is an amplitude, Omega denotes 2(pi)x a carrier frequency (the design value of which is 10 kHz), and t denotes time]. These signals are applied to the excitation terminals of a shaft-angle resolver, causing the resolver to put out signals C sin(Omega(t)-Theta) and C cos(Omega(t)-Theta). The cosine excitation signal and the cosine resolver output signal are processed through inverting comparator circuits, which are configured to function as inverting squarers, to obtain logic-level or square-wave signals .-LL[cos(Omega(t)] and -LL[cos(Omega(t)-Theta)], respectively. These signals are fed as inputs to a block containing digital logic circuits that effectively measure the phase difference (which equals Theta between the two logic-level signals). The output of this block is a pulse-width-modulated signal, PWM(Theta), the time-averaged value of which ranges from 0 to 5 VDC as Theta ranges from .180 to +180deg. PWM(Theta) is fed to a block of amplifying and level-shifting circuitry, which converts the input PWM waveform to an output waveform that switches between precise reference voltage levels of +10 and -10 V. This waveform is processed by a two-pole, low-pass filter, which removes the carrier-frequency component. The final output signal is a DC potential, proportional to Theta that ranges continuously from -10 V at Theta = -180deg to +10 V at Theta = +180deg..

Alhorn, Dean C.↗
NASA NTRS2012

mREST Interface Specification

mREST is an implementation of the REST architecture specific to the management and sharing of data in a system of logical elements. The purpose of this document is to clearly define the mREST interface protocol. The interface protocol covers all of the interaction between mREST clients and mREST servers. System-level requirements are not specifically addressed. In an mREST system, there are typically some backend interfaces between a Logical System Element (LSE) and the associated hardware/software system. For example, a network camera LSE would have a backend interface to the camera itself. These interfaces are specific to each type of LSE and are not covered in this document. There are also frontend interfaces that may exist in certain mREST manager applications. For example, an electronic procedure execution application may have a specialized interface for configuring the procedures. This interface would be application specific and outside of this document scope. mREST is intended to be a generic protocol which can be used in a wide variety of applications. A few scenarios are discussed to provide additional clarity but, in general, application-specific implementations of mREST are not specifically addressed. In short, this document is intended to provide all of the information necessary for an application developer to create mREST interface agents. This includes both mREST clients (mREST manager applications) and mREST servers (logical system elements, or LSEs).

McCartney, Patrick↗
NASA NTRS2014

Using a Commercial Ethernet PHY Device in a Radiation Environment

This work involved placing a commercial Ethernet PHY on its own power boundary, with limited current supply, and providing detection methods to determine when the device is not operating and when it needs either a reset or power-cycle. The device must be radiation-tested and free of destructive latchup errors. The commercial Ethernet PHY's own power boundary must be supplied by a current-limited power regulator that must have an enable (for power cycling), and its maximum power output must not exceed the PHY's input requirements, thus preventing damage to the device. A regulator with configurable output limits and short-circuit protection (such as the RHFL4913, rad hard positive voltage regulator family) is ideal. This will prevent a catastrophic failure due to radiation (such as a short between the commercial device's power and ground) from taking down the board's main power. Logic provided on the board will detect errors in the PHY. An FPGA (field-programmable gate array) with embedded Ethernet MAC (Media Access Control) will work well. The error detection includes monitoring the PHY's interrupt line, and the status of the Ethernet's switched power. When the PHY is determined to be non-functional, the logic device resets the PHY, which will often clear radiation induced errors. If this doesn't work, the logic device power-cycles the FPGA by toggling the regulator's enable input. This should clear almost all radiation induced errors provided the device is not latched up.

Parks, Jeremy↗
NASA NTRS2013

The Integration of DCS I/O to an Existing PLC

At the NASA Glenn Research Center (GRC), Existing Programmable Logic Controller (PLC) I/O was replaced with Distributed Control System (DCS) I/O, while keeping the existing PLC sequence Logic. The reason for integration of the PLC logic and DCS I/O, along with the evaluation of the resulting system is the subject of this paper. The pros and cons of the old system and new upgrade are described, including operator workstation screen update times. Detail of the physical layout and the communication between the PLC, the DCS I/O and the operator workstations are illustrated. The complex characteristics of a central process control system and the plan to remove the PLC processors in future upgrades is also discussed.

Sadhukhan, Debashis↗
NASA NTRS2014

Data Automata in Scala

The field of runtime verification has during the last decade seen a multitude of systems for monitoring event sequences (traces) emitted by a running system. The objective is to ensure correctness of a system by checking its execution traces against formal specifications representing requirements. A special challenge is data parameterized events, where monitors have to keep track of the combination of control states as well as data constraints, relating events and the data they carry across time points. This poses a challenge wrt. efficiency of monitors, as well as expressiveness of logics. Data automata is a form of automata where states are parameterized with data, supporting monitoring of data parameterized events. We describe the full details of a very simple API in the Scala programming language, an internal DSL (Domain-Specific Language), implementing data automata. The small implementation suggests a design pattern. Data automata allow transition conditions to refer to other states than the source state, and allow target states of transitions to be inlined, offering a temporal logic flavored notation. An embedding of a logic in a high-level language like Scala in addition allows monitors to be programmed using all of Scala's language constructs, offering the full flexibility of a programming language. The framework is demonstrated on an XML processing scenario previously addressed in related work.

runtime verification↗
NASA NTRS2019

Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project: ACAS Xu HITL Overview

This presentation provides an overview of a recently completed human-in-the-loop simulation, conducted as part of the Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project. This study examined how to present resolution advisories (RAs) issued by Airborne Collision Avoidance System (ACAS) Xu, which can be in the vertical dimension, the horizontal dimension, or both (i.e., "blended"). The study varied the location of the ACAS Xu traffic information - it was either presented within an 'integrated' display or a 'standalone' display, where the traffic information was separated from the vehicle control interfaces and navigational information. The presentation covers the test set-up, scenario design, and facilities utilized in this experiment. The primary dependent variables are listed, but no detailed results are included in this outbrief since data analysis is still underway. Goal: assess ACAS Xu Run 5 in a HITL setting to measure pilot & system performance – RWC alerting and guidance – RA alerting and guidance • Horizontal-only, vertical-only, and blended RAs • Strengthening RAs, reversals and added/removed RAs during blended maneuvers – Incorporate realistic sensor noise into the simulation environment – Compare pilot and DAA system performance back to NASA’s Phase 1 DAA MOPS V&V HITL • We leveraged the findings of an engineering analysis conducted in March to help inform how to implement the Xu logic – Part 1 focused on how to display horizontal-only, vertical-only and blended RAs – Part 2 focused on how to display automated RA responses Xu Engineering Analysis Results Part 1 objectives: – Characterize pilot responses to (canned) ACAS Xu RAs in a variety of display configurations • With vs. Without text accompaniment • Simple vs. ‘Advanced’ aural alerting • Results – Pilots struggled to meet 5 seconds initial response requirement • Particularly against horizontal and blended RAs – Pilots failed to respond more quickly to secondary RAs • Expected response time to subsequent RAs = 2.5 seconds No clear effect of the different alerting conditions on response times – Response times primarily driven by RA type • Pilots demonstrated high level of compliance with RAs and self-reported Xu alerting and guidance as being acceptable – 1/5 reported text as being necessary – 4/5 wanted the aural alert to retain the original RA sequence (i.e., issue a follow-on RA second rather than first) – 4/5 wanted to retain the “Maintain Heading/Vertical Speed” aural alert in the event that the pilot reached their target response at the time of secondary RA Based on these results, we decided on the following for the HITL experimental design: – Incorporated an ‘auto-fill’ feature in Vigilant Spirit that removes the need for pilots to manually enter a heading or altitude for RAs • Pilots only have to click ‘Send’ to upload the RA target heading/altitude – Did not include an RA ‘text box’ • The auto-fill feature largely replaces the purpose of the text box – Using a combination of the ‘Basic’ and ‘Advanced’ aural alerting • In case of blended maneuvers will issue “Maintain Heading/Vertical Rate” if pilot has reached 1st RA target at the time the 2nd RA is issued • Integration and testing with Xu Run 5 also resulted in us adding display logic to modify how horizontal RAs are presented – Target heading was shown to update at approx. 1 Hz making it difficult for pilots to implement – Display logic limited horizontal RA strengthening to once every 5 seconds • Did not impact timing of reversals, new RAs (i.e., blended), or CoC Engineering Analysis Results

human systems integration↗