Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “communication protocols”

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 631 records · Page 35
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Asynchronous Message Service for Deep Space Mission Operations

AMS is in early stages of standardization. a) CCSDS "white book" (Proposed Standard) has been published. b) A single implementation has been developed and is being tested. No major obstacles encountered so far. a) Protocol has changed since original concept paper, but not radically. b) Design concepts seem to be sound. AMS capabilities seem to be broadly applicable. a) On-board, proximity, and deep-space communications for spacecraft. b) Suitable underlying messaging protocol for proposed CCSDS Spacecraft Monitor and Control protocols. c) Terrestrial applications designed for operation over a message bus. AMS Working Group within CCSDS is on schedule, so far.

asynchronous message exchanges↗
NASA NTRS1992

Distributed project scheduling at NASA: Requirements for manual protocols and computer-based support

The increasing complexity of space operations and the inclusion of interorganizational and international groups in the planning and control of space missions lead to requirements for greater communication, coordination, and cooperation among mission schedulers. These schedulers must jointly allocate scarce shared resources among the various operational and mission oriented activities while adhering to all constraints. This scheduling environment is complicated by such factors as the presence of varying perspectives and conflicting objectives among the schedulers, the need for different schedulers to work in parallel, and limited communication among schedulers. Smooth interaction among schedulers requires the use of protocols that govern such issues as resource sharing, authority to update the schedule, and communication of updates. This paper addresses the development and characteristics of such protocols and their use in a distributed scheduling environment that incorporates computer-aided scheduling tools. An example problem is drawn from the domain of Space Shuttle mission planning.

Richards, Stephen F.↗
NASA NTRS2008

The Interplanetary Overlay Networking Protocol Accelerator

A document describes the Interplanetary Overlay Networking Protocol Accelerator (IONAC) an electronic apparatus, now under development, for relaying data at high rates in spacecraft and interplanetary radio-communication systems utilizing a delay-tolerant networking protocol. The protocol includes provisions for transmission and reception of data in bundles (essentially, messages), transfer of custody of a bundle to a recipient relay station at each step of a relay, and return receipts. Because of limitations on energy resources available for such relays, data rates attainable in a conventional software implementation of the protocol are lower than those needed, at any given reasonable energy-consumption rate. Therefore, a main goal in developing the IONAC is to reduce the energy consumption by an order of magnitude and the data-throughput capability by two orders of magnitude. The IONAC prototype is a field-programmable gate array that serves as a reconfigurable hybrid (hardware/ firmware) system for implementation of the protocol. The prototype can decode 108,000 bundles per second and encode 100,000 bundles per second. It includes a bundle-cache static randomaccess memory that enables maintenance of a throughput of 2.7Gb/s, and an Ethernet convergence layer that supports a duplex throughput of 1Gb/s.

Pang, Jackson↗
NASA NTRSDate not supplied

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗
NASA NTRS1992

Tradeoffs in implementing primary-backup protocols

One way to implement a fault-tolerant service is by using multiple servers that fail independently. The state of the service is replicated and distributed among these servers, and updates are coordinated so that even when a subset of the servers fail, the service remains available. A common approach to structuring such replicated services is to designate one server as the primary and all the others as backups. Clients make requests by sending messages only to the primary. If the primary fails, then a failover occurs and one of the backups takes over. This service architecture is commonly called the primary-backup or the primary-copy approach. In most such primary-backup protocols, when the primary receives a client request, it informs the backups about the request, and then responds to the client. Informally, this primary-backup protocol is non-blocking if the primary does not wait for an acknowledgement from the backups before it sends the response; otherwise, it is blocking. Most of the existing protocols are blocking as non-blocking protocols cannot be constructed for some kinds of failures. However, it is shown that non-blocking protocols can be constructed for most of the process and communication failures that are expected to occur in the primary-backup systems of the future. Since non-blocking protocols can theoretically achieve the smallest possible response time, this paper analyzes these protocols under various system parameters. Two kinds of non-blocking protocols are analyzed: one in which the processes use point-to-point communication to exchange messages, and the other in which processes use hardware broadcasts.

Budhiraja, Navin↗
NASA NTRS1985

A retransmission protocol for the message service of a land mobile satellite experiment

