Search NASA⌕ Search

SEARCH · Search NASA

Results for “flexible architectures”

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 271 records · Page 15

Propulsion Control Technology Development Needs to Address NASA Aeronautics Research Mission Goals for Thrusts 3a and 4

The Commercial Aero-Propulsion Control Working Group (CAPCWG), consisting of propulsion control technology leads from The Boeing Company, GE Aviation, Honeywell, Pratt & Whitney, Rolls-Royce, and NASA (National Aeronautics and Space Administration) Glenn Research Center, has been working together over the past year to identify propulsion control technology areas of common interest that we believe are critical to achieving the challenging NASA Aeronautics Research goals for Thrust 3a: Ultra-Efficient Commercial Vehicles - Subsonic Transports, and Thrust 4: Transition to Alternative Propulsion and Energy. This paper describes the various propulsion control technology development areas identified by CAPCWG as most critical for NASA to invest in. For Thrust 3a these are: i) Integrated On-Board Model Based Engine Control and Health Management; ii) Flexible and Modular Networked Control Hardware and Software Architecture; iii) Intelligent Air/Fuel Control for Low Emissions Combustion; and iv) Active Clearance Control. For Thrust 4a, the focus is on Hybrid Electric Propulsion (HEP) for single aisle commercial aircraft. The specific technology development areas include: i) Integrated Power and Propulsion System Dynamic Modeling for Control; ii) Control Architectures for HEP; iii) HEP Control Verification and Validation; and iv) Engine/Airplane Control Integration. For each of the technology areas, the discussion includes: problem to be solved and how it relates to NASA goals, and the challenges to be addressed in reducing risk.

Propulsion Control↗

Probabilistic Modeling of a Three-Stage Human Landing System Architecture

