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 91 records · Page 5

[Determine and Implement Updates to Be Made to MODEAR (Mission Operations Data Enterprise Architecture Repository)]

My main project was to determine and implement updates to be made to MODEAR (Mission Operations Data Enterprise Architecture Repository) process definitions to be used for CST-100 (Crew Space Transportation-100) related missions. Emphasis was placed on the scheduling aspect of the processes. In addition, I was to complete other tasks as given. Some of the additional tasks were: to create pass-through command look-up tables for the flight controllers, finish one of the MDT (Mission Operations Directorate Display Tool) displays, gather data on what is included in the CST-100 public data, develop a VBA (Visual Basic for Applications) script to create a csv (Comma-Separated Values) file with specific information from spreadsheets containing command data, create a command script for the November MCC-ASIL (Mission Control Center-Avionics System Integration Laboratory) testing, and take notes for one of the TCVB (Terminal Configured Vehicle B-737) meetings. In order to make progress in my main project I scheduled meetings with the appropriate subject matter experts, prepared material for the meetings, and assisted in the discussions in order to understand the process or processes at hand. After such discussions I made updates to various MODEAR processes and process graphics. These meetings have resulted in significant updates to the processes that were discussed. In addition, the discussions have helped the departments responsible for these processes better understand the work ahead and provided material to help document how their products are created. I completed my other tasks utilizing resources available to me and, when necessary, consulting with the subject matter experts. Outputs resulting from my other tasks were: two completed and one partially completed pass through command look-up tables for the fight controllers, significant updates to one of the MDT displays, a spreadsheet containing data on what is included in the CST-100 public data, a tool to create a csv file with specific information from spreadsheets containing command data, a command script for the November MCC-ASIL testing which resulted in a successful test day identifying several potential issues, and notes from one of the TCVB meetings that was used to keep the teams up to date on what was discussed and decided. I have learned a great deal working at NASA these last four months. I was able to meet and work with amazing individuals, further develop my technical knowledge, expand my knowledge base regarding human spaceflight, and contribute to the CST-100 missions. My work at NASA has strengthened my desire to continue my education in order to make further contributions to the field, and has given me the opportunity to see the advantages of a career at NASA.

Fanourakis, Sofia↗

Communications System Architecture Development for Air Traffic Management and Aviation Weather Information Dissemination

This document is the NASA AATT Task Order 24 Final Report. NASA Research Task Order 24 calls for the development of eleven distinct task reports. Each task was a necessary exercise in the development of comprehensive communications systems architecture (CSA) for air traffic management and aviation weather information dissemination for 2015, the definition of the interim architecture for 2007, and the transition plan to achieve the desired End State. The eleven tasks are summarized along with the associated Task Order reference. The output of each task was an individual task report. The task reports that make up the main body of this document include Task 5, Task 6, Task 7, Task 8, Task 10, and Task 11. The other tasks provide the supporting detail used in the development of the architecture. These reports are included in the appendices. The detailed user needs, functional communications requirements and engineering requirements associated with Tasks 1, 2, and 3 have been put into a relational database and are provided electronically.

Gallagher, Seana↗

Space Telecommunications Radio Systems (STRS) Hardware Architecture Standard: Release 1.0 Hardware Section

This report defines a hardware architecture approach for software-defined radios to enable commonality among NASA space missions. The architecture accommodates a range of reconfigurable processing technologies including general-purpose processors, digital signal processors, field programmable gate arrays, and application-specific integrated circuits (ASICs) in addition to flexible and tunable radiofrequency front ends to satisfy varying mission requirements. The hardware architecture consists of modules, radio functions, and interfaces. The modules are a logical division of common radio functions that compose a typical communication radio. This report describes the architecture details, the module definitions, the typical functions on each module, and the module interfaces. Tradeoffs between component-based, custom architecture and a functional-based, open architecture are described. The architecture does not specify a physical implementation internally on each module, nor does the architecture mandate the standards or ratings of the hardware used to construct the radios.

