Systems engineering, manned space flight.
Systems engineering activities in manned space flight involving design, development, manufacture, test and operation of Mercury, Gemini and Apollo flight systems
Mathews, C. W.↗
SEARCH · Engineering Papers
Results for “Systems Engineering”
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.
Analytical investigation of two hydrogen oxygen rocket engine systems for low-thrust application
Two hydrogen oxygen rocket engine system concepts were analyzed parametrically over a thrust range from 100 to 1000 pounds and a chamber pressure range from 175 to 1000 psia. Both concepts were regeneratively cooled with hydrogen and were pump fed by electric motor driven positive displacement pumps. Electric power was provided by either a turboalternator (turboalternator concept) or some means external to the engine system (auxiliary power concept). The turboalternator concept is discussed. The computer program used to conduct the analyses along with the design characteristics of the major engine system components is described. The feasible design range of the systems over the parametric range of thrust is discussed in terms of allowable chamber pressure. Engine system estimated performance, mass, and dimensional envelope parametric data within the feasible design range are presented.
Scheer, D. D.↗
ISO 9000 and/or Systems Engineering Capability Maturity Model?
For businesses and organizations to remain competitive today they must have processes and systems in place that will allow them to first identify customer needs and then develop products/processes that will meet or exceed the customers needs and expectations. Customer needs, once identified, are normally stated as requirements. Designers can then develop products/processes that will meet these requirements. Several functions, such as quality management and systems engineering management are used to assist product development teams in the development process. Both functions exist in all organizations and both have a similar objective, which is to ensure that developed processes will meet customer requirements. Are efforts in these organizations being duplicated? Are both functions needed by organizations? What are the similarities and differences between the functions listed above? ISO 9000 is an international standard of goods and services. It sets broad requirements for the assurance of quality and for management's involvement. It requires organizations to document the processes and to follow these documented processes. ISO 9000 gives customers assurance that the suppliers have control of the process for product development. Systems engineering can broadly be defined as a discipline that seeks to ensure that all requirements for a system are satisfied throughout the life of the system by preserving their interrelationship. The key activities of systems engineering include requirements analysis, functional analysis/allocation, design synthesis and verification, and system analysis and control. The systems engineering process, when followed properly, will lead to higher quality products, lower cost products, and shorter development cycles. The System Engineering Capability Maturity Model (SE-CMM) will allow companies to measure their system engineering capability and continuously improve those capabilities. ISO 9000 and SE-CMM seem to have a similar objective, which is to document the organization's processes and certify to potential customers the capability of a supplier to control the processes that determine the quality of the product or services being produced. The remaining sections of this report examine the differences and similarities between ISO 9000 and SE-CMM and make recommendations for implementation.
Sampson E. Gholston↗
Hubble Space Telescope systems engineering
The role of systems engineering in the Hubble Space Telescope (HST) development program at NASA Marshall is reviewed. The scientific objectives and overall characteristics of the HST are recalled, and particular attention is given to the early identification and correction of problems in the optical system, the pointing-control system (maneuvering and fine guidance), the rate-gyro assembly, reaction-wheel isolation, the battery reconditioning circuit, and optical cleanliness.
Wojtalik, F. S.↗
Impingement effect of service module reaction control system engine plumes. Results of service module reaction control system plume model force field application to an inflight Skylab mission proximity operation situation with the inflight Skylab response
Plume impingement effects of the service module reaction control system thruster firings were studied to determine if previous flight experience would support the current plume impingement model for the orbiter reaction control system engines. The orbiter reaction control system is used for rotational and translational maneuvers such as those required during rendezvous, braking, docking, and station keeping. Therefore, an understanding of the characteristics and effects of the plume force fields generated by the reaction control system thruster firings were examined to develop the procedures for orbiter/payload proximity operations.
Lobb, J. D., Jr.↗
Systems Engineering for Manned Space Flight
Systems engineering for manned space flight
SYSTEMS ENGINEERING↗
Systems Engineering Tutorial with Case Studies
Due to the ever-growing number of complex technical problems facing our world, a Systems Engineering approach is needed to assist in successful design, build and implementation of solutions. The interdisciplinary technical structure of current systems, technical processes representing System Design, Technical Management and Product Realization are instrumental in the development and integration of new technologies into mainstream applications. This tutorial will demonstrate the application of Systems Engineering tools to these types of problems. Learning objectives include, understanding how to develop and engineer a conceptual system; understand the importance of teams, communication, requirements definition, interface control, and focus on deliverables; useful tools and techniques for each aspect of the System Engineering process including Model Based Systems Engineering which will be touched upon lightly. Some hands-on problems will be pursued especially in requirements development which is always key to a successful project. Case studies will be presented to assist in the learning process.
Systems Engineering↗
Collaborative Systems Engineering in the Ascent Abort-2 Crew Module/Separation Ring Project
Generally speaking, systems engineering (SE) tool-sets face a dilemma balancing power and accessibility. High-powered SE tools (MagicDraw, Cradle, Core, etc.) tend to be specialized and are available only to highly trained Systems Engineers, and/or through the use of a 'back room' developer team making the output products available to the broader team. On the other hand, highly accessible tools (MS Word, Excel, etc.) do not have the power to implement SE in a rigorous manner. NASA has to test all aspects of the new human-rated Orion Multi-Purpose Crew Vehicle spacecraft prior to its first crewed mission. The test program includes uncrewed launch abort flight tests to demonstrate the capability to save the crew in the event that a launch failure occurs. Orion's second abort flight test will be a low-altitude flight test known as "Ascent Abort 2 (AA-2)." This test is currently scheduled to be carried out at Cape Canaveral Air Force Station's Space Launch Complex 46 (SLC-46) in Florida in 2019. NASA's in-house AA-2 Crew Module and Separation Ring (CSR) Team is producing the crew module and separation ring. Operating jointly as both an Advanced Exploration Systems (AES) Project and an Orion Project, the CSR project charter includes development of innovative, streamlined and generally more efficient practices for creation of flight hardware and software. One result of this tasking has been development of a collaborative and data-centric systems engineering environment within the team's shared web environment (Microsoft SharePoint). Through the use of built-in, 'out of the box capabilities' present in MS SharePoint, the CSR Systems Engineering team has created (with some limited developer support) a data-centric architecture for the project's SE implementation, including functional and interface analysis, requirements development and management, risk management, verification planning and management, test results, and end item management. Data elements are linked between data structures so as to define and control relationships between item types, link requirements to parents and children, and link tests to the requirements that they verify. The overall project team integration is increased by also linking SE content to project management content over the project life cycle, including team communication, action items, configuration management, decisional and meeting materials, and life cycle reviews. This presentation will provide an overview of the collaborative SE environment, showing how it provides the power for a number of SE tasks while still providing the accessibility and transparency to allow the full project team to collaborate and succeed. Given the project phase, we'll be able to present a nearly full lifecycle discussion, from concept through verification and approaching delivery.
Systems Engineering environments↗
Study and Design of a Cesium Bombardment Ion Engine System
Cesium bombardment ion engine system design, modification, and testing
Grant, G.↗
Systems Engineering and Integration (SE and I)
Systems engineering and integration topics are presented in viewgraph form. Requirements, risk, redundancy, standards, costs, tests beds, and operations are covered.
Source record↗
Helping System Engineers Bridge the Peaks
In our experience at NASA, system engineers generally follow the Twin Peaks approach when developing safety-critical systems. However, iterations between the peaks require considerable manual, and in some cases duplicate, effort. A significant part of the manual effort stems from the fact that requirements are written in English natural language rather than a formal notation. In this work, we propose an approach that enables system engineers to leverage formal requirements and automated test generation to streamline iterations, effectively "bridging the peaks". The key to the approach is a formal language notation that a) system engineers are comfortable with, b) is supported by a family of automated V&V tools, and c) is semantically rich enough to describe the requirements of interest. We believe the combination of formalizing requirements and providing tool support to automate the iterations will lead to a more efficient Twin Peaks implementation at NASA.
Requirements↗
Model Based Document and Report Generation for Systems Engineering
As Model Based Systems Engineering (MBSE) practices gain adoption, various approaches have been developed in order to simplify and automate the process of generating documents from models. Essentially, all of these techniques can be unified around the concept of producing different views of the model according to the needs of the intended audience. In this paper, we will describe a technique developed at JPL of applying SysML Viewpoints and Views to generate documents and reports. An architecture of model-based view and document generation will be presented, and the necessary extensions to SysML with associated rationale will be explained. A survey of examples will highlight a variety of views that can be generated, and will provide some insight into how collaboration and integration is enabled. We will also describe the basic architecture for the enterprise applications that support this approach.
Architecture↗
Analytical investigation of two hydrogen-oxygen rocket engine systems for low-thrust application
Two hydrogen-oxygen rocket engine system concepts were analyzed parametrically over a thrust range from 100 to 1000 pounds and a chamber pressure range from 175 to 1000 psia. Both concepts were regeneratively cooled with hydrogen and were pump-fed by electric motor driven positive displacement pumps. Electric power was provided by either a turboalternator (turboalternator concept) or some means external to the engine system (auxiliary power concept). The computer program used to conduct the analyses along with the design characteristics of the major engine system components are briefly described. The feasible design range of the systems over the parametric range of thrust is discussed in terms of allowable chamber pressure considering the constraints of thrust chamber cooling and cycle power. Engine system estimated performance, mass, and dimensional envelope parametric data within the feasible design range are presented.
Scheer, D. D.↗
A Model-Based Systems Engineering Journey to Developing a Concept of Operations
Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.
Jeffrey Robert Cohen↗
Engine system assessment study using Martian propellants
A top-level feasibility study was conducted that identified and characterized promising chemical propulsion system designs which use two or more of the following propellant combinations: LOX/H2, LOX/CH4, and LOX/CO. The engine systems examined emphasized the usage of common subsystem/component hardware where possible. In support of this study, numerous mission scenarios were characterized that used various combinations of Earth, lunar, and Mars propellants to establish engine system requirements to assess the promising engine system design concept examined, and to determine overall exploration leverage of such systems compared to state-of-the-art cryogenic (LOX/H2) propulsion systems. Initially in the study, critical propulsion system technologies were assessed. Candidate expander and gas generator cycle LOX/H2/CO, LOX/H2/CH4, and LOX/CO/CH4 engine system designs were parametrically evaluated. From this evaluation baseline, tripropellant Mars Transfer Vehicle (MTV) LOX cooled and bipropellant Lunar Excursion Vehicle (LEV) and Mars Excursion Vehicle (MEV) engine systems were identified. Representative tankage designs for a MTV were also investigated. Re-evaluation of the missions using the baseline engine design showed that in general the slightly lower performance, smaller, lower weight gas generator cycle-based engines required less overall mission Mars and in situ propellant production (ISPP) infrastructure support compared to the larger, heavier, higher performing expander cycle engine systems.
Pelaccio, Dennis↗
Future Model-Based Systems Engineering Vision and Strategy Bridge for NASA
A vision for the future of model-based systems engineering (MBSE) at NASA in 2029 and a strategy bridge towards that future are presented. Strategic thinking and leading change concepts were used to analyze reports and presentations on global trends and visionary thinking about the future of systems and digital engineering. The context, strategic time horizon, stakeholders, strategic challenges, strategic advantages, driving forces, and opportunities were considered. The analysis resulted in a future vision of MBSE that shows what NASA systems engineers and digital machines will do to perform rapid, extraordinary, and unprecedented missions. The NASA systems engineer, in this future vision, works with a global project team in a virtual and collaborative environment, engineers the system, and uses digital approaches as the routine and default way of working. The digital machines provide data-driven and automated mission designs; have a backbone of program and project management, systems engineering, and product life-cycle management; and are a knowledge-sharing infrastructure. The NASA systems engineer and the systems engineering team are envisioned to use digital machines to plan and perform rapid exploration missions, develop a digital twin that lasts across the life cycle, and develop enduring and adaptable systems. NASA has an engineering enterprise and a life-cycle management framework that endure, adapt, and respond. A strategy bridge based on the Baldrige Criteria for Performance Excellence Framework and lessons learned from a recent MBSE initiative illuminates a way forward from today to this desired future. The bridge lays out a strategy for leaders and recommends investments of today for immediate benefits and for benefits in 2029.
model-based systems engineering, digital engineeri↗
Interdisciplinary Interactions During R&D and Early Design of Large Engineered Systems
Designing Large-Scale Complex Engineered Systems (LaCES) such as aircraft and submarines requires the input of thousands of engineers and scientists whose work is proximate in neither time nor space. Comprehensive knowledge of the system is dispersed among specialists whose expertise is in typically one system component or discipline. This study examined the interactive work practices among such specialists seeking to improve engineering practice through a rigorous and theoretical understanding of current practice. This research explored current interdisciplinary practices and perspectives during R&D and early LaCES design and identified why these practices and perspectives prevail and persist. The research design consisted of a three-fold, integrative approach that combined an open-ended survey, semi-structured interviews, and ethnography. Significant empirical data from experienced engineers and scientists in a large engineering organization were obtained and integrated with theories from organization science and engineering. Qualitative analysis was used to obtain a holistic, contextualized understanding. The over-arching finding is that issues related to cognition, organization, and social interrelations mostly dominate interactions across disciplines. Engineering issues, such as the integration of hardware or physics-based models, are not as significant. For example, organization culture is an important underlying factor that guided researchers more toward individual sovereignty over cross-disciplinarity. The organization structure and the engineered system architecture also serve as constraints to the engineering work. Many differences in work practices were observed, including frequency and depth of interactions, definition or co-construction of requirements, clarity or creation of the system architecture, work group proximity, and cognitive challenges. Practitioners are often unaware of these differences resulting in confusion and incorrect assumptions regarding work expectations. Cognitively, the enactment and coconstruction of knowledge are the fundamental tasks of the interdisciplinary interactions. Distributed and collective cognition represent most of the efforts. Argument, ignorance, learning, and creativity are interrelated aspects of the interactions that cause discomfort but yield benefits such as problem mitigation, broader understanding, and improved system design and performance. The quality and quantity of social interrelations are central to all work across disciplines with reciprocity, respectful engagement, and heedful interrelations being significant to the effectiveness of the engineering and scientific work.
McGowan, Anna-Maria Rivas↗
Application of Agile for Systems Engineering, Project Management and Modeling and Lessons Learned
The Systems Engineering team within the Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has been transforming its development processes to be more efficient, robust,and responsive to change and to its stakeholders. To these ends, the Systems Engineering team trialed the integration of agile development techniques into existing and new processes. Agile development methods are well understood within the software development community. Outside ofsoftware development, however, how non-software project management (PM) and systems engineering (SE) teams implement agile development techniques is less well understood. In its transformation efforts, the ExMC SE team focused on three main areas: Improving the project communications among subsystem teams and stakeholders by adopting a scrum-like process, Changing the status and reporting mechanisms to improve schedule coordination between the subsystem team, SE leadership, and ExMC Element leadership, and Unifying the model-based SE workflow to improve understanding of Concepts of Operations across projects.This presentation highlights several of these transformations and what the SE team learned while undergoing the transformation.
S Lumpkins↗