Space Policy Directive-1 has led to NASA partnerships with commercial entities on procurement which includes the development of the Human Landing System (HLS) [1]. With the goal of delivering human crew to the lunar surface by 2024, system uncertainties become an important obstacle to the maturation of multiple new, driving technologies and mission concepts of the HLS program. As unmitigated uncertainties have previously led to failed development programs, these risks and their impacts must be understood and handled to ensure program success [2]. Sources of uncertainty include novel engine designs and configurations, increased reliance on cryogenic fluid management(CFM), and refueling technologies—which propagate as high-level performance metrics such as overall propellant mass and engine performance. Also, the occurrence of operational uncertainties—e.g. launch conditions or need to abort during the mission—can cause cascading effects on the rest of the mission that are difficult to definitively quantify, and are outside the scope of control. These concrete examples and other occurrences can be categorized as either epistemic or aleatory uncertainties.Epistemic uncertainty arises due to a lack of knowledge and can be alleviated with design and program maturation. Aleatory uncertainty is due to the inherent randomness of the system and cannot be directly reduced, unlike epistemic uncertainty. Robust design and probabilistic methods can compensate for aleatory effects. A taxonomy of uncertainty is referred to for this work [3]. In this paper, a probabilistic methodology to handle uncertainties has been demonstrated on a three-element HLS concept [1, 4], which allows tracking of current best estimates of the concept and assessment of concept design robustness against uncertainties. A sample case has been completed for this abstract, and an expansion on the methodology will be included in the final paper. This methodology has two key parts: first, the creation of a dynamic architecture model of a three-element HLS concept; and second, its use with surrogate modeling and range estimating techniques to capture and propagate uncertainties. This abstract will cover the basics of the approach used, and further details and justifications will be in the final paper.The mission profile associated with this three-element concept (Fig 1) was modeled as a set of mission events that facilitated mass changes, idles, or spacecraft maneuvers. The mission profile scope starts with each element’s NRHO orbit insertion and aggregation and ends at post-sortie rendezvous with Orion. More detail on the mission profile will be in the final paper. The DYnamic Rocket EQuation Tool (DYREQT), a space systems synthesis and sizing framework used by NASA, was used as the physics framework to model the HLS architecture for applying the probabilistic methodology [5, 6]. Specifically, a parametric representation of the lander, ascent, and transfer elements and the mission profile of each element was established, with vehicle and mission parameters available as inputs to allow for a dynamic model. Each vehicle stage was modeled with high-level performance metrics, using Isp and propellant mass fraction (PMF) to remain parametric. For the probabilistic analysis, uncertainties of interest within the HLS concept were enumerated and represented as parameters within the DYREQT model as inputs for vehicle stages or mission profile events. These parameters were frozen at their nominal values for the purposes of baselining architecture performance and sizing the vehicle appropriately based on reference documentation [1]. Range estimating—a probabilistic method that combines Monte Carlo sampling, focus on critical parameters, and heuristics to assess risk and opportunities—is traditionally used with Mass Equipment Lists (MELs), but has been adapted with operational parameters as well as vehicle parameters in theDYREQT model to capture mission uncertainty alongside vehicle uncertainty [7, 3]. This method was selected due to its application and insight on a system from a bottom-up perspective, independence from historical rules of thumb, and ability to generate sensitivities based on design decisions and uncertainties. As a sample case for the abstract, the boiloff rates of the vehicle elements and the loiter times during the mission (simulating launch time variations and changing window of opportunities) were used with range estimating to provide preliminary results. To perform the range estimation portion of this methodology (depicted in Fig. 3, further details in final paper), the DYREQT model was sampled using a Design of Experiments (DoE) to efficiently explore the architecture design space with respect to the sample set of uncertainty parameters; 5,000 cases via Latin Hypercube Sampling were computed on the DYREQT architecture model. Then, the results were used to create surrogate models, multivariate regressions that can visualize hypercube trends in the design space, of the architecture with respect to the uncertainty parameters. Range estimating was applied to the surrogates instead of the actual models, which saves computational expense due to the bulk of cases needed for the Monte Carlo simulation as part of range estimating. Uncertainty parameters were sampled independently from triangular distributions using the DoE ranges as ‘min’ and ‘max’, and the nominal value as ‘most likely’. Based engineering intuition, some uncertainty parameters are correlated—e.g. if the main propellant has a high boil-off rate, the oxidizer should follow suit as both are related to CFM technology.While a Monte Carlo simulation samples all inputs as independent, the results would show model correlations; thus, it is efficient to sample the inputs as correlated. Using a correlation matrix constructed for the uncertainty parameters, previously independent samples were transformed to perform a Correlated Monte Carlo. A table for the DoE ranges and probability distribution parameters is shown in Table 1, and more details on Correlated Monte Carlo Simulations will be discussed in the final paper. The model’s resulting DoE showed that multivariate polynomial equations fit via least squares method captured its behavior accurately for the sample case. For the Correlated Monte Carlo Simulation, a positive correlation between fuel and oxidizer boiloff rates was used as a demonstration. 10,000 cases were computed with the surrogates and the launched masses for each vehicle element was collated. The results can be displayed in a probability density function (PDF), showing the impact of the uncertainty parameters chosen. Integrating the PDFs will yield a cumulative distribution function (CDF) that shows the cumulative probability of a given value on the x-axis. For the sample case, the elements’ launch mass margin was calculated and represented in as CDFs, as a demonstrated representation of figures of merit for the HLS concept. For the lander and ascent elements, the NRHO mass insertion limit is 16t; the transfer element has a limit of 30t [1]. It can be seen with Figure 2 that this probabilistic methodology can provide insight into mass margin with respect to the uncertainties being modeled. Currently, the results show that the lander (descent) vehicle element has the most restrictive design space; it is the only element to show a 10% probability of negative margin. Further analysis on the Monte Carlo results will show sensitivities for driving constraints and parameters for architecture feasibility, which can lead to establishing potential mission rules.The combination of range estimating with a parametric architecture model for HLS demonstrated the capability of this probabilistic methodology in a sample case. As the HLS development progresses, this methodology has the potential for keeping current best estimates of architecture performance for awarded concepts due to the flexibility in DYREQT’s modeling framework and its parametric nature. Concept maturation and increased epistemic knowledge can be injected into the model probabilistic modeling, and thus continue to track probability of mission success.

Stephanie Y Zhu↗

The NASA/OAST telerobot testbed architecture

Through a phased development such as a laboratory-based research testbed, the NASA/OAST Telerobot Testbed provides an environment for system test and demonstration of the technology which will usefully complement, significantly enhance, or even replace manned space activities. By integrating advanced sensing, robotic manipulation and intelligent control under human-interactive supervision, the Testbed will ultimately demonstrate execution of a variety of generic tasks suggestive of space assembly, maintenance, repair, and telescience. The Testbed system features a hierarchical layered control structure compatible with the incorporation of evolving technologies as they become available. The Testbed system is physically implemented in a computing architecture which allows for ease of integration of these technologies while preserving the flexibility for test of a variety of man-machine modes. The development currently in progress on the functional and implementation architectures of the NASA/OAST Testbed and capabilities planned for the coming years are presented.

