SEARCH · Search NASA

Results for “information 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.

SourceResearch connectionFrom yearThrough year

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

At least 253 records · Page 14

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Expressing Functionality Using Design Patterns, A Real-World Example

Digital Engineering is a transformative strategy that leverages an integrated model-based approach to improve communication, decision making, design understanding, and acquisition efficiency of system development. As modern systems are derived from pre-existing systems, harvesting tacit knowledge from existing systems in a useful, model-based way will reduce the experiential learning and cognition required for new system development, contributing to a Digital Engineering transformation. This study enables such a technique by demonstrating the use of architectural theory in expressing tacit knowledge from existing systems and presenting that knowledge according to the model-based view offered by the Functional Architecture of Systems methodology. By validating the functional information expressed by the design pattern, this work solidifies design patterns as a critical component of a technical architecture and proposes a functional architecture viewpoint for describing mined knowledge in a usable, model-based, way suitable for archival in a modern knowledge management system.

Systems Engineering↗

NASA NTRS2007

"Fly-by-Wireless" : A Revolution in Aerospace Architectures for Instrumentation and Control

The conference presentation provides background information on Fly-by-Wireless technologies as well as reasons for implementation, CANEUS project goals, cost of change for instrumentation, reliability, focus areas, conceptual Hybrid SHMS architecture for future space habitats, real world problems that the technology can solve, evolution of Micro-WIS systems, and a WLEIDS system overview and end-to-end system design.

Studor, George F.↗

NASA NTRS1976

Architecture and data processing alternatives for the TSE computer. Volume 2: Extraction of topological information from an image by the Tse computer

A simple programmable Tse processor organization and arithmetic operations necessary for extraction of the desired topological information are described. Hardware additions to this organization are discussed along with trade-offs peculiar to the tse computing concept. An improved organization is presented along with the complementary software for the various arithmetic operations. The performance of the two organizations is compared in terms of speed, power, and cost. Software routines developed to extract the desired information from an image are included.

Jones, J. R.↗

NASA NTRS2018

Data, Meet Compute: NASA's Cumulus Ingest Architecture

NASA's Earth Observing System Data and Information System (EOSDIS) houses nearly 30PBs of critical Earth Science data and with upcoming missions is expected to balloon to between 200PBs-300PBs over the next seven years. In addition to the massive increase in data collected, researchers and application developers want more and faster access - enabling complex visualizations, long time-series analysis, and cross dataset research without needing to copy and manage massive amounts of data locally. NASA has looked to the cloud to address these needs, building its Cumulus system to manage the ingest of diverse data in a wide variety of formats into the cloud. In this talk, we look at what Cumulus is from a high level and then take a deep dive into how it manages complexity and versioning associated with multiple AWS Lambda and ECS microservices communicating through AWS Step Functions across several disparate installations

EOSDIS↗

NASA NTRS2021

Accessible Telemetry Streams using a Zero Trust Architecture for the Flight Operations Directorate

As a result of information technology based work becoming increasingly distributed, unique challenges have been presented within the realm of defined network perimeters, namely with respect to secure access to resources. Historically, and from a simplistic abstract perspective, the common approach has been to adopt the, so-called, moat model whereby a physical network perimeter (or interconnected perimeters) is defined to encapsulate resources behind a boundary protected by a firewall. Users are provisioned access through a virtual private network (VPN) and may be further constrained to resources through specific firewall allow and disallow rulesets. Virtual Private Networks and firewall rulesets lead to common problems, particularly at scale and, as a result, perimeter-less architectures provided over the public internet are increasingly becoming prevalent, particularly with its more popular implementation, the Zero Trust Architecture. We present a proposed implementation of the Zero Trust Architecture with a particular concrete example utilizing a de-perimeterized network that requires authentication and authorization for each action between nodes and does not operate within an implicit trust boundary. It should be noted that this paper is not an attempt at providing comprehensive resolutions for the specific problem space with respect to perimeter based security and is more directed at providing information with regard to our proposed implementation of a Zero Trust Architecture for the Flight Operations Directorate. We direct the reader to our Introduction and Background section for more details on specific documentation and where it can be located as it relates to de-perimeterization and Zero Trust.