Reinhart, Richard C.↗

An MBSE Approach to Space Suit Development

The EVA/Space Suit Development Office (ESSD) Systems Engineering and Integration (SE&I) team has utilized MBSE in multiple programs. After developing operational and architectural models, the MBSE framework was expanded to link the requirements space to the system models through functional analysis and interfaces definitions. By documenting all the connections within the technical baseline, ESSD experienced significant efficiency improvements in analysis and identification of change impacts. One of the biggest challenges presented to the MBSE structure was a program transition and restructuring effort, which was completed successfully in 4 months culminating in the approval of a new EVA Technical Baseline. During this time three requirements sets spanning multiple DRMs were streamlined into one NASA-owned Systems Requirement Document (SRD) that successfully identified requirements relevant to the current hardware development effort while remaining extensible to support future hardware developments. A capability-based hierarchy was established to provide a more flexible framework for future space suit development that can support multiple programs with minimal rework of basic EVA/Space Suit requirements. This MBSE approach was most recently applied for generation of an EMU Demonstrator technical baseline being developed for an ISS DTO. The relatively quick turnaround of operational concepts, architecture definition, and requirements for this new suit development has allowed us to test and evolve the MBSE process and framework in an extremely different setting while still offering extensibility and traceability throughout ESSD projects. The ESSD MBSE framework continues to be evolved in order to support integration of all products associated with the SE&I engine.

Cordova, Lauren↗

Surface Habitat Systems

The Surface Habitat Systems (SHS) Focused Investment Group (FIG) is part of the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) effort to provide a focused direction and funding to the various projects that are working on human surface habitat designs and technologies for the planetary exploration missions. The overall SHS-FIG effort focuses on directing and guiding those projects that: 1) develop and demonstrate new surface habitat system concepts, innovations, and technologies to support human exploration missions, 2) improve environmental systems that interact with human habitats, 3) handle and emplace human surface habitats, and 4) focus on supporting humans living and working in habitats on planetary surfaces. The activity areas of the SHS FIG described herein are focused on the surface habitat project near-term objectives as described in this document. The SHS-FIG effort focuses on mitigating surface habitat risks (as identified by the Lunar Surface Systems Project Office (LSSPO) Surface Habitat Element Team; and concentrates on developing surface habitat technologies as identified in the FY08 gap analysis. The surface habitat gap assessment will be updated annually as the surface architecture and surface habitat definition continues to mature. These technologies are mapped to the SHS-FIG Strategic Development Roadmap. The Roadmap will bring to light the areas where additional innovative efforts are needed to support the development of habitat concepts and designs and the development of new technologies to support of the LSSPO Habitation Element development plan. Three specific areas of development that address Lunar Architecture Team (LAT)-2 and Constellation Architecture Team (CxAT) Lunar habitat design issues or risks will be focused on by the SHS-FIG. The SHS-FIG will establish four areas of development that will help the projects prepare in their planning for surface habitat systems development. Those development areas are the 1) surface habitat concept definition, 2) inflatable surface habitat development, and 3) autonomous habitat operations, and 4) cross-cutting / systems engineering. In subsequent years, the SHS-FIG will solicit a call for innovations and technologies that will support the development of these four development areas. The other development areas will be assessed yearly and identified on the SHS-FIG s Strategic Development Roadmap. Initial investment projects that are funded by the Constellation Program Office (CxPO), LSSPO, or the Exploration Technology Development Projects (ETDP) will also be included on the Roadmap. For example, in one or two years from now, the autonomous habitat operations and testbed would collaborations with the Integrated Systems Health Management (ISHM) and Automation for Operations ETDP projects, which will give the surface habitat projects an integrated habitat autonomy testbed to test software and systems. The SHS-FIG scope is to provide focused direction for multiple innovations, technologies and subsystems that are needed to support humans at a remote planetary surface habitat during the concept development, design definition, and integration phases of that project. Subsystems include: habitability, lightweight structures, power management, communications, autonomy, deployment, outfitting, life support, wireless connectivity, lighting, thermal and more.