Matijevic, J. R.↗

Advanced Modular Power Approach to Affordable, Supportable Space Systems

Recent studies of missions to the Moon, Mars and Near Earth Asteroids (NEA) indicate that these missions often involve several distinct separately launched vehicles that must ultimately be integrated together in-flight and operate as one unit. Therefore, it is important to see these vehicles as elements of a larger segmented spacecraft rather than separate spacecraft flying in formation. The evolution of large multi-vehicle exploration architecture creates the need (and opportunity) to establish a global power architecture that is common across all vehicles. The Advanced Exploration Systems (AES) Modular Power System (AMPS) project managed by NASA Glenn Research Center (GRC) is aimed at establishing the modular power system architecture that will enable power systems to be built from a common set of modular building blocks. The project is developing, demonstrating and evaluating key modular power technologies that are expected to minimize non-recurring development costs, reduce recurring integration costs, as well as, mission operational and support costs. Further, modular power is expected to enhance mission flexibility, vehicle reliability, scalability and overall mission supportability. The AMPS project not only supports multi-vehicle architectures but should enable multi-mission capability as well. The AMPS technology development involves near term demonstrations involving developmental prototype vehicles and field demonstrations. These operational demonstrations not only serve as a means of evaluating modular technology but also provide feedback to developers that assure that they progress toward truly flexible and operationally supportable modular power architecture.

Oeftering, Richard C.↗

Evaluation of Dual-Launch Lunar Architectures Using the Mission Assessment Post Processor

The National Aeronautics and Space Administrations (NASA) Constellation Program is currently designing a new transportation system to replace the Space Shuttle, support human missions to both the International Space Station (ISS) and the Moon, and enable the eventual establishment of an outpost on the lunar surface. The present Constellation architecture is designed to meet nominal capability requirements and provide flexibility sufficient for handling a host of contingency scenarios including (but not limited to) launch delays at the Earth. This report summarizes a body of work performed in support of the Review of U.S. Human Space Flight Committee. It analyzes three lunar orbit rendezvous dual-launch architecture options which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. NASA employed the recently-developed Mission Assessment Post Processor (MAPP) tool to quickly evaluate vehicle performance requirements for several candidate approaches for conducting human missions to the Moon. The MAPP tool enabled analysis of Earth perturbation effects and Earth-Moon geometry effects on the integrated vehicle performance as it varies over the 18.6-year lunar nodal cycle. Results are provided summarizing best-case and worst-case vehicle propellant requirements for each architecture option. Additionally, the associated vehicle payload mass requirements at launch are compared between each architecture and against those of the Constellation Program. The current Constellation Program architecture assumes that the Altair lunar lander and Earth Departure Stage (EDS) vehicles are launched on a heavy lift launch vehicle. The Orion Crew Exploration Vehicle (CEV) is separately launched on a smaller man-rated vehicle. This strategy relaxes man-rating requirements for the heavy lift launch vehicle and has the potential to significantly reduce the cost of the overall architecture over the operational lifetime of the program. The crew launch occurs first, four days prior to the optimal trans-lunar injection (TLI) departure window. This is done to allow for launch delays in the Altair/EDS launch. During this time, the Orion vehicle is required to conduct orbit maintenance while loitering in low Earth orbit (LEO). The alternative architectures presented aim to eliminate the need for costly orbit maintenance maneuvers while loitering in LEO. In all of the alternative architectures considered, it is assumed that the Altair and Orion vehicles are nominally launched 90 minutes apart, depart the Earth separately, and complete the rendezvous and docking sequence at the Moon. In this lunar orbit rendezvous (LOR) strategy, both the Altair and Orion vehicles will require separate EDS stages, and each will be required to perform lunar orbit insertion (LOI). This has the effect of balancing payload requirements between the two launch vehicles at the Earth. In this case, the overall payload mass is increased slightly, but the increased mission costs could potentially be offset by requiring the construction of two rockets similar in size and nature, unlike the current Constellation architecture. Three dual-launch architecture options with LOR were evaluated, which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. Benefits and drawbacks of each of the dual-launch architecture options with LOR are discussed and the overall mission performance is compared with that of the existing Constellation Program lunar architecture.

