Search NASA⌕ Search

SEARCH · Search NASA

Results for “architecture definition”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

Increasing the Automation and Autonomy for Spacecraft Operations with Criteria Action Table

The Criteria Action Table (CAT) is an automation tool developed for monitoring real time system messages for specific events and processes in order to take user defined actions based on a set of user-defined rules. CAT was developed by Lockheed Martin Space Operations as a part of a larger NASA effort at the Goddard Space Flight Center (GSFC) to create a component-based, middleware-based, and standard-based general purpose ground system architecture referred as GMSEC - the GSFC Mission Services Evolution Center. CAT has been integrated into the upgraded ground systems for Tropical Rainfall Measuring Mission (TRMM) and Small Explorer (SMEX) satellites and it plays the central role in their automation effort to reduce the cost and increase the reliability for spacecraft operations. The GMSEC architecture provides a standard communication interface and protocol for components to publish/describe messages to an information bus. It also provides a standard message definition so components can send and receive messages to the bus interface rather than each other, thus reducing the component-to-component coupling, interface, protocols, and link (socket) management. With the GMSEC architecture, components can publish standard event messages to the bus for all nominal, significant, and surprising events in regard to satellite, celestial, ground system, or any other activity. In addition to sending standard event messages, each GMSEC compliant component is required to accept and process GMSEC directive request messages.

Li, Zhen-Ping↗
NASA NTRS1972

Advanced Software Techniques for Data Management Systems. Volume 2: Space Shuttle Flight Executive System: Functional Design

A functional design of software executive system for the space shuttle avionics computer is presented. Three primary functions of the executive are emphasized in the design: task management, I/O management, and configuration management. The executive system organization is based on the applications software and configuration requirements established during the Phase B definition of the Space Shuttle program. Although the primary features of the executive system architecture were derived from Phase B requirements, it was specified for implementation with the IBM 4 Pi EP aerospace computer and is expected to be incorporated into a breadboard data management computer system at NASA Manned Spacecraft Center's Information system division. The executive system was structured for internal operation on the IBM 4 Pi EP system with its external configuration and applications software assumed to the characteristic of the centralized quad-redundant avionics systems defined in Phase B.

Pepe, J. T.↗
NASA NTRS2001

Living With a Star, the Geospace Mission Definition Team and Aeronomy

To gain an understanding of the Sun-Earth system, including how and why the sun varies, how the earth responds, and the impacts on humanity, research is needed that has a integrated and systematic approach. The Living With a Star (LWS) program represents an important element in this regard both to continued progress in space science in general and in Aeronomy in particular. A fundamental question in Aeronomy is how the variable sun affects the ionosphere, thermosphere, and mesosphere. The LWS program focuses on those areas of scientific understanding that promote progress in areas that have human impact and can be investigated with space borne instruments. The Geospace Mission Definition Team is charged with investigating the science priorities identified by the LWS Science Architecture Team and developing an approach to making the necessary measurements in concert with other missions and programs. An important aspect of this approach is that all LWS measurement programs are operating simultaneously for several years. We will review some of the areas that the LWS SAT have emphasized in Aeronomy, including understanding the effects of solar variability on ionospheric density and irregularities, the effects of solar variability on the mass density of the atmosphere at LEO altitudes, and the effects of solar variability on near-surface temperatures and on ozone distribution.

Kintner, Paul M., Jr.↗
NASA NTRSDate not supplied

Operational Workflow in a Sample Receiving Facility: Input from the MSR Operation Definition Team

