Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2017

Control of Architecture in Rhombic Dodecahedral Pt–Ni Nanoframe Electrocatalysts

Platinum-based alloys are known to demonstrate advanced properties in electrochemical reactions that are relevant for proton exchange membrane fuel cells and electrolyzers. Further development of Pt alloy electrocatalysts relies on the design of architectures with highly active surfaces and optimized utilization of the expensive element, Pt. For this study, we show that the three-dimensional Pt anisotropy of Pt-Ni rhombic dodecahedra can be tuned by controlling the ratio between Pt and Ni precursors such that either a completely hollow nanoframe or a new architecture, the excavated nanoframe, can be obtained. The excavated nanoframe showed ~10 times higher specific and ~6 times higher mass activity for the oxygen reduction reaction than Pt/C, and twice the mass activity of the hollow nanoframe. The high activity is attributed to enhanced Ni content in the near-surface region and the extended two-dimensional sheet structure within the nanoframe that minimizes the number of buried Pt sites.

36 MATERIALS SCIENCE↗
DOE OSTI2020

Response to Questionnaire of Grid Control Architecture Description Document: Mission Innovation, Innovation Challenge 1. Task 5 – New Grid Control Architectures. Subtask 5.1 – Collection of Available New Grid Control Architectures

As part of Task 5 (New Grid Control Architectures) of Mission Innovation, Innovation Challenge 1, a questionnaire was provided to all countries participating in the project. In this document, PNNL has responded to the questionnaire with information regarding new grid control architectures being proposed or developed in the US. Ron Melton sent the report to all participants.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2022

INTERSECT Architecture Specification: Microservice Architecture (V.0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

INTERSECT Architecture Specification: System-of-systems Architecture (Version 0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected ScienceEcosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The architecture project is divided into three focus areas: design patterns; SoS architecture; and microservices architecture. The design patterns area focuses on describing science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions interms of control, work and data flow. The SoS architecture area focuses on an open architecture specification for the federated ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. The microservices architecture describes blueprints for loosely coupled microservices, standardized interfaces, and multi-programming language support. This document is the SoS Architecture specification only, and captures the system of systems architecture design for the INTERSECT Initiative and its components. It is intended to provide a deep analysis and specification of how the INTERSECT platform will be designed, and to link the scientific needs identified across disciplines with the technical needs involved in the support, development, and evolution of a science ecosystem. PLEASE NOTE: This is a working document and reflects current discussions and design activity among the authors. There may be inconsistencies within the document as different parts evolve at a different pace. We invite comments and thoughts from the public on this and following working drafts. The first finished version of this document is scheduled for release in September 2023.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

INTERSECT Architecture Specification: Microservice Architecture (V.0.9)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

Comparative Architecture Analysis: Using Laminar Structure to Unify Multiple Grid Architectures

A great many architectures for various aspects of electric grids have been proposed over recent years and new ones continue to be suggested. Generally speaking, there is no means except ad hoc analysis by which one can reduce these architectures to some common basis, or extract common elements. This leads to confusion in choosing an architecture for implementation, as well as making it difficult to identify core product or platform opportunities with sufficient potential markets to encourage vendors to provide or develop them. The discipline of Grid Architecture as defined for the US Department of Energy (DOE) in 2014 has multiple purposes. Among them are two that are relevant here: Providing rigorous bases for architectural structures and Identifying common aspects of apparently divergent architectural structures. For the first of these, mathematical methods are applied where possible to provide the rigorous basis for structure. For the second, mapping of architectural structures to a canonical structure puts apparently disparate architectures onto a common basis. In the best case, these two methods coincide. In this paper, Laminar Coordination structure serves as the rigorously defined common basis for analysis of several real and proposed grid architectures.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS2002

Analysis of Parallel Burn Without Crossfeed TSTO RLV Architectures and Comparison to Parallel Burn With Crossfeed and Series Burn Architectures

There are currently three dominant TSTO class architectures. These are Series Burn (SB), Parallel Burn with crossfeed (PBw/cf), and Parallel Burn without crossfeed (PBncf). The goal of this study was to determine what factors uniquely affect PBncf architectures, how each of these factors interact, and to determine from a performance perspective whether a PBncf vehicle could be competitive with a PBw/cf or SB vehicle using equivalent technology and assumptions. In all cases, performance was evaluated on a relative basis for a fixed payload and mission by comparing gross and dry vehicle masses of a closed vehicle. Propellant combinations studied were LOX: LH2 propelled orbiter and booster (HH) and LOX: Kerosene booster with LOX: LH2 orbiter (KH). The study conclusions were: 1) a PBncf orbiter should be throttled as deeply as possible after launch until the staging point. 2) a detailed structural model is essential to accurate architecture analysis and evaluation. 3) a PBncf TSTO architecture is feasible for systems that stage at mach 7. 3a) HH architectures can achieve a mass growth relative to PBw/cf of < 20%. 3b) KH architectures can achieve a mass growth relative to Series Burn of < 20%. 4) center of gravity (CG) control will be a major issue for a PBncf vehicle, due to the low orbiter specific thrust to weight ratio and to the position of the orbiter required to align the nozzle heights at liftoff. 5 ) thrust to weight ratios of 1.3 at liftoff and between 1.0 and 0.9 when staging at mach 7 appear to be close to ideal for PBncf vehicles. 6) performance for all vehicles studied is better when staged at mach 7 instead of mach 5. The study showed that a Series Burn architecture has the lowest gross mass for HH cases, and has the lowest dry mass for KH cases. The potential disadvantages of SB are the required use of an air-start for the orbiter engines and potential CG control issues. A Parallel Burn with crossfeed architecture solves both these problems, but the mechanics of a large bipropellant crossfeed system pose significant technical difficulties. Parallel Burn without crossfeed vehicles start both booster and orbiter engines on the ground and thus avoid both the risk of orbiter air-start and the complexity of a crossfeed system. The drawback is that the orbiter must use 20% to 35% of its propellant before reaching the staging point. This induces a weight penalty in the orbiter in order to carry additional propellant, which causes a further weight penalty in the booster to achieve the same staging point. One way to reduce the orbiter propellant consumption during the first stage is to throttle down the orbiter engines as much as possible. Another possibility is to use smaller or fewer engines. Throttling the orbiter engines soon after liftoff minimizes CG control problems due to a low orbiter liftoff thrust, but may result in an unnecessarily high orbiter thrust after staging. Reducing the number or size of engines size may cause CG control problems and drift at launch. The study suggested possible methods to maximize performance of PBncf vehicle architectures in order to meet mission design requirements.

