Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “file transfer”

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 145 records · Page 8

Evaluation of IEEE 802.11g and 802.16 for Lunar Surface Exploration Missions Using MACHETE Simulations

In this paper, we investigated the suitability of terrestrial wireless networking technologies for lunar surface exploration missions. Specifically, the scenario we considered consisted of two teams of collaborating astronauts, one base station and one rover, where the base station and the rover have the capability of acting as relays. We focused on the evaluation of IEEE 802.11g and IEEE 802.16 protocols, simulating homogeneous 802.11g network, homogeneous 802.16 network, and heterogeneous network using both 802.11g and 802.16. A mix of traffic flows were simulated, including telemetry, caution and warning, voice, command and file transfer. Each traffic type had its own distribution profile, data volume, and priority. We analyzed the loss and delay trade-offs of these wireless protocols with various link-layer options. We observed that 802.16 network managed the channel better than an 802.11g network due to controlled infrastructure and centralized scheduling. However, due to the centralized scheduling, 802.16 also had a longer delay. The heterogeneous (hybrid) of 802.11/802.16 achieved a better balance of performance in terms of data loss and delay compared to using 802.11 or 802.16 alone.

Segui, John↗

Smashing the Stovepipe: Leveraging the GMSEC Open Architecture and Advanced IT Automation to Rapidly Prototype, Develop and Deploy Next-Generation Multi-Mission Ground Systems

Satellite/Payload Ground Systems - Typically highly-customized to a specific mission's use cases - Utilize hundreds (or thousands!) of specialized point-to-point interfaces for data flows / file transfers Documentation and tracking of these complex interfaces requires extensive time to develop and extremely high staffing costs Implementation and testing of these interfaces are even more cost-prohibitive, and documentation often lags behind implementation resulting in inconsistencies down the road With expanding threat vectors, IT Security, Information Assurance and Operational Security have become key Ground System architecture drivers New Federal security-related directives are generated on a daily basis, imposing new requirements on current / existing ground systems - These mandated activities and data calls typically carry little or no additional funding for implementation As a result, Ground System Sustaining Engineering groups and Information Technology staff continually struggle to keep up with the rolling tide of security Advancing security concerns and shrinking budgets are pushing these large stove-piped ground systems to begin sharing resources - I.e. Operational / SysAdmin staff, IT security baselines, architecture decisions or even networks / hosting infrastructure Refactoring these existing ground systems into multi-mission assets proves extremely challenging due to what is typically very tight coupling between legacy components As a result, many "Multi-Mission" ops. environments end up simply sharing compute resources and networks due to the difficulty of refactoring into true multi-mission systems Utilizing continuous integration / rapid system deployment technologies in conjunction with an open architecture messaging approach allows System Engineers and Architects to worry less about the low-level details of interfaces between components and configuration of systems GMSEC messaging is inherently designed to support multi-mission requirements, and allows components to aggregate data across multiple homogeneous or heterogeneous satellites or payloads - The highly-successful Goddard Science and Planetary Operations Control Center (SPOCC) utilizes GMSEC as the hub for it's automation and situational awareness capability Shifts focus towards getting GS to a final configuration-managed baseline, as well as multi-mission / big-picture capabilities that help increase situational awareness, promote cross-mission sharing and establish enhanced fleet management capabilities across all levels of the enterprise.

GMSEC↗

Porting the Core Flight System to the Dellingr Cubesat

Dellingr is a 6U Cubesat developed by NASA Goddard Space Flight Center. It was delivered to the International Space Station in August 2017, and is scheduled to be deployed in November 2017. Compared to a typical NASA satellite, the Dellingr Cubesat had an extremely low budget and short schedule. Although the Dellingr Cubesat has minimal hardware resources, the cFS was ultimately chosen for the flight software. Using the cFS on the Dellingr Cubesat presented a few challenges, but also offered opportunities to help speed up development and verify the ACS flight software. This presentation will cover the lessons learned in porting the cFS to the Dellingr Cubesat, including working with the limited hardware resources, porting the cFS to FreeRTOS, and overcoming limitations related to data storage and file transfer. This presentation will also cover how hardware abstraction was used to run the flight software on multiple platforms and interface with the 42 dynamic simulator.

flight softwar↗

Pathfinder Technology Demonstrator: GlobalStar Testing and Results