The return of scientifically selected samples from Mars would provide a rare opportunity for investigation with the full range of the latest technology available. To take full advantage of this opportunity, it is important to plan ahead to ensure the pristine nature of the samples upon arrival within the Earth environment until scientific investigations can begin. The NASA/ESA science community-driven MSR Science Planning Group – Phase 2 (MSPG2) delivered recommendations and guidance regarding curation (1) and science (2,3) activities to be performed on the samples under containment. High-level requirements for the infrastructure were also developed by MSPG2 (4). In order to prepare infrastructure-targeted input for the ESA and NASA facility studies planned in the 2022-2023 timeframe, the MSR agency-led Operational Scenarios Definition Team (MOSDT) was assembled to conceptualize the sample operations that will inform future architecture teams. Emphasis was placed on the responsibility of MOSDT to use community-defined requirements and to represent the view of the international scientific community. The main deliverable of MOSDT was an operational workflow for a Sample Receiving Facility (SRF). Two other deliverables were produced: a report to narrate the workflow, and a list of instruments (see Hutzler et al., this conference). Activities described in the main sequence of the workflow range from engineering operations to curation to science, with the latter term being used here as the science to be done within a SRF. Side sequences (e.g. engineering inspection of hardware, head gas extraction) were also identified, and detailed when they would have a significant impact on the infrastructure of a SRF. It was necessary for the MOSDT to rely on assumptions for some steps and activities, and though these were kept to a minimum (and are described in both the report supporting the workflow and in the full presentation), in general, the assumptions and overall work were very conservative, as the impact of underestimating the scope of the SRF infrastructure was considered more detrimental than overestimating it. It is expected that future work will be able to confirm or inform these assumptions. The community was consulted during the course of the MOSDT work. This abstract’s aim is two-fold: on one hand, inform the scientific community and overall MSR stakeholders, to make the infrastructure studies and trade-off more understandable; on the other hand, to solicit feedback from a larger community audience for the next iterations planning for SRF design and activities.

Mars Sample Return↗
NASA NTRS1994

STI Architectural Framework Working Group

A general overview of the architecture developed for the NASA scientific and technical information (STI) modernization plan is presented. The value of standardization as a technique to reduce life cycle costs, to facilitate interoperability and scalability and to simplify the management process is explained. Definitions for both de facto and de jure standards follow with emphasis on government and industrial standards. The methodology applied in developing the STI architecture is described.

Kaye, Karen↗
NASA NTRS1993

Node assignment in heterogeneous computing

A number of node assignment schemes, both static and dynamic, are explored for the Algorithm to Architecture Mapping Model (ATAMM). The architecture under consideration consists of heterogeneous processors and implements dataflow models of real-time applications. Terminology is developed for heterogeneous computing. New definitions are added to the ATAMM for token and assignment classifications. It is proved that a periodic execution is possible for dataflow graphs. Assignment algorithms are developed and proved. A design procedure is described for satisfying an objective function in an heterogeneous architecture. Several examples are provided for illustration.

Som, Sukhamoy↗
NASA NTRS1988

Expert system technology as a data processing tool

The expert system technology is focused on as a data processing tool. Several existing applications are analyzed. Their original definition as pure expert systems is contrasted with their current status as integrated systems. The architectural requirements needed to support such a heterogeneous environment are given.

Hennessy, John F.↗
NASA NTRS1999

Plug and Play Integration through Space Object Standardization

Plug and play is an industry standard promoted by Intel and Microsoft, and others that allows users to add and remove various input and output devices without making specific customizations to their systems. The idea behind concept is that using standard products eases integration of components and promotes capabilities of conforming products. The concept works because vendors comply with a standard specification. This paper reports the development of a reference architecture for the mission control domain, which is leveraging off this revolutionary concept. Standards are being developed at the application layer, which enable "plug and play" of mission software products. A Mission Control, reference architecture has been defined. For each sub-domain, the interfaces are modeled in Interface Definition Language (IDL). A subset of the IDL has been developed within both commercial off-the-shelf (COTS) and government (GOTS) products. Selected vendors have agreed to modify their products to be compatible with the defined IDL. The plug and play integration of these different products has been validated in a demonstration testbed.

Boyce, Leslye↗
NASA NTRS2000

Developing CORBA-Based Distributed Scientific Applications from Legacy Fortran Programs

