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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 379 records · Page 21

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Commanding Constellations (Pipeline Architecture)

Providing ground command software for constellations of spacecraft is a challenging problem. Reliable command delivery requires a feedback loop; for a constellation there will likely be an independent feedback loop for each constellation member. Each command must be sent via the proper Ground Station, which may change from one contact to the next (and may be different for different members). Dynamic configuration of the ground command software is usually required (e.g. directives to configure each member's feedback loop and assign the appropriate Ground Station). For testing purposes, there must be a way to insert command data at any level in the protocol stack. The Pipeline architecture described in this paper can support all these capabilities with a sequence of software modules (the pipeline), and a single self-identifying message format (for all types of command data and configuration directives). The Pipeline architecture is quite simple, yet it can solve some complex problems. The resulting solutions are conceptually simple, and therefore, reliable. They are also modular, and therefore, easy to distribute and extend. We first used the Pipeline architecture to design a CCSDS (Consultative Committee for Space Data Systems) Ground Telecommand system (to command one spacecraft at a time with a fixed Ground Station interface). This pipeline was later extended to include gateways to any of several Ground Stations. The resulting pipeline was then extended to handle a small constellation of spacecraft. The use of the Pipeline architecture allowed us to easily handle the increasing complexity. This paper will describe the Pipeline architecture, show how it was used to solve each of the above commanding situations, and how it can easily be extended to handle larger constellations.

Tim Ray↗

NASA NTRS2004

Evolutionary Space Communications Architectures for Human/Robotic Exploration and Science Missions

NASA enterprises have growing needs for an advanced, integrated, communications infrastructure that will satisfy the capabilities needed for multiple human, robotic and scientific missions beyond 2015. Furthermore, the reliable, multipoint infrastructure is required to provide continuous, maximum coverage of areas of concentrated activities, such as around Earth and in the vicinity of the Moon or Mars, with access made available on demand of the human or robotic user. As a first step, the definitions of NASA's future space communications and networking architectures are underway. Architectures that describe the communications and networking needed between the nodal regions consisting of Earth, Moon, Lagrange points, Mars, and the places of interest within the inner and outer solar system have been laid out. These architectures will need the modular flexibility that must be included in the communication and networking technologies to enable the infrastructure to grow in capability with time and to transform from supporting robotic missions in the solar system to supporting human ventures to Mars, Jupiter, Jupiter's moons, and beyond. The protocol-based networking capability seamlessly connects the backbone, access, inter-spacecraft and proximity network elements of the architectures employed in the infrastructure. In this paper, we present the summary of NASA's near and long term needs and capability requirements that were gathered by participative methods. We describe an integrated architecture concept and model that will enable communications for evolutionary robotic and human science missions. We then define the communication nodes, their requirements, and various options to connect them.

Bhasin, Kul↗

NASA NTRS2000

An Architecture for Real-Time Interpretation and Visualization of Structural Sensor Data in a Laboratory Environment

A visualization system is being developed out of the need to monitor, interpret, and make decisions based on the information from several thousand sensors during experimental testing to facilitate development and validation of structural health monitoring algorithms. As an added benefit the system will enable complete real-time sensor assessment of complex test specimens. Complex structural specimens are routinely tested that have hundreds or thousands of sensors. During a test, it is impossible for a single researcher to effectively monitor all the sensors and subsequently interesting phenomena occur that are not recognized until post-test analysis. The ability to detect and alert the researcher to these unexpected phenomena as the test progresses will significantly enhance the understanding and utilization of complex test articles. Utilization is increased by the ability to halt a test when the health monitoring algorithm response is not satisfactory or when an unexpected phenomenon occurs, enabling focused investigation potentially through the installation of additional sensors. Often if the test continues, structural changes make it impossible to reproduce the conditions that exhibited the phenomena. The prohibitive time and costs associated with fabrication, sensoring, and subsequent testing of additional test articles generally makes it impossible to further investigate the phenomena. A scalable architecture is described to address the complex computational demands of structural health monitoring algorithm development and laboratory experimental test monitoring. The researcher monitors the test using a photographic quality 3D graphical model with actual sensor locations identified. In addition, researchers can quickly activate plots displaying time or load versus selected sensor response along with the expected values and predefined limits. The architecture has several key features. First, distributed dissimilar computers may be seamlessly integrated into the information flow. Second, virtual sensors may be defined that are complex functions of existing sensors or other virtual sensors. Virtual sensors represent a calculated value not directly measured by particular physical instrument. They can be used, for example, to represent the maximum difference in a range of sensors or the calculated buckling load based on the current strains. Third, the architecture enables autonomous response to preconceived events, where by the system can be configured to suspend or abort a test if a failure is detected in the load introduction system. Fourth, the architecture is designed to allow cooperative monitoring and control of the test progression from multiple stations both remote and local to the test system. To illustrate the architecture, a preliminary implementation is described monitoring the Stitched Composite Wing recently tested at LaRC.

Doggett, William↗

NASA NTRS2004

Discrete-Time Demodulator Architectures for Free-Space Broadband Optical Pulse-Position Modulation

The objective of this work is to develop discrete-time demodulator architectures for broadband optical pulse-position modulation (PPM) that are capable of processing Nyquist or near-Nyquist data rates. These architectures are motivated by the numerous advantages of realizing communications demodulators in digital very large scale integrated (VLSI) circuits. The architectures are developed within a framework that encompasses a large body of work in optical communications, synchronization, and multirate discrete-time signal processing and are constrained by the limitations of the state of the art in digital hardware. This work attempts to create a bridge between theoretical communication algorithms and analysis for deep-space optical PPM and modern digital VLSI. The primary focus of this work is on the synthesis of discrete-time processing architectures for accomplishing the most fundamental functions required in PPM demodulators, post-detection filtering, synchronization, and decision processing. The architectures derived are capable of closely approximating the theoretical performance of the continuous-time algorithms from which they are derived. The work concludes with an outline of the development path that leads to hardware.

Gray, A. A.↗

NASA NTRS2003

Effects of Fiber Reinforcement Architecture on the Hygrothermal-Mechanical Performance of Polyimide Matrix Composites for Aeropropulsion Applications

A lightweight sandwich support structure, for the combustor chamber of a new generation liquid propellant rocket engine, was designed and fabricated using a polymer matrix composite (PMC) facesheet on a Ti honeycomb core. The PMC facesheet consisted of high stiffness carbon fiber, M40JB, and high temperature Polyimides, such as PMR-II-50 and HFPE-II-52. Six different fiber architectures; four harness satin (4HS) woven fabric, uni-tape, woven-uni hybrid, stitched woven fabric, stitched uni-tape and triaxial braided structures have been investigated for optimum stiffness-thickness-weight-hygrothermal performance design criteria for the hygrothermal-mechanical propulsion service exposure conditions including rapid heating up to 200 F/sec, maximum operating temperature of 600 F, internal pressure up to 100 psi. One of the specific objectives in this study is to improve composite blistering resistance in z-direction at minimum expense of in-plane mechanical properties. An extensive property-performance database including dry-wet mechanical properties at various temperatures, thermal-physical properties, such as blistering onset condition was generated for fiber architecture down-selection and design guidelines. Various optimized process methods such as vacuum bag compression molding, solvent assistant resin transfer molding (SaRTM), resin film infusion (RFI) and autoclaving were utilized for PMC panel fabrication depending on the architecture type. In the case of stitched woven fabric architecture, the stitch pattern in terms of stitch density and yarn size was optimized based on both in-plane mechanical properties and blistering performance. Potential reduction of the in-plane properties transverse to the line of stitching was also evaluated. Efforts have been made to correlate the experimental results with theoretical micro-mechanics predictions. Changes in deformation mechanism and failure sequences in terms of fiber architecture will be discussed.

Shin, E. Eugene↗

NASA NTRS2004

Specification, Design, and Analysis of Advanced HUMS Architectures

During the two-year project period, we have worked on several aspects of domain-specific architectures for HUMS. In particular, we looked at using scenario-based approach for the design and designed a language for describing such architectures. The language is now being used in all aspects of our HUMS design. In particular, we have made contributions in the following areas. 1) We have employed scenarios in the development of HUMS in three main areas. They are: (a) To improve reusability by using scenarios as a library indexing tool and as a domain analysis tool; (b) To improve maintainability by recording design rationales from two perspectives - problem domain and solution domain; (c) To evaluate the software architecture. 2) We have defined a new architectural language called HADL or HUMS Architectural Definition Language. It is a customized version of xArch/xADL. It is based on XML and, hence, is easily portable from domain to domain, application to application, and machine to machine. Specifications written in HADL can be easily read and parsed using the currently available XML parsers. Thus, there is no need to develop a plethora of software to support HADL. 3) We have developed an automated design process that involves two main techniques: (a) Selection of solutions from a large space of designs; (b) Synthesis of designs. However, the automation process is not an absolute Artificial Intelligence (AI) approach though it uses a knowledge-based system that epitomizes a specific HUMS domain. The process uses a database of solutions as an aid to solve the problems rather than creating a new design in the literal sense. Since searching is adopted as the main technique, the challenges involved are: (a) To minimize the effort in searching the database where a very large number of possibilities exist; (b) To develop representations that could conveniently allow us to depict design knowledge evolved over many years; (c) To capture the required information that aid the automation process.