The communications subsystem of a spacecraft is typically a SWaP (size, weight, and power) intensive subsystem in a SWaP constrained environment such as a CubeSat. Use of a satellite-based communication system, such as GlobalStars duplex GSP-1720 radio is a low SWaP potentially game-changing low-cost communication subsystem solution that was evaluated for feasibility for the NASA Pathfinder Technology Demonstrator (PTD) project. The PTD project is a series of 6U CubeSat missions to flight demonstrate and characterize novel small satellite payloads in low Earth orbit. GlobalStar is a low Earth orbit satellite constellation for satellite phone and low-speed data communications, and the GSP-1720 is their single board duplex radio most commonly used in satellite phones and shipment tracking devices. The PTD project tested the GSP-1720 to characterize its viability for flight using NASA GEVS (General Environmental Verification Standard) vibration and thermal vacuum levels, as well as testing the uplink-downlink connectivity, data throughput, and file transfer capabilities. This presentation will present the results of the environmental and capability testing of the GSP-1720 performed at NASA Ames Research Center, as well as the viability for CubeSat use in LEO.

satellite communication↗

Operations of the Optical Communications Demonstration for the Orion EM-2 Mission

The GSFC implementation of an Optical Communication System to demonstrate an operational optical communication link for Orion EM-2. It will serve as a base for providing an operational optical communications capability for future Orion missions. GSFC plans to maintain a development path for the optical communication flight terminal to allow commercialization and implementation on future Orion missions. The Orion optical module part of the optical communications flight terminal and its control electronics have a common architecture with the ILLUMA-T optical terminal provided by GSFC for use on the ISS. The plan is to flow data from Orion through the Optical Communication Fight Terminal to the Optical Communication Ground Terminal and reverse. NASA's Orion spacecraft is an exploratory vehicle designed for longer-duration flights beyond the Moon. Following Orion's Exploration Mission-1 (EM-1), during which the spacecraft will travel beyond the Moon, enter a distant retrograde orbit around the Moon and return to Earth unmanned, Exploration Mission-2 (EM-2) will see a crewed spacecraft complete a slightly different flight path. First crewed test flight of the Orion spacecraft, currently targeting a June 30, 2022 launch. The mission involves: One revolution in Low Earth Orbit (LEO) parking orbit to verify basic Orion systems functionality and deploy solar arrays. A single 42-hour Highly Elliptical Orbit (HEO) intermediate checkout orbit allows characterization of the Orion vehicle system performance prior to committing to a cis-lunar flight. Trans Lunar Injection (TLI) burn using Orion Service Module (SM) main engine, which sends Orion on a lunar flyby and free return. Skip reentry at lunar return velocities to splashdown off the coast of San Diego. Total mission duration is approximately 10 days. EM-2 is the first crewed mission of the Orion Spacecraft that crew brings more video up/downloads, file transfers, and real-time chats with family back home and high-rate communications enables live HD streaming for Crew conferences, Public Affairs Office (PAO) events, and significant mission events. Also still collecting vehicle data on numerous Orion subsystems via Development Flight Instrumentation (DFI) allows large data volume returns sooner for DFI and future science payloads, as opposed to waiting for end-of-mission. O2O is a demonstration of operational utility system tested as a Developmental Test Objective (DTO) and not required to meet mission requirements/success/ Flight Test Objectives (FTO). EM-2 architecture is as close to future mission operational architecture as possible.Orion subsystems (video, DFI, etc.) expected to generate ~250 GB of data in the first 24 hours of flight. Total data generated over the mission estimated to be more than 400 GBUsing S-Band alone, Orion limited to ~ 6GB of data downlink per day. Because of this limitation, Orion is planning to limit live video downlinks on EM-1 in order to downlink high priority fileswith 1 hour/day of Optical Communication, Orion could downlink ~6x more data per day (~ 36GB/day).The optical communication system is capable of multiple data rates up to at least 80 Mbps downlink for the transfer of Orion data to Earth while Orion is operating in the lunar vicinity.

Optical Communication↗

Truncated ARQ Statistical Link Analysis for Dynamic Links