Recent progress in distributed object technology has enabled software applications to be developed and deployed easily such that objects or components can work together across the boundaries of the network, different operating systems, and different languages. A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that co-operates with other objects in a plug-and-play fashion via a well-defined interface. The Common Object Request Broker Architecture (CORBA), a middleware standard defined by the Object Management Group (OMG), uses the Interface Definition Language (IDL) to specify such an interface for transparent communication between distributed objects. Since IDL can be mapped to any programming language, such as C++, Java, Smalltalk, etc., existing applications can be integrated into a new application and hence the tasks of code re-writing and software maintenance can be reduced. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with CORBA objects can increase the codes reusability. For example, scientists could link their scientific applications to vintage Fortran programs such as Partial Differential Equation(PDE) solvers in a plug-and-play fashion. Unfortunately, CORBA IDL to Fortran mapping has not been proposed and there seems to be no direct method of generating CORBA objects from Fortran without having to resort to manually writing C/C++ wrappers. In this paper, we present an efficient methodology to integrate Fortran legacy programs into a distributed object framework. Issues and strategies regarding the conversion and decomposition of Fortran codes into CORBA objects are discussed. The following diagram shows the conversion and decomposition mechanism we proposed. Our goal is to keep the Fortran codes unmodified. The conversion- aided tool takes the Fortran application program as input and helps programmers generate C/C++ header file and IDL file for wrapping the Fortran code. Programmers need to determine by themselves how to decompose the legacy application into several reusable components based on the cohesion and coupling factors among the functions and subroutines. However, programming effort still can be greatly reduced because function headings and types have been converted to C++ and IDL styles. Most Fortran applications use the COMMON block to facilitate the transfer of large amount of variables among several functions. The COMMON block plays the similar role of global variables used in C. In the CORBA-compliant programming environment, global variables can not be used to pass values between objects. One approach to dealing with this problem is to put the COMMON variables into the parameter list. We do not adopt this approach because it requires modification of the Fortran source code which violates our design consideration. Our approach is to extract the COMMON blocks and convert them into a structure-typed attribute in C++. Through attributes, each component can initialize the variables and return the computation result back to the client. We have tested successfully the proposed conversion methodology based on the f2c converter. Since f2c only translates Fortran to C, we still needed to edit the converted code to meet the C++ and IDL syntax. For example, C++/IDL requires a tag in the structure type, while C does not. In this paper, we identify the necessary changes to the f2c converter in order to directly generate the C++ header and the IDL file. Our future work is to add GUI interface to ease the decomposition task by simply dragging and dropping icons.

Sang, Janche↗
NASA NTRS2009

Propelling Exploration to the Moon and Beyond

As the Constellation Program enters its fourth year, the Ares Projects have made substantial progress toward sending human explorers beyond Earth orbit. The Ares I crew launch vehicle, which will take six astronauts or cargo to the International Space Station or four astronauts to rendezvous with Ares V for missions to the Moon, is the first human-rated vehicle NASA has developed in over 30 years. Since the Exploration Systems Architecture Study in 2005, the Ares Projects have completed a successful system requirements review, system definition review, and preliminary design review for the Ares I crew launch vehicle. The Ares I elements are well into development, beginning with the Shuttle-derived, five-segment solid rocket motor that will provide first-stage propulsion. The first stage team has poured its first production simulation article motor and will be pouring and firing the first five-segment development motor in 2009. Large-scale tooling has been installed and tested to produce propellant tanks for the liquid-fuel upper stage at Marshall Space Flight Center (MSFC) in Alabama. The initial upper stage units and main propulsion test article will be manufactured and tested at MSFC before transferring to Michoud Assembly Facility in Louisiana. The upper stage engine team has completed powerpack testing using Apollo J-2 heritage hardware and begun construction of a new altitude test stand at Stennis Space Center in Mississippi. The flight and integrated testing group has designed and built hardware for the Ares I-X test flight scheduled for 2009, as well as begun refurbishing existing infrastructure to support ground testing. Additionally, a base configuration has been selected for the Ares V cargo launch vehicle, which will send the Altair lunar lander and Orion to the Moon. Today, the Ares Projects are well on the way to building America s next generation of exploration-capable launch vehicles.

Cook, Stephen A.↗
NASA NTRS2009

Achieving a Prioritized Research and Technology Development Portfolio for the Dust Management Project