The objectives of NASA's land mobile satellite experiments are discussed. The assigned multiple access protocol combined with a retransmission scheme is to provide reliable transmission of data messages from mobiles to base stations (BSs). The sequences for communication between mobiles and BSs, mobiles and the network management center (NMC), and BSs and NMC are examined, and an example of mobiles/BSs communication is provided. The performance of the retransmission protocol and data message reservation and message channels delays are analyzed. A bit error rate of 0.001 is observed for satellite channels in a mobile environment and the message error probability is between 0-0.1.

Yan, T.-Y.↗
NASA NTRS2011

SNE Industrial Fieldbus Interface

Programmable logic controllers (PLCs) have very limited diagnostic and no prognostic capabilities, while current smart sensor designs do not have the capability to communicate over Fieldbus networks. The aim is to interface smart sensors with PLCs so that health and status information, such as failure mode identification and measurement tolerance, can be communicated via an industrial Fieldbus such as ControlNet. The SNE Industrial Fieldbus Interface (SIFI) is an embedded device that acts as a communication module in a networked smart sensor. The purpose is to enable a smart sensor to communicate health and status information to other devices, such as PLCs, via an industrial Fieldbus networking protocol. The SNE (Smart Network Element) is attached to a commercial off-the-shelf Any bus-S interface module through the SIFI. Numerous Anybus-S modules are available, each one designed to interface with a specific Fieldbus. Development of the SIFI focused on communications using the ControlNet protocol, but any of the Anybus-S modules can be used. The SIFI communicates with the Any-bus module via a data buffer and mailbox system on the Anybus module, and supplies power to the module. The Anybus module transmits and receives data on the Fieldbus using the proper protocol. The SIFI is intended to be connected to other existing SNE modules in order to monitor the health and status of a transducer. The SIFI can also monitor aspects of its own health using an onboard watchdog timer and voltage monitors. The SIFI also has the hardware to drive a touchscreen LCD (liquid crystal display) unit for manual configuration and status monitoring.

Lucena, Angel↗
DOE OSTI2022

A High Voltage Distribution System for the Mu2e Electron Tracker

This paper describes the design and development of a High Voltage distribution system (Smart Switch - SS) which distributes one input high voltage (HV) into six High Voltage channels (HVDS) of a straw detector plane. The SS independently sets, controls, and monitors the HV to each individual channel of a straw-detector plane in the Mu2E Electron Tracking Detector. Each straw plane is composed of three 120 deg crescent-shaped panels, and each panel is composed of 96 straw-tube detectors. Each output channel of the SS has independent, ON-OFF, current and HV monitoring, as well as filtration, isolation, and a crowbar to provide overcurrent protection for in that channel. The inter-communication system is based on TCP/IP protocol using a Raspberry Pi. The HVDS meets all required specifications including long term stability, accurate monitoring of the HV and current, and overcurrent trip. The performance of the HVDS was found to be comparable to, if not better than, commercial HV power supplies.

42 ENGINEERING↗
DOE OSTI2025

Electric Utility Communications Standards Landscape 2025 Edition

Historically, challenges to managing electric utility data exchange have been addressed through dedicated communication solutions, enabling the transmission of data with both speed and security. Protocols have been deployed in a relatively uniform fashion; for example, field communications for Supervisory Control and Data Acquisition (SCADA) are commonly implemented using IEEE 1815 (DNP3).

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS1988

Space information systems in the Space Station era; Proceedings of the AIAA/NASA International Symposium on Space Information Systems, Washington, DC and Greenbelt, MD, June 22, 23, 1987

Technological and planning issues for data management, processing, and communication on Space Station Freedom are discussed in reviews and reports by U.S., European, and Japanese experts. The space-information-system strategies of NASA, ESA, and NASDA are discussed; customer needs are analyzed; and particular attention is given to communication and data systems, standards and protocols, integrated system architectures, software and automation, and plans and approaches being developed on the basis of experience from past programs. Also included are the reports from workshop sessions on design to meet customer needs, the accommodation of growth and new technologies, and system interoperability.

Gerard, Mireille↗
NASA NTRS2005

Solution Concepts for Distributed Decision-Making without Coordination