Stewart, Shaun M.↗

Flexible Proteins at the Origin of Life

Almost all modern proteins possess well-defined, relatively rigid scaffolds that provide structural preorganization for desired functions. Such scaffolds require the sufficient length of a polypeptide chain and extensive evolutionary optimization. How ancestral proteins attained functionality, even though they were most likely markedly smaller than their contemporary descendants, remains a major, unresolved question in the origin of life. On the basis of evidence from experiments and computer simulations, we argue that at least some of the earliest water-soluble and membrane proteins were markedly more flexible than their modern counterparts. As an example, we consider a small, evolved in vitro ligase, based on a novel architecture that may be the archetype of primordial enzymes. The protein does not contain a hydrophobic core or conventional elements of the secondary structure characteristic of modern water-soluble proteins, but instead is built of a flexible, catalytic loop supported by a small hydrophilic core containing zinc atoms. It appears that disorder in the polypeptide chain imparts robustness to mutations in the protein core. Simple ion channels, likely the earliest membrane protein assemblies, could also be quite flexible, but still retain their functionality, again in contrast to their modern descendants. This is demonstrated in the example of antiamoebin, which can serve as a useful model of small peptides forming ancestral ion channels. Common features of the earliest, functional protein architectures discussed here include not only their flexibility, but also a low level of evolutionary optimization and heterogeneity in amino acid composition and, possibly, the type of peptide bonds in the protein backbone.

Flexible protein↗

High-Performance Spaceflight Computing (HPSC) Middleware Overview

High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes in 2021. The HPSC Chiplet prototypes will be delivered with an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an overview of the HPSC project, including a hardware overview, system software overview, Middleware overview, and mission use cases. The hardware overview will provide a look at the 8 core High Performance Processing Subsystem (HPPS), the Real Time Processing Subsystem (RTPS), the Chiplet Configuration Management Subsystem, on chip peripherals, and high speed I/O. The system software overview will introduce the boot loaders, operating systems, device drivers, and software development environment. The Middleware overview will provide insight into the high-level services that will be provided to help mission developers manage the many resources and configurations made possible with the Chiplet. Finally, the presentation will provide a brief look at the mission use cases that can be enabled with this next generation architecture.

middleware↗

Evolution of the Florida Launch Site Architecture: Embracing Multiple Customers, Enhancing Launch Opportunities

The impending conclusion of the Space Shuttle Program and the Constellation Program cancellation unveiled in the FY2011 President's budget created a large void for human spaceflight capability and specifically launch activity from the Florida launch Site (FlS). This void created an opportunity to re-architect the launch site to be more accommodating to the future NASA heavy lift and commercial space industry. The goal is to evolve the heritage capabilities into a more affordable and flexible launch complex. This case study will discuss the FlS architecture evolution from the trade studies to select primary launch site locations for future customers, to improving infrastructure; promoting environmental remediation/compliance; improving offline processing, manufacturing, & recovery; developing range interface and control services with the US Air Force, and developing modernization efforts for the launch Pad, Vehicle Assembly Building, Mobile launcher, and supporting infrastructure. The architecture studies will steer how to best invest limited modernization funding from initiatives like the 21 st elSe and other potential funding.

Colloredo, Scott↗

Redundancy in sensors, control and planning of a robotic system for space telerobotics

The analysis and development of a manipulator redundant in structure and sensor devices controlled by a distributed multiprocessor architecture are discussed. The goal has been the realization of a modular structure of the manipulator with evident aspects of flexibility and transportability. The distributed control structure, thanks to his modularity and flexibility could be integrated in the future into an operative structure aimed to space telerobotics. The architecture is applied to the 6 DOF manipulator Gilberto.

Rovetta, A.↗

Laser Doppler Velocimetry and full-field soot volume fraction

