Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Data Communications”

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 307 records · Page 17

Use of Data Comm by Flight Crew in High-Density Terminal Areas

This paper describes a collaborative FAA and NASA experiment using 22 commercial airline pilots to determine the effect of using Datalink Communication (Data Comm) to issue messages in busy, terminal area operations. Four conditions were defined that span current day to future flight deck equipage levels (voice communication only, Data Comm only, Data Comm with Moving Map Display, Data Comm with Moving Map displaying taxi route), and each condition was used to create an arrival and a departure scenario at the Boston Logan Airport. These eight scenarios were repeated twice for a total of 16 scenarios for each of the eleven crews. Quantitative data was collected on subject reaction time and eye tracking information. Questionnaires collected subjective feedback on workload and acceptability to the flight crew for using Data Comm in a busy terminal area. 95% of the Data Comm messages were responded to by the flight crew within one minute; however, post experiment debrief comments revealed almost unanimous consensus that two minutes was a reasonable expectation for crew response. Eye tracking data indicated an insignificant decrease in head-up time for the Pilot Flying when Data Comm was introduced; however, the Pilot Monitoring had significantly less head-up time. Data Comm workload was rated as operationally acceptable by both crew members in all conditions in flight at any altitude above the Final Approach Fix in terms of response time and workload. Results also indicate the use of Data Comm during surface operations was acceptable, the exception being the simultaneous use of voice, Data Comm, and audio chime required for an aircraft to cross an active runway. Many crews reported they believed Data Comm messages would be acceptable after the Final Approach Fix or to cross a runway if the message was not accompanied by a chime and there was not a requirement to immediately respond to the uplink message.

Baxley, Brian T.↗

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗

Disruption of Commercial Solar Inverter System by TLS Proxy Man-in-the-Middle Attack

Transport Layer Security (TLS) is a cryptographic protocol that encrypts communication data, providing end-to-end communication encryption and authentication. Currently, TLS is widely adopted for securing communication between servers and end devices, including solar inverter systems. Therefore, users/operators can securely access the solar inverters through a web user interface (WebUI) application programmable interface (API) on a PC or server over TLS-enabled Wi-Fi or Ethernet. However, the security of the TLS-based network becomes compromised if it is breached by a TLS proxy man-in-the-middle (MITM) exploit. This report explores potential vulnerabilities in a commercial solar inverter system that leverages a TLS proxy MITM and discusses the impacts through assume-breached penetration testing. Furthermore, the paper explores recommended mitigation methods against the TLS proxy MITM exploit in solar inverters.

97 MATHEMATICS AND COMPUTING↗

Implementing High-Performance Geometric Multigrid Solver with Naturally Grained Messages

Structured-grid linear solvers often require manually packing and unpacking of communication data to achieve high performance.Orchestrating this process efficiently is challenging, labor-intensive, and potentially error-prone.In this paper, we explore an alternative approach that communicates the data with naturally grained messagesizes without manual packing and unpacking. This approach is the distributed analogue of shared-memory programming, taking advantage of the global addressspace in PGAS languages to provide substantial programming ease. However, its performance may suffer from the large number of small messages. We investigate theruntime support required in the UPC ++ library for this naturally grained version to close the performance gap between the two approaches and attain comparable performance at scale using the High-Performance Geometric Multgrid (HPGMG-FV) benchmark as a driver.

97 MATHEMATICS AND COMPUTING↗

Lightweight LSTM for CAN Signal Decoding

