Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Communication traces”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

Ignitability test method and apparatus

An apparatus for testing ignitability of an initiator includes a body with a central cavity, initiator holder for holding the initiator over the central cavity of the body, an ignition material holder disposed in the central cavity of the body and a cavity facing the initiator holder which receives a measured quantity of ignition material to be ignited by the initiator and a chamber in communication with the cavity of the ignition material holder and the central cavity of the body. A measuring system for analyzing pressure characteristics is generated by ignition material by the initiator. The measuring system includes at least one transducer coupled to an oscillograph for recording pressure traces generated by ignition.

Bement, Laurence J.↗
NASA NTRS1991

Ignitability test method and apparatus

An apparatus for testing ignitability of an initiator includes a body having a central cavity, an initiator holder for holding the initiator over the central cavity of the body, an ignition material holder disposed in the central cavity of the body and having a cavity facing the initiator holder which receives a measured quantity of ignition material to be ignited by the initiator. It contains a chamber in communication with the cavity of the ignition material and the central cavity of the body, and a measuring system for analyzing pressure characteristics generated by ignition of the ignition material by the initiator. The measuring system includes at least one transducer coupled with an oscillograph for recording pressure traces generated by ignition.

Bement, Laurence J.↗
NASA NTRS2017

Lightning Protection and Detection System

A lightning protection and detection system includes a non-conductive substrate material of an apparatus; a sensor formed of a conductive material and deposited on the non-conductive substrate material of the apparatus. The sensor includes a conductive trace formed in a continuous spiral winding starting at a first end at a center region of the sensor and ending at a second end at an outer corner region of the sensor, the first and second ends being open and unconnected. An electrical measurement system is in communication with the sensor and receives a resonant response from the sensor, to perform detection, in real-time, of lightning strike occurrences and damage therefrom to the sensor and the non-conductive substrate material.

Dudley, Kenneth L.↗
NASA NTRSDate not supplied

Exploration Medical Integrated Product Team Clinical Decision Support Market Survey

NASA’s Exploration Medical Integrated Product Team (XMIPT) has identified Clinical Decision Support (CDS) technology as a critical need for future human space exploration. Such technology will support real time diagnosis, monitoring, and treatment of spaceflight medical conditions. The need for such tools and support systems is critical for in-mission clinical decision-making, especially when Earth-based support is unavailable due to communication delays or blackouts. Supporting technologies may or may not involve Artificial Intelligence (AI), and would support astronaut crew with minimal clinical training, or even those with advanced training if they are, for example, in need of a refresher, experiencing multiple stressors, or temporarily overloaded with tasking. This need traces to the Development of Earth Independent Operations Technologies for NASA’s Mars Campaign Office. The CDS Market Survey purpose, methods, outcomes thus far, and near-term steps will be discussed.

Decision support↗
NASA NTRS1988

Explanation production by expert planners

Although the explanation capability of expert systems is usually listed as one of the distinguishing characteristics of these systems, the explanation facilities of most existing systems are quite primitive. Computer generated explanations are typically produced from canned text or by direct translation of the knowledge structures. Explanations produced in this manner bear little resemblance to those produced by humans for similar tasks. The focus of our research in explanation is the production of justifications for decisions by expert planning systems. An analysis of justifications written by people for planning tasks has been taken as the starting point. The purpose of this analysis is two-fold. First, analysis of the information content of the justifications will provide a basis for deciding what knowledge must be represented if human-like justifications are to be produced. Second, an analysis of the textual organization of the justifications will be used in the development of a mechanism for selecting and organizing the knowledge to be included in a computer-produced explanation. This paper describes a preliminary analysis done of justifications written by people for a planning task. It is clear that these justifications differ significantly from those that would be produced by an expert system by tracing the firing of production rules. The results from the text analysis have been used to develop an augmented phrase structured grammar (APSG) describing the organization of the justifications. The grammar was designed to provide a computationally feasible method for determining textual organization that will allow the necessary information to be communicated in a cohesive manner.

Bridges, Susan↗
NASA NTRS2016

Enabling International Data Relay at Mars