Mukkamala, Ravi↗

NASA NTRS1999

Satellite ATM Networks: Architectures and Guidelines Developed

An important element of satellite-supported asynchronous transfer mode (ATM) networking will involve support for the routing and rerouting of active connections. Work published under the auspices of the Telecommunications Industry Association (http://www.tiaonline.org), describes basic architectures and routing protocol issues for satellite ATM (SATATM) networks. The architectures and issues identified will serve as a basis for further development of technical specifications for these SATATM networks. Three ATM network architectures for bent pipe satellites and three ATM network architectures for satellites with onboard ATM switches were developed. The architectures differ from one another in terms of required level of mobility, supported data rates, supported terrestrial interfaces, and onboard processing and switching requirements. The documentation addresses low-, middle-, and geosynchronous-Earth-orbit satellite configurations. The satellite environment may require real-time routing to support the mobility of end devices and nodes of the ATM network itself. This requires the network to be able to reroute active circuits in real time. In addition to supporting mobility, rerouting can also be used to (1) optimize network routing, (2) respond to changing quality-of-service requirements, and (3) provide a fault tolerance mechanism. Traffic management and control functions are necessary in ATM to ensure that the quality-of-service requirements associated with each connection are not violated and also to provide flow and congestion control functions. Functions related to traffic management were identified and described. Most of these traffic management functions will be supported by on-ground ATM switches, but in a hybrid terrestrial-satellite ATM network, some of the traffic management functions may have to be supported by the onboard satellite ATM switch. Future work is planned to examine the tradeoffs of placing traffic management functions onboard a satellite as opposed to implementing those functions at the Earth station components.

vonDeak, Thomas C.↗

NASA NTRS2005

Thermostructural Properties Of Sic/Sic Panels With 2.5d And 3d Fiber Architectures

CMC hot-section components in advanced engines for power and propulsion will typically require high cracking strength, high ultimate strength and strain, high creep- rupture resistance, and high thermal conductivity in all directions. In the past, NASA has demonstrated fabrication of a variety of SiC/SiC flat panels and round tubes with various 2D fiber architectures using the high-modulus high-performance Sylramic-iBN Sic fiber and Sic-based matrices derived by CVI, MI, and/or PIP processes. The thermo- mechanical properties of these CMC have shown state-of-the-art performance, but primarily in the in-plane directions. Currently NASA is extending the thermostructural capability of these SiC/SiC systems in the thru-thickness direction by using various 2.5D and 3D fiber architectures. NASA is also using specially designed fabrication steps to optimize the properties of the BN-based interphase and Sic-based matrices. In this study, Sylramic-iBN/SiC panels with 2D plain weave, 2.5D satin weave, 2.5D ply-to-ply interlock weave, and 3D angle interlock fiber architectures, all woven at AITI, were fabricated using matrix densification routes previously established between NASA and GEPSC for CVI-MI processes and between NASA and Starfire-Systems for PIP processes. Introduction of the 2.5 D fiber architecture along with an improved matrix process was found to increase inter-laminar tensile strength from 1.5 -2 to 3 - 4 ksi and thru-thickness thermal conductivity from 15-20 to 30-35 BTU/ft.hr.F with minimal reduction in in-plane strength and creep-rupture properties. Such improvements should reduce thermal stresses and increase the thermostructural operating envelope for SiC/SiC engine components. These results are analyzed to offer general guidelines for selecting fiber architectures and constituent processes for high-performance SiC/SiC engine components.

Yun, H. M.↗

NASA NTRS2005

A Demonstration of a Retrofit Architecture for Intelligent Control and Diagnostics of a Turbofan Engine

A retrofit architecture for intelligent turbofan engine control and diagnostics that changes the fan speed command to maintain thrust is proposed and its demonstration in a piloted flight simulator is described. The objective of the implementation is to increase the level of autonomy of the propulsion system, thereby reducing pilot workload in the presence of anomalies and engine degradation due to wear. The main functions of the architecture are to diagnose the cause of changes in the engine s operation, warning the pilot if necessary, and to adjust the outer loop control reference signal in response to the changes. This requires that the retrofit control architecture contain the capability to determine the changed relationship between fan speed and thrust, and the intelligence to recognize the cause of the change in order to correct it or warn the pilot. The proposed retrofit architecture is able to determine the fan speed setting through recognition of the degradation level of the engine, and it is able to identify specific faults and warn the pilot. In the flight simulator it was demonstrated that when degradation is introduced into an engine with standard fan speed control, the pilot needs to take corrective action to maintain heading. Utilizing the intelligent retrofit control architecture, the engine thrust is automatically adjusted to its expected value, eliminating yaw without pilot intervention.

Litt, Jonathan S.↗

NASA NTRS2006

Mission Architecture Comparison for Human Lunar Exploration

The Vision for Space Exploration outlines a bold new national space exploration policy that holds as one of its primary objectives the extension of human presence outward into the Solar System, starting with a return to the Moon in preparation for the future exploration of Mars and beyond. The National Aeronautics and Space Administration is currently engaged in several preliminary analysis efforts in order to develop the requirements necessary for implementing this objective in a manner that is both sustainable and affordable. Such analyses investigate various operational concepts, or mission architectures , by which humans can best travel to the lunar surface, live and work there for increasing lengths of time, and then return to Earth. This paper reports on a trade study conducted in support of NASA s Exploration Systems Mission Directorate investigating the relative merits of three alternative lunar mission architecture strategies. The three architectures use for reference a lunar exploration campaign consisting of multiple 90-day expeditions to the Moon s polar regions, a strategy which was selected for its high perceived scientific and operational value. The first architecture discussed incorporates the lunar orbit rendezvous approach employed by the Apollo lunar exploration program. This concept has been adapted from Apollo to meet the particular demands of a long-stay polar exploration campaign while assuring the safe return of crew to Earth. Lunar orbit rendezvous is also used as the baseline against which the other alternate concepts are measured. The first such alternative, libration point rendezvous, utilizes the unique characteristics of the cislunar libration point instead of a low altitude lunar parking orbit as a rendezvous and staging node. Finally, a mission strategy which does not incorporate rendezvous after the crew ascends from the Moon is also studied. In this mission strategy, the crew returns directly to Earth from the lunar surface, and is thus referred to as direct return. Figures of merit in the areas of safety and mission success, mission effectiveness, extensibility, and affordability are used to evaluate and compare the lunar orbit rendezvous, libration point rendezvous, and direct return architectures, and this paper summarizes the results of those assessments.

Geffre, Jim↗

NASA NTRS2006

The K9 On-Board Rover Architecture

This paper describes the software architecture of NASA Ames Research Center s K9 rover. The goal of the onboard software architecture team was to develop a modular, flexible framework that would allow both high- and low-level control of the K9 hardware. Examples of low-level control are the simple drive or pan/tilt commands which are handled by the resource managers, and examples of high-level control are the command sequences which are handled by the conditional executive. In between these two control levels are complex behavioral commands which are handled by the pilot, such as drive to goal with obstacle avoidance or visually servo to a target. This paper presents the design of the architecture as of Fall 2000. We describe the state of the architecture implementation as well as its current evolution. An early version of the architecture was used for K9 operations during a dual-rover field experiment conducted by NASA Ames Research Center (ARC) and the Jet Propulsion Laboratory (JPL) from May 14 to May 16, 2000.

Bresina, John L.↗

NASA NTRS2007

NASA CEV Reference GN&C Architecture

The Orion Crew Exploration Vehicle (CEV) will be the first human spacecraft built by NASA in almost 3 decades and will be the first vehicle to perform both Low Earth Orbit (LEO) missions and lunar missions since Apollo. The awesome challenge of designing a Guidance, Navigation, and Control (GN&C) system for this vehicle that satisfies all of its various mission requirements is countered by the opportunity to take advantage of the improvements in algorithms, software, sensors, and other related GN&C technology over this period. This paper describes the CEV GN&C reference architecture developed to support the overall NASA reference configuration and validate the driving requirements of the Constellation (Cx) Architecture Requirements Document (CARD, Reference 1) and the CEV System Requirements Document (SRD, Reference 2). The Orion GN&C team designed the reference architecture based on the functional allocation of GN&C roles and responsibilities of CEV with respect to the other Cx vehicles, such as the Crew Launch Vehicle (CLV), Earth Departure Stage (EDS), and Lunar Surface Area Module (LSAM), across all flight phases. The specific challenges and responsibilities of the CEV GN&C system from launch pad to touchdown will be introduced along with an overview of the navigation sensor suite, its redundancy management, and flight software (FSW) architecture. Sensors will be discussed in terms of range of operation, data utility within the navigation system, and rationale for selection. The software architecture is illustrated via block diagrams, commensurate with the design aspects.

Tamblyn, Scott↗

NASA NTRS2006

SpaceWire Architectures: Present and Future

A viewgraph presentation on current and future spacewire architectures is shown. The topics include: 1) Current Spacewire Architectures: Swift Data Flow; 2) Current SpaceWire Architectures : LRO Data Flow; 3) Current Spacewire Architectures: JWST Data Flow; 4) Current SpaceWire Architectures; 5) Traditional Systems; 6) Future Systems; 7) Advantages; and 8) System Engineer Toolkit.

