Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “function as a service”

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 793 records · Page 44

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↗

Orbital Fluid Transfer System

An automated fluid and power interface system needs to be developed for future space missions which require on orbit consumable replenishment. Current method of fluid transfer require manned vehicles and extravehicular activity. Currently the US does not have an automated capability for consumable transfer on-orbit. This technology would benefit both Space Station and long duration satellites. In order to provide this technology the Automated Fluid Interface System (AFIS) was developed. The AFIS project was an advanced development program aimed at developing a prototype satellite servicer for future space operations. This mechanism could transfer propellants, cryogens, fluids, gasses, electrical power, and communications from a tanker unit to the orbiting satellite. The development of this unit was a cooperative effort between Marshall Space Flight Center in Huntsville, Alabama, and Moog, Inc. in East Aurora, New York. An engineering model was built and underwent substantial development testing at Marshall Space Flight Center (MSFC). While the AFIS is not suitable for spaceflight, testing and evaluation of the AFIS provided significant experience which would be beneficial in building a flight unit. The lessons learned from testing the AFIS provided the foundation for the next generation fluid transfer mechanism, the Orbital Fluid Transfer System (OFTS). The OFTS project was a study contract with MSFC and Moog, Inc. The OFTS was designed for the International Space Station (ISS), but its flexible design could used for long duration satellite missions and other applications. The OFTS was designed to be used after docking. The primary function was to transfer bipropellants and high pressure gases. The other items addressed by this task included propellant storage, hardware integration, safety and control system issues. A new concept for high pressure couplings was also developed. The results of the AFIS testing provided an excellent basis for the OFTS design. The OFTS meet the servicing requirements for ISS and could also provide the automated fluid and power interface system needed for on orbit consumable resupply of spacecraft into the new century.

Johnston, A. S., (Nick)↗

AIRSAR Automated Web-based Data Processing and Distribution System

In this paper, we present an integrated, end-to-end synthetic aperture radar (SAR) processing system that accepts data processing requests, submits processing jobs, performs quality analysis, delivers and archives processed data. This fully automated SAR processing system utilizes database and internet/intranet web technologies to allow external users to browse and submit data processing requests and receive processed data. It is a cost-effective way to manage a robust SAR processing and archival system. The integration of these functions has reduced operator errors and increased processor throughput dramatically.

WEB SERVICES↗

Apollo/Saturn 5 postflight trajectory: AS-512

The postflight trajectory is presented for the Apollo/Saturn V AS-512 flight. An analysis is included of the orbital and powered flight trajectories of the launch vehicle and the free flight trajectories of the expended S-IC and S-II stages. Trajectory dependent parameters are provided in earth-fixed launch site, launch vehicle navigation, and geographic polar coordinate systems. The time history of the trajectory parameters for the launch vehicle is presented from guidance reference release to Command Service Module (CSM) separation. Tables of significant parameters at engine cutoff, stage separation, parking orbit insertion, and translunar injection are included. Figures of such parameters as altitude, surface and cross range, and the magnitude of total velocity and acceleration as a function of range time for the powered flight trajectories are presented.

Pinson, G. T.↗

CTS /Hermes/ - United States experiments and operations summary

The U.S. experiments conducted with the Communications Technology Satellite, a joint Canadian-U.S. venture launched in 1976, are discussed. The 14/12 GHz frequencies employed by the 200-W transmitter on board the satellite provide two-way television and voice communications. Applications of the satellite in the categories of health care, community services and education are considered; experiments have also made use of the special properties of the super-high frequency band (e.g. link characterization and digital communications). Time-sharing of the 14/12 GHz communication between the U.S. and Canada has functioned well.

Donoughe, P. L.↗

Test and evaluation plan for the Centralized Storm Information System

The installation of the Centralized Storm Information System (CSIS) at the NOAA operational complex in Kansas City, Missouri is described. This complex includes the National Severe Storms Forecast center and a Satellite Field Service Station which is denoted in this research plan as NSSFC. CSIS computers will act in concert to merge analyze the many data sets needed to forecast severe convective storms. Specific aspects of CSIS are evaluated against the CSIS objectives. The functions to be evaluated characterize the attributes of a generalized interactive computer system. A major development in the CSIS program will allow communication between CSIS and the NSSFC Eclipse computer.

Source record↗