The most commonly used mode of communications be-tween Earth and a Mars surface mission is ultra-high fre-quency (UHF) radio relay via a Mars orbiter. There are four orbiters and two surface rovers operating at Mars and by October there should be five orbiters and three landers or rovers. There has been some collaboration between ESA’s Mars Express orbiter and NASA’s rovers, but 2016 is when Mars relay becomes fully international. In October, ESA will deliver the ExoMars Trace Gas Orbiter (TGO) and En-try, Descent, and Landing (EDL) Demonstrator Module (EDM) lander to Mars. The ExoMars program includes both ESA and ROSCOSMOS, with NASA participation (the Electra UHF transceiver on TGO). NASA orbiters will pro-vide relay for EDM and future ESA Mars landers and rov-ers. TGO will provide relay for NASA's current and future surface assets (as Mars Express will continue to do). Inter-national collaboration is enabled in several steps. At the in-struction of the space agencies, the Mars mission projects negotiate and write a “Service Agreement.” This describes at a high level how a new Mars orbiter would operate with its corresponding surface missions or how a new surface mis-sion would operate with its corresponding orbiters. It in-cludes the roles of the different projects, how the new mis-sion would communicate with existing or planned missions, the general flow of data and commands, and the capabilities or requirements of the new mission. After completing the Service Agreement, the projects write Interface Control Doc-uments (ICDs), each of which describes data and command flow in greater detail and quantitative aspects of the relay link and operations timeline between an orbiter and a cor-responding lander/rover. Interfaces and operations are test-ed before a new mission arrives at Mars. Once at Mars, a new orbiter performs some “practice” relay contacts with its partners. For a new lander (e.g. EDM), relay operations gen-erally begin before atmospheric entry at Mars, with record-ing of the UHF relay signal from the lander (including open-loop wide-bandwidth recording) as it enters and traverses Mars’s atmosphere and lands on its surface. After Mars EDL or orbit injection, each relay contact is negotiat-ed and scheduled using the Mars Relay Operations Service (MaROS). This paper describes the international approach to develop inter-agency agreements, inter-project interfaces, and specifics of how MaROS is used in actual relay opera-tions between international partners.

Winton, Alistair J.↗
NASA NTRS1983

SPP: A data base processor data communications protocol

The design and implementation of a data communications protocol for the Intel Data Base Processor (DBP) is defined. The protocol is termed SPP (Service Port Protocol) since it enables data transfer between the host computer and the DBP service port. The protocol implementation is extensible in that it is explicitly layered and the protocol functionality is hierarchically organized. Extensive trace and performance capabilities have been supplied with the protocol software to permit optional efficient monitoring of the data transfer between the host and the Intel data base processor. Machine independence was considered to be an important attribute during the design and implementation of SPP. The protocol source is fully commented and is included in Appendix A of this report.

Fishwick, P. A.↗
NASA NTRS1994

Performance Metrics for Monitoring Parallel Program Executions

Existing tools for debugging performance of parallel programs either provide graphical representations of program execution or profiles of program executions. However, for performance debugging tools to be useful, such information has to be augmented with information that highlights the cause of poor program performance. Identifying the cause of poor performance necessitates the need for not only determining the significance of various performance problems on the execution time of the program, but also needs to consider the effect of interprocessor communications of individual source level data structures. In this paper, we present a suite of normalized indices which provide a convenient mechanism for focusing on a region of code with poor performance and highlights the cause of the problem in terms of processors, procedures and data structure interactions. All the indices are generated from trace files augmented with data structure information.. Further, we show with the help of examples from the NAS benchmark suite that the indices help in detecting potential cause of poor performance, based on augmented execution traces obtained by monitoring the program.

Sarukkai, Sekkar R.↗
NASA NTRS2004

Discrepancy Reporting Management System

Discrepancy Reporting Management System (DRMS) is a computer program designed for use in the stations of NASA's Deep Space Network (DSN) to help establish the operational history of equipment items; acquire data on the quality of service provided to DSN customers; enable measurement of service performance; provide early insight into the need to improve processes, procedures, and interfaces; and enable the tracing of a data outage to a change in software or hardware. DRMS is a Web-based software system designed to include a distributed database and replication feature to achieve location-specific autonomy while maintaining a consistent high quality of data. DRMS incorporates commercial Web and database software. DRMS collects, processes, replicates, communicates, and manages information on spacecraft data discrepancies, equipment resets, and physical equipment status, and maintains an internal station log. All discrepancy reports (DRs), Master discrepancy reports (MDRs), and Reset data are replicated to a master server at NASA's Jet Propulsion Laboratory; Master DR data are replicated to all the DSN sites; and Station Logs are internal to each of the DSN sites and are not replicated. Data are validated according to several logical mathematical criteria. Queries can be performed on any combination of data.

