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.

SourceResearch connectionFrom yearThrough year

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

At least 181 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

NASA NTRSDate not supplied

Development of the Artemis Distributed Simulation FOMs

HLA↗

NASA NTRS2013

Solar System Escape Architecture for Revolutionary Science

Our most distance spacecraft, Voyager 1 and Voyager 2, recently reached the boundary of the solar system known as the Heliopause. Beyond this boundary lies interstellar space, and, at tremendous distance, the stars. The Voyager spacecraft have shown us that the Heliopause is a dynamic, rapidly changing environment, varying greatly as the fields and effects emanating from the sun are met by a host of forces pushing in from our nearby galactic neighborhood. This is the region we aim to explore. Specifically we aim to develop a mission architecture and spacecraft concept capable of reaching the Heliopause (approximately100 AU (Astronomical Units)) region in multiple directions of interest, with a variety of scientific instrument suites, within a reasonable timeframe (about 15 years.) This report details our Phase 1 work including science goal definition, trajectory planning, technology research, mission planning, instrument selection, spacecraft design, and more. We present an architecture employing a 250-meter by 250-meter solar sail with a 175 kilogram spacecraft. This spacecraft could carry a variety of instrument suites depending on the destination, time, and other factors. The spin-stabilized spacecraft would powered by a small radioisotope power system (about 20 watts), makes use of an optical communication system, and carries 3 extensible booms for instrument accommodation as visible in the sketch and rendering below. We conclude that it would be reasonable to implement the architecture described herein in the 2020-2030 timeframe based on likely near-term technological and material advances. We are confident that cruise times of around 15 years could be achieved to science-rich destinations. This report details the approach we used to come to these conclusions and identifies some of the steps along the way. We utilized a variety of methodologies involving our full capability at JPL (Jet Propulsion Laboratory) - from small point studies to large collaborative engineering processes. This paper also describes potential industry partnerships and costing information, and includes the methods used to account for our project’s significant deviation from any prior mission in the NASA costing tool database. Outreach and public engagement is an important part of NASA activities. We engaged in several different forms of this outreach and describe them in this report. We conclude with some open questions and a summary of activities we hope to engage in with Phase 2 funding. The entire team would like to thank the NIAC (NASA Innovative Advanced Concepts) program for the opportunity to investigate this fascinating and challenging concept. The Voyager program gives us tantalizing clues as to the nature and behavior of the Heliopause – the boundary between the sun’s influence and the interstellar medium. This information comes from forty-year old instruments designed to study the outer planets. A targeted Heliopause investigation would give insight into the formation of the solar system, the role of the sun in the local interstellar neighborhood, and contribute to human exploration planning by helping to predict periods of low galactic cosmic ray (GCR) penetration into the inner solar system.

Spacecraft↗

NASA NTRS2012

Potential Applications of Modularity to Enable a Deep Space Habitation Capability for Future Human Exploration Beyond Low-Earth Orbit

Evaluating preliminary concepts of a Deep Space Habitat (DSH) enabling long duration crewed exploration of asteroids, the Moon, and Mars is a technically challenging problem. Sufficient habitat volumes and equipment, necessary to ensure crew health and functionality, increase propellant requirements and decrease launch flexibility to deliver multiple elements on a single launch vehicle; both of which increase overall mission cost. Applying modularity in the design of the habitat structures and subsystems can alleviate these difficulties by spreading the build-up of the overall habitation capability across several smaller parts. This allows for a more flexible habitation approach that accommodates various crew mission durations and levels of functionality. This paper provides a technical analysis of how various modular habitation approaches can impact the parametric design of a DSH with potential benefits in mass, packaging volume, and architectural flexibility. This includes a description of the desired long duration habitation capability, the definition of a baseline model for comparison, a small trade study to investigate alternatives, and commentary on potentially advantageous configurations to enable different levels of habitability. The approaches investigated include modular pressure vessel strategies, modular subsystems, and modular manufacturing approaches to habitat structure. The paper also comments upon the possibility of an integrated habitation strategy using modular components to create all short and long duration habitation elements required in the current exploration architectures.

Simon, Matthew A.↗

NASA NTRS1988

Exploration Studies Technical Report - Volume 2: Studies Approach and Results