Paul Shoemaker↗

NASA NTRSDate not supplied

Functional Volume Assessment of an Early Version of the Mars Transit Habitat

During the summer of 2020, the NASA Mars Architecture Team (MAT) assessed the Enhanced Habitation Capability (EHC), the transit spacecraft that was part of what was then the current Mars human exploration architecture, the Basis of Comparison (BOC). This assessment had six primary objectives: provide a sanity check to the BOC-derived EHC layout; understand if we can fit the hardware and functional tasks in the volume; provide a high-level assessment of how aggressive the layout is; generate a list of challenges or assumptions necessary to make it work; generate a list of future work to refine understanding; and identify proposed requirements. The results of this evaluation are discussed, including methodological challenges and rating challenges. Acceptability results are discussed for functions that the participants were able to rate and participant comments for functions that could not be evaluated are also described. Final conclusions are described, including challenges or assumptions needed to make the EHC design acceptable, future work needed to refine understanding of the EHC, and proposed habitat requirements based on test data. While NASA has since moved away from the BOC architecture, this assessment is still useful to inform the design of future Transit Habitats.

Mars Transit Habitat↗

NASA NTRSDate not supplied

An Ontological Approach to Integrate Commercial Space Operations with an In-time Aviation Safety Management System (IASMS)

The emergence of commercial space operations (CSO) is one of many Advanced Air Mobility domains that pose major challenges to in-time safety assurance because of the different architectures used by the operators and other agents. The National Academies recognized the need to improve integration of disparate architectures and recommended that an In-time Aviation Safety Management System(IASMS) be developed to provide seamless connectivity across interacting architectures and enable in-time safety assurance. An ontological approach to integrating CSO with IASMS involves in-time Services, Functions, and Capabilities design to manage operational risks and inform changes to design. The resulting integrated architecture provides a common basis for risk management and in-time safety assurance.

K Ellis↗

NASA NTRS2016

A Cognitive Systems Engineering Approach to Developing HMI Requirements for New Technologies

This document examines the challenges inherent in designing and regulating to support human-automation interaction for new technologies that will deployed into complex systems. A key question for new technologies, is how work will be accomplished by the human and machine agents. This question has traditionally been framed as how functions should be allocated between humans and machines. Such framing misses the coordination and synchronization that is needed for the different human and machine roles in the system to accomplish their goals. Coordination and synchronization demands are driven by the underlying human-automation architecture of the new technology, which are typically not specified explicitly by the designers. The human machine interface (HMI) which is intended to facilitate human-machine interaction and cooperation, however, typically is defined explicitly and therefore serves as a proxy for human-automation cooperation requirements with respect to technical standards for technologies. Unfortunately, mismatches between the HMI and the coordination and synchronization demands of the underlying human-automation architecture, can lead to system breakdowns. A methodology is needed that both designers and regulators can utilize to evaluate the expected performance of a new technology given potential human-automation architectures. Three experiments were conducted to inform the minimum HMI requirements a detect and avoid system for unmanned aircraft systems (UAS). The results of the experiments provided empirical input to specific minimum operational performance standards that UAS manufacturers will have to meet in order to operate UAS in the National Airspace System (NAS). These studies represent a success story for how to objectively and systematically evaluate prototype technologies as part of the process for developing regulatory requirements. They also provide an opportunity to reflect on the lessons learned from a recent research effort in order to improve the methodology for defining technology requirements for regulators in the future. The biggest shortcoming of the presented research program was the absence of the explicit definition, generation and analysis of potential human-automation architectures. Failure to execute this step in the research process resulted in less efficient evaluation of the candidate prototypes technologies in addition to the complete absence of different approaches to human-automation cooperation. For example, all of the prototype technologies that were evaluated in the research program assumed a human-automation architecture that relied on serial processing from the automation to the human. While this type of human-automation architecture is typical across many different technologies and in many different domains, it ignores different architectures where humans and automation work in parallel. Defining potential human-automation architectures a priori also allows regulators to develop scenarios that will stress the performance boundaries of the technology during the evaluation phase. The importance of adding this step of generating and evaluating candidate human-automation architectures prior to formal empirical evaluation is discussed.