Since its introduction in the mid-sixties, Laser Doppler Velocimetry (LDV) has become one of the most widely used methods for the measurement of flows. Its remote and essentially non-intrusive nature provides an invaluable tool for a variety of difficult measurement situations which would be otherwise inaccessible. The high spatial resolution and rapid temporal response afforded by this technique are well suited to the determination of spatial and temporal details of flow fields, as well as characterization of turbulence. Advances in the understanding of the properties of LDV signals, accompanied by technological advances in coherent laser sources, detectors of high sensitivity and low noise, optical fabrication techniques and high-speed digital signal processing architectures have resulted in systems of increased accuracy and flexibility. As will be shown, recent progress in solid-state lasers and photo-detectors has been beneficial insofar as the compatibility of this method with the unique and severe constraints inherent in microgravity combustion science experiments.

Greenberg, Paul S.↗

An Enabling Technology for New Planning and Scheduling Paradigms

The Night Projects Directorate at NASA's Marshall Space Flight Center is developing a new planning and scheduling environment and a new scheduling algorithm to enable a paradigm shift in planning and scheduling concepts. Over the past 33 years Marshall has developed and evolved a paradigm for generating payload timelines for Skylab, Spacelab, various other Shuttle payloads, and the International Space Station. The current paradigm starts by collecting the requirements, called ?ask models," from the scientists and technologists for the tasks that are to be scheduled. Because of shortcomings in the current modeling schema, some requirements are entered as notes. Next, a cadre with knowledge of vehicle and hardware modifies these models to encompass and be compatible with the hardware model; again, notes are added when the modeling schema does not provide a better way to represent the requirements. Finally, the models are modified to be compatible with the scheduling engine. Then the models are submitted to the scheduling engine for automatic scheduling or, when requirements are expressed in notes, the timeline is built manually. A future paradigm would provide a scheduling engine that accepts separate science models and hardware models. The modeling schema would have the capability to represent all the requirements without resorting to notes. Furthermore, the scheduling engine would not require that the models be modified to account for the capabilities (limitations) of the scheduling engine. The enabling technology under development at Marshall has three major components: (1) A new modeling schema allows expressing all the requirements of the tasks without resorting to notes or awkward contrivances. The chosen modeling schema is both maximally expressive and easy to use. It utilizes graphical methods to show hierarchies of task constraints and networks of temporal relationships. (2) A new scheduling algorithm automatically schedules the models without the intervention of a scheduling expert. The algorithm is tuned for the constraint hierarchies and the complex temporal relationships provided by the modeling schema. It has an extensive search algorithm that can exploit timing flexibilities and constraint and relationship options. (3) An innovative architecture allows multiple remote users to simultaneously model science and technology requirements and other users to model vehicle and hardware characteristics. The architecture allows the remote users to submit scheduling requests directly to the scheduling engine and immediately see the results. These three components are integrated so that science and technology experts with no knowledge of the vehicle or hardware subsystems and no knowledge of the internal workings of the scheduling engine have the ability to build and submit scheduling requests and see the results. The immediate feedback will hone the users' modeling skills and ultimately enable them to produce the desired timeline. This paper summarizes the three components of the enabling technology and describes how this technology would make a new paradigm possible.

Jaap, John↗

High Performance Spacecraft Computing (HPSC) Middleware Update

High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes, an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an HPSC project update, an overview of the latest HPSC System Software release, an overview of HPSC Middleware Release 2, and a preview of the third HPSC Middleware release. The presentation will begin with a project update that will provide a look at the high-level changes since the project was introduced at the Flight Software Workshop last year. Next, the presentation will provide an overview of the current suite of HPSC System Software which includes the vendor provided bootloaders, operating systems, emulator, and development tools. Next, the HPSC Middleware progress will be presented, which includes an overview of the features and capabilities of HPSC Middleware Release 2, followed by a look at the reference flight software applications which utilize the Middleware. Finally, the presentation will give a preview of the HPSC Middleware Release 3.

Cudmore, Alan↗

Adding GPU Support to the Markov Chain Monte Carlo Code Catmip

