Engineering Papers⌕ Search

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.

At least 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

The OpenSE Cookbook: A Practical, Recipe Based Collection of Patterns, Procedures, and Best Practices for Executable Systems Engineering for the Thirty Meter Telescope

The OpenSE Cookbook is an open-sourced collection of patterns, procedures, and best practices targeted for systems engineers who seek guidance on applying model-based and executable systems engineering (MBSE) using SysML. Its content has emerged from the system level modeling effort on the European Framework Program 6 (FP6) and the Thirty Meter Telescope (TMT). The TMT MBSE approach applied the Executable Systems Engineering Method (ESEM) and the open-source Engineering Environment (OpenMBEE) to specify, analyze, and verify requirements of TMT’s Alignment and Phasing System (APS) and the Narrow Field Infrared Adaptive Optics System (NFIRAOS). In these applications, implicit dependencies are made explicit in a formal model through the use of ESEM, OpenMBEE, and SysML modeling constructs. The value proposition for applying this MBSE approach was to establish precise requirements and fine-grained traceability to system designs, and to verify key requirements beginning early in development. The integration of ESEM and the OpenMBEE tooling infrastructure (providing linked-data and web-operability) is a significant added value for the MBSE approach. The APS is responsible for the overall pre-adaptive optics wavefront quality, using starlight to measure wavefront errors and align the TMT optics. In the formally integrated and executable SysML model, simulations are performed to analyze the impact of changed requirements and verify specified constraints for various operational scenarios. The APS team used several modeling patterns to capture information such as the requirements, the operational scenarios, involved subsystems and their interaction points, the estimated or required time durations, and the mass and power consumption. Adaptive optics systems are designed to sense real-time atmospheric turbulence and correct the telescope’s optical beam to remove its effect. The system model for the adaptive optics operational modes was developed to capture sequence behaviors and operational scenarios to run Monte-Carlo simulations for verifying acquisition time, observing efficiency, and operational behavior requirements. The model is particularly useful for investigating the effect of parallelization, identifying interface issues, and re-ordering sequence acquisition tasks. A former version of the Cookbook (which is now updated to MBSE challenges, goals, and lessons learned) included modeling guidelines and conventions for all system aspects, hierarchy levels, and views, which were developed during for the Active Phasing Experiment (APE), an opto-mechatronical system technology demonstrator for the Extremely Large Telescope (ELT). The Cookbook utilizes the above mentioned system models as real-world case-studies to demonstrate and document the applications of the recipes, providing also instructional examples and addressing the available tooling support. The Cookbook is accompanied by a number of SysML models and aodel libraries which facilitate model authoring and maintenance. The Cookbook covers the different aspects of Systems Engineering such as management of Requirements, Design (behavior and structure), Interfaces, Interdisciplinary Integration, Analysis, Trade Studies, and Technical Resources. This paper presents the background, motivation, architecture, and highlights some key content of the Cookbook. For example, interface management, error budget management, requirements verification, Monte Carlo driven analysis, and timing analysis of operational scenarios. The paper discusses how the capabilities of OpenMBEE contributed significantly to the adoption of executable systems engineering.

Brower, Eric↗
NASA NTRS2018

Using Board Games as Subject Matter for Developing Expertise in Model-Based Systems Engineering

As more organizations transition from traditional document-centric systems engineering to a model-based approach, many are challenged to train their staff in new languages, tools, and methodologies, while managing the expectations of stakeholders and their expected model outcomes. In particular, challenges associated with learning a new modeling language and developing skills in the 'art' of modeling present organizations with formidable obstacles to realizing this transition. This paper hypothesizes that systems engineers may more readily learn how to correctly model with SysML, and develop intuition about the art of modeling and using patterns, if their learning references a commonly and thoroughly-understood subject, such as a board game. This paper presents a case for the use of board games as subject matter for new modelers. It demonstrates the concept with a sample model of Hasbro's popular board game, Monopoly, and discusses the limitations of this approach and potential adaptations that may broaden the applicability of the learned skills to projects. Finally, results from a small feasibility assessment and concepts for more formal study to evaluate the hypothesis are presented.

Model-Based Systems Engineering↗
NASA NTRS1984

Automotive Stirling engine systems development

The objective of the Automotive Stirling Engine (ASE) program is to develop a Stirling engine for automotive use that provides a 30 percent improvement in fuel economy relative to a comparable internal-combustion engine while meeting emissions goals. This paper traces the engine systems' development efforts focusing on: (1) a summary of engine system performance for all Mod I engines; (2) the development, program conducted for the upgraded Mod I; and (3) vehicle systems work conducted to enhance vehicle fuel economy. Problems encountered during the upgraded Mod I test program are discussed. The importance of the EPA driving cycle cold-start penalty and the measures taken to minimize that penalty with the Mod II are also addressed.