Cooper, Tonja M.↗
NASA NTRS2009

Model Checking - My 27-Year Quest to Overcome the State Explosion Problem

Model Checking is an automatic verification technique for state-transition systems that are finite=state or that have finite-state abstractions. In the early 1980 s in a series of joint papers with my graduate students E.A. Emerson and A.P. Sistla, we proposed that Model Checking could be used for verifying concurrent systems and gave algorithms for this purpose. At roughly the same time, Joseph Sifakis and his student J.P. Queille at the University of Grenoble independently developed a similar technique. Model Checking has been used successfully to reason about computer hardware and communication protocols and is beginning to be used for verifying computer software. Specifications are written in temporal logic, which is particularly valuable for expressing concurrency properties. An intelligent, exhaustive search is used to determine if the specification is true or not. If the specification is not true, the Model Checker will produce a counterexample execution trace that shows why the specification does not hold. This feature is extremely useful for finding obscure errors in complex systems. The main disadvantage of Model Checking is the state-explosion problem, which can occur if the system under verification has many processes or complex data structures. Although the state-explosion problem is inevitable in worst case, over the past 27 years considerable progress has been made on the problem for certain classes of state-transition systems that occur often in practice. In this talk, I will describe what Model Checking is, how it works, and the main techniques that have been developed for combating the state explosion problem.

Clarke, Ed↗
NASA NTRS1995

MMPP Traffic Generator for the Testing of the SCAR 2 Fast Packet Switch

A prototype MWP Traffic Generator (TG) has been designed for testing of the COMSAT-supplied SCAR II Fast Packet Switch. By generating packets distributed according to a Markov-Modulated Poisson Process (MMPP) model. it allows the assessment of the switch performance under traffic conditions that are more realistic than could be generated using the COMSAT-supplied Traffic Generator Module. The MMPP model is widely believed to model accurately real-world superimposed voice and data communications traffic. The TG was designed to be as much as possible of a "drop-in" replacement for the COMSAT Traffic Generator Module. The latter fit on two Altera EPM7256EGC 192-pin CPLDs and produced traffic for one switch input port. No board changes are necessary because it has been partitioned to use the existing board traces. The TG, consisting of parts "TGDATPROC" and "TGRAMCTL" must merely be reprogrammed into the Altera devices of the same name. However, the 040 controller software must be modified to provide TG initialization data. This data will be given in Section II.

Chren, William A., Jr.↗
NASA NTRS2012

The Geostationary Fourier Transform Spectrometer

The Geostationary Fourier Transform Spectrometer (GeoFTS) is an imaging spectrometer designed for a geostationary orbit (GEO) earth science mission to measure key atmospheric trace gases and process tracers related to climate change and human activity. GEO allows GeoFTS to continuously stare at a region of the earth for frequent sampling to capture the variability of biogenic fluxes and anthropogenic emissions from city to continental spatial scales and temporal scales from diurnal, synoptic, seasonal to interannual. The measurement strategy provides a process based understanding of the carbon cycle from contiguous maps of carbon dioxide (CO2), methane (CH4), carbon monoxide (CO), and chlorophyll fluorescence (CF) collected many times per day at high spatial resolution (~2.7kmx2.7km at nadir). The CO2/CH4/CO/CF measurement suite in the near infrared spectral region provides the information needed to disentangle natural and anthropogenic contributions to atmospheric carbon concentrations and to minimize uncertainties in the flow of carbon between the atmosphere and surface. The half meter cube size GeoFTS instrument is based on a Michelson interferometer design that uses all high TRL components in a modular configuration to reduce complexity and cost. It is self-contained and as independent of the spacecraft as possible with simple spacecraft interfaces, making it ideal to be a "hosted" payload on a commercial communications satellite mission. The hosted payload approach for measuring the major carbon-containing gases in the atmosphere from the geostationary vantage point will affordably advance the scientific understating of carbon cycle processes and climate change.

atmospheric trace gases↗
NASA NTRS2015

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗
NASA NTRS2016

Command and Data Handling Branch Internship

Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments (TI)' MSP430 16-bit ultra-low-power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display (LCD) touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320 by 240 RGB resistive color screen including an optional carrier board. The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA (Field Programmable Gate Array) development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At the moment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process. Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments’ MSP430 16 bit ultra-low power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320x240 RGB resistive color screen including an optional carrier board.The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At themoment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process.Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate school for a master's or doctorate degree in electrical or computer engineering.

