Search NASA⌕ Search

SEARCH · Search NASA

Results for “Architecture”

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 163 records · Page 9

Fabrication of Single, Vertically Aligned Carbon Nanotubes in 3D Nanoscale Architectures

Plasma-enhanced chemical vapor deposition (PECVD) and high-throughput manufacturing techniques for integrating single, aligned carbon nanotubes (CNTs) into novel 3D nanoscale architectures have been developed. First, the PECVD growth technique ensures excellent alignment of the tubes, since the tubes align in the direction of the electric field in the plasma as they are growing. Second, the tubes generated with this technique are all metallic, so their chirality is predetermined, which is important for electronic applications. Third, a wafer-scale manufacturing process was developed that is high-throughput and low-cost, and yet enables the integration of just single, aligned tubes with nanoscale 3D architectures with unprecedented placement accuracy and does not rely on e-beam lithography. Such techniques should lend themselves to the integration of PECVD grown tubes for applications ranging from interconnects, nanoelectromechanical systems (NEMS), sensors, bioprobes, or other 3D electronic devices. Chemically amplified polyhydroxystyrene-resin-based deep UV resists were used in conjunction with excimer laser-based (lambda = 248 nm) step-and-repeat lithography to form Ni catalyst dots = 300 nm in diameter that nucleated single, vertically aligned tubes with high yield using dc PECVD growth. This is the first time such chemically amplified resists have been used, resulting in the nucleation of single, vertically aligned tubes. In addition, novel 3D nanoscale architectures have been created using topdown techniques that integrate single, vertically aligned tubes. These were enabled by implementing techniques that use deep-UV chemically amplified resists for small-feature-size resolution; optical lithography units that allow unprecedented control over layer-to-layer registration; and ICP (inductively coupled plasma) etching techniques that result in near-vertical, high-aspect-ratio, 3D nanoscale architectures, in conjunction with the use of materials that are structurally and chemically compatible with the high-temperature synthesis of the PECVD-grown tubes. The techniques offer a wafer-scale process solution for integrating single PECVD-grown nanotubes into novel architectures that should accelerate their integration in 3D electronics in general. NASA can directly benefit from this technology for its extreme-environment planetary missions. Current Si transistors are inherently more susceptible to high radiation, and do not tolerate extremes in temperature. These novel 3D nanoscale architectures can form the basis for NEMS switches that are inherently less susceptible to radiation or to thermal extremes.

Kaul, Anupama B.↗

Architecture Adaptive Computing Environment

Architecture Adaptive Computing Environment (aCe) is a software system that includes a language, compiler, and run-time library for parallel computing. aCe was developed to enable programmers to write programs, more easily than was previously possible, for a variety of parallel computing architectures. Heretofore, it has been perceived to be difficult to write parallel programs for parallel computers and more difficult to port the programs to different parallel computing architectures. In contrast, aCe is supportable on all high-performance computing architectures. Currently, it is supported on LINUX clusters. aCe uses parallel programming constructs that facilitate writing of parallel programs. Such constructs were used in single-instruction/multiple-data (SIMD) programming languages of the 1980s, including Parallel Pascal, Parallel Forth, C*, *LISP, and MasPar MPL. In aCe, these constructs are extended and implemented for both SIMD and multiple- instruction/multiple-data (MIMD) architectures. Two new constructs incorporated in aCe are those of (1) scalar and virtual variables and (2) pre-computed paths. The scalar-and-virtual-variables construct increases flexibility in optimizing memory utilization in various architectures. The pre-computed-paths construct enables the compiler to pre-compute part of a communication operation once, rather than computing it every time the communication operation is performed.

Dorband, John E.↗

Scalable Architecture for Multihop Wireless ad Hoc Networks

A scalable architecture for wireless digital data and voice communications via ad hoc networks has been proposed. Although the details of the architecture and of its implementation in hardware and software have yet to be developed, the broad outlines of the architecture are fairly clear: This architecture departs from current commercial wireless communication architectures, which are characterized by low effective bandwidth per user and are not well suited to low-cost, rapid scaling in large metropolitan areas. This architecture is inspired by a vision more akin to that of more than two dozen noncommercial community wireless networking organizations established by volunteers in North America and several European countries.

Arabshahi, Payman↗

Architecture for a 1-GHz Digital RADAR