Rakow, Glen Parker↗

NASA NTRS2007

Development of Network-based Communications Architectures for Future NASA Missions

Since the Vision for Space Exploration (VSE) announcement, NASA has been developing a communications infrastructure that combines existing terrestrial techniques with newer concepts and capabilities. The overall goal is to develop a flexible, modular, and extensible architecture that leverages and enhances terrestrial networking technologies that can either be directly applied or modified for the space regime. In addition, where existing technologies leaves gaps, new technologies must be developed. An example includes dynamic routing that accounts for constrained power and bandwidth environments. Using these enhanced technologies, NASA can develop nodes that provide characteristics, such as routing, store and forward, and access-on-demand capabilities. But with the development of the new infrastructure, challenges and obstacles will arise. The current communications infrastructure has been developed on a mission-by-mission basis rather than an end-to-end approach; this has led to a greater ground infrastructure, but has not encouraged communications between space-based assets. This alone provides one of the key challenges that NASA must encounter. With the development of the new Crew Exploration Vehicle (CEV), NASA has the opportunity to provide an integration path for the new vehicles and provide standards for their development. Some of the newer capabilities these vehicles could include are routing, security, and Software Defined Radios (SDRs). To meet these needs, the NASA/Glenn Research Center s (GRC) Network Emulation Laboratory (NEL) has been using both simulation and emulation to study and evaluate these architectures. These techniques provide options to NASA that directly impact architecture development. This paper identifies components of the infrastructure that play a pivotal role in the new NASA architecture, develops a scheme using simulation and emulation for testing these architectures and demonstrates how NASA can strengthen the new infrastructure by implementing these concepts.