human systems integration↗

NASA NTRS2007

Space Invariant Independent Component Analysis and ENose for Detection of Selective Chemicals in an Unknown Environment

In this paper, we present a space invariant architecture to enable the Independent Component Analysis (ICA) to solve chemical detection from two unknown mixing chemical sources. The two sets of unknown paired mixture sources are collected via JPL 16-ENose sensor array in the unknown environment with, at most, 12 samples data collected. Our space invariant architecture along with the maximum entropy information technique by Bell and Sejnowski and natural gradient descent by Amari has demonstrated that it is effective to separate the two mixing unknown chemical sources with unknown mixing levels to the array of two original sources under insufficient sampled data. From separated sources, they can be identified by projecting them on the 11 known chemical sources to find the best match for detection. We also present the results of our simulations. These simulations have shown that 100% correct detection could be achieved under the two cases: a) under-completed case where the number of input (mixtures) is larger than number of original chemical sources; and b) regular case where the number of input is as the same as the number of sources while the time invariant architecture approach may face the obstacles: overcomplete case, insufficient data and cumbersome architecture.

ENose↗

NASA NTRS2005

Modular Software Interfaces for Revolutionary Flexibility in Space Operations

To make revolutionary improvements in exploration, space systems need to be flexible, realtime reconfigurable, and able to trade data transparently among themselves and mission operations. Onboard operations systems, space assembly coordination and EVA systems in exploration and construction all require real-time modular reconfigurability and data sharing. But NASA's current exploration systems are still largely legacies from hastily-developed, one-off Apollo-era practices. Today's rovers, vehicles, spacesuits, space stations, and instruments are not able to plug-and-play, Lego-like: into different combinations. Point-to-point dominates - individual suit to individual vehicle, individual instrument to rover. All are locally optimized, all unique, each of the data interfaces has been recoded for each possible combination. This will be an operations and maintenance nightmare in the much larger Project Constellation system of systems. This legacy approach does not scale to the hundreds of networked space components needed for space construction and for new, space-based approaches to Earth-Moon operations. By comparison, battlefield information management systems, which are considered critical to military force projection, have long since abandoned a point-to-point approach to systems integration. From a system-of-systems viewpoint, a clean-sheet redesign of the interfaces of all exploration systems is a necessary prerequisite before designing the interfaces of the individual exploration systems. Existing communications and Global Information Grid and middleware technologies are probably sufficient for command and control and information interfaces, with some hardware and time-delay modifications for space environments. NASA's future advanced space operations must also be information and data compatible with aerospace operations and surveillance systems being developed by other US Government agencies such as the Department of Homeland Security, Federal Aviation Administration and Department of Defense. This paper discusses fundamental system-of-systems infrastructure: approaches and architectures for modular plug-and-play software interfaces for revolutionary improvements in flexibility, modularity, robustness, ease of maintenance, reconfigurability, safety and productivity. Starting with middleware, databases, and mobile communications technologies, our technical challenges will be to apply these ideas to the requirements of constellations of space systems and to implement them initially on prototype space hardware. This is necessary to demonstrate an integrated information sharing architecture and services. It is a bottom-up approach, one that solves the problem of space operations data integration. Exploration demands uniform software mechanisms for application information interchange, and the corresponding uniformly available software services to enhance these mechanisms. We will examine the issues in plug-and-play, real-time-configurable systems, including common definition and management and tracking of data and information among many different space systems. Different field test approaches are discussed, including the use of the International Space Station and terrestrial analog mission operations at field sites.

Glass, Brian↗

NASA NTRS2004

Geographic Information Systems and Web Page Development