Smith, Garrett↗
NASA NTRS2011

Architecture Governance: The Importance of Architecture Governance for Achieving Operationally Responsive Ground Systems

Topics covered (1) Why Governance and Why Now? (2) Characteristics of Architecture Governance (3) Strategic Elements (3a) Architectural Principles (3b) Architecture Board (3c) Architecture Compliance (4) Architecture Governance Infusion Process. Governance is concerned with decision making (i.e., setting directions, establishing standards and principles, and prioritizing investments). Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level

Architecture Governance↗
NASA NTRS2004

Architecture Synthesis and Reduced-Cost Architectures for Human Exploration Missions

Development of architectures for human exploration missions has been pursued in the international aerospace community for a long time. This paper attempts a different approach and way of looking at architectures. Most of the emphasis is on lunar architectures with a brief look at Mars. The first step is to set forth overarching gods in order to understand origins of requirements. Then, principles and guidelines are developed for architecture formulation. It is argued that safety and cost are the primary factors. Alternative mission profiles are examined for adherence to the principles, and specific architectures formulated according to the guidelines. The guidelines themselves indicate preferred evolution paths from lunar to Mars architectures. Results of example calculations are given to illustrate the process, and an evolution path is recommended. Safety and cost criteria tend to conflict, but it is shown that cost-efficient architectures can be enhanced for good safety ratings at modest cost.

Woodcock, Gordon↗
DOE OSTI2023

New trends in photonic switching and optical networking architectures for data centers and computing systems [Invited]

The rapid increases in data traffic coupled with user preferences are driving the data center and computing system service providers to offer energy-efficient, intelligent, flexible, cost-effective, high-capacity, and low-latency data services without added complexity to the users. Disaggregated heterogeneous reconfigurable computing systems realized by photonic switching and interconnects can enhance throughput and energy efficiency for artificial intelligence/machine learning (AI/ML) workloads, especially when aided by the AI/ML-enhanced control plane. Photonic switching and new optical networking architectures are expected to solve many of these challenging problems. This paper discusses new trends in photonic switching and optical network architectures for future data centers and computing systems summarized as follows: (1) flat reconfigurable disaggregated computing enabled by high-radix photonic switching and interconnects in data centers; (2) chiplet-based computing architectures empowered by embedded photonics toward heterogeneous reconfigurable computing; (3) nanosecond-scale photonic switching in data centers and computing systems; (4) AI/ML in self-driving, application-aware, and situation-aware data centers; (5) the emergence of flexible networking for cloud computing, edge computing, and split computing, as well as flexible networking for 5G/6G RF-optical networks; and (6) the deployment of embedded co-designed silicon photonics being considered for future data centers.