This paper describes an approach to identify undecoded Controller Area Network (CAN) data from one vehicle, based on the data similarity to previously decoded CAN data from another vehicle. Modern vehicles communicate data and signals from on-board sensors and controllers through the CAN bus. Networked sensors contain information such as wheel speeds, fuel gauges, turn signals, and radar signals. In the effort to use this information and make cars safer through human-in-the-loop CPS, signals on the CAN bus such as wheel speed and radar can be used to support the driver. However, data from the CAN bus are encoded and in some cases compressed, and different car manufacturers use different encoding schemes to represent data on the CAN bus. With hundreds of messages and thousands of possible encoding schemes to consider, it is laborious to identify the unique bits and encoding schemes that represent signals on each vehicle. In this study, we propose a method for training a Long Short-Term Memory (LSTM) neural network on known radar signals from one vehicle manufacturer, a Toyota, and successfully apply the network to identify the encoding for radar signals on a different vehicle, a Honda. By augmenting the training dataset with varied encoding bit boundaries, a small and lightweight LSTM network can learn to recognize radar data across different encoding schemes. The results are an improvement on exhaustive-search algorithms and other methods previously used in the search for such signals.

Ngo, Paul↗

Using CAD/CAM to improve productivity - The IPAD approach

Progress in designing and implementing CAD/CAM systems as a result of the NASA Integrated Programs for Aerospace-Vehicle Design is discussed. Essential software packages have been identified as executive, data management, general user, and geometry and graphics software. Data communication, as a means to integrate data over a network of computers of different vendors, provides data management with the capability of meeting design and manufacturing requirements of the vendors. Geometry software is dependent on developmental success with solid geometry software, which is necessary for continual measurements of, for example, a block of metal while it is being machined. Applications in the aerospace industry, such as for design, analysis, tooling, testing, quality control, etc., are outlined.

Fulton, R. E.↗

Office of Space Flight standard spaceborne Global Positioning System user equipment project

The Global Positioning System (GPS) provides users autonomous, real-time navigation capability. A vehicle equipped with GPS user equipment can receive and process signals transmitted by a constellation of GPS satellites and derive from the resulting measurements the vehicle's position and velocity. Specified accuracies range from 16 to 76 meters and 0.1 to 1.0 meters/second for position and velocity, respectively. In a rendezvous and docking scenario, the use of a technique called relative GPS can provide range and range rate accuracies on the order of 1 meter and 0.01 meters/second, respectively. Relative GPS requires both vehicles to be equipped with GPS user equipment and a data communication link for transmission of GPS data and GPS satellite selection coordination information. Through coordinated satellite selection, GPS measurement errors common to both users are cancelled and improved relative position and velocity accuracies are achieved. The background, the design approach, the expected performance and capabilities, the development plan, and the project status are described. In addition, a description of relative GPS, the possible GPS hardware and software configurations, and its application to automated rendezvous and capture are presented.

Saunders, Penny E.↗

Capability 9.2 Mobility

Modern operational concepts require significant bandwidths and multipoint communication capabilities. Provide voice, video and data communications among vehicles moving along the surface, vehicles in suborbital transport or reconnaissance, surface elements, and home planet facilities.

Zakrasjek, June↗

Earth Observatory Satellite system definition study. Report 5: System design and specifications. Volume 3: General purpose spacecraft segment and module specifications

The specifications for the Earth Observatory Satellite (EOS) general purpose aircraft segment are presented. The satellite is designed to provide attitude stabilization, electrical power, and a communications data handling subsystem which can support various mission peculiar subsystems. The various specifications considered include the following: (1) structures subsystem, (2) thermal control subsystem, (3) communications and data handling subsystem module, (4) attitude control subsystem module, (5) power subsystem module, and (6) electrical integration subsystem.

Source record↗

A Formal Messaging Notation for Alaskan Aviation Data

Data exchange is an increasingly important aspect of the National Airspace System. While many data communication channels have become more capable of sending and receiving data at higher throughput rates, there is still a need to use communication channels efficiently with limited throughput. The limitation can be based on technological issues, financial considerations, or both. This paper provides a complete description of several important aviation weather data in Abstract Syntax Notation format. By doing so, data providers can take advantage of Abstract Syntax Notation's ability to encode data in a highly compressed format. When data such as pilot weather reports, surface weather observations, and various weather predictions are compressed in such a manner, it allows for the efficient use of throughput-limited communication channels. This paper provides details on the Abstract Syntax Notation One (ASN.1) implementation for Alaskan aviation data, and demonstrates its use on real-world aviation weather data samples as Alaska has sparse terrestrial data infrastructure and data are often sent via relatively costly satellite channels.