Mission architectures for human exploration of the lunar surface continue to advance as well as the definitions of capability needs, best practices and engineering design to mitigate the impact of lunar dust on exposed systems. The NASA DMP has been established as the agency focal point for dust characterization, technology, and simulant development. As described in this paper, the DMP has defined a process for selecting and justifying its R&T portfolio. The technology prioritization process, which is based on a ranking system according to weighted criteria, has been successfully applied to the current DMP dust mitigation technology portfolio. Several key findings emerged from this assessment. Within the dust removal and cleaning technologies group, there are critical technical challenges that must be overcome for these technologies to be implemented for lunar applications. For example, an in-situ source of CO2 on the moon is essential to the CO2 shower technology. Also, significant development effort is required to achieve technology readiness level TRL 6 for the electrostatic cleaning system for removal of particles smaller than 50 pm. The baseline materials related technologies require considerable development just to achieve TRL 6. It is also a nontrivial effort to integrate the materials in hardware for lunar application. At present, there are no terrestrial applications that are readily adaptable to lunar surface applications nor are there any obvious leading candidates. The unique requirements of dust sealing systems for lunar applications suggest an extensive development effort will be necessary to mature dust sealing systems to TRL 6 and beyond. As discussed here, several alternate materials and technologies have achieved high levels of maturity for terrestrial applications and warrant due diligence in ongoing assessment of the technology portfolio. The present assessment is the initial step in an ongoing effort to continually evaluate the DMP technology portfolio and external non-NASA relevant technology developments efforts to maintain an optimal investment profile. At the same time, there is an ongoing review of agency-wide dust-related R&T activities. The results of these ongoing assessments will be reported in future publications.

Hyatt, Mark J.↗
NASA NTRS2005

Range Process Simulation Tool

Range Process Simulation Tool (RPST) is a computer program that assists managers in rapidly predicting and quantitatively assessing the operational effects of proposed technological additions to, and/or upgrades of, complex facilities and engineering systems such as the Eastern Test Range. Originally designed for application to space transportation systems, RPST is also suitable for assessing effects of proposed changes in industrial facilities and large organizations. RPST follows a model-based approach that includes finite-capacity schedule analysis and discrete-event process simulation. A component-based, scalable, open architecture makes RPST easily and rapidly tailorable for diverse applications. Specific RPST functions include: (1) definition of analysis objectives and performance metrics; (2) selection of process templates from a processtemplate library; (3) configuration of process models for detailed simulation and schedule analysis; (4) design of operations- analysis experiments; (5) schedule and simulation-based process analysis; and (6) optimization of performance by use of genetic algorithms and simulated annealing. The main benefits afforded by RPST are provision of information that can be used to reduce costs of operation and maintenance, and the capability for affordable, accurate, and reliable prediction and exploration of the consequences of many alternative proposed decisions.

Phillips, Dave↗
NASA NTRS1979

Inverse boundary-layer technique for airfoil design

A description is presented of a technique for the optimization of airfoil pressure distributions using an interactive inverse boundary-layer program. This program allows the user to determine quickly a near-optimum subsonic pressure distribution which meets his requirements for lift, drag, and pitching moment at the desired flow conditions. The method employs an inverse turbulent boundary-layer scheme for definition of the turbulent recovery portion of the pressure distribution. Two levels of pressure-distribution architecture are used - a simple roof top for preliminary studies and a more complex four-region architecture for a more refined design. A technique is employed to avoid the specification of pressure distributions which result in unrealistic airfoils, that is, those with negative thickness. The program allows rapid evaluation of a designed pressure distribution off-design in Reynolds number, transition location, and angle of attack, and will compute an airfoil contour for the designed pressure distribution using linear theory.

Henderson, M. L.↗
NASA NTRS1986

Potential directions for a second generation Space Shuttle

This paper reports on trends and potentials for advanced rocket vehicles which may be candidates for eventual phased replacement of the Shuttle. Although such a replacement need is not foreseen until 2002 at the earliest, due to the long time to develop a new vehicle its definition has already begun. The paper discusses the role of such a "Shuttle II' in the architecture of launch vehicles likely to exist in the post-2000 era, leading to its designation as a smaller, primarily passenger-carrying vehicle to complement large, unmanned cargo launch vehicles. While a two-stage glide-back fully reusable configuration is optimum for near-term technology, a single-stage-to-orbit reusable glide-back configuration is optimum for farther-term technology advances. For advanced technology which could be available in the mid-90s, such vehicle could orbit a payload weight equal to their own dry weight - a factor of 10 better than current launch vehicles.

Bekey, I.↗
NASA NTRS1988

Automated generation of reliability models