Yoo, S. J. Ben (ORCID:0000000274201871)↗
NASA NTRS1989

The flight telerobotic servicer: From functional architecture to computer architecture

After a brief tutorial on the NASA/National Bureau of Standards Standard Reference Model for Telerobot Control System Architecture (NASREM) functional architecture, the approach to its implementation is shown. First, interfaces must be defined which are capable of supporting the known algorithms. This is illustrated by considering the interfaces required for the SERVO level of the NASREM functional architecture. After interface definition, the specific computer architecture for the implementation must be determined. This choice is obviously technology dependent. An example illustrating one possible mapping of the NASREM functional architecture to a particular set of computers which implements it is shown. The result of choosing the NASREM functional architecture is that it provides a technology independent paradigm which can be mapped into a technology dependent implementation capable of evolving with technology in the laboratory and in space.

Lumia, Ronald↗
NASA NTRS2003

Analysis of Parallel Burn, No-Crossfeed TSTO RLV Architectures and Comparison to Parallel Burn with Crossfeed and Series Burn Architectures

Three dominant Two Stage To Orbit (TSTO) class architectures were studied: Series Burn (SB), Parallel Bum with crossfeed (PBw/cf), and Parallel Burn, no-crossfeed (PBncf). The study goal was to determine what factors uniquely affect PBncf architectures, how each of these factors interact, and to determine from a performance perspective whether a PBncf vehicle could be competitive with a PBw/cf or a SB vehicle using equivalent technology and assumptions. In all cases, performance was evaluated on a relative basis for a fixed payload and mission by comparing gross and dry vehicle masses of a closed vehicle. Propellant combinations studied were LOX: LH2 propelled booster and orbiter (HH) and LOX: Kerosene booster with LOX: LH2 orbiter (KH). The study observations were: 1) A PBncf orbiter should be throttled as deeply as possible after launch until the staging point. 2) A PBncf TSTO architecture is feasible for systems that stage at mach 7. 2a) HH architectures can achieve a mass growth relative to PBw/cf of <20%. 2b) KH architectures can achieve a mass growth relative to Series Burn of <20%. 3) Center of gravity (CG) control will be a major issue for a PBncf vehicle, due to the low orbiter specific thrust to weight ratio and to the position of the orbiter required to align the nozzle heights at liftoff. 4) Thrust to weight ratios of 1.3 at liftoff and between 1.0 and 0.9 when staging at mach 7 appear to be close to ideal for PBncf vehicles. 5) Performance for HH vehicles was better when staged at mach 7 instead of mach 5. The study suggests possible methods to maximize performance of PBncf vehicle architectures in order to meet mission design requirements.

Smith, Garrett↗
DOE OSTI2022

Power and Communications Hardware-in-the-Loop CPS Architecture and Platform for DER Monitoring and Control Applications: Preprint

The rapid growth of distributed energy resources (DERs) has prompted increasing interest in the monitoring and control of DERs through hybrid smart grid communications. The deployment of communications and computation has transformed the traditional physical power grid into a smart cyber-physical system (CPS). To fully understand the interdependency between physical grid and cyber netowrks, this study designed a power and communications hardware-in-the-loop (PCommHIL) CPS architecture, which enables the flexible verification of DER monitoring and control with hybrid communications architectures and Internet protocols. Design, development and case study of a PCommHIL testbed for the DER coordination are discussed in detail, and the proposed platform integrates DER devices, Advanced Metering Infrastructures (AMIs), and a suite of hybrid communications networks for distribution automation applications. Case study on DER situational awareness and Volt-Var control validates the efficacy of this proposed PCommHIL platform with hybrid communications designs. Results show that the HAN communication technologies play a critical role in hybrid designs and it is the bottleneck for DER applications. High performance communication technologies are highly recommended to be applied in the HAN for enhanced monitoring and real-time control of DERs.

AMIs↗
NASA NTRS2001

Project Integration Architecture: Architectural Overview

The Project Integration Architecture (PIA) implements a flexible, object-oriented, wrapping architecture which encapsulates all of the information associated with engineering applications. The architecture allows the progress of a project to be tracked and documented in its entirety. By being a single, self-revealing architecture, the ability to develop single tools, for example a single graphical user interface, to span all applications is enabled. Additionally, by bringing all of the information sources and sinks of a project into a single architectural space, the ability to transport information between those applications becomes possible, Object-encapsulation further allows information to become in a sense self-aware, knowing things such as its own dimensionality and providing functionality appropriate to its kind.

Jones, William Henry↗