Kennedy, Kriss J.↗

Constellation Architecture Team-Lunar Scenario 12.0 Habitation Overview

This paper will describe an overview of the Constellation Architecture Team Lunar Scenario 12.0 surface habitation approach, concept, and assessments performed during the study definition. The Lunar Scenario 12 architecture study focused on two primary habitation approaches: a horizontally-oriented habitation module (LS-12.0) and a vertically-oriented habitation module (LS-12.1). This paper will provide an overview of 12.0 lunar surface campaign, the associated outpost architecture, habitation functionality, concept description, system integration strategy, mass and power resource estimates. The Scenario 12 architecture resulted from combining three previous scenarios after the Lunar Surface Systems (LSS) Project Office meeting in April 28-30, 2009. The best attributes from Scenario 4 "Optimized Exploration", Scenario 5 "Fission Surface Power System" and Scenario 8 "Initial Extensive Mobility" were combined into Scenario 12 along with an added emphasis on defining the excursion ConOps while the crew is away from the outpost location.

Kennedy, Kriss J.↗

Constellation Architecture Team-Lunar Scenario 12.0 Habitation Overview

This paper will describe an overview of the Constellation Architecture Team Lunar Scenario 12.0 (LS-12) surface habitation approach and concept performed during the study definition. The Lunar Scenario 12 architecture study focused on two primary habitation approaches: a horizontally-oriented habitation module (LS-12.0) and a vertically-oriented habitation module (LS-12.1). This paper will provide an overview of the 12.0 lunar surface campaign, the associated outpost architecture, habitation functionality, concept description, system integration strategy, mass and power resource estimates. The Scenario 12 architecture resulted from combining three previous scenario attributes from Scenario 4 "Optimized Exploration", Scenario 5 "Fission Surface Power System" and Scenario 8 "Initial Extensive Mobility" into Scenario 12 along with an added emphasis on defining the excursion ConOps while the crew is away from the outpost location. This paper will describe an overview of the CxAT-Lunar Scenario 12.0 habitation concepts and their functionality. The Crew Operations area includes basic crew accommodations such as sleeping, eating, hygiene and stowage. The EVA Operations area includes additional EVA capability beyond the suitlock function such as suit maintenance, spares stowage, and suit stowage. The Logistics Operations area includes the enhanced accommodations for 180 days such as enhanced life support systems hardware, consumable stowage, spares stowage, interconnection to the other habitation elements, a common interface mechanism for future growth, and mating to a pressurized rover or Pressurized Logistics Module (PLM). The Mission & Science Operations area includes enhanced outpost autonomy such as an IVA glove box, life support, medical operations, and exercise equipment.

Kennedy, Kriss J.↗

Smart Sensors' Role in Integrated System Health Management

During the last decade, there has been a major effort in the aerospace industry to reduce the cost per pond of payload and become competitive in the international market. Competition from Europe, Japan, and China has reduced this cost to almost a third from 1990 to 2000. This cost has leveled in recent years to an average price of around $12,000/pound of payload. One of NASA's goals is to promote the development of technologies to reduce this cost by a factor of 10 or more Exploration of space, specially manned exploration missions, involves very complex launch and flight vehicles, associated ground support systems, and extensive human support during all phases of the mission. When considering the Space Shuttle Program, we can see that vehicle and ground support systems' processing, operation, and maintenance represent a large percentage of the program cost and time. Reducing operating, processing and maintenance costs will greatly reduce the cost of Exploration programs. The Integrated System Health Management (ISHM) concept is one of the technologies that will help reduce these operating, processing and maintenance costs. ISHM is an integrated health monitoring system applicable to both flight and ground systems. It automatically and autonomously acquires information from sensors and actuators and processes that information using the ISHM-embedded knowledge. As a result, it establishes the health of the system based on the acquired information and its prior knowledge. When this concept is fully implemented, ISHM systems shall be able to perform failure prediction and remediation before actual hard failures occurs, preventing its costly consequences. Data sources, sensors, and their associated data acquisition systems, constitute the foundation of the system. A smart sensing architecture is required to support the acquisition of reliable, high quality data, required by the ISHM. A thorough definition of the smart sensor architectures, their embedded diagnostic agents, and communication protocols need to be established and standardized to allow the embedding and exchange of health information among sensors and ISHM. This workshop is aimed to foster the exchange of ideas and lessons learned between government, industry and academia to aid in the establishment of ISHM (and smart sensors) standards and guidelines as well as to identify present technology gaps that will have to be overcome to successfully achieve this goal.

