Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “engineered systems”

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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Management issues in systems engineering

When applied to a system, the doctrine of successive refinement is a divide-and-conquer strategy. Complex systems are sucessively divided into pieces that are less complex, until they are simple enough to be conquered. This decomposition results in several structures for describing the product system and the producing system. These structures play important roles in systems engineering and project management. Many of the remaining sections in this chapter are devoted to describing some of these key structures. Structures that describe the product system include, but are not limited to, the requirements tree, system architecture and certain symbolic information such as system drawings, schematics, and data bases. The structures that describe the producing system include the project's work breakdown, schedules, cost accounts and organization.

Shishko, Robert↗
NASA NTRS1993

Nuclear Engine System Simulation (NESS) version 2.0

The topics are presented in viewgraph form and include the following; nuclear thermal propulsion (NTP) engine system analysis program development; nuclear thermal propulsion engine analysis capability requirements; team resources used to support NESS development; expanded liquid engine simulations (ELES) computer model; ELES verification examples; NESS program development evolution; past NTP ELES analysis code modifications and verifications; general NTP engine system features modeled by NESS; representative NTP expander, gas generator, and bleed engine system cycles modeled by NESS; NESS program overview; NESS program flow logic; enabler (NERVA type) nuclear thermal rocket engine; prismatic fuel elements and supports; reactor fuel and support element parameters; reactor parameters as a function of thrust level; internal shield sizing; and reactor thermal model.

Pelaccio, Dennis G.↗
NASA NTRSDate not supplied

Using Systems Engineering to Develop an Integrated Crew Health and Performance System to Mitigate Risk for Human Exploration Missions

New space exploration missions are currently being designed to take humanity beyond Low EarthOrbit (LEO) to cis-lunar space, the lunar surface, and eventually to Mars. These missions carryincreased risks due to a number of factors, including distance from Earth, exposure to deep spacehazards, reduced capacity and ability to resupply and evacuate, and increased communication delays.As distance from Earth grows and mission length increases, a growing proportion of overall missionrisk can be attributed to the “human system.” Almost twenty years ago, the Institute of Medicine in theUnited States recommended the early and complete integration of the human system into thespacecraft and mission design process to mitigate this increased risk inherent in exploration missions.Exploration missions will require increasing levels of crew self-sufficiency that will challenge thecurrent operational paradigms established in LEO. Enabling progressive Earth independence requiresmanagement of the increasingly complex interactions among spacecraft systems and integration of allthe data and functions that affect human health and performance into one coordinated system – theCrew Health and Performance (CHP) system. This system is a critical spacecraft system that isanalogous to other systems such as propulsion, guidance and navigation, or avionics. Design andintegration of the CHP system requires the evidence-based merger of typically disparate disciplinessuch as medicine, human factors, and physiological support system design, using systems engineering(SE) practices. The approach described here enables spacecraft and mission designers to align thescope of a CHP system with mission specific requirements, decrease risk to the crew, and increase theprobability of mission success.

Kerry Mcguire↗
NASA NTRS2008

Enabling Innovation and Collaboration Across Geography and Culture: A Case Study of NASA's Systems Engineering Community of Practice

In 2004, NASA faced major knowledge sharing challenges due to geographically isolated field centers that inhibited personnel from sharing experiences and ideas. Mission failures and new directions for the agency demanded better collaborative tools. In addition, with the push to send astronauts back to the moon and to Mars, NASA recognized that systems engineering would have to improve across the agency. Of the ten field centers, seven had not built a spacecraft in over 30 years, and had lost systems engineering expertise. The Systems Engineering Community of Practice came together to capture the knowledge of its members using the suite of collaborative tools provided by the NASA Engineering Network (NEN.) The NEN provided a secure collaboration space for over 60 practitioners across the agency to assemble and review a NASA systems engineering handbook. Once the handbook was complete, they used the open community area to disseminate it. This case study explores both the technology and the social networking that made the community possible, describes technological approaches that facilitated rapid setup and low maintenance, provides best practices that other organizations could adopt, and discusses the vision for how this community will continue to collaborate across the field centers to benefit the agency as it continues exploring the solar system.

NEN↗
NASA NTRS1986

Systems Engineering of Electric and Hybrid Vehicles

Technical paper notes systems engineering principles applied to development of electric and hybrid vehicles such that system performance requirements support overall program goal of reduced petroleum consumption. Paper discusses iterative design approach dictated by systems analyses. In addition to obvious peformance parameters of range, acceleration rate, and energy consumption, systems engineering also considers such major factors as cost, safety, reliability, comfort, necessary supporting infrastructure, and availability of materials.

Kurtz, D. W.↗
NASA NTRSDate not supplied

ExMC Systems Engineering Developments