The future deep space links are migrating towards higher frequency bands such as Ka band and optical. These links are susceptible to non Gaussian and non linear effects such as atmospheric turbulence, scintillation, antenna mis-pointing, jitter, etc. These dynamic links thus will experience various degrees of fading loss, and some of these link disruptions cannot be effectively mitigated by forward error correction coding and/or interleaving. One effective way to ensure reliable communication is by using Automatic Repeat Request (ARQ) protocol, where the receiver acknowledges to the transmitter whether or not a data unit is successfully received. If a data unit is not successfully received (such as after a pre-set time-out), the transmitter would then re-transmit the lost data unit to the receiver. In a previous paper, we derived a statistical link analysis method of finding the optimal operating Signal-to-Noise Ratio (SNR) and estimating the latency of an ARQ scheme. In a more recent paper, we demonstrated the above method using the SNR distribution constructed from the Ka-band (32 GHz) flight data. To simplify the discussion, we considered the academic approach that the ARQ scheme allows for an infinite number of retransmissions. In this paper, we consider the more practical case of a truncated ARQ scheme, where there is a limit on the number of retransmissions. We derive the error probability, the optimal SNR setting, and the latency statistics of the correctly received frames of the truncated ARQ schemes. We first discuss the truncated ARQ link analysis principles using the Gaussian assumption for SNR distribution with a large variance. Next, we demonstrate the statistical truncated ARQ link analysis using the SNR distribution constructed from the Ka-band flight data. The results in this paper can be applied in the design of reliable communication systems such as the Consultative Committee for Space Data System (CCSDS) File Transfer Protocol (CFTP) and the Delay Tolerant Network (DTN).

Morabito, David↗

Optical Communications Operations Concept for the Artemis II Crewed Mission to the Moon

NASA’s Artemis II mission will fly a human crew of 4 to the Moon aboard the Orion spacecraft for the first time since the Apollo missions. The Orion spacecraft includes an optical communication payload, known on board as “OpCom,” which is part of NASA’s Orion Artemis II Optical Communications (O2O) demonstration. OpCom will be controlled directly from the Mission Control System (MCC) in Houston and will support forward links up to 20 Mbps and return links up to 250 Mbps for at least 1 hour per mission day. It will be used to transfer files and provide real-time video SD and HD video to/from MCC. We describe the OpCom system architecture and operations concept.

optical communications↗

Space Station Operations Capabilities in a Shoebox: Marshall Space Flight Center’s Telescience Resource Kit

The International Space Station (ISS) has provided the world an unprecedented capability, establishing a continuous human foothold in outer space for more than 22 years now. But maintaining that capability and supporting the ambitious portfolio of scientific research it hosts has required another unprecedented capability – providing groundbased operations support for the crew and a diverse manifest of research payloads, all simultaneously. To help meet this challenge, NASA’s Marshall Space Flight Center (MSFC) developed TReK, the Telescience Resource Kit, providing a robust solution for data, command, metadata, and file transfer capabilities. In response to an increasingly wide and diverse need for operations support resources, the TReK team has worked to find ways to make the software more flexible in order to support a wide range of missions. Today it has supported not only hundreds of ISS payloads, but also free-flying spacecraft and even aircraft-based research. This presentation will discuss how the team has modified capabilities needed to enable 24/7/365 research aboard ISS to provide the flexibility needed to support Small Sat missions, going back to one of MSFC’s first “minisatellite” missions in 2010 and beyond.

Jeff Lippincott↗

Space Station Operations Capabilities in a Shoebox Marshall Space Flight Center’s Telescience Resource Kit

The International Space Station (ISS) has provided the world an unprecedented capability, establishing a continuous human foothold in outer space for more than 22 years now. But maintaining that capability and supporting the ambitious portfolio of scientific research it hosts has required another unprecedented capability – providing groundbased operations support for the crew and a diverse manifest of research payloads, all simultaneously. To help meet this challenge, NASA’s Marshall Space Flight Center (MSFC) developed TReK, the Telescience Resource Kit, providing a robust solution for data, command, metadata, and file transfer capabilities. In response to an increasingly wide and diverse need for operations support resources, the TReK team has worked to find ways to make the software more flexible in order to support a wide range of missions. Today it has supported not only hundreds of ISS payloads, but also free-flying spacecraft and even aircraft-based research. This presentation will discuss how the team has modified capabilities needed to enable 24/7/365 research aboard ISS to provide the flexibility needed to support Small Sat missions, going back to one of MSFC’s first “minisatellite” missions in 2010 and beyond.

Jeff Lippincott↗

Smallsat 2024 - Starling Cubesat Swarm Technology Demonstration Flight Results