The Facilities Engineering and Architectural Branch is responsible for the design and maintenance of buildings, laboratories, and civil structures. In order to improve efficiency and quality, the FEAB has dedicated itself to establishing a data infrastructure based on Geographic Information Systems, GIS. The value of GIS was explained in an article dating back to 1980 entitled "Need for a Multipurpose Cadastre" which stated, "There is a critical need for a better land-information system in the United States to improve land-conveyance procedures, furnish a basis for equitable taxation, and provide much-needed information for resource management and environmental planning." Scientists and engineers both point to GIS as the solution. What is GIS? According to most text books, Geographic Information Systems is a class of software that stores, manages, and analyzes mapable features on, above, or below the surface of the earth. GIS software is basically database management software to the management of spatial data and information. Simply put, Geographic Information Systems manage, analyze, chart, graph, and map spatial information. GIS can be broken down into two main categories, urban GIS and natural resource GIS. Further still, natural resource GIS can be broken down into six sub-categories, agriculture, forestry, wildlife, catchment management, archaeology, and geology/mining. Agriculture GIS has several applications, such as agricultural capability analysis, land conservation, market analysis, or whole farming planning. Forestry GIs can be used for timber assessment and management, harvest scheduling and planning, environmental impact assessment, and pest management. GIS when used in wildlife applications enables the user to assess and manage habitats, identify and track endangered and rare species, and monitor impact assessment.

Reynolds, Justin↗

NASA NTRS2004

Geographic Information Systems and Web Page Development

The Facilities Engineering and Architectural Branch is responsible for the design and maintenance of buildings, laboratories, and civil structures. In order to improve efficiency and quality, the FEAB has dedicated itself to establishing a data infrastructure based on Geographic Information Systems, GIs. The value of GIS was explained in an article dating back to 1980 entitled "Need for a Multipurpose Cadastre which stated, "There is a critical need for a better land-information system in the United States to improve land-conveyance procedures, furnish a basis for equitable taxation, and provide much-needed information for resource management and environmental planning." Scientists and engineers both point to GIS as the solution. What is GIS? According to most text books, Geographic Information Systems is a class of software that stores, manages, and analyzes mapable features on, above, or below the surface of the earth. GIS software is basically database management software to the management of spatial data and information. Simply put, Geographic Information Systems manage, analyze, chart, graph, and map spatial information. At the outset, I was given goals and expectations from my branch and from my mentor with regards to the further implementation of GIs. Those goals are as follows: (1) Continue the development of GIS for the underground structures. (2) Extract and export annotated data from AutoCAD drawing files and construct a database (to serve as a prototype for future work). (3) Examine existing underground record drawings to determine existing and non-existing underground tanks. Once this data was collected and analyzed, I set out on the task of creating a user-friendly database that could be assessed by all members of the branch. It was important that the database be built using programs that most employees already possess, ruling out most AutoCAD-based viewers. Therefore, I set out to create an Access database that translated onto the web using Internet Explorer as the foundation. After some programming, it was possible to view AutoCAD files and other GIS-related applications on Internet Explorer, while providing the user with a variety of editing commands and setting options. I was also given the task of launching a divisional website using Macromedia Flash and other web- development programs.

Reynolds, Justin↗

NASA NTRSDate not supplied

In-Situ Resource Utilization Options for the Moon and Mars

In-Situ Resource Utilization (ISRU) is key to enabling extended presence at exploration locations. NASA’s focus for ISRU to date has been human exploration locations: the Moon and Mars. Likewise the primary target for ISRU has been the production of mission consumables for propulsion and life support. Producing oxygen alone from minerals on the Moon or atmosphere on Mars can provide the majority of these consumables. However, accessing water at either location allows for full propellant production (fuel and oxidizer) as well as other applications (eg life support). Current and previous study efforts have looked at mission architectures and ISRU mass payback for these options. Studies have also identified gaps in information needed to design effective ISRU hardware and choose best architectures

In-Situ Resource Utilization↗

NASA NTRS2010

Considerations for Architecture Level Trade Studies for Environmental Sensors