Perotti, Jose M.↗

Reusable Autonomy

Currently, spacecraft ground systems have a well defined and somewhat standard architecture and operations concept. Based on domain analysis studies of various control centers conducted over the years it is clear that ground systems have core capabilities and functionality that are common across all ground systems. This observation alone supports the realization of reuse. Additionally, spacecraft ground systems are increasing in their ability to do things autonomously. They are being engineered using advanced expert systems technology to provide automated support for operators. A clearer understanding of the possible roles of agent technology is advancing the prospects of greater autonomy for these systems. Many of their functional and management tasks are or could be supported by applied agent technology, the dynamics of the ground system's infrastructure could be monitored by agents, there are intelligent agent-based approaches to user-interfaces, etc. The premise of this paper is that the concepts associated with software reuse, applicable in consideration of classically-engineered ground systems, can be updated to address their application in highly agent-based realizations of future ground systems. As a somewhat simplified example consider the following situation, involving human agents in a ground system context. Let Group A of controllers be working on Mission X. They are responsible for the command, control and health and safety of the Mission X spacecraft. Let us suppose that mission X successfully completes it mission and is turned off. Group A could be dispersed or perhaps move to another Mission Y. In this case there would be reuse of the human agents from Mission X to Mission Y. The Group A agents perform their well-understood functions in a somewhat but related context. There will be a learning or familiarization process that the group A agents go through to make the new context, determined by the new Mission Y, understood. This simplified scenario highlights some of the major issues that need to be addressed when considering the situation where Group A is composed of software-based agents (not their human counterparts) and they migrate from one mission support system to another. This paper will address: - definition of an agent architecture appropriate to support reuse; - identification of non-mission-specific agent capabilities required; - appropriate knowledge representation schemes for mission-specific knowledge; - agent interface with mission-specific knowledge (a type of Learning); development of a fully-operational group of cooperative software agents for ground system support; architecture and operation of a repository of reusable agents that could be the source of intelligent components for realizing an autonomous (or nearly autonomous) agent-based ground system, and an agent-based approach to repository management and operation (an intelligent interface for human use of the repository in a ground-system development activity).

Truszkowski, Walt↗

NASA's satellite relay tracking and data acquisition program

The Tracking and Data Acquisition System (TDAS) is currently being planned to support NASA missions and the Space Station and will serve as a replacement to the present Tracking and Data Relay Satellite System (TDRSS). Its operational date is currently projected for the late 1990s. Near term objectives involve the definition of a TDAS architecture, the development of functional and performance specifications and implementation of a TDRSS-to-TDAS transition plan. The present paper provides an overview of the baseline TDAS architecture and summarizes key ingredients of system and technology studies in progress. In particular, this paper addresses a summary of projected mission requirements for the TDAS era; a characterization of the space segment constellation; use of lasers, 60 GHz, and multibeam 30/20 GHz technologies; ground architecture and operational interfaces; a distributed hardware/software processing concept for more flexible and reliable interfaces, signal processing and operations. Also included is a status summary of the TDAS program plan for the 1984-1990 time frame. Finally, an overview is presented of NASA's current plans to augment the TDRSS to meet the Space Station IOC requirements in the time period 1993-2000.