The Starling swarm of four 6U CubeSats launched in July 2023 to test four key technologies to enable future swarm missions: 1) Mobile Ad-Hoc Networking (MANET) over a crosslink radio network 2) Autonomous onboard decision-making for operations 3) Optical-based absolute and relative navigation 4) Autonomous maneuver planning and execution The Starling team implemented the Better Approach to Mobile Ad-hoc Networking (B.A.T.M.A.N.) protocol to automatically manage the crosslink network of four satellites. The B.A.T.M.A.N. protocol uses a decentralized approach to managing a multi-hop mesh network of devices, in this case, a satellite swarm. The four satellites were able to successfully establish a network at multiple data rates and demonstrate file transfer and command issuance between spacecraft over the network. Starling incorporated Distributed Spacecraft Autonomy's (DSA) software to demonstrate onboard decision-making. The DSA software takes L1/L2 band GPS measurements and uses them to estimate the relative Total Electron Count (TEC) in the ionosphere. The onboard software then determines if there are any features of interest and provides that information to the other satellites over the crosslink network. The swarm of satellites then reaches a consensus on the optimal TEC observation strategy and adjusts its measurement collection tactics autonomously. The Starling Formation-Flying Optical Experiment (StarFOX), produced by Stanford's Space Rendezvous Laboratory, uses the onboard star trackers to collect images of the other swarm spacecraft and produce angles-only navigation estimates. This system is envisioned to be valuable in applications in which Global Navigation Satellite Systems (GNSS) are not available, such as in cis-lunar or deep space. StarFOX successfully applied its algorithms to multiple simultaneous spacecraft targets using the star tracker imagery. Finally, Starling used Emergent Space's Cluster Flight Application (CFA) software suite for the Reconfiguration and Orbit Maintenance Experiments Onboard (ROMEO) demonstration of autonomously planning and executing propulsive maneuvers. Large swarms will need to be able to maintain formation requirements with minimal operator involvement, especially as the size of the swarm scales up. Results from the ROMEO experiment are presented. Starling is funded by the Small Spacecraft Technology (SST) program out of NASA's Space Technology Mission Directorate (STMD).

distributed systems↗

Communication Delays in Cislunar Space: A Lab Study Examining Human System Integration Architecture (HSIA) and Team Risk Concerns

BACKGROUND: Communication delays are an inherent challenge of space missions to the Moon and beyond. Past research studies showed that 50+ second delays adversely affected individual well-being, team cohesion, and overall task performance (Kintz et al., 2016; Larson et al., 2019). However, there is a dearth of research on the effects of shorter delays (on the order of 4-12 seconds one-way) that may present a more immediate challenge during the upcoming Artemis missions. Even these shorter delays could make it difficult or infeasible for ground control to provide real-time support to Artemis astronauts, especially in complex and time-critical tasks such as extra-vehicular activities (EVAs). Results from studies on longer or Mars-like delays cannot be directly applied to Artemis-like delays, due to the large differences in delay magnitude and task types between these mission categories. For example, real-time oversight and guidance from ground control is impossible under Mars-like delays but may be performed under Artemis-like delays, albeit with potentially high workload and communication difficulty. Thus, a better understanding of the effects of Artemis-like communication delays on collaborative task performance is needed. Additionally, there is a need to develop reliable task paradigms that can be used in future studies on communication delays. METHODS: This project will study the effects of Artemis-like communication delays on collaborative task performance in a simulated space-to-ground team task via a lunar Gateway-like interface prototype. Teams of two astronaut-like participants - one serving as “crewmember” and one as “flight controller” - will perform a spaceflight-relevant task under six delay conditions (i.e., 0, 4, 6, 8, 10, and 12 seconds). Audio, video, texting, and file transfer will be delayed between the participants to mimic lunar-like communication delays. Measures related to workload, situation awareness, system usability, task performance, team cohesion, well-being, and communication strategies will be collected. These measures will be compared across delay levels, participant roles, and off-nominal and nominal tasks. Participants will be given the choice to use any combination of video and text communication in order to study preferences in interaction modality. RESEARCH AIMS: One aim is to identify a delay level or range of levels at which there may be significant decrements in individual and team-based measures. Identifying such ranges may help design novel workload management or communication countermeasures for future space missions. Also, the spaceflight-relevant research tasks and corresponding communication delay technology developed as part of this effort may be used for future studies on communication delays. Results from this work are also expected to inform study scenarios in the Human Exploration Research Analog (HERA) Campaign.

S Upasani↗

FTS3: Data Movement Service in containers deployed in OKD