The NASA Office of Exploration has been tasked with defining and recommending alternatives for an early 1990's national decision on a focused program of human exploration of the solar system. The Mission Analysis and System Engineering (MASE) group, which is managed by the Exploration Studies Office at the Johnson Space Center, is responsible for coordinating the technical studies necessary for accomplishing such a task. This technical report describes the process that has been developed in a case study approach. The four case studies that were developed in FY88 include: 1. Human expedition to Phobos 2. Human expeditions to Mars 3. Lunar observatory 4. Lunar outpost to early Mars evolution The final outcome of this effort is a set of programmatic and technical conclusions and recommendations for the following year's work. Volume 2 describes the case study process, the technical results of each of the case studies, and opportunities for additional study. Included in the discussion of each case study is a description of the mission key features and profile. Mission definition and manifesting are detailed, followed by a description of the mission architecture and infrastructure. Systems concepts for the required orbital nodes, transportation systems, and planetary surface systems are discussed. Prerequisite implementation plans resulting from the synthesized case studies are described and in-depth assessments are presented.

Interplanetary flight↗

NASA NTRS1998

F-Nets and Software Cabling: Deriving a Formal Model and Language for Portable Parallel Programming

Parallel programming is still being based upon antiquated sequence-based definitions of the terms "algorithm" and "computation", resulting in programs which are architecture dependent and difficult to design and analyze. By focusing on obstacles inherent in existing practice, a more portable model is derived here, which is then formalized into a model called Soviets which utilizes a combination of imperative and functional styles. This formalization suggests more general notions of algorithm and computation, as well as insights into the meaning of structured programming in a parallel setting. To illustrate how these principles can be applied, a very-high-level graphical architecture-independent parallel language, called Software Cabling, is described, with many of the features normally expected from today's computer languages (e.g. data abstraction, data parallelism, and object-based programming constructs).

DiNucci, David C.↗

NASA NTRS2015

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗

NASA NTRSDate not supplied

An Integrated Development Environment for the Prototype Verification System

The steep learning curve of formal technologies is a well-known barrier to the adoption of formal verification tools in industry. This paper presents VSCode-PVS, a modern integrated development environment for the Prototype Verification System (PVS). This new environment integrates the editing and proof management functionalities of PVS in Visual Studio Code, a popular code editor widely used by software developers. VSCode-PVS provides functionalities that developers expect to find in modern verification tools but are not available in the standard Emacs front-end of PVS, such as auto-completion, point-and-click navigation of definitions, live diagnostics for errors, and literate programming. The main features and architecture of the environment are presented, along with a comparison with other similar tools.

Paolo Masci↗

NASA NTRS1991

A biconjugate gradient type algorithm on massively parallel architectures

The biconjugate gradient (BCG) method is the natural generalization of the classical conjugate gradient algorithm for Hermitian positive definite matrices to general non-Hermitian linear systems. Unfortunately, the original BCG algorithm is susceptible to possible breakdowns and numerical instabilities. Recently, Freund and Nachtigal have proposed a novel BCG type approach, the quasi-minimal residual method (QMR), which overcomes the problems of BCG. Here, an implementation is presented of QMR based on an s-step version of the nonsymmetric look-ahead Lanczos algorithm. The main feature of the s-step Lanczos algorithm is that, in general, all inner products, except for one, can be computed in parallel at the end of each block; this is unlike the other standard Lanczos process where inner products are generated sequentially. The resulting implementation of QMR is particularly attractive on massively parallel SIMD architectures, such as the Connection Machine.

Freund, Roland W.↗

NASA NTRS2000

Photochemical Phenomenology Model for the New Millenium

This project tackles the problem of conversion of validated a priori physics-based modeling capabilities, specifically those relevant to the analysis and interpretation of planetary atmosphere observations, to application-oriented software for use in science and science-support activities. The software package under development, named the Photochemical Phenomenology Modeling Tool (PPMT), has particular focus on the atmospheric remote sensing data to be acquired by the CIRS instrument during the CASSINI Jupiter flyby and orbital tour of the Saturnian system. Overall, the project has followed the development outline given in the original proposal, and the Year 1 design and architecture goals have been met. Specific accomplishments and the difficulties encountered are summarized in this report. Most of the effort has gone into complete definition of the PPMT interfaces within the context of today's IT arena: adoption and adherence to the CORBA Component Model (CCM) has yielded a solid architecture basis, and CORBA-related issues (services, specification options, development plans, etc.) have been largely resolved. Implementation goals have been redirected somewhat so as to be more relevant to the upcoming CASSINI flyby of Jupiter, with focus now being more on data analysis and remote sensing retrieval applications.

Bishop, James↗

NASA NTRSDate not supplied

Data Definition Management for Orion Backup Flight Software

The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. Missions using cFS can reuse code from other missions, as well as leverage deployment to similar computer architectures. The Orion Backup Flight Software (BFS) team selected cFS as the architecture to be used on the program, and this presentation will describe some design choices we made, and the consequences of those decisions.