Billings, Rachel Mae↗
NASA NTRS2020

Communications with Curiosity during solar conjunction

This study examines the methodology for operating and communicating with NASA's Curiosity Rover (MSL) during the 2019 solar conjunction. For MSL, solar conjunction occurs when the viewing angle between the Sun and Mars from Earth's perspective falls below 3 degrees, which occurs roughly every two Earth years and lasts for about two weeks. This presents a challenge for engineers operating a vehicle on Mars because the degraded signal to noise ratio disrupts data flow between Earth and the spacecraft. As a result, operators designate a command moratorium in which no commands are sent to the rover and instead design long-term plans that are uplinked weeks in advance (rather than the nominal case of daily uplinks). Coordinating communications with the rover leading up to and following conjunction requires negotiations with several orbiters, another lander, and the Deep Space Network (DSN) each with their own set of constraints. It is the Strategic Comm Planning T coordination, which acts as a baseline for the conjunction Comm team faced additional complications such as the arrival of two new spacecraft at Mars - Roscosmos ExoMars Trace Gas Orbiter (TGO).

Laubach, Sharon↗
NASA NTRS2005

Synergy Between probes and Orbiter

There are many ways in which the science return from a planetary mission is considerably enhanced by interactions between entry probes and a mission orbiter. Mission configuration aspects that are desirable include delivery of entry probes by the orbiter, and communication between probe and orbiter. Both of these mission aspects could greatly enhance access to key scientific sites that might not otherwise be accessible using delivery from say, a flyby, or employing direct communication from probes to Earth. Examples for Venus and Jupiter will be discussed. A second class of orbiter-probe interaction could better be termed direct probe-orbiter science collaboration. That would include, determining the global context of the entry probe sites from the orbiter, obtaining ground truth from the probe for remote sensing observations from the orbiter, observing the global and vertical distribution of key atmospheric trace species, and measuring the global and vertical distribution of clouds and winds. The importance of each of these items will be illustrated by particular examples.

Young, Richard E.↗
NASA NTRSDate not supplied

Medical System Foundation Overview for Long-Duration Lunar Orbit and Surface Operations Missions

The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a Medical System Foundation for Level of Care IV, as defined by NASA’s space flight human-system standards, for long-duration lunar orbit and surface operation missions by employing a systems engineering approach using model-based systems engineering tools. This Foundation model includes a concept of operations; functional decomposition; clinical content (medical conditions, capabilities, and resources); associated functional, interface and non-functional technical requirements; and traces to the current versions of NASA standards documents and parent-level (Program- and Vehicle habitat system level) requirements. Collectively, these components constitute a foundation that serves as a starting point for a medical system that meets the Level of Care IV requirement. The Foundation was developed by a multidisciplinary team consisting of systems engineers, scientists, and clinicians across NASA, and information is presented in an easily accessible format that is understandable across disciplines. Stakeholders can use the Foundation to analyze the traces between medical capabilities, medical conditions, medical resources, and requirements and to identify medical system interfaces with other vehicle systems/subsystems. It can also be used as a basis for performing trades on risks vs. medical system mass and volume allocation. This discussion will focus on the processes through which the Medical System Foundation was developed, how the Foundation builds a bridge between the medical and engineering domains and facilitates communication between these communities, and how these processes can be applied more broadly to a crew health and performance system and other system domains. The presentation also discusses Foundation modifications based on the recently updated versions of the NASA 3001 Standards.

S. Lumpkins↗
NASA NTRS1994

A Study on the Effect of Communication Performance on Message-Passing Parallel Programs: Methodology and Case Studies

From a source-program perspective, the performance achieved on distributed/parallel systems is governed by the underlying message-passing library overhead and the network capabilities of the architecture. Studying the impact of changes in these features on the source-program. can have a significant influence in the development of next-generation system designs. In this paper we introduce a simple and robust tool that can be used for this purpose. This tool is based on event-driven simulation of programs that generates a new set of trace events - that preserves causality and partial order - corresponding to the expected execution of the program in the simulated environment. Trace events can be visualized and source-level profile information can be used to pin-point locations of program which are most significantly affected with changing system parameters in the simulated environment. We present a number of examples from the NAS benchmark suite, executed on the Intel Paragon and iPSC/860 that are used to identify and expose performance bottlenecks with varying system parameters. Specific aspects of the system that significantly effect these benchmarks are presented and discussed,

Sarukkai, Sekhar R.↗