In geophysics, we are confronted with many under-determined inverse problems. For example, all of our observations of earthquakes are made at the Earth’s surface. So, when we try to infer how slip during an earthquake evolves in space and time, we find that there are many potential slip histories that are consistent with our limited observations and our understanding of earthquake physics. One way to approach these problems is with Bayesian analysis which allows us to infer the ensemble of all potential slip models that satisfy the observations and our prior knowledge of earthquake physics. In Bayesian analysis, our prior knowledge is known as the prior probability density function or prior PDF, the fit to the data is known as the data likelihood, and the target PDF that satisfies both the prior PDF and data likelihood is known as the posterior PDF. However, simulating the posterior PDF typically requires using Markov Chain Monte Carlo (MCMC) to draw tens of billions of random realizations of earthquake slip models, which may not be computationally feasible. To make this and similar geophysical inversions computationally tractable, we developed the Cascading Adaptive Transitional Metropolis In Parallel (CATMIP) algorithm. CATMIP is an efficient parallel Markov Chain Monte Carlo (MCMC) sampler that is used for model fitting and uncertainty quantification in geophysics. Example use cases are earthquake rupture modeling, determining mineral composition on Mars, reconstructing the history of ocean salinity, and historical earthquake relocation. CATMIP employs many parallel instances of the Metropolis algorithm for sampling in a transitioning framework. Transitioning is a process in which a set of random samples at equilibrium with a known probability density function (PDF) are used as seeds for the Markov chains to sample successive target PDFs that incrementally move the distribution from the starting seeds to the final desired PDF that describes the relative plausibility of potential values for the model parameters. The algorithm is implemented as a Master-Worker model employing MPI for communication. The worker processes are loosely coupled with global parameters periodically optimized by the master process. This provides a very high amount of parallelism with little communication between updates. During the presentation we will discuss the history of the algorithm and elaborate the earthquake rupture modeling use case for the CATMIP package. Our first step toward GPU optimization was to optimize the code for the CPU. CPU profiling revealed that most of the compute time is spent in calls to level 2 BLAS routines and calls to GSL random number generators. We revised the algorithm to employ level 3 BLAS routines instead. In our presentation we will describe how this was accomplished. Adding GPU support to CATMIP consisted mostly of replacing the calls to GSL with calls to GPU vendor-provided library routines. A small number of loops were directly implemented in CUDA. In the presentation will provide implementation details. Finally, we will discuss methods for profiling and opportunities for further optimizing GPU execution. By creating a code with the flexibility to run on either a CPU or GPU architecture, CATMIP can be used on systems ranging from large CPU-based HPC environments to single servers with GPU acceleration and everything in between.

HECC↗

Space Telecommunications Radio Systems (STRS) Hardware Architecture Standard: Release 1.0 Hardware Section

This report defines a hardware architecture approach for software-defined radios to enable commonality among NASA space missions. The architecture accommodates a range of reconfigurable processing technologies including general-purpose processors, digital signal processors, field programmable gate arrays, and application-specific integrated circuits (ASICs) in addition to flexible and tunable radiofrequency front ends to satisfy varying mission requirements. The hardware architecture consists of modules, radio functions, and interfaces. The modules are a logical division of common radio functions that compose a typical communication radio. This report describes the architecture details, the module definitions, the typical functions on each module, and the module interfaces. Tradeoffs between component-based, custom architecture and a functional-based, open architecture are described. The architecture does not specify a physical implementation internally on each module, nor does the architecture mandate the standards or ratings of the hardware used to construct the radios.

Reinhart, Richard C.↗

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗

WMS Server 2.0

This software is a simple, yet flexible server of raster map products, compliant with the Open Geospatial Consortium (OGC) Web Map Service (WMS) 1.1.1 protocol. The server is a full implementation of the OGC WMS 1.1.1 as a fastCGI client and using Geospatial Data Abstraction Library (GDAL) for data access. The server can operate in a proxy mode, where all or part of the WMS requests are done on a back server. The server has explicit support for a colocated tiled WMS, including rapid response of black (no-data) requests. It generates JPEG and PNG images, including 16-bit PNG. The GDAL back-end support allows great flexibility on the data access. The server is a port to a Linux/GDAL platform from the original IRIX/IL platform. It is simpler to configure and use, and depending on the storage format used, it has better performance than other available implementations. The WMS server 2.0 is a high-performance WMS implementation due to the fastCGI architecture. The use of GDAL data back end allows for great flexibility. The configuration is relatively simple, based on a single XML file. It provides scaling and cropping, as well as blending of multiple layers based on layer transparency.

Plesea, Lucian↗

A Ground Systems Architecture Transition for A Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the ISS payloads program, and the resulting functional breakdown of the products that support that architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗

A Ground Systems Architecture Transition for a Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the International Space Station (ISS) payloads program, and the resulting functional breakdown of the products that support this architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