Consider a single-stage problem in which we have a group N agents who are attempting to minimize the expected cost of their joint actions, without the benefit of communication or a pre-established protocol but with complete knowledge of the expected cost of any joint set of actions for the group. We call this situation a static coordination problem. The central issue in defining an appropriate solution concept for static coordination problems is considering how to deal with the fact that if the agents axe faced with a set of multiple (mixed) strategies that are equally attractive in terms of cost, a failure of coordination may lead to an expected cost value that is worse than that of any of the strategies in the set. In this proposal, we describe the notion of a general coordination problem, describe initial efforts at developing a solution concept for static coordination problems, and then outline a research agenda that centers on activities that will be basis for obtaining a complete understanding of solutions to static coordination problems.

Beling, Peter A.↗
NASA NTRS2018

Computer Controlled Solid State Lighting Assembly to Emulate Diurnal Cycle and Improve Circadian Rhythm Control

A light system can simultaneously emulate more than one different diurnal cycle to individually improve circadian rhythm control for more than one observer by having each light fixture autonomously self-controlled. Each light fixture is mountable in respective locations to individually treat respective observers. Each light fixture includes one or more light elements mounted to a housing and are controllable to emit a selected light intensity at a selected light temperature. A micro controller is contained in the housing and includes memory containing instructions for one or more automatic diurnal cycle protocols. The micro controller is in communication with the memory and the one or more light elements to execute the instructions to configure the light fixture to vary the light intensity and the light temperature of the emitted light.

Holbert, Eirik↗
NASA NTRS2018

A Fault-Tolerant Clock Synchronization and Geometry Determination Protocol

A fault-tolerant distributed protocol (algorithm) is presented that achieves optimum timing precision (clock synchronization) among the nodes and, simultaneously, determines the network's geometry (shape) - locations and distances of the nodes relative to each other - in a wireless distributed system. This protocol is based on the assumption of initial coarse synchrony of nodes' local clocks. The proposed solution assumes no prior knowledge of the nodes' locations, the distances between the nodes, or network's geometry, but assumes an ordered geometry where nodes have unique identifiers. This protocol accommodates large variations in the communication latencies among the nodes; thus, it applies equally to both wireless and wired networks.

Malekpour, Mahyar R.↗
DOE OSTI2024

A Framework to Demonstrate a DNP3 Interface With a CIM-Based Data Integration Platform: Preprint

The contemporary electrical grid is characterized by its complexity and abundance of data. A control-rich environment supported by information and communication technologies within an Advanced Distribution Management System (ADMS) presents a viable and cost-effective option for utility companies aiming to implement advanced real-time analytical schemes for monitoring and remotely controlling distribution feeders. Modular platform-based approaches to distribution operations require a structured framework for acquiring field device measurements, performing analytics, converting the setpoint to the correct protocol, and sending it on the appropriate communications network to the field devices. We present the development and deployment of an application service to integrate an open-source standardsbased platform with an ADMS test bed with field devices using the Distributed Network Protocol (DNP3) for data exchange. The step-by-step procedure for establishing the DNP3-Master service on an open-source distribution platform is outlined, comprehensively explaining the Master setup process. Moreover, sample use case results highlight the capabilities of the DNP3- Master service setup. Results demonstrate the scalability and configurability of the DNP3-Master service, making it adaptable for integration with other relevant applications, thus providing potential opportunities for real-world field trials and real-time assessments.

ADMS↗
NASA NTRS1990

CSMA/RN: A universal protocol for gigabit networks

Networks must provide intelligent access for nodes to share the communications resources. In the range of 100 Mbps to 1 Gbps, the demand access class of protocols were studied extensively. Many use some form of slot or reservation system and many the concept of attempt and defer to determine the presence or absence of incoming information. The random access class of protocols like shared channel systems (Ethernet), also use the concept of attempt and defer in the form of carrier sensing to alleviate the damaging effects of collisions. In CSMA/CD, the sensing of interference is on a global basis. All systems discussed above have one aspect in common, they examine activity on the network either locally or globally and react in an attempt and whatever mechanism. Of the attempt + mechanisms discussed, one is obviously missing; that is attempt and truncate. Attempt and truncate was studied in a ring configuration called the Carrier Sensed Multiple Access Ring Network (CSMA/RN). The system features of CSMA/RN are described including a discussion of the node operations for inserting and removing messages and for handling integrated traffic. The performance and operational features based on analytical and simulation studies which indicate that CSMA/RN is a useful and adaptable protocol over a wide range of network conditions are discussed. Finally, the research and development activities necessary to demonstrate and realize the potential of CSMA/RN as a universal, gigabit network protocol is outlined.