communications↗

DDCP framework

DDCP protocol software 1.0 This repository contains the C++ implementation of version 1.x of the Distributed Data Communications Protocol (DDCP). DDCP provides request/reply, feature discovery, data transfer, control, interrupt, and transaction support for communicating with accelerator instrumentation over UDP. The standard server port is 65000. The framework is a source dependency for services that communicate directly with DDCP hardware. It is not a deployable service by itself.

Joshi, Shreya [Fermi National Accelerator Laborato↗

Communication in Pipes Using Acoustic Modems that Provide Minimal Obstruction to Fluid Flow

A plurality of phased array acoustic communication devices are used to communicate data along a tubulation, such as a well. The phased array acoustic communication devices employ phased arrays of acoustic transducers, such as piezoelectric transducers, to direct acoustic energy in desired directions along the tubulation. The system is controlled by a computer-based controller. Information, including data and commands, is communicated using digital signaling.

Bar-Cohen, Yoseph↗

Major RFI conditions effecting TDRSS

An evaluation of the radio frequency interference (RFI) conditions which would affect operating frequency band selections and data communications equipment design approaches for the Tracking Data Relay Satellite System (TDRSS) is presented. The subjects discussed are: (1) the scope of the investigation, (2) relative RFI in the frequency bands considered, (3) radar RFI power and duty factor, (4) radio relay communications RFI, (5) radio frequency band usage recommendations, and (6) radar RFI impact areas.

Lyttle, J. D.↗

Remote Objects Message Exchange (ROME)

The performance of a single program running on a single processor is limited by the character of the processor. Moreover, the cost and difficulty of developing and sustaining programs tend to increase as their size and complexity increase. Clearly there ought to be some advantage in partitioning powerful application software in relatively small and simple components that can run in parallel on multiple processors; the software should run faster and it should be cheaper and easier to deploy. Remote Objects Message Exchange (ROME) is an attempt to provide a single relatively simple, universally available abstraction for data communication among C++ objects. It aims to enable the C++ application developer to specify objects' interactions with other objects wholly in terms of the application domain, without concern for details of interprocess communication. Every ROME-compliant object is conceptually a network peer of every other, as if each one were (for example) a separate UNIX process.

processors application software data communication↗

Calculating a checksum with inactive networking components in a computing system

Calculating a checksum utilizing inactive networking components in a computing system, including: identifying, by a checksum distribution manager, an inactive networking component, wherein the inactive networking component includes a checksum calculation engine for computing a checksum; sending, to the inactive networking component by the checksum distribution manager, metadata describing a block of data to be transmitted by an active networking component; calculating, by the inactive networking component, a checksum for the block of data; transmitting, to the checksum distribution manager from the inactive networking component, the checksum for the block of data; and sending, by the active networking component, a data communications message that includes the block of data and the checksum for the block of data.

97 MATHEMATICS AND COMPUTING↗

Calculating a checksum with inactive networking components in a computing system

Calculating a checksum utilizing inactive networking components in a computing system, including: identifying, by a checksum distribution manager, an inactive networking component, wherein the inactive networking component includes a checksum calculation engine for computing a checksum; sending, to the inactive networking component by the checksum distribution manager, metadata describing a block of data to be transmitted by an active networking component; calculating, by the inactive networking component, a checksum for the block of data; transmitting, to the checksum distribution manager from the inactive networking component, the checksum for the block of data; and sending, by the active networking component, a data communications message that includes the block of data and the checksum for the block of data.

97 MATHEMATICS AND COMPUTING↗