CFS↗

NASA NTRS2000

Parallel Conjugate Gradient: Effects of Ordering Strategies, Programming Paradigms, and Architectural Platforms

The Conjugate Gradient (CG) algorithm is perhaps the best-known iterative technique to solve sparse linear systems that are symmetric and positive definite. A sparse matrix-vector multiply (SPMV) usually accounts for most of the floating-point operations within a CG iteration. In this paper, we investigate the effects of various ordering and partitioning strategies on the performance of parallel CG and SPMV using different programming paradigms and architectures. Results show that for this class of applications, ordering significantly improves overall performance, that cache reuse may be more important than reducing communication, and that it is possible to achieve message passing performance using shared memory constructs through careful data ordering and distribution. However, a multi-threaded implementation of CG on the Tera MTA does not require special ordering or partitioning to obtain high efficiency and scalability.

Oliker, Leonid↗

NASA NTRS2004

Flight Test of Weather Data Exchange Using the 1090 Extended Squitter (1090ES) and VDL Mode 3 Data Links

This report describes preliminary results of work done by JHU/APL under contract to the NASA Glenn Research Center to support flight testing of the Universal Access Transceiver (UAT) data link as a medium for weather data exchange. It presents a high level architectural description of the use of UAT to meet the program objectives with an identification of issues associated with the use of this data link, including a high level definition of the changes required to UAT avionics and ground-based receivers and supporting ground infrastructure to support implementation of the recommended architecture with focus on the issues associated with these changes.

Griner, James H., Jr.↗

NASA NTRS1987

Applications of expert systems for satellite autonomy

Some aspects of the on-board application of expert systems in artificial satellites are discussed. The activities of the study, which include the implementation of two prototypes on a dedicated artificial intelligence machine, are described. The general implications of the experience are then discussed. These concern the interrelationship between the expert system and the architecture of the satellite and the expert system's impact on the mission definition phase of the satellite lifecycle. The main obstacles that need to be overcome before operational use of onboard expert systems can take place are discussed.

Ciarlo, A.↗

NASA NTRSDate not supplied

Notional Habitat Science Outfitting for a Lunar Surface Habitat or Mars Transit Habitat

Science outfitting is often given insufficient treatment in the development of early conceptual studies for lunar surface habitats. In some cases, only control masses and volumes are used as placeholders. In others, one science discipline may be given detailed treatment while others are largely ignored. It is not unheard of for science outfitting to be entirely forgotten in initial concept layouts. This is exacerbated by the reality that spacecraft design studies are often initiated long before science objectives have been established for any given human spaceflight destination. When those objectives later emerge, they can be difficult to accommodate if sizing studies did not allocate sufficient resources for them. A notional science outfitting can be created for virtually any human exploration habitat, however, utilizing data created by the International Space Station and Constellation programs. Biology, human research, physics, and geology science laboratories and a general-purpose work area for a lunar surface habitat will be derived using equipment identified by the Constellation-era Optimizing Science and Exploration Working Group (OSEWG) or flown on the International Space Station. Early science outfitting definition and inclusion in surface habitat sizing is critical for developing an exploration architecture that meets science needs. The mass, volume, power, and use cases associated with these notional laboratories impacts all of the habitat subsystems, habitat dimensions, hatch dimensions, logistics operations, launch vehicles and landers.

Lunar Habitat↗

NASA NTRSDate not supplied