Schwartz, J. J.↗

Lunar Transportation Facilities and Operations Study, option 1

Throughout the Option I period of the Lunar Transportation Facilities and Operations Study (LTFOS), McDonnell Douglas Space Systems Company - Kennedy Space Center (MDSSC-KSC) provided support to both the Planetary Surface Systems (PSS) Office at the National Aeronautics and Space Administration (NASA) at the Johnson Space Center and to the Flight and Ground Systems Projects Office (Payload Projects Management) at the Kennedy Space Center. The primary objective of the Option I phase of the study was to assist the above NASA centers in developing Space Exploration Initiative (SEI) concepts. MDSSC-KSC conducted three analyses which provided launch and landing detail to the proposed exploration concepts. One analysis, the Lunar Ejecta Assessment, was conducted to determine the effects of launch and landing a vehicle in a dusty environment. A second analysis, the Thermal/Micrometeoroid Protection Trade Study, was refined to determine the impacts that Reference Architecture Option 5A would have on thermal/micrometeoroid protection approaches. The third analysis, the Centaur Prelaunch Procedure Analysis, used a Centaur prelaunch test and checkout flow to identify key considerations that would be important if a Lunar Excursion Vehicle (LEV) was to use an expander cycle liquid oxygen-liquid hydrogen engine. Several 'quick look' assessments were also conducted. One quick look assessment, the Storable Propellant Quick Look Assessment, was conducted to identify design considerations that should be made if storable propellants were to be used instead of liquid oxygen and liquid hydrogen. The LEV Servicer Maintenance Analysis provided an early look at the effort required to maintain an LEV Servicer on the lunar surface. Also, support was provided to the PSS Logistics Manager to develop initial LEV Servicer cost inputs. Consideration was given to the advanced development that must be provided to accomplish a lunar and/or Mars mission. MDSS-KSC also provided support to both MASE and PSS by reviewing and commenting on architecture documents and concept definitions to ensure adequate considerations were given to the launch and landing function of an exploration initiative.

Source record↗

Advancing the practice of systems engineering at JPL

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

process improvement↗

A fault-tolerant multiprocessor architecture for aircraft, volume 1

A fault-tolerant multiprocessor architecture is reported. This architecture, together with a comprehensive information system architecture, has important potential for future aircraft applications. A preliminary definition and assessment of a suitable multiprocessor architecture for such applications is developed.

Smith, T. B.↗

The Habitat Demonstration Unit Project Overview

This paper will describe an overview of the National Aeronautics and Space Administration (NASA) led multi-center Habitat Demonstration Unit (HDU) Project. The HDU project is a "technology-pull" project that integrates technologies and innovations from numerous NASA centers. This project will be used to investigate and validate surface architectures, operations concepts, and requirements definition of various habitation concepts. The first habitation configuration this project will build and test is the Pressurized Excursion Module (PEM). This habitat configuration - the PEM - is based on the Constellation Architecture Scenario 12.1 concept of a vertically oriented habitat module. The HDU project will be tested as part of the 2010 Desert Research and Technologies Simulations (D-RATS) test objectives. The purpose of this project is to develop, integrate, test, and evaluate a habitat configuration in the context of the mission architectures and surface operation concepts. A multi-center approach will be leveraged to build, integrate, and test the PEM through a shared collaborative effort of multiple NASA centers. The HDU project is part of the strategic plan from the Exploration Systems Mission Directorate (ESMD) Directorate Integration Office (DIO) and the Lunar Surface Systems Project Office (LSSPO) to test surface elements in a surface analog environment. The 2010 analog field test will include two Lunar Electric Rovers (LER) and the PEM among other surface demonstration elements. This paper will describe the overall objectives, its various habitat configurations, strategic plan, and technology integration as it pertains to the 2010 and 2011 field analog tests. To accomplish the development of the PEM from conception in June 2009 to rollout for operations in July 2010, the HDU project team is using a set of design standards to define the interfaces between the various systems of PEM and to the payloads, such as the Geology Lab, that those systems will support. Scheduled activities such as early fit-checks and the utilization of a habitat avionics test bed prior to equipment installation into PEM are planned to facilitate the integration process.

