Search NASA⌕ Search

SEARCH · Search NASA

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 217 records · Page 12
All sourcesNASA NTRSDOE OSTI
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↗
NASA NTRS2009

Robust Software Architecture for Robots

Robust Real-Time Reconfigurable Robotics Software Architecture (R4SA) is the name of both a software architecture and software that embodies the architecture. The architecture was conceived in the spirit of current practice in designing modular, hard, realtime aerospace systems. The architecture facilitates the integration of new sensory, motor, and control software modules into the software of a given robotic system. R4SA was developed for initial application aboard exploratory mobile robots on Mars, but is adaptable to terrestrial robotic systems, real-time embedded computing systems in general, and robotic toys.

Aghazanian, Hrand↗
NASA NTRS2010

An Integrated Architecture for On-Board Aircraft Engine Performance Trend Monitoring and Gas Path Fault Diagnostics

Aircraft engine performance trend monitoring and gas path fault diagnostics are closely related technologies that assist operators in managing the health of their gas turbine engine assets. Trend monitoring is the process of monitoring the gradual performance change that an aircraft engine will naturally incur over time due to turbomachinery deterioration, while gas path diagnostics is the process of detecting and isolating the occurrence of any faults impacting engine flow-path performance. Today, performance trend monitoring and gas path fault diagnostic functions are performed by a combination of on-board and off-board strategies. On-board engine control computers contain logic that monitors for anomalous engine operation in real-time. Off-board ground stations are used to conduct fleet-wide engine trend monitoring and fault diagnostics based on data collected from each engine each flight. Continuing advances in avionics are enabling the migration of portions of the ground-based functionality on-board, giving rise to more sophisticated on-board engine health management capabilities. This paper reviews the conventional engine performance trend monitoring and gas path fault diagnostic architecture commonly applied today, and presents a proposed enhanced on-board architecture for future applications. The enhanced architecture gains real-time access to an expanded quantity of engine parameters, and provides advanced on-board model-based estimation capabilities. The benefits of the enhanced architecture include the real-time continuous monitoring of engine health, the early diagnosis of fault conditions, and the estimation of unmeasured engine performance parameters. A future vision to advance the enhanced architecture is also presented and discussed

Simon, Donald L.↗
NASA NTRS2010

Reference Avionics Architecture for Lunar Surface Systems

Developing and delivering infrastructure capable of supporting long-term manned operations to the lunar surface has been a primary objective of the Constellation Program in the Exploration Systems Mission Directorate. Several concepts have been developed related to development and deployment lunar exploration vehicles and assets that provide critical functionality such as transportation, habitation, and communication, to name a few. Together, these systems perform complex safety-critical functions, largely dependent on avionics for control and behavior of system functions. These functions are implemented using interchangeable, modular avionics designed for lunar transit and lunar surface deployment. Systems are optimized towards reuse and commonality of form and interface and can be configured via software or component integration for special purpose applications. There are two core concepts in the reference avionics architecture described in this report. The first concept uses distributed, smart systems to manage complexity, simplify integration, and facilitate commonality. The second core concept is to employ extensive commonality between elements and subsystems. These two concepts are used in the context of developing reference designs for many lunar surface exploration vehicles and elements. These concepts are repeated constantly as architectural patterns in a conceptual architectural framework. This report describes the use of these architectural patterns in a reference avionics architecture for Lunar surface systems elements.

Somervill, Kevin M.↗
NASA NTRS2004

A Software Architecture for Semiautonomous Robot Control

A software architecture has been developed to increase the safety and effectiveness with which tasks are performed by robots that are capable of functioning autonomously but sometimes are operated under control by humans. The control system of such a robot designed according to a prior software architecture has no way of taking account of how the environment has changed or what parts of a task were performed during an interval of control by a human, so that errors can occur (and, hence, safety and effectiveness jeopardized) when the human relinquishes control. The present architecture incorporates the control, task-planning, and sensor-based-monitoring features of typical prior autonomous-robot software architectures, plus features for updating information on the environment and planning of tasks during control by a human operator in order to enable the robot to track the actions taken by the operator and to be ready to resume autonomous operation with minimal error. The present architecture also provides a user interface that presents, to the operator, a variety of information on the internal state of the robot and the status of the task.

Kortenkamp, David↗
NASA NTRS2011

Jupiter Europa Orbiter Architecture Definition Process

The proposed Jupiter Europa Orbiter mission, planned for launch in 2020, is using a new architectural process and framework tool to drive its model-based systems engineering effort. The process focuses on getting the architecture right before writing requirements and developing a point design. A new architecture framework tool provides for the structured entry and retrieval of architecture artifacts based on an emerging architecture meta-model. This paper describes the relationships among these artifacts and how they are used in the systems engineering effort. Some early lessons learned are discussed.

requirements analysis↗