Slywczak, Richard A.↗

NASA NTRS2008

Updates to the NASA Space Telecommunications Radio System (STRS) Architecture

This paper describes an update of the Space Telecommunications Radio System (STRS) open architecture for NASA space based radios. The STRS architecture has been defined as a framework for the design, development, operation and upgrade of space based software defined radios, where processing resources are constrained. The architecture has been updated based upon reviews by NASA missions, radio providers, and component vendors. The STRS Standard prescribes the architectural relationship between the software elements used in software execution and defines the Application Programmer Interface (API) between the operating environment and the waveform application. Modeling tools have been adopted to present the architecture. The paper will present a description of the updated API, configuration files, and constraints. Minimum compliance is discussed for early implementations. The paper then closes with a summary of the changes made and discussion of the relevant alignment with the Object Management Group (OMG) SWRadio specification, and enhancements to the specialized signal processing abstraction.

Kacpura, Thomas J.↗

NASA NTRS2008

Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems

NASA is developing an architecture standard for software-defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer. This paper presents the initial Space Telecommunications Radio System (STRS) Architecture for NASA missions to provide the desired software abstraction and flexibility while minimizing the resources necessary to support the architecture.

Reinhart, Richard C.↗

NASA NTRS2009

Lunar Navigation Architecture Design Considerations