Foudriat, E. C.↗
NASA NTRS2008

Delay-Tolerant Networking for Space Flight Operations: Design and Development

Interplanetary Overlay Network (ION) is an implementation of the Delay-Tolerant Networking (DTN) architecture that is specifically intended to be usable for interplanetary communications. As such, its design differs in several ways from that of other implementations including DTN2, the reference implementation of the DTN Bundle Protocol. This paper briefly reviews the constraints on interplanetary communication that argue against the suitability not only of most off-the-shelf Internet technology but also of many DTN implementations. It then describes the operational components of ION, including its implementations of both the Bundle Protocol and the Licklider Transmission Protocol, noting the ways in which they address those constraints. Features of the system are explained with reference to their counterparts in the Internet architecture. The paper concludes with some notes on ION testing experience to date and plans for additional development in the future.

Interplanetary Overlay Network (ION)↗
NASA NTRS2004

Toward Synthesis, Analysis, and Certification of Security Protocols

Implemented security protocols are basically pieces of software which are used to (a) authenticate the other communication partners, (b) establish a secure communication channel between them (using insecure communication media), and (c) transfer data between the communication partners in such a way that these data only available to the desired receiver, but not to anyone else. Such an implementation usually consists of the following components: the protocol-engine, which controls in which sequence the messages of the protocol are sent over the network, and which controls the assembly/disassembly and processing (e.g., decryption) of the data. the cryptographic routines to actually encrypt or decrypt the data (using given keys), and t,he interface to the operating system and to the application. For a correct working of such a security protocol, all of these components must work flawlessly. Many formal-methods based techniques for the analysis of a security protocols have been developed. They range from using specific logics (e.g.: BAN-logic [4], or higher order logics [12] to model checking [2] approaches. In each approach, the analysis tries to prove that no (or at least not a modeled intruder) can get access to secret data. Otherwise, a scenario illustrating the &tack may be produced. Despite the seeming simplicity of security protocols ("only" a few messages are sent between the protocol partners in order to ensure a secure communication), many flaws have been detected. Unfortunately, even a perfect protocol engine does not guarantee flawless working of a security protocol, as incidents show. Many break-ins and security vulnerabilities are caused by exploiting errors in the implementation of the protocol engine or the underlying operating system. Attacks using buffer-overflows are a very common class of such attacks. Errors in the implementation of exception or error handling can open up additional vulnerabilities. For example, on a website with a log-in screen: multiple tries with invalid passwords caused the expected error message (too many retries). but let the user nevertheless pass. Finally, security can be compromised by silly implementation bugs or design decisions. In a commercial VPN software, all calls to the encryption routines were incidentally replaced by stubs, probably during factory testing. The product worked nicely. and the error (an open VPN) would have gone undetected, if a team member had not inspected the low-level traffic out of curiosity. Also, the use secret proprietary encryption routines can backfire, because such algorithms often exhibit weaknesses which can be exploited easily (see e.g., DVD encoding). Summarizing, there is large number of possibilities to make errors which can compromise the security of a protocol. In today s world with short time-to-market and the use of security protocols in open and hostile networks for safety-critical applications (e.g., power or air-traffic control), such slips could lead to catastrophic situations. Thus, formal methods and automatic reasoning techniques should not be used just for the formal proof of absence of an attack, but they ought to be used to provide an end-to-end tool-supported framework for security software. With such an approach all required artifacts (code, documentation, test cases) , formal analyses, and reliable certification will be generated automatically, given a single, high level specification. By a combination of program synthesis, formal protocol analysis, certification; and proof-carrying code, this goal is within practical reach, since all the important technologies for such an approach actually exist and only need to be assembled in the right way.

Schumann, Johann↗