The File Transfer Service (FTS3) is a data movement service developed at CERN which is used to distribute the majority of the Large Hadron Collider's data across the Worldwide LHC Computing Grid (WLCG) infrastructure. At Fermilab, we have deployed FTS3 instances for Intensity Frontier experiments (e.g. DUNE) to transfer data in America and Europe, using a container-based strategy. In this article we summarize our experience building docker images based on work from the SLATE project (slateci.io) and deployed in OKD, the community distribution of Red Hat OpenShift. Additionally, we discuss our method of certificate management and maintenance utilizing Kubernetes CronJobs. Finally, we also report on the two different configurations currently running at Fermilab, comparing and contrasting a Docker-based OKD deployment against a traditional RPM-based deployment.

Lobato Pardavila, Lorena↗

Verifying Cyber Implementation Best Practices With Malcolm

Network traffic analysis can reveal a lot about what's right or wrong with a network's cybersecurity footing. Using Malcolm, a powerful open-source network traffic analysis tool suite for network security monitoring, cyber analysts and asset owners can validate cybersecurity best practices and uncover red flags in network configuration, including: proper network segmentation east-west (cross-segment) and north-south traffic unsecure or outdated network protocols authentication using clear text credentials rogue devices and services unexpected protocols (e.g., IPv6, DNS, DHCP, update checks, etc.) suspicious file transfers

99 GENERAL AND MISCELLANEOUS↗

CMS Token Transition

Within the LHC community, a momentous transition has been occurring in authorization. For nearly 20 years, services within the Worldwide LHC Computing Grid (WLCG) have authorized based on mapping an identity, derived from an X.509 credential, or a group/role, derived from a VOMS extension issued by the experiment. A fundamental shift is occurring to capabilities: the credential, a bearer token, asserts the authorizations of the bearer, not the identity. By the HL-LHC era, the CMS experiment plans for the transition to tokens, based on the WLCG Common JSON Web Token profile, to be complete. Services in the technology architecture include the INDIGO Identity and Access Management server to issue tokens; a HashiCorp Vault server to store and refresh access tokens for users and jobs; a managed token bastion server to push credentials to the HTCondor CredMon service; and HTCondor to maintain valid tokens in long-running batch jobs. We will describe the transition plans of the experiment, current status, configuration of the central authorization server, lessons learned in commissioning token-based access with sites, and operational experience using tokens for both job submissions and file transfers.

43 PARTICLE ACCELERATORS↗

Fermilab's Transition to Token Authentication

Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. The grid workload management system GlideinWMS which is also based on HTCondor was updated to use tokens for pilot job submission. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility, but some experiments are beginning to transition to stop using them.

Dykstra, Dave [Fermilab] (ORCID:0000000326539015)↗

File-Format Program For Transferable Output ASCII Data

TOAD utilities machine-independent and require minimal central memory. Transferable Output ASCII Data (TOAD) file-format computer program facilitates transfer of data files from one computer installation to another. TOAD files preferred type and record length, easy to edit, read, and write on magnetic tape or transfer across communications networks. Applications programs write TOAD files directly and conform to all ANSI FORTRAN 77 standards.

Bingle, Bradford↗

Transferable Output ASCII Data (TOAD) file format description

Described is a format for writing ASCII data on a file to facilitate its transfer from one computer system to another. The TOAD format conforms to all ANSI FORTRAN 77 standards. There are two advantages in using the TOAD format. First, TOAD files are of the preferred type and record length to make them easy to edit, read from and write on magnetic tape, or transfer across communications networks. Secondly, application programs, using the TOAD format to write computational results, are more portable and the answer files easier to postprocess. TOAD utility software is listed in an appendix.

Bingel, Bradford↗

Program for transfer research and impact studies

Research activities conducted under the Program for Transfer Research and Impact Studies (TRIS) during 1972 included: (1) preparation of 10,196 TSP requests for TRIS application analysis; (2) interviews with over 500 individuals concerning the technical, economic, and social impacts of NASA-generated technology; (3) preparation of 38 new technology transfer example files and 101 new transfer cases; and (4) maintenance of a technology transfer library containing more than 2,900 titles. Six different modes of technology utilization are used to illustrate the pervasiveness of the transfer and diffusion of aerospace innovations. These modes also provide a basis for distinguishing the unique characteristics of the NASA Technology Utilization Program. An examination is reported of the ways in which NASA-generated technology is contributing to beneficial social change in five major areas of human concern: health, environment, safety, transportation, and communication.

Rusnak, J. J.↗