Kennedy, Kriss J.↗

The Habitat Demonstration Unit Project

This paper will describe an overview of the NASA-led multi-center Habitat Demonstration Unit (HDU) Project. The HDU project is a technology-pull project that integrates technologies and innovations from numerous NASA centers. This project will be used to investigate and validate surface architectures, operations concepts, and requirements definition. The HDU project will be part of the 2010 Desert Research and Technologies Simulations (DRATS). The purpose of this project is to develop, integrate, test, and evaluate a HDU in the context of the mission architectures and surface operation concepts. This HDU is based on the Constellation Architecture Scenario 12.1 concept of a vertically oriented habitat module. A multi-center approach with be utilized to build, integrate, and test the HDU project through a shared collaborative effort of multiple NASA centers. This project is part of the strategic plan from the ESMD Directorate Integration Office (DIO) and the Lunar Surface Systems Project Office (LSSPO) to test surface elements in a surface analog environment which includes two Lunar Electric Rovers and the HDU during the 2010 analog field test. This paper will describe the overall objectives, its various configurations, strategic plan, and technology integration as it pertains to the 2010 and 2011 field analog tests.

Kennedy, Kriss J.↗

Structural Definition and Mass Estimation of Lunar Surface Habitats for the Lunar Architecture Team Phase 2 (LAT-2) Study

The Lunar Architecture Team Phase 2 study defined and assessed architecture options for a Lunar Outpost at the Moon's South Pole. The Habitation Focus Element Team was responsible for developing concepts for all of the Habitats and pressurized logistics modules particular to each of the architectures, and defined the shapes, volumes and internal layouts considering human factors, surface operations and safety requirements, as well as Lander mass and volume constraints. The Structures Subsystem Team developed structural concepts, sizing estimates and mass estimates for the primary Habitat structure. In these studies, the primary structure was decomposed into a more detailed list of components to be sized to gain greater insight into concept mass contributors. Structural mass estimates were developed that captured the effect of major design parameters such as internal pressure load. Analytical and empirical equations were developed for each structural component identified. Over 20 different hard-shell, hybrid expandable and inflatable soft-shell Habitat and pressurized logistics module concepts were sized and compared to assess structural performance and efficiency during the study. Habitats were developed in three categories; Mini Habs that are removed from the Lander and placed on the Lunar surface, Monolithic habitats that remain on the Lander, and Habitats that are part of the Mobile Lander system. Each category of Habitat resulted in structural concepts with advantages and disadvantages. The same modular shell components could be used for the Mini Hab concept, maximizing commonality and minimizing development costs. Larger Habitats had higher volumetric mass efficiency and floor area than smaller Habitats (whose mass was dominated by fixed items such as domes and frames). Hybrid and pure expandable Habitat structures were very mass-efficient, but the structures technology is less mature, and the ability to efficiently package and deploy internal subsystems remains an open issue.

Dorsey, John T.↗

Open Architecture Synthesis for Intelligent Systems (OASIS)

The concepts and preliminary results for the OASIS testbed which will permit an evolutionary growth with minimum impact to the existing software and hardware environment are presented. Space Station Freedom's data management system is utilized as the application focus for the evaluation of the OASIS concepts. It is concluded that guidelines for the validation and definition of standards for open architectures must be aggressively pursued with attention paid to the integration of these standards with the hardware platforms, graphics interface, and operating system software infrastructure.

Lum, Henry, Jr.↗