Comparisons of key characteristics of environmental sensors such as technology readiness levels, mass, power, volume, and detection capabilities are essential for initial trade studies to determine likely candidates for further development and evaluation. However, these trade studies only provide part of the information necessary to make selection decisions. Ultimately, the sensors must be judged based on the overall system architectures and operational scenarios for which they are intended. This means that additional characteristics, such as architectural needs for redundancy, operational lifetime, ability to maintain calibration, and repair and replacement strategies, among others, must also be considered. Given that these characteristics can be extremely time-consuming and costly to obtain, careful planning is essential to minimize the effort involved. In this paper, an approach is explored for determining an effective yet comprehensive set of architecture level trades which is minimally impacted by the inevitable changes in operational (mission) scenarios. The approach will also identify and integrate the various facilities and opportunities required to obtain the desired architecture level trade information.

Peterson, Craig↗

NASA NTRS2022

Moon to Mars (M2M) Habitation Considerations: A Snap Shot As of January 2022

The following NASA Technical Memorandum (TM) is intended to provide a snapshot in time of NASA’s current considerations (ground rules and assumptions, functional allocations, logistics) for habitation systems for the lunar surface (non-roving) and Mars transits. As NASA continues to refine the reference designs to meet the needs of an evolving architecture, it is expected that this information will also be updated as a result. Where appropriate, relevant publicly released documents will be referenced to provide further detail. NASA’s human lunar exploration plan under the Artemis program calls for achieving the goal of sending the first woman and first person of color to the surface of the Moon in the mid- 2020s and working toward sustainable exploration by the end of the decade. Working with both commercial and international partners, NASA will establish a permanent human presence on the Moon to uncover new scientific discoveries and lay the foundation for private companies to build a lunar economy. Longer duration missions on the lunar surface and in lunar orbit will also serve as a test bed for technologies to support future Mars exploration campaigns. The agency will use what we learn on the Moon to prepare for humanity's next giant leap – sending astronauts to Mars. NASA intends to establish a sustained lunar presence with the development of the Artemis Base Camp to prove technologies and capabilities that will one day enable humans to live and work on Mars, beginning with core elements including the Lunar Terrain Vehicle (LTV), the Pressurized Rover (PR), the lunar Surface Habitat (SH), power systems, and in-situ resource utilization (ISRU) systems. For in space operations and eventual transport of humans to Mars, NASA will utilize a Mars Transit Habitat (TH). Following deployment, the TH will complete a series of longer duration missions and shakedown testing while docked at Gateway, leveraging Gateway’s habitation redundancy for safety measures. Proposed Gateway-TH missions will far exceed the longest duration cislunar human missions to date. They will be the first operational readiness tests of our long-duration deep space systems, and of the split crew (two crew on the surface, two crew in space) operations that are vital to the approach for the first human Mars mission. Both the SH and TH are major architectural elements of NASA’s Moon to Mars (M2M) approach, each with very different concepts of operation. The SH is intended for use on the lunar surface as a home for astronauts, surface operations base, science facility, hub for communications, extravehicular activity (EVA) equipment repair site, waste processing facility, and supply hub. It serves as an enabler for a sustained surface presence and preparation for partial gravity operations during Mars missions. The SH will be designed to be self-sufficient for operations on the lunar surface. The SH will independently provide several functions, including its own power generation, energy storage capability, sleep quarters, hygiene areas, work areas, and dining areas. It will be capable of communicating with surface assets, orbital assets, and directly with Earth ground stations. It is planned to operate with two crew in the habitat for ~28- day stays with crew swap-outs in which the PR crew of two trades places with the habitat crew. During the swap-out, the habitat will nominally support four crew for a short period of time. For contingency scenarios, the habitat must also be capable of supporting four crew for up to 7 days. The TH will be designed to be capable of up to ~1,200-day Mars missions with the ability to carry all food and supplies needed to support a crew of four for this duration. An assumed Mars mission profile for the TH is to carry crew and supplies for ~850-day roundtrips between Earth and Mars orbit that allows 30-day stays on the Martian surface. To test the systems for this long journey, the TH will be used to extend the duration of missions at Gateway, enabling the orbiting outpost to be used as a Mars analog. These analog missions will be accomplished by attaching the TH to Gateway and conducting lunar surface operations from the TH. The TH may also need to perform free-flying shakedown missions to test out all systems prior to leaving for Mars. The habitat provides many critical functions including: a contingency airlock, crew quarters, galley, hygiene areas, safe haven capability, and science equipment. It can receive docked items from either axial end or on a radial port.