The NASA Constellation Program is aiming to establish a long-term presence on the lunar surface. The Constellation elements (Orion, Altair, Earth Departure Stage, and Ares launch vehicles) will require a lunar navigation architecture for navigation state updates during lunar-class missions. Orion in particular has baselined earth-based ground direct tracking as the primary source for much of its absolute navigation needs. However, due to the uncertainty in the lunar navigation architecture, the Orion program has had to make certain assumptions on the capabilities of such architectures in order to adequately scale the vehicle design trade space. The following paper outlines lunar navigation requirements, the Orion program assumptions, and the impacts of these assumptions to the lunar navigation architecture design. The selection of potential sites was based upon geometric baselines, logistical feasibility, redundancy, and abort support capability. Simulated navigation covariances mapped to entry interface flightpath- angle uncertainties were used to evaluate knowledge errors. A minimum ground station architecture was identified consisting of Goldstone, Madrid, Canberra, Santiago, Hartebeeshoek, Dongora, Hawaii, Guam, and Ascension Island (or the geometric equivalent).

D'Souza, Christopher↗

NASA NTRS2009

Verifying Architectural Design Rules of the Flight Software Product Line

This paper presents experiences of verifying architectural design rules of the NASA Core Flight Software (CFS) product line implementation. The goal of the verification is to check whether the implementation is consistent with the CFS architectural rules derived from the developer's guide. The results indicate that consistency checking helps a) identifying architecturally significant deviations that were eluded during code reviews, b) clarifying the design rules to the team, and c) assessing the overall implementation quality. Furthermore, it helps connecting business goals to architectural principles, and to the implementation. This paper is the first step in the definition of a method for analyzing and evaluating product line implementations from an architecture-centric perspective.

Ganesan, Dharmalingam↗