Richey, A. E.↗
NASA NTRS2017

NASA Systems Engineering Handbook

The update of this handbook continues the methodology of the previous revision: a top-down compatibility with higher level Agency policy and a bottom-up infusion of guidance from the NASA practitioners in the field. This approach provides the opportunity to obtain best practices from across NASA and bridge the information to the established NASA systems engineering processes and to communicate principles of good practice as well as alternative approaches rather than specify a particular way to accomplish a task. The result embodied in this handbook is a top-level implementation approach on the practice of systems engineering unique to NASA. Material used for updating this handbook has been drawn from many sources, including NPRs, Center systems engineering handbooks and processes, other Agency best practices, and external systems engineering textbooks and guides. This handbook consists of six chapters: (1) an introduction, (2) a systems engineering fundamentals discussion, (3) the NASA program project life cycles, (4) systems engineering processes to get from a concept to a design, (5) systems engineering processes to get from a design to a final product, and (6) crosscutting management processes in systems engineering. The chapters are supplemented by appendices that provide outlines, examples, and further information to illustrate topics in the chapters. The handbook makes extensive use of boxes and figures to define, refine, illustrate, and extend concepts in the chapters.

ENGINEERING MANAGEMENT; HANDBOOKS; MANAGEMENT METH↗
NASA NTRS2006

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

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), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), 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 an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; 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.

systems engineering↗
NASA NTRS2006

Industrial and Systems Engineering Applications in NASA

A viewgraph presentation on the many applications of Industrial and Systems Engineering used for safe NASA missions is shown. The topics include: 1) NASA Information; 2) Industrial Engineering; 3) Systems Engineering; and 4) Major NASA Programs.

Shivers, Charles H.↗
NASA NTRS2003

Systems Engineering Education Development(SEED)Case Study

The Systems Engineering Development Program (SEED) was initiated to help Goddard resolve a Systems Engineering skill shortage. The chronology of events and the experiences of the pilot program are outlined to describe the development of the present program. The program goals are included in order to give a focus on what the developers saw as the program drivers. Lessons learned from a pilot program were incorporated into the present program. This program is constantly learning from its past efforts and looks for continuous improvement. We list several future ideas for improvement and change.

Bagg, Thomas C., III↗
NASA NTRS2012

Tailoring Systems Engineering Processes in a Conceptual Design Environment: A Case Study at NASA Marshall Spaceflight Center's ACO

This paper provides an overview of Systems Engineering as it is applied in a conceptual design space systems department at the National Aeronautics and Space Administration (NASA) Marshall Spaceflight Center (MSFC) Advanced Concepts Office (ACO). Engineering work performed in the NASA MFSC's ACO is targeted toward the Exploratory Research and Concepts Development life cycle stages, as defined in the International Council on Systems Engineering (INCOSE) System Engineering Handbook. This paper addresses three ACO Systems Engineering tools that correspond to three INCOSE Technical Processes: Stakeholder Requirements Definition, Requirements Analysis, and Integration, as well as one Project Process Risk Management. These processes are used to facilitate, streamline, and manage systems engineering processes tailored for the earliest two life cycle stages, which is the environment in which ACO engineers work. The role of systems engineers and systems engineering as performed in ACO is explored in this paper. The need for tailoring Systems Engineering processes, tools, and products in the ever-changing engineering services ACO provides to its customers is addressed.

Mulqueen, John↗
NASA NTRS1993

SSME engine system integration of the alternate turbopump program

The effect of the engine level integration of the alternate High Pressure Oxidizer Turbopump (HPOTP) on the performance of the Space Shuttle Main Engine (SSME) is examined with reference to the results of the current engine system ground test data analysis. In particular, attention is given to the observed steady state and transient mainstage engine system effects with respect to various engine hardware combinations. It is concluded that none of the engine system concerns eliminate the turbomump from consideration as a permanent addition to the flight program pending certification.

Sander, E. J.↗
NASA NTRSDate not supplied

A Case Study on the Challenges and Opportunities for the Deployment of PHM Capabilities in Existing Engineering Systems