Analytical Needs 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 forinvestigation with the full range of the latest technology available, but to take full advantageof this opportunity, it is important to plan ahead to ensure the pristine nature of the samplesupon 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 tobe performed on the samples under containment. High-level requirements for the infrastruc-ture were also developed by MSPG2 (4). In order to prepare infrastructure-targeted input forthe ESA and NASA facility studies planned in the 2022-2023 timeframe, the agency-led MSROperational Scenarios Definition Team (MOSDT) was assembled to conceptualize the sampleoperations that will inform future architecture teams. Emphasis was placed on the respon-sibility of MOSDT to use community-defined requirements and to represent the view of the international scientific community.All necessary and sufficient instruments and analytical needs described in MSPG2 were inte-grated in MOSDT main deliverable, the operational workflow (see Hays et al, this conference).In MSPG2, notional instruments were split between curation analytical needs, and objective-driven (time-sensitive and sterilization-sensitive) science analytical needs. In MOSDT, whilethe first phases of curation, “pre-Basic Characterization” and “Basic Characterization” wererather streamlined and separate from other analytical needs, “Preliminary Examination” and“Science” instruments were not always physically segregated. In addition to the necessary andsufficient instruments described by MSPG2, the MOSDT recommended additional supportequipment for sterilization, cleanliness and contamination monitoring.It was sometimes necessary for the MOSDT to rely on assumptions to integrate instruments inthe activity workflow. In general, the assumptions were very conservative to limit contaminationand cross-contamination risks. It is expected that future work to refine limits of contaminationwill enable optimization of instrumentation.The community was consulted during the course of the MOSDT work. This abstract’s aimis two-fold: on one hand, inform the scientific community and overall MSR stakeholders, tobring their attention on the analytical needs currently considered as necessary and sufficient;on the other hand, to solicit feedback from a larger community audience to optimize and refineanalytical needs during the next phases of MSR ground-segment preparation.Disclaimer: The decision to implement Mars Sample Return will not be finalized until NASA’scompletion of the program’s National Environmental Policy Act (NEPA) process. This docu-ment is being made available for informational purposes only.[1] Tait et al. (2021) Preliminary planning for Mars Sample Return (MSR) curation activities ina Sample Receiving Facility (SRF). Astrobiology in press, doi:10.1089/ast.2021.0105. [2] Toscaet al. (2021) Time-sensitive aspects of Mars Sample Return (MSR) science. Astrobiologyin press, doi:10.1089/ast.2021.0115. [3] Velbel et al. (2021) Planning implications relatedto sterilization-sensitive science investigations associated with Mars Sample Return (MSR).Astrobiology in press, doi:10.1089/ast.2021.0113. [4] Carrier et al. (2021) Science and curationconsiderations for the design of a Mars Sample Return (MSR) Sample Receiving Facility (SRF).Astrobiology in press, doi:10.1089/ast.2021.0110.

Mars Sample Return↗

NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗

NASA NTRS2002

Systems Architecture for Fully Autonomous Space Missions

The NASA Goddard Space Flight Center is working to develop a revolutionary new system architecture concept in support of fully autonomous missions. As part of GSFC's contribution to the New Millenium Program (NMP) Space Technology 7 Autonomy and on-Board Processing (ST7-A) Concept Definition Study, the system incorporates the latest commercial Internet and software development ideas and extends them into NASA ground and space segment architectures. The unique challenges facing the exploration of remote and inaccessible locales and the need to incorporate corresponding autonomy technologies within reasonable cost necessitate the re-thinking of traditional mission architectures. A measure of the resiliency of this architecture in its application to a broad range of future autonomy missions will depend on its effectiveness in leveraging from commercial tools developed for the personal computer and Internet markets. Specialized test stations and supporting software come to past as spacecraft take advantage of the extensive tools and research investments of billion-dollar commercial ventures. The projected improvements of the Internet and supporting infrastructure go hand-in-hand with market pressures that provide continuity in research. By taking advantage of consumer-oriented methods and processes, space-flight missions will continue to leverage on investments tailored to provide better services at reduced cost. The application of ground and space segment architectures each based on Local Area Networks (LAN), the use of personal computer-based operating systems, and the execution of activities and operations through a Wide Area Network (Internet) enable a revolution in spacecraft mission formulation, implementation, and flight operations. Hardware and software design, development, integration, test, and flight operations are all tied-in closely to a common thread that enables the smooth transitioning between program phases. The application of commercial software development techniques lays the foundation for delivery of product-oriented flight software modules and models. Software can then be readily applied to support the on-board autonomy required for mission self-management. An on-board intelligent system, based on advanced scripting languages, facilitates the mission autonomy required to offload ground system resources, and enables the spacecraft to manage itself safely through an efficient and effective process of reactive planning, science data acquisition, synthesis, and transmission to the ground. Autonomous ground systems in turn coordinate and support schedule contact times with the spacecraft. Specific autonomy software modules on-board include mission and science planners, instrument and subsystem control, and fault tolerance response software, all residing within a distributed computing environment supported through the flight LAN. Autonomy also requires the minimization of human intervention between users on the ground and the spacecraft, and hence calls for the elimination of the traditional operations control center as a funnel for data manipulation. Basic goal-oriented commands are sent directly from the user to the spacecraft through a distributed internet-based payload operations "center". The ensuing architecture calls for the use of spacecraft as point extensions on the Internet. This paper will detail the system architecture implementation chosen to enable cost-effective autonomous missions with applicability to a broad range of conditions. It will define the structure needed for implementation of such missions, including software and hardware infrastructures. The overall architecture is then laid out as a common thread in the mission life cycle from formulation through implementation and flight operations.

Esper, Jamie↗