Design and implementation of interface units for high speed fiber optics local area networks and broadband integrated services digital networks

The design and implementation of interface units for high speed Fiber Optic Local Area Networks and Broadband Integrated Services Digital Networks are discussed. During the last years, a number of network adapters that are designed to support high speed communications have emerged. This approach to the design of a high speed network interface unit was to implement package processing functions in hardware, using VLSI technology. The VLSI hardware implementation of a buffer management unit, which is required in such architectures, is described.

Tobagi, Fouad A.↗

On-board processing architectures for satellite B-ISDN services

Onboard baseband processing architectures for future satellite broadband integrated services digital networks (B-ISDN's) are addressed. To assess the feasibility of implementing satellite B-ISDN services, critical design issues, such as B-ISDN traffic characteristics, transmission link design, and a trade-off between onboard circuit and fast packet switching, are analyzed. Examples of the two types of switching mechanisms and potential onboard network control functions are presented. A sample network architecture is also included to illustrate a potential onboard processing system.

Inukai, Thomas↗

On-board processing satellite network architectures for broadband ISDN

Onboard baseband processing architectures for future satellite broadband integrated services digital networks (B-ISDN's) are addressed. To assess the feasibility of implementing satellite B-ISDN services, critical design issues, such as B-ISDN traffic characteristics, transmission link design, and a trade-off between onboard circuit and fast packet switching, are analyzed. Examples of the two types of switching mechanisms and potential onboard network control functions are presented. A sample network architecture is also included to illustrate a potential onboard processing system.

Inukai, Thomas↗

Space Commercialization

A robust and competitive commercial space sector is vital to continued progress in space. The United States is committed to encouraging and facilitating the growth of a U.S. commercial space sector that supports U.S. needs, is globally competitive, and advances U.S. leadership in the generation of new markets and innovation-driven entrepreneurship. Energize competitive domestic industries to participate in global markets and advance the development of: satellite manufacturing; satellite-based services; space launch; terrestrial applications; and increased entrepreneurship. Purchase and use commercial space capabilities and services to the maximum practical extent Actively explore the use of inventive, nontraditional arrangements for acquiring commercial space goods and services to meet United States Government requirements, including measures such as public-private partnerships, . Refrain from conducting United States Government space activities that preclude, discourage, or compete with U.S. commercial space activities. Pursue potential opportunities for transferring routine, operational space functions to the commercial space sector where beneficial and cost-effective.

Martin, Gary L.↗

Interoperable End-To-End Space Communications Architecture Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗

Interoperable End-To-End Space Communications Architectures Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗

Ground Segment Operations Concept for the Orion Artemis-2 Optical Communications System

The ACCESS Project (formerly Space Network) will implement an optical communications ground segment to support the Orion Artemis II Optical Communications (O2O) demonstration as part of the next manned human spaceflight mission to the moon, Artemis II. O2O implements laser communication (lasercomm) technology for operational use on the Orion series of spacecraft, as a development test objective (DTO), in order to demonstrate the feasibility and operational utility of lasercomm for human spaceflight missions. O2O consists of three segments: Space Segment, Ground Segment, and Operations Segment. The Space Segment consists of the Space Terminal Element and the Orion spacecraft. The Space Terminal Element effort is managed by the GSFC Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) project in collaboration with MIT Lincoln Laboratory. The Ground Segment consists of an optical ground terminal (GT) at the White Sands Complex (WSC), which is being developed in collaboration with MIT Lincoln Laboratory, the Ground Segment Operations and Analysis (GSOA) element and Ground Data Element (GDE), and a second optical GT in the Optical Communications Telescope Laboratory (OCTL) at the JPL Table Mountain Facility. The Operations Segment consists of the Artemis II Mission Control Center (MCC), the Lasercomm Space Terminal Console (LSTC), and the Lasercomm Link Planning & Analysis Center (LPAC), all located at the Johnson Space Center (JSC). O2O utilizes pulse-position modulation (PPM) direct-to-earth services resulting in an 80 Mbps downlink data rate from lunar orbit. The O2O concept of operations is to provide optical services for a minimum of 1 hour per day for each day of the Artemis II mission. O2O will utilize a 10-20 Mbps uplink data rate and 40-260 Mbps downlink data rate, depending on the Artemis II mission phase. The ACCESS project will also provide a centralized mission data interface for user data distribution and storage to the MCC and perform planning and scheduling of services in coordination with the Operations Segment for the O2O Ground Segment. The O2O Ground Segment will support the following O2O mission phases: Pre-Mission Planning; Daily Operations Planning; Event Execution; and Post-Pass Reporting. O2O will be used to exchange data files between Orion and the MCC and to distribute real-time video through the optical downlink service to the MCC; which would not be possible without the high-bandwidth link that O2O will provide to Orion. In this paper, I will discuss the O2O Ground Segment development approach and how it will support these critical O2O functions: plan and schedule the contact; acquire and track the optical link; flow information bidirectionally; distribute information; and control and accommodate the system.

optical communications↗

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↗

Continental Land Mass Air Traffic Control (COLM ATC)

The application of various satellite systems and techniques relative to providing air traffic control services for the continental United States was studied. Three satellite configurations were reviewed. The characteristics and capabilities of the satellites are described. The study includes consideration for the various ranging waveforms, multiple access alternatives, and the power and bandwidth required as a function of the number of users.

Pecar, J. A.↗

Survey: Federal Aviation Administration National Communication Center

The National Communication (NATCOM) Center (commonly known as the FAA Weather Message Switching Center), is a Federal Aviation Administration (FAA) facility with responsibility for providing communication switching services to the National Weather Service (NWS), the FAA, commercial and private flight organizations under the auspices of the FAA, and DoD. Data handled by NATCOM include weather data, flight plans, and Notices to Airmen (NOTAMS) on both national and international networks. The communications and data management functions are handled through four computer-controlled communication networks designated as WMSC, AFTN, A-BDIS, and NASNET. The functions of these networks are discussed with emphasis on those networks that support the different elements of the NWS. The primary network of concern to NASA, the WMSC (Weather Message Switching Center) network, performs approximately 60 percent of its work for the NWS, 20 percent for the State Department, and 20 percent for the FAA. This document discusses the current and future systems capabilities and workload of NATCOM in terms of new roles.

Source record↗

Infrasonic emissions from local meteorological events: A summary of data taken throughout 1984

Records of infrasonic signals, propagating through the Earth's atmosphere in the frequency band 2 to 16 Hz, were gathered on a three microphone array at Langley Research Center throughout the year 1984. Digital processing of these records fulfilled three functions: time delay estimation, based on an adaptive filter; source location, determined from the time delay estimates; and source identification, based on spectral analysis. Meteorological support was provided by significant meteorological advisories, lightning locator plots, and daily reports from the Air Weather Service. The infrasonic data are organized into four characteristic signatures, one of which is believed to contain emissions from local meteorological sources. This class of signature prevailed only on those days when major global meteorological events appeared in or near to eastern United States. Eleven case histories are examined. Practical application of the infrasonic array in a low level wing shear alert system is discussed.

Zuckerwar, A. J.↗

Orbit Determination Toolbox

The Orbit Determination Toolbox is an orbit determination (OD) analysis tool based on MATLAB and Java that provides a flexible way to do early mission analysis. The toolbox is primarily intended for advanced mission analysis such as might be performed in concept exploration, proposal, early design phase, or rapid design center environments. The emphasis is on flexibility, but it has enough fidelity to produce credible results. Insight into all flight dynamics source code is provided. MATLAB is the primary user interface and is used for piecing together measurement and dynamic models. The Java Astrodynamics Toolbox is used as an engine for things that might be slow or inefficient in MATLAB, such as high-fidelity trajectory propagation, lunar and planetary ephemeris look-ups, precession, nutation, polar motion calculations, ephemeris file parsing, and the like. The primary analysis functions are sequential filter/smoother and batch least-squares commands that incorporate Monte-Carlo data simulation, linear covariance analysis, measurement processing, and plotting capabilities at the generic level. These functions have a user interface that is based on that of the MATLAB ODE suite. To perform a specific analysis, users write MATLAB functions that implement truth and design system models. The user provides his or her models as inputs to the filter commands. The software provides a capability to publish and subscribe to a software bus that is compliant with the NASA Goddard Mission Services Evolution Center (GMSEC) standards, to exchange data with other flight dynamics tools to simplify the flight dynamics design cycle. Using the publish and subscribe approach allows for analysts in a rapid design center environment to seamlessly incorporate changes in spacecraft and mission design into navigation analysis and vice versa.

Carpenter, James R.↗