The field of Prognostics and Health Management (PHM) of engineering systems has experienced considerable growth over the last decade. From benefits associated with faster and more powerful hardware in the form of wireless sensors, edge devices, and general computing capabilities (GPU’s and cloud computing), to development of powerful algorithms for anomaly detection and remaining useful life (RUL) estimation, the number of engineering systems featuring advanced diagnostics and prognostics capabilities continues to grow at an increasingly faster pace. However, the deployment of PHM capabilities as part of the upgrade of existing engineering systems presents multiple challenges to the PHM practitioner charged with retrofitting such systems. Issues include a lack of specific instrumentation needed to capture the signals of interest; insufficient data and sampling rates required for fault detection and diagnosis, and for detection of failure/degradation indicators; and difficulties in the identification of a system’s nominal behavior as a result of age induced degradation. Today’s PHM practitioner must be able to quickly identify and assess these types of issues to effectively evaluate and select the optimal PHM strategies required to achieve the desired results. This paper presents results from the preliminary evaluation of the High-Pressure Gas Facility (HPGF) infrastructure at NASA’s Stennis Space Center in Hancock County, Mississippi. This evaluation is part of a feasibility study conducted prior to the deployment of prognostics and diagnostics capabilities in the pumps skids of the liquid nitrogen (LN2) system of the HPGF.

Condition Based Maintenance↗
NASA NTRS2016

Expanded Guidance for NASA Systems Engineering. Volume 2: Crosscutting Topics, Special Topics, and Appendices

Historically, most successful NASA projects have depended on effectively blending project management, systems engineering, and technical expertise among NASA, contractors, and third parties. Underlying these successes are a variety of agreements (e.g., contract, memorandum of understanding, grant, cooperative agreement) between NASA organizations or between NASA and other Government agencies, Government organizations, companies, universities, research laboratories, and so on. To simplify the discussions, the term "contract" is used to encompass these agreements. This section focuses on the NASA systems engineering activities pertinent to awarding a contract, managing contract performance, and completing a contract. In particular, NASA systems engineering interfaces to the procurement process are covered, since the NASA engineering technical team plays a key role in the development and evaluation of contract documentation. Contractors and third parties perform activities that supplement (or substitute for) the NASA project technical team accomplishment of the NASA common systems engineering technical process activities and requirements outlined in this guide. Since contractors might be involved in any part of the systems engineering life cycle, the NASA project technical team needs to know how to prepare for, allocate or perform, and implement surveillance of technical activities that are allocated to contractors.

Steven R Hirshorn↗
NASA NTRS2000

Applying Technology Ranking and Systems Engineering in Advanced Life Support

According to the Advanced Life Support (ALS) Program Plan, the Systems Modeling and Analysis Project (SMAP) has two important tasks: 1) prioritizing investments in ALS Research and Technology Development (R&TD), and 2) guiding the evolution of ALS systems. Investments could be prioritized simply by independently ranking different technologies, but we should also consider a technology's impact on system design. Guiding future ALS systems will require SMAP to consider many aspects of systems engineering. R&TD investments can be prioritized using familiar methods for ranking technology. The first step is gathering data on technology performance, safety, readiness level, and cost. Then the technologies are ranked using metrics or by decision analysis using net present economic value. The R&TD portfolio can be optimized to provide the maximum expected payoff in the face of uncertain future events. But more is needed. The optimum ALS system can not be designed simply by selecting the best technology for each predefined subsystem. Incorporating a new technology, such as food plants, can change the specifications of other subsystems, such as air regeneration. Systems must be designed top-down starting from system objectives, not bottom-up from selected technologies. The familiar top-down systems engineering process includes defining mission objectives, mission design, system specification, technology analysis, preliminary design, and detail design. Technology selection is only one part of systems analysis and engineering, and it is strongly related to the subsystem definitions. ALS systems should be designed using top-down systems engineering. R&TD technology selection should consider how the technology affects ALS system design. Technology ranking is useful but it is only a small part of systems engineering.

Jones, Harry↗
NASA NTRS2008

Engineering America's Current and Future Space Transportation Systems: 50 Years of Systems Engineering Innovation for Sustainable Exploration