An architecture for a Direct RF-digitization Type Digital Mode RADAR was developed at GSFC in 2008. Two variations of a basic architecture were developed for use on RADAR imaging missions using aircraft and spacecraft. Both systems can operate with a pulse repetition rate up to 10 MHz with 8 received RF samples per pulse repetition interval, or at up to 19 kHz with 4K received RF samples per pulse repetition interval. The first design describes a computer architecture for a Continuous Mode RADAR transceiver with a real-time signal processing and display architecture. The architecture can operate at a high pulse repetition rate without interruption for an infinite amount of time. The second design describes a smaller and less costly burst mode RADAR that can transceive high pulse repetition rate RF signals without interruption for up to 37 seconds. The burst-mode RADAR was designed to operate on an off-line signal processing paradigm. The temporal distribution of RF samples acquired and reported to the RADAR processor remains uniform and free of distortion in both proposed architectures. The majority of the RADAR's electronics is implemented in digital CMOS (complementary metal oxide semiconductor), and analog circuits are restricted to signal amplification operations and analog to digital conversion. An implementation of the proposed systems will create a 1-GHz, Direct RF-digitization Type, L-Band Digital RADAR--the highest band achievable for Nyquist Rate, Direct RF-digitization Systems that do not implement an electronic IF downsample stage (after the receiver signal amplification stage), using commercially available off-the-shelf integrated circuits.

Mallik, Udayan↗

Advances in Digital Calibration Techniques Enabling Real-Time Beamforming SweepSAR Architectures

Real-time digital beamforming, combined with lightweight, large aperture reflectors, enable SweepSAR architectures, which promise significant increases in instrument capability for solid earth and biomass remote sensing. These new instrument concepts require new methods for calibrating the multiple channels, which are combined on-board, in real-time. The benefit of this effort is that it enables a new class of lightweight radar architecture, Digital Beamforming with SweepSAR, providing significantly larger swath coverage than conventional SAR architectures for reduced mass and cost. This paper will review the on-going development of the digital calibration architecture for digital beamforming radar instrument, such as the proposed Earth Radar Mission's DESDynI (Deformation, Ecosystem Structure, and Dynamics of Ice) instrument. This proposed instrument's baseline design employs SweepSAR digital beamforming and requires digital calibration. We will review the overall concepts and status of the system architecture, algorithm development, and the digital calibration testbed currently being developed. We will present results from a preliminary hardware demonstration. We will also discuss the challenges and opportunities specific to this novel architecture.

TR (Transmit/Receive)↗

Considerations for the Next Revision of NASA's Space Telecommunications Radio System Architecture

Development of NASA's Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for National Aeronautics and Space Administration (NASA) space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module - which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions.

transmitters receivers↗

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IVV) Program, with Software Assurance Research Program support, extracted FM architectures across the IVV portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IVV projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management.

Fitz, Rhonda↗

An Integrated Hybrid Transportation Architecture for Human Mars Expeditions

NASA's Human Spaceflight Architecture Team is developing a reusable hybrid transportation architecture that uses both chemical and electric propulsion systems on the same vehicle to send crew and cargo to Mars destinations such as Phobos, Deimos, the surface of Mars, and other orbits around Mars. By applying chemical and electrical propulsion where each is most effective, the hybrid architecture enables a series of Mars trajectories that are more fuel-efficient than an all chemical architecture without significant increases in flight times. This paper presents an integrated Hybrid in-space transportation architecture for piloted missions and delivery of cargo. A concept for a Mars campaign including orbital and Mars surface missions is described in detail including a system concept of operations and conceptual design. Specific constraints, margin, and pinch points are identified for the architecture and opportunities for critical path commercial and international collaboration are discussed.

Merrill, Raymond G.↗

External Dependencies-Driven Architecture Discovery and Analysis of Implemented Systems

A method for architecture discovery and analysis of implemented systems (AIS) is disclosed. The premise of the method is that architecture decisions are inspired and influenced by the external entities that the software system makes use of. Examples of such external entities are COTS components, frameworks, and ultimately even the programming language itself and its libraries. Traces of these architecture decisions can thus be found in the implemented software and is manifested in the way software systems use such external entities. While this fact is often ignored in contemporary reverse engineering methods, the AIS method actively leverages and makes use of the dependencies to external entities as a starting point for the architecture discovery. The AIS method is demonstrated using the NASA's Space Network Access System (SNAS). The results show that, with abundant evidence, the method offers reusable and repeatable guidelines for discovering the architecture and locating potential risks (e.g. low testability, decreased performance) that are hidden deep in the implementation. The analysis is conducted by using external dependencies to identify, classify and review a minimal set of key source code files. Given the benefits of analyzing external dependencies as a way to discover architectures, it is argued that external dependencies deserve to be treated as first-class citizens during reverse engineering. The current structure of a knowledge base of external entities and analysis questions with strategies for getting answers is also discussed.

