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 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
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↗
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.↗
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↗
NASA NTRS1999

Design of a Channel Error Simulator using Virtual Instrument Techniques for the Initial Testing of TCP/IP and SCPS Protocols

There exists a need for designers and developers to have a method to conveniently test a variety of communications parameters for an overall system design. This is no different when testing network protocols as when testing modulation formats. In this report, we discuss a means of providing a networking test device specifically designed to be used for space communications. This test device is a PC-based Virtual Instrument (VI) programmed using the LabVIEW(TM) version 5 software suite developed by National Instruments(TM)TM. This instrument was designed to be portable and usable by others without special, additional equipment. The programming was designed to replicate a VME-based hardware module developed earlier at New Mexico State University (NMSU) and to provide expanded capabilities exceeding the baseline configuration existing in that module. This report describes the design goals for the VI module in the next section and follows that with a description of the design of the VI instrument. This is followed with a description of the validation tests run on the VI. An application of the error-generating VI to networking protocols is then given.

Horan, Stephen↗
NASA NTRS2009

Wireless Network Communications Overview for Space Mission Operations

The mission of the On-Board Wireless Working Group (WWG) is to serve as a general CCSDS focus group for intra-vehicle wireless technologies. The WWG investigates and makes recommendations pursuant to standardization of applicable wireless network protocols, ensuring the interoperability of independently developed wireless communication assets. This document presents technical background information concerning uses and applicability of wireless networking technologies for space missions. Agency-relevant driving scenarios, for which wireless network communications will provide a significant return-on-investment benefiting the participating international agencies, are used to focus the scope of the enclosed technical information.

Fink, Patrick W.↗
NASA NTRS2004

Argumentation for coordinating shared activities

an increasing need for space missions to be able to collaboratively (and competitively) develop plans both within and across missions. In addition, interacting spacecraft that interleave onboard planning and execution must reach consensus on their commitments to each other prior to execution. In domains where missions have varying degrees of interaction and different constraints on communication and computation, the missions will require different coordination protocols in order to efficiently reach consensus with in their imposed deadlines. We describe a Shared Activity Coordination (SHAC) framework that provides a decentralized algorithm for negotiating the scheduling of shared activities over the lifetimes of multiple agents and a foundation for customizing protocols for negotiating planner interactions. We investigate variations of a few simple protocols based on argumentation and distributed constraints satisfaction techniques and evaluate their abilities to reach consistent solutions according to computation, time, and communication costs in an abstract domain where spacecraft propose joint measurements.

Mars↗
NASA NTRS2016

In-Space Networking on NASA's SCAN Testbed

The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios and a flight computer for supporting in-space communication research. New technologies being studied using the SCaN Testbed include advanced networking, coding, and modulation protocols designed to support the transition of NASAs mission systems from primarily point to point data links and preplanned routes towards adaptive, autonomous internetworked operations needed to meet future mission objectives. Networking protocols implemented on the SCaN Testbed include the Advanced Orbiting Systems (AOS) link-layer protocol, Consultative Committee for Space Data Systems (CCSDS) Encapsulation Packets, Internet Protocol (IP), Space Link Extension (SLE), CCSDS File Delivery Protocol (CFDP), and Delay-Tolerant Networking (DTN) protocols including the Bundle Protocol (BP) and Licklider Transmission Protocol (LTP). The SCaN Testbed end-to-end system provides three S-band data links and one Ka-band data link to exchange space and ground data through NASAs Tracking Data Relay Satellite System or a direct-to-ground link to ground stations. The multiple data links and nodes provide several upgradable elements on both the space and ground systems. This paper will provide a general description of the testbeds system design and capabilities, discuss in detail the design and lessons learned in the implementation of the network protocols, and describe future plans for continuing research to meet the communication needs for evolving global space systems.

space networks↗