The Exploration Medical Capability (ExMC) Element within the Human Research Program (HRP) applies systems engineering (SE) principles along with the use of Model-Based Systems Engineering (MBSE) tools to identify and communicate the requirements for medical and crew health and performance (CHP) systems. In the past fiscal year, the MBSE approach sought to advance the digital engineering toolset for medical and CHP system representation. These digital artifacts provide enhanced views of the relationships among requirements, standards, functions, and capabilities, to name a few, that is best suited for a user’s objectives. The MBSE tools and SE practices were applied to the development of the revised Earth Independent Medical Operations (EIMO) medical system and the Artemis III and IV CHP System models. In addition, a System of Systems concept was integrated into the EIMO model to facilitate the identification of system interfaces that interact with the medical system. Finally, the ExMC SE team has initiated several efforts to bring operationally relevant digital engineering practices to the Human Health and Performance Directorate (HHPD). This included the development of a pilot program within the directorate to help foster utilization of tools such as MagicDraw for system modeling and Power BI for visualizing extracted data in an easily accessible dashboard format. Additionally, with the increase in complexity of the integration effort for Artemis missions, ExMC has endeavored to bring digital engineering strategies to potentially increase efficiency in review processes. This talk will provide a high-level overview of the ExMC SE team accomplishments since the last Investigators’ Workshop, an introduction to upcoming SE talks, and the ongoing systems engineering work.

systems engineering↗
NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗
NASA NTRS2015

Model-Based Systems Engineering in Concurrent Engineering Centers

Concurrent Engineering Centers (CECs) are specialized facilities with a goal of generating and maturing engineering designs by enabling rapid design iterations. This is accomplished by co-locating a team of experts (either physically or virtually) in a room with a focused design goal and a limited timeline of a week or less. The systems engineer uses a model of the system to capture the relevant interfaces and manage the overall architecture. A single model that integrates other design information and modeling allows the entire team to visualize the concurrent activity and identify conflicts more efficiently, potentially resulting in a systems model that will continue to be used throughout the project lifecycle. Performing systems engineering using such a system model is the definition of model-based systems engineering (MBSE); therefore, CECs evolving their approach to incorporate advances in MBSE are more successful in reducing time and cost needed to meet study goals. This paper surveys space mission CECs that are in the middle of this evolution, and the authors share their experiences in order to promote discussion within the community.

systems engineering↗
NASA NTRS2013

Towards Requirements in Systems Engineering for Aerospace IVHM Design

Health management (HM) technologies have been employed for safety critical system for decades, but a coherent systematic process to integrate HM into the system design is not yet clear. Consequently, in most cases, health management resorts to be an after-thought or 'band-aid' solution. Moreover, limited guidance exists for carrying out systems engineering (SE) on the subject of writing requirements for designs with integrated vehicle health management (IVHM). It is well accepted that requirements are key to developing a successful IVHM system right from the concept stage to development, verification, utilization, and support. However, writing requirements for systems with IVHM capability have unique challenges that require the designers to look beyond their own domains and consider the constraints and specifications of other interlinked systems. In this paper we look at various stages in the SE process and identify activities specific to IVHM design and development. More importantly, several relevant questions are posed that system engineers must address at various design and development stages. Addressing these questions should provide some guidance to systems engineers towards writing IVHM related requirements to ensure that appropriate IVHM functions are built into the system design.

Requirements↗
NASA NTRS1993

Nuclear Engine System Simulation (NESS). Version 2.0: Program user's guide

This Program User's Guide discusses the Nuclear Thermal Propulsion (NTP) engine system design features and capabilities modeled in the Nuclear Engine System Simulation (NESS): Version 2.0 program (referred to as NESS throughout the remainder of this document), as well as its operation. NESS was upgraded to include many new modeling capabilities not available in the original version delivered to NASA LeRC in Dec. 1991, NESS's new features include the following: (1) an improved input format; (2) an advanced solid-core NERVA-type reactor system model (ENABLER 2); (3) a bleed-cycle engine system option; (4) an axial-turbopump design option; (5) an automated pump-out turbopump assembly sizing option; (6) an off-design gas generator engine cycle design option; (7) updated hydrogen properties; (8) an improved output format; and (9) personal computer operation capability. Sample design cases are presented in the user's guide that demonstrate many of the new features associated with this upgraded version of NESS, as well as design modeling features associated with the original version of NESS.

Pelaccio, Dennis G.↗
NASA NTRSDate not supplied

Using Systems Engineering to Develop an Integrated Crew Health and Performance System to Mitigate Risk for Human Exploration Missions