The abstract semi-Markov specification interface to the SURE (Semi-Markov Range Evaluator) tool (ASSIST) program allows the user to describe the Markov model in a high-level language. Instead of listing the individual states of the model, the user specifies the rules governing the behavior of the system, and these are used to automatically generate the model. A small number of statements in the abstract language can describe a large, complex model. Becuase no assumptions are made about the system being modeled, ASSIST can be used to generate models describing the behavior of any type of system. The abstract model definition and the automatic model generation strategy are described. Analysis of an example fault-tolerant architecture, a triad of processor with cold spare processors, shows how the behavior of a system can be captured by a few general rules. The syntax of the ASSIST input language is then described and demonstrated by creating a model to describe the fault behavior of the example architecture. The flexibility of the abstract language is demonstrated by expanding the example to model multiple triads of processors sharing a pool of cold spare processors.

Johnson, Sally C.↗
NASA NTRS2008

Multidisciplinary Analysis and Optimization Generation 1 and Next Steps

The Multidisciplinary Analysis & Optimization Working Group (MDAO WG) of the Systems Analysis Design & Optimization (SAD&O) discipline in the Fundamental Aeronautics Program s Subsonic Fixed Wing (SFW) project completed three major milestones during Fiscal Year (FY)08: "Requirements Definition" Milestone (1/31/08); "GEN 1 Integrated Multi-disciplinary Toolset" (Annual Performance Goal) (6/30/08); and "Define Architecture & Interfaces for Next Generation Open Source MDAO Framework" Milestone (9/30/08). Details of all three milestones are explained including documentation available, potential partner collaborations, and next steps in FY09.

Naiman, Cynthia Gutierrez↗
NASA NTRS2013

Adoption of Test Driven Development and Continuous Integration for the Development of the Trick Simulation Toolkit

This paper describes the adoption of a Test Driven Development approach and a Continuous Integration System in the development of the Trick Simulation Toolkit, a generic simulation development environment for creating high fidelity training and engineering simulations at the NASA/Johnson Space Center and many other NASA facilities. It describes what was learned and the significant benefits seen, such as fast, thorough, and clear test feedback every time code is checked-in to the code repository. It also describes a system that encourages development of code that is much more flexible, maintainable, and reliable. The Trick Simulation Toolkit development environment provides a common architecture for user-defined simulations. Trick builds executable simulations using user-supplied simulation-definition files (S_define) and user supplied "model code". For each Trick-based simulation, Trick automatically provides job scheduling, checkpoint / restore, data-recording, interactive variable manipulation (variable server), and an input-processor. Also included are tools for plotting recorded data and various other supporting tools and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX. Prior to adopting this new development approach, Trick testing consisted primarily of running a few large simulations, with the hope that their complexity and scale would exercise most of Trick's code and expose any recently introduced bugs. Unsurprising, this approach yielded inconsistent results. It was obvious that a more systematic, thorough approach was required. After seeing examples of some Java-based projects that used the JUnit test framework, similar test frameworks for C and C++ were sought. Several were found, all clearly inspired by JUnit. Googletest, a freely available Open source testing framework, was selected as the most appropriate and capable. The new approach was implemented while rewriting the Trick memory management component, to eliminate a fundamental design flaw. The benefits became obvious almost immediately, not just in the correctness of the individual functions and classes but also in the correctness and flexibility being added to the overall design. Creating code to be testable, and testing as it was created resulted not only in better working code, but also in better-organized, flexible, and readable (i.e., articulate) code. This was, in essence the Test-driven development (TDD) methodology created by Kent Beck. Seeing the benefits of Test Driven Development, other Trick components were refactored to make them more testable and tests were designed and implemented for them.

Penn, John M.↗
NASA NTRS2019

An Exploration of Mission Concepts That Could Utilize Small RPS

The NASA Radioisotope Power Systems (RPS) Program Mission Analysis Team at the Jet Propulsion Laboratory (JPL) requested a JPL Innovation Foundry Architecture Team (A-Team) study to assess mission pull for small RPS (1 mWe - 40 We) in order to inform the RPS Program Office on what future power system developments should be focused on. The A-Team is JPL’s concurrent engineering design team for science definition and early mission concept development, targeting concept maturation levels of 1 through 3. The requested small RPS study was tasked to identify the architecture space of potential small RPS missions, and suggest power levels that could enable or enhance potential future small spacecraft missions. This paper describes the collaborative engineering processes that the A-Team and Mission Analysis Team used to reach results quickly and the findings to inform the RPS Program about mission concept power requirements on RPS for small missions.

Bairstow, Brian K.↗