Over the past 50 years, the National Aeronautics and Space Administration (NASA) has delivered space transportation solutions for America's complex missions, ranging from scientific payloads that expand knowledge, such as the Hubble Space Telescope, to astronauts and lunar rovers destined for voyages to the Moon. Currently, the venerable Space Shuttle, which has been in service since 1981, provides the United States' (U.S.) capability for both crew and heavy cargo to low-Earth orbit to' construct the International Space Station, before the Shuttle is retired in 2010. In the next decade, NASA will replace this system with a duo of launch vehicles: the Ares I Crew Launch Vehicle and the Ares V Cargo Launch Vehicle (Figure 1). The goals for this new system include increased safety and reliability coupled with lower operations costs that promote sustainable space exploration for decades to come. The Ares I will loft the Orion Crew Exploration Vehicle, while the heavy-lift Ares V will carry the Altair Lunar Lander and the equipment and supplies needed to construct a lunar outpost for a new generation of human and robotic space pioneers. This paper will provide details of the in-house systems engineering and vehicle integration work now being performed for the Ares I and planned for the Ares V. It will give an overview of the Ares I system-level test activities, such as the ground vibration testing that will be conducted in the Marshall Center's Dynamic Test Stand to verify the integrated vehicle stack's structural integrity and to validate computer modeling and simulation (Figure 2), as well as the main propulsion test article analysis to be conducted in the Static Test Stand. These activities also will help prove and refine mission concepts of operation, while supporting the spectrum of design and development work being performed by Marshall's Engineering Directorate, ranging from launch vehicles and lunar rovers to scientific spacecraft and associated experiments. Ultimately, fielding a robust space transportation solution that will carry international explorers and essential payloads will pave the way for a new century of scientific discovery beyond planet Earth.

Dmbacher, Daniel L.↗
NASA NTRS2017

NASA's Robotic Mining Competition Provides Undergraduates Full Life Cycle Systems Engineering Experience

NASA has held an annual robotic mining competition for teams of university/college students since 2010. This competition is yearlong, suitable for a senior university engineering capstone project. It encompasses the full project life cycle from ideation of a robot design, through tele-operation of the robot collecting regolith in simulated Mars conditions, to disposal of the robot systems after the competition. A major required element for this competition is a Systems Engineering Paper in which each team describes the systems engineering approaches used on their project. The score for the Systems Engineering Paper contributes 25% towards the team’s score for the competition’s grand prize. The required use of systems engineering on the project by this competition introduces the students to an intense practical application of systems engineering throughout a full project life cycle.

Stecklein, Jonette↗
NASA NTRS2012

Semantically-Rigorous Systems Engineering Modeling Using Sysml and OWL

The Systems Modeling Language (SysML) has found wide acceptance as a standard graphical notation for the domain of systems engineering. SysML subsets and extends the Unified Modeling Language (UML) to define conventions for expressing structural, behavioral, and analytical elements, and relationships among them. SysML-enabled modeling tools are available from multiple providers, and have been used for diverse projects in military aerospace, scientific exploration, and civil engineering. The Web Ontology Language (OWL) has found wide acceptance as a standard notation for knowledge representation. OWL-enabled modeling tools are available from multiple providers, as well as auxiliary assets such as reasoners and application programming interface libraries, etc. OWL has been applied to diverse projects in a wide array of fields. While the emphasis in SysML is on notation, SysML inherits (from UML) a semantic foundation that provides for limited reasoning and analysis. UML's partial formalization (FUML), however, does not cover the full semantics of SysML, which is a substantial impediment to developing high confidence in the soundness of any conclusions drawn therefrom. OWL, by contrast, was developed from the beginning on formal logical principles, and consequently provides strong support for verification of consistency and satisfiability, extraction of entailments, conjunctive query answering, etc. This emphasis on formal logic is counterbalanced by the absence of any graphical notation conventions in the OWL standards. Consequently, OWL has had only limited adoption in systems engineering. The complementary strengths and weaknesses of SysML and OWL motivate an interest in combining them in such a way that we can benefit from the attractive graphical notation of SysML and the formal reasoning of OWL. This paper describes an approach to achieving that combination.

Web Ontology Language (OWL)↗
NASA NTRS2018

Using Board Games as Subject Matter for Developing Expertise in Model-Based Systems Engineering

As more organizations transition from traditional document-centric systems engineering to a model-based approach, many are challenged to train their staff in new languages, tools, and methodologies, and manage the expectations of stakeholders and their expected model outcomes. In particular, challenges associated with learning a new modeling language and developing skills in the 'art' of modeling present organizations with formidable obstacles to realizing this transition. This paper hypothesizes that systems engineers may more readily learn how to correctly model with SysML, and develop intuition about the art of modeling and using patterns, if their learning references a commonly and thoroughly-understood subject matter, such as a board game. This paper presents a case for the use of board games as subject matter for new modelers, demonstrates the concept with a sample model of Hasbro's popular board game, Monopoly, and discusses the limitations of this approach and potential adaptations that may broaden the applicability of the learned skills to projects.

Systems Engineering↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