New space exploration missions are currently being designed to take humanity beyond low Earth orbit (LEO) to cis-lunar space, the lunar surface, and eventually to Mars. These missions carry increased risks due to a number of factors, including distance from Earth, exposure to deep space hazards, reduced capacity and ability to resupply and evacuate, and increased communication delays. As distance from Earth grows and mission length increases, a growing proportion of mission risk can be attributed to the “human system.” Almost twenty years ago, the Institute of Medicine in the United States recommended the early and complete integration of the human system into the spacecraft and mission design process to mitigate this increased risk inherent in exploration missions. Exploration missions will require increasing levels of crew self-sufficiency that will challenge the current operational paradigms established in LEO. Enabling progressive Earth independence requires management of the increasingly complex interactions among spacecraft systems and integration of all the data and functions that affect human health and performance into one coordinated system –the Crew Health and Performance (CHP) system. This system is a critical spacecraft system that is analogous to other systems such as propulsion, guidance and navigation, or avionics. Design and integration of the CHP system requires the evidence-based merger of typically disparate disciplines such as medicine, human factors, and life support system design, using systems engineering (SE) practices. SE provides traceability of spacecraft requirements and enables reliable and repeatable trade space analysis of the many competing options for hardware and software to be included in the mission architecture. The approach described here enables spacecraft and mission designers to align the scope of a CHP system with mission specific requirements, decrease risk to the crew, and increase the probability of mission success.

Kerry McGuire↗
NASA NTRS1987

A computer simulator for development of engineering system design methodologies

A computer program designed to simulate and improve engineering system design methodology is described. The simulator mimics the qualitative behavior and data couplings occurring among the subsystems of a complex engineering system. It eliminates the engineering analyses in the subsystems by replacing them with judiciously chosen analytical functions. With the cost of analysis eliminated, the simulator is used for experimentation with a large variety of candidate algorithms for multilevel design optimization to choose the best ones for the actual application. Thus, the simulator serves as a development tool for multilevel design optimization strategy. The simulator concept, implementation, and status are described and illustrated with examples.

Padula, S. L.↗
DOE OSTI2025

Capturing Historic Reliability Performance Through Graph Databases: A Model Based System Engineering Approach

With the goal of improving the performance and reliability of high dependable technological systems such as nuclear power plants, advanced monitoring and health management systems are employed to inform system engineers on observed degradation processes and anomalous behaviors of assets and components. This information is captured in the form of large amount of data which can be heterogenous in nature (e.g., numeric, textual). Such large data availability poses challenges when system engineers are required to parse and analyze them in order to track historic reliability performance of assets and components. This paper tackles directly this challenge by providing means to organize data in the form of a graph: a knowledge graph. The presented approach distinguish itself from current knowledge graph-based methods by the fact that model-based system engineering (MBSE) models are used to “put data into context”. In particular, MBSE models are used as skeleton of a knowledge graph; numeric and textual data elements, once processed, are associated to MBSE model elements. Thus, a knowledge graph captures both system architecture (though MBSE models) and health/performance data. Such feature opens the door to new data analytics methods designed to identify causal relations between observed phenomena.

97 - MATHEMATICS AND COMPUTING↗
NASA NTRSDate not supplied

Lessons Learned in Systems Engineering Availability and Recommendations for Mission Technical Leaders

In spaceflight missions at Goddard Space Flight Center (GSFC), the Mission System Engineer (MSE) is the technical leader of the overall engineering team and also is the Independent Engineering Technical Authority. The responsibility of this role includes the definition of the mission design architecture, concept of operations, and mission requirements, management of risk throughout the development, and verification and validation of the final system performance and function amongst other duties. This responsibility inherently requires time management, enabling focus on a balanced development with appropriate risk. Time is the most valuable resource of the MSE. The system engineer’s availability to interact with the development team (often product or component design leads and technicians, often in different worksites) to discover and mitigate mission risks during development is key to mission success. This paper presents examples from Lunar Reconnaissance Orbiter, Landsat 9, and Neutron star Interior Composition ExploreR (NICER) which represent in-house and out-of-house hardware builds. These examples demonstrate how interactions between the Mission Systems Engineers and other project and partner engineers result in discovery of critical risks, leading to early mitigation with significant cost and performance savings. These three missions would have suffered test failures or on-orbit failures had their MSEs not set aside time to visit engineers and technicians that were working on key pieces of space flight hardware. Availability is more than just time; it is openness to listen to concerns and questions. It begins by building a level of trust in the team that it is safe to ask questions or share concerns without the fear of blame or additional workload. It also requires enabling informal conversations (over lunch, coffee, in the clean room, or at the team members desk, etc.) where key information can be exchanged, and team members may even provide an easy-to-implement mitigation idea for another subsystem. Availability is a highly valuable commodity and completely non-obvious to protect and optimize. The natural tendency of engineers is to keep themselves busy with solving problems that they know about. This paper is encouraging MSEs to resist this tendency to try and solve all the complex problems themselves and actively devote daily time to learning and solving problems that are found with informal communications with other team members.

Lessons Learned↗
NASA NTRS2016

Application of Model-Based Systems Engineering for the Development of the Asteroid Redirect Robotic Mission

Model-Based Systems Engineering (MBSE) can augment existing Systems Engineering (SE) processes to more efficiently deliver enhanced products over the project life cycle. Using a multi-user accessible System Model, MBSE has been successfully deployed for the conceptual and preliminary design development of the Asteroid Redirect Robotic Mission (ARRM). The paper provides an overview and examples of the targeted MBSE deployment for development of the mission operational concept, system description, and functional requirements. The paper also includes description of the challenges and lessons learned.

Sindiy, Oleg V.↗