Habitat↗

NASA NTRS2010

Product Lifecycle Management and the Quest for Sustainable Space Exploration Solutions

Product Lifecycle Management (PLM) is an outcome of lean thinking to eliminate waste and increase productivity. PLM is inextricably tied to the systems engineering business philosophy, coupled with a methodology by which personnel, processes and practices, and information technology combine to form an architecture platform for product design, development, manufacturing, operations, and decommissioning. In this model, which is being implemented by the Engineering Directorate at the National Aeronautics and Space Administration's (NASA's) Marshall Space Flight Center, total lifecycle costs are important variables for critical decisionmaking. With the ultimate goal to deliver quality products that meet or exceed requirements on time and within budget, PLM is a powerful tool to shape everything from engineering trade studies and testing goals, to integrated vehicle operations and retirement scenarios. This paper will demonstrate how the Engineering Directorate is implementing PLM as part of an overall strategy to deliver safe, reliable, and affordable space exploration solutions. It has been 30 years since the United States fielded the Space Shuttle. The next generation space transportation system requires a paradigm shift such that digital tools and knowledge management, which are central elements of PLM, are used consistently to maximum effect. The outcome is a better use of scarce resources, along with more focus on stakeholder and customer requirements, as a new portfolio of enabling tools becomes second nature to the workforce. This paper will use the design and manufacturing processes, which have transitioned to digital-based activities, to show how PLM supports the comprehensive systems engineering and integration function. It also will go through a launch countdown scenario where an anomaly is detected to show how the virtual vehicle created from paperless processes will help solve technical challenges and improve the likelihood of launching on schedule, with less hands-on labor needed for processing and troubleshooting. Sustainable space exploration solutions demand that all lifecycle phases be optimized. Adopting PLM, which has been used by the automotive industry for many years, for aerospace applications provides a foundation for strong, disciplined systems engineering and accountable return on investment by making lifecycle considerations variables in an iterative decision-making process. This paper combines the perspectives of the founding father of PLM, along with the experience of Engineering leaders who are implementing these processes and practices real-time. As the nation moves from an industrial-based society to one where information is a valued commodity, future NASA programs and projects will benefit from the experience being gained today for the exploration missions of tomorrow.

Caruso, Pamela W.↗

NASA NTRS1991

Telecommunications, navigation and information management concept overview for the Space Exploration Initiative program

An overview is provided of the Space Exploration Initiative (SEI) concepts for telecommunications, information systems, and navigation (TISN), and engineering and architecture issues are discussed. The SEI program data system is reviewed to identify mission TISN interfaces, and reference TISN concepts are described for nominal, degraded, and mission-critical data services. The infrastructures reviewed include telecommunications for robotics support, autonomous navigation without earth-based support, and information networks for tracking and data acquisition. Four options for TISN support architectures are examined which relate to unique SEI exploration strategies. Detailed support estimates are given for: (1) a manned stay on Mars; (2) permanent lunar and Martian settlements; short-duration missions; and (4) systematic exploration of the moon and Mars.

Bell, Jerome A.↗

NASA NTRS1984

The Pilot Land Data System: Report of the Program Planning Workshops

An advisory report to be used by NASA in developing a program plan for a Pilot Land Data System (PLDS) was developed. The purpose of the PLDS is to improve the ability of NASA and NASA sponsored researchers to conduct land-related research. The goal of the planning workshops was to provide and coordinate planning and concept development between the land related science and computer science disciplines, to discuss the architecture of the PLDs, requirements for information science technology, and system evaluation. The findings and recommendations of the Working Group are presented. The pilot program establishes a limited scale distributed information system to explore scientific, technical, and management approaches to satisfying the needs of the land science community. The PLDS paves the way for a land data system to improve data access, processing, transfer, and analysis, which land sciences information synthesis occurs on a scale not previously permitted because of limits to data assembly and access.

Source record↗