Ganesan, Dharmalingam↗

DIAMOND - an Architecture for Persistent Space Platforms

We define DIAMOND, an architecture for generalized, persistent platforms in space, providing support infrastructure for multiple payloads with diverse missions, and able to accept the integration of payloads delivered to the platform after it is established in space. Such platforms would create a new space ecosystem with opportunities for much larger platforms than currently exist, for adaptation to changing technological and market conditions over long periods of time, and for tenants of the platform to launch only their unique payloads without having to carry all the equipment needed to support them. The DIAMOND architecture uses a novel “Architectural Shearing Layer” approach combining long-lived but replaceable structural and support infrastructure components with shorter-lived, higher-value service and tenant facilities. The structural aspect of the proposed architecture is a regular lattice constructed of tetrahedral cells, constructed of only a few types of simple structural components, patterned according to the cubic lattice of natural diamond crystals. The cubic lattice is arranged on larger scales to be fractal sponge, providing a disproportionately large number of surface attachment points while maintaining overall low mass of the entire structure. Generalized architectural shearing layers are also provided that permit easy separation between structural, power, thermal, propulsion/attitude control, pointing/vibration control, computing/data storage, and communication, and various operational aspects of the architecture. The combined result ensures longevity by enabling space platforms to undergo many cycles of change with little peril and at low cost, changing any part of the platform at different times and rates while leaving the remaining parts of the platform undisturbed.

Breidenthal, Julian↗

Zero-Trust Architecture for Autonomous Edge Computing

We are at the apex of an aviation revolution where autonomy will play a central role in enabling complex, multi-agent systems to communicate, interact, and collaborate on a myriad of applications spanning autonomous swarms to wild-fire management. Autonomy is not an absolute but rather a spectrum ranging from a system requiring significant human intervention to one requiring little to none [1]. For example, the extreme, in the case of an autonomous aircraft, is one that operates independently in the airspace interacting with all other elements (air traffic controllers, other pilots) as if it were a human pilot. Critical to this vision is an architecture that enables autonomous agents to interact with minimal latency. Edge computing is an emerging architecture where compute and storage is pushed to the ‘edge’ of the network in order to minimize the round-trip time from agent to resource thereby mitigating the latency associated with cloud-only based approaches. Additionally, services can generate massive amounts of data (e.g., video feeds), which may require analysis in near real-time. Moving this data to the cloud for further processing may not be feasible due to latency, bandwidth, and cost. Privacy, security, and reliability can also be improved by edge computing architectures. However, this geo-distributed and dynamic* architecture complicates the establishment of unambiguous network security boundaries and can lead to vulnerabilities including man in the middle attacks, replay attacks, physical security breaches of edge nodes, signal interception, etc. This motivates the need for zero-trust architectures [2–4] which de-emphasize the notion of static network perimeters and, as the name implies, do not instill any innate trust in any particular agent. It is required that all agents must be authorized and approved in every transaction. In this paper, we present a zero-trust architecture suitable for edge-computing applications that demand significant low-latency, security, privacy, and reliability.

zero trust↗

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo↗

Artemis Navigation Architecture: Early Capabilities and Long Term Evolvability and Evolution

With the awarding of multiple contracts within the Artemis program and building on the success of Artemis I, NASA is investing in and demonstrating the vehicle capabilities necessary for a return to human crewed Lunar Missions. To support activities on the lunar surface, NASA is also assessing architecture options and approaches to enable high precision in-situ navigation within the lunar sphere of influence. These capabilities build on decades of research and advancements within the field, building and evolving the techniques used during Apollo. To support inter-operability and broad application within its elements, NASA conducted a trade on Orbital and Surface Lunar Architecture for PNT. Time-defined mission requirements were captured across elements to inform a phased approach and deployment of needed capability. The architecture must also address unique aspects of the South Pole lunar environments, specifically in terms of harsh lighting and hazardous terrain. To inform the study, documentation of primary users, operational concepts of operations, driving scenarios, and mission needs were used to define performance constraints and phasing. Multiple technologies were assessed in terms of maturity, applicability, and performance to meet the primary user needs forecast. The results of this study support the utilization of in-situ orbital infrastructure to provide a back-bone for navigation and emphasize the need for a common Lunar Reference System and Lunar Time Reference. This deployment can ensure compatibility and enable a high-accuracy in-situ capability. This provides further justification for the capabilities being invested in and deployed by NASA and other international agencies. In addition to including advancements in terrestrial surface navigation, NASA is also applying lessons learned and innovation in the contractual approach to the individual elements by means of a services-based contract mechanism. This impacts the navigation architecture heavily in terms of government and provider roles, in terms of levels of implementation, interoperability, and verification. These distinctions in roles provide constraints to the architecture approach in terms of implementation and integration and will be discussed. The development, use, and mandate of interoperability standards are being deployed to support cross-element compatibility. This paper will provide a summary of the NASA Lunar Navigation needs across its various elements and the proposed deployment of an integrated navigation architecture to support early mission needs with inherent extensibility towards the future.

Evan Anzalone↗

Architecture Study on Telemetry Coverage for Immediate Post-Separation Phase

This paper presents the preliminary results of an architecture study that provides continuous telemetry coverage for NASA missions for immediate post-separation phase. This study is a collaboration effort between Jet Propulsion Laboratory (JPL), Goddard Space Flight Center (GSFC), and Applied Physics Laboratory (APL). After launch when the spacecraft separated from the upper stage, the spacecraft typically executes a number of mission-critical operations prior to the deployment of solar panels and the activation of the primary communication subsystem. JPL, GSFC, and APL have similar design principle statements that require continuous coverage of mission-critical telemetry during the immediate post-separation phase. To conform to these design principles, an architecture that consists of a separate spacecraft transmitter and a robust communication network capable of tracking the spacecraft signals is needed.This paper presents the preliminary results of an architecture study that provides continuous telemetry coverage for NASA missions for immediate post-separation phase. This study is a collaboration effort between Jet Propulsion Laboratory (JPL), Goddard Space Flight Center (GSFC), and Applied Physics Laboratory (APL). After launch when the spacecraft separated from the upper stage, the spacecraft typically executes a number of mission-critical operations prior to the deployment of solar panels and the activation of the primary communication subsystem. JPL, GSFC, and APL have similar design principle statements that require continuous coverage of mission-critical telemetry during the immediate post-separation phase. To conform to these design principles, an architecture that consists of a separate spacecraft transmitter and a robust communication network capable of tracking the spacecraft signals is needed. The main results of this study are as follows: 1) At low altitude (< 10000 km) when most post-separation critical operations are executed, Earth-based network (e.g. Deep Space Network (DSN)) can only provide limited coverage, whereas space-based network (e.g. Space Network (SN)) can provide continuous coverage. 2) Commercial-off-the-shelf SN compatible transmitters are available for small satellite applications. In this paper we present the detailed coverage analysis of Earth-based and Space-based networks. We identify the key functional and performance requirements of the architecture, and describe the proposed selection criteria of the spacecraft transmitter. We conclude the paper with a proposed forward plan.

architecture↗

NASA's Advanced Multimission Operations System: A Case Study in Formalizing Software Architecture Evolution

All software systems of significant size and longevity eventually undergo changes to their basic architectural structure. Such changes may be prompted by evolving requirements, changing technology, or other reasons. Whatever the cause, software architecture evolution is commonplace in real world software projects. Recently, software architecture researchers have begun to study this phenomenon in depth. However, this work has suffered from problems of validation; research in this area has tended to make heavy use of toy examples and hypothetical scenarios and has not been well supported by real world examples. To help address this problem, I describe an ongoing effort at the Jet Propulsion Laboratory to re-architect the Advanced Multimission Operations System (AMMOS), which is used to operate NASA's deep-space and astrophysics missions. Based on examination of project documents and interviews with project personnel, I describe the goals and approach of this evolution effort and then present models that capture some of the key architectural changes. Finally, I demonstrate how approaches and formal methods from my previous research in architecture evolution may be applied to this evolution, while using languages and tools already in place at the Jet Propulsion Laboratory.

software architecture evolution↗

Ultra-Stable Segmented Telescope Sensing and Control Architecture

The LUVOIR team is conducting two full architecture studies Architecture A 15 meter telescope that folds up in an 8.4m SLS Block 2 shroud is nearly complete. Architecture B 9.2 meter that uses an existing fairing size will begin study this Fall. This talk will summarize the ultra-stable architecture of the 15m segmented telescope including the basic requirements, the basic rationale for the architecture, the technologies employed, and the expected performance. This work builds on several dynamics and thermal studies performed for ATLAST segmented telescope configurations. The most important new element was an approach to actively control segments for segment to segment motions which will be discussed later.

Telescope↗

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.

medical data architecture↗

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.

medical data architecture↗