SEARCH · Search NASA

Results for “system engineering system process”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 217 records · Page 12

All sources NASA NTRS DOE OSTI

NASA NTRS1993

Spacecraft systems engineering: An introduction to the process at GSFC

The main objective in systems engineering is to devise a coherent total system design capable of achieving the stated requirements. Requirements should be rigid. However, they should be continuously challenged, rechallenged and/or validated. The systems engineer must specify every requirement in order to design, document, implement and conduct the mission. Each and every requirement must be logically considered, traceable and evaluated through various analysis and trade studies in a total systems design. Margins must be determined to be realistic as well as adequate. The systems engineer must also continuously close the loop and verify system performance against the requirements. The fundamental role of the systems engineer, however, is to engineer, not manage. Yet, in large, complex missions, where more than one systems engineer is required, someone needs to manage the systems engineers, and we call them 'systems managers.' Systems engineering management is an overview function which plans, guides, monitors and controls the technical execution of a project as implemented by the systems engineers. As the project moves on through Phases A and B into Phase C/D, the systems engineering tasks become a small portion of the total effort. The systems management role increases since discipline subsystem engineers are conducting analyses and reviewing test data for final review and acceptance by the systems managers.

Fragomeni, Tony↗

NASA NTRS2011

SOFIA Program SE and I Lessons Learned

Once a "Troubled Project" threatened with cancellation, the Stratospheric Observatory for Infrared Astronomy (SOFIA) Program has overcome many difficult challenges and recently achieved its first light images. To achieve success, SOFIA had to overcome significant deficiencies in fundamental Systems Engineering identified during a major Program restructuring. This presentation will summarize the lessons learn in Systems Engineering on the SOFIA Program. After the Program was reformulated, an initial assessment of Systems Engineering established the scope of the problem and helped to set a list of priorities that needed to be work. A revised Systems Engineering Management Plan (SEMP) was written to address the new Program structure and requirements established in the approved NPR7123.1A. An important result of the "Technical Planning" effort was the decision by the Program and Technical Leadership team to re-phasing the lifecycle into increments. The reformed SOFIA Program Office had to quickly develop and establish several new System Engineering core processes including; Requirements Management, Risk Management, Configuration Management and Data Management. Implementing these processes had to consider the physical and cultural diversity of the SOFIA Program team which includes two Projects spanning two NASA Centers, a major German partnership, and sub-contractors located across the United States and Europe. The SOFIA Program experience represents a creative approach to doing "System Engineering in the middle" while a Program is well established. Many challenges were identified and overcome. The SOFIA example demonstrates it is never too late to benefit from fixing deficiencies in the System Engineering processes.

Ray, Ronald J.↗

NASA NTRS2017

A Framework for Extending the Science Traceability Matrix: Application to the Planned Europa Mission

One of the most critical functions of the systems engineering requirements process for a large multi-instrument science-driven space mission is to successfully communicate customer expectations into a comprehensive and traceable science requirements flowdown. These requirements are essential to communicating the constraints on the scope of the science investigations and clarifying how multiple instruments contribute to a given science goal. They also provide insight into how the science goals of the whole mission are affected by design choices. There is little specific guidance available on best practices for developing this science-driven flowdown. A unified Science Traceability Matrix (USTM) contains a significant amount of information that can be leveraged for that purpose, but the USTM was not designed to directly produce a complete science requirements flowdown. Thus, starting with the principles codified in a USTM, the authors propose a framework that directly maps into the requirements flowdown and supports broader systems engineering processes while retaining its meaning to the science team. This Science Traceability and Alignment Framework, or STAF, defines a set of common definitions and valid relationships to structure communication across the project. In addition, STAF populates a network of information that can be useful to support complex mission analysis activities such as fault protection. This work discusses the highest-level implementation of the STAF, the project-domain or P-STAF, which describes an approach to decomposing customer requirements into science requirements. The planned Europa Mission is used as a case study for the implementation of this framework and its potential benefits to a project.

Susca, Sara↗

NASA NTRS2013

Tailoring Systems Engineering Projects for Small Satellite Missions

NASA maintains excellence in its spaceflight systems by utilizing rigorous engineering processes based on over 50 years of experience. The NASA systems engineering process for flight projects described in NPR 7120.5E was initially developed for major flight projects. The design and development of low-cost small satellite systems does not entail the financial and risk consequences traditionally associated with spaceflight projects. Consequently, an approach is offered to tailoring of the processes such that the small satellite missions will benefit from the engineering rigor without overly burdensome overhead. In this paper we will outline the approaches to tailoring the standard processes for these small missions and describe how it will be applied in a proposed small satellite mission.

Horan, Stephen↗

NASA NTRS2016

A Process for Capturing the Art of Systems Engineering

There is both an art and a science to systems engineering. The science of systems engineering is effectively captured in processes and procedures, but the art is much more elusive. We propose that there is six step process that can be applied to any systems engineering organization to create an environment from which the "art" of that organization can be captured, be allowed to evolve collaboratively and be shared with all members of the organization. This paper details this process as it was applied to NASA Launch Services Program (LSP) Integration Engineering Branch during a pilot program of Confluence, a Commercial Off The Shelf (COTS) wiki tool.

Commercial Off The Shelf↗

NASA NTRS2009

Human Factors Interface with Systems Engineering for NASA Human Spaceflights

This paper summarizes the past and present successes of the Habitability and Human Factors Branch (HHFB) at NASA Johnson Space Center s Space Life Sciences Directorate (SLSD) in including the Human-As-A-System (HAAS) model in many NASA programs and what steps to be taken to integrate the Human-Centered Design Philosophy (HCDP) into NASA s Systems Engineering (SE) process. The HAAS model stresses systems are ultimately designed for the humans; the humans should therefore be considered as a system within the systems. Therefore, the model places strong emphasis on human factors engineering. Since 1987, the HHFB has been engaging with many major NASA programs with much success. The HHFB helped create the NASA Standard 3000 (a human factors engineering practice guide) and the Human Systems Integration Requirements document. These efforts resulted in the HAAS model being included in many NASA programs. As an example, the HAAS model has been successfully introduced into the programmatic and systems engineering structures of the International Space Station Program (ISSP). Success in the ISSP caused other NASA programs to recognize the importance of the HAAS concept. Also due to this success, the HHFB helped update NASA s Systems Engineering Handbook in December 2007 to include HAAS as a recommended practice. Nonetheless, the HAAS model has yet to become an integral part of the NASA SE process. Besides continuing in integrating HAAS into current and future NASA programs, the HHFB will investigate incorporating the Human-Centered Design Philosophy (HCDP) into the NASA SE Handbook. The HCDP goes further than the HAAS model by emphasizing a holistic and iterative human-centered systems design concept.

Wong, Douglas T.↗

NASA NTRS2011

The MSFC Collaborative Engineering Process for Preliminary Design and Concept Definition Studies

This paper describes a collaborative engineering process developed by the Marshall Space Flight Center's Advanced Concepts Office for performing rapid preliminary design and mission concept definition studies for potential future NASA missions. The process has been developed and demonstrated for a broad range of mission studies including human space exploration missions, space transportation system studies and in-space science missions. The paper will describe the design team structure and specialized analytical tools that have been developed to enable a unique rapid design process. The collaborative engineering process consists of integrated analysis approach for mission definition, vehicle definition and system engineering. The relevance of the collaborative process elements to the standard NASA NPR 7120.1 system engineering process will be demonstrated. The study definition process flow for each study discipline will be will be outlined beginning with the study planning process, followed by definition of ground rules and assumptions, definition of study trades, mission analysis and subsystem analyses leading to a standardized set of mission concept study products. The flexibility of the collaborative engineering design process to accommodate a wide range of study objectives from technology definition and requirements definition to preliminary design studies will be addressed. The paper will also describe the applicability of the collaborative engineering process to include an integrated systems analysis approach for evaluating the functional requirements of evolving system technologies and capabilities needed to meet the needs of future NASA programs.

Mulqueen, Jack↗

NASA NTRS1993

Systems engineering and the user: Incorporation of user requirements into the SE process

This paper is organized into four parts. In the Gestation Phase, I describe the process of starting a new mission and establishing its rough boundaries. Next I show how the scientific experiments are selected. Then we enter the Preliminary Design Phase, where we incorporate the scientist's instruments into the systems engineering process. Finally, I show how the Preliminary Design Review (PDR) assures NASA management and the scientists that the scientific requirements have been incorporated into the systems engineering process to everyone's satisfaction.

Naugle, John E.↗

NASA NTRS2017

Dynamic Positioning System (DPS) Risk Analysis Using Probabilistic Risk Assessment (PRA)

The National Aeronautics and Space Administration (NASA) Safety & Mission Assurance (S&MA) directorate at the Johnson Space Center (JSC) has applied its knowledge and experience with Probabilistic Risk Assessment (PRA) to projects in industries ranging from spacecraft to nuclear power plants. PRA is a comprehensive and structured process for analyzing risk in complex engineered systems and/or processes. The PRA process enables the user to identify potential risk contributors such as, hardware and software failure, human error, and external events. Recent developments in the oil and gas industry have presented opportunities for NASA to lend their PRA expertise to both ongoing and developmental projects within the industry. This paper provides an overview of the PRA process and demonstrates how this process was applied in estimating the probability that a Mobile Offshore Drilling Unit (MODU) operating in the Gulf of Mexico and equipped with a generically configured Dynamic Positioning System (DPS) loses location and needs to initiate an emergency disconnect. The PRA described in this paper is intended to be generic such that the vessel meets the general requirements of an International Maritime Organization (IMO) Maritime Safety Committee (MSC)/Circ. 645 Class 3 dynamically positioned vessel. The results of this analysis are not intended to be applied to any specific drilling vessel, although provisions were made to allow the analysis to be configured to a specific vessel if required.

Thigpen, Eric B.↗

NASA NTRS2017

Dynamic Positioning System (DPS) Risk Analysis Using Probabilistic Risk Assessment (PRA)

Thigpen, Eric B.↗

NASA NTRS2005

Monitoring Agents for Assisting NASA Engineers with Shuttle Ground Processing

The Spaceport Processing Systems Branch at NASA Kennedy Space Center has designed, developed, and deployed a rule-based agent to monitor the Space Shuttle's ground processing telemetry stream. The NASA Engineering Shuttle Telemetry Agent increases situational awareness for system and hardware engineers during ground processing of the Shuttle's subsystems. The agent provides autonomous monitoring of the telemetry stream and automatically alerts system engineers when user defined conditions are satisfied. Efficiency and safety are improved through increased automation. Sandia National Labs' Java Expert System Shell is employed as the agent's rule engine. The shell's predicate logic lends itself well to capturing the heuristics and specifying the engineering rules within this domain. The declarative paradigm of the rule-based agent yields a highly modular and scalable design spanning multiple subsystems of the Shuttle. Several hundred monitoring rules have been written thus far with corresponding notifications sent to Shuttle engineers. This chapter discusses the rule-based telemetry agent used for Space Shuttle ground processing. We present the problem domain along with design and development considerations such as information modeling, knowledge capture, and the deployment of the product. We also present ongoing work with other condition monitoring agents.

Semmel, Glenn S.↗

NASA NTRS2016

Assessment of the Orion-SLS Interface Management Process in Achieving the EIA 731.1 Systems Engineering Capability Model Generic Practices Level 3 Criteria

NASA is currently developing the next generation crewed spacecraft and launch vehicle for exploration beyond earth orbit including returning to the Moon and making the transit to Mars. Managing the design integration of major hardware elements of a space transportation system is critical for overcoming both the technical and programmatic challenges in taking a complex system from concept to space operations. An established method of accomplishing this is formal interface management. In this paper we set forth an argument that the interface management process implemented by NASA between the Orion Multi-Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) achieves the Level 3 tier of the EIA 731.1 System Engineering Capability Model (SECM) for Generic Practices. We describe the relevant NASA systems and associated organizations, and define the EIA SECM Level 3 Generic Practices. We then provide evidence for our compliance with those practices. This evidence includes discussions of: NASA Systems Engineering Interface (SE) Management standard process and best practices; the tailoring of that process for implementation on the Orion to SLS interface; changes made over time to improve the tailored process, and; the opportunities to take the resulting lessons learned and propose improvements to our institutional processes and best practices. We compare this evidence against the practices to form the rationale for the declared SECM maturity level.

Jellicorse, John J.↗

NASA NTRS2009

The JSC Engineering Directorate Product Peer Review Process

The JSC Engineering Directorate has developed a Product Peer Review process in support of NASA policies for project management and systems engineering. The process complies with the requirements of NPR 7120.5, NPR 7123.1 and NPR 7150.2 and follows the guidance in NASA/SP-2007-6105. This presentation will give an overview of the process followed by a brief demonstration of an actual peer review, with audience participation.

Jenks, Kenneth C.↗

NASA NTRS1992

Subsonic flight test evaluation of a propulsion system parameter estimation process for the F100 engine

An adaptive-performance-seeking control system which optimizes the quasi-steady-state performance of the F-15 propulsion system is discussed. This paper presents flight- and ground-test evaluations of the propulsion system parameter-estimation process used by the performance seeking control system. The estimator consists of a compact propulsion system model and an extended Kalman filter. The extended Kalman filter estimates five engine component deviation parameters from measured inputs. The compact model uses measurements and Kalman-filter estimates as inputs to predict unmeasured propulsion parameters such as net propulsive force and fan stall margin. The ability to track trends and estimate absolute values of propulsion system parameters was demonstrated. For example, thrust stand results show a good correlation especially in trends between the performance seeking control estimated and measured thrust.

Orme, John S.↗

NASA NTRS1993

Appendix B: Rapid development approaches for system engineering and design

Conventional processes often produce systems which are obsolete before they are fielded. This paper explores some of the reasons for this, and provides a vision of how we can do better. This vision is based on our explorations in improved processes and system/software engineering tools.

Source record↗

NASA NTRS1979

Process Feasibility Study in Support of Silicon Material, Task 1

During this reporting period, major activies were devoted to process system properties, chemical engineering and economic analyses. Analyses of process system properties was continued for materials involved in the alternate processes under consideration for solar cell grade silicon. The following property data are reported for silicon tetrafluoride: critical constants, vapor pressure, heat of varporization, heat capacity, density, surface tension, viscosity, thermal conductivity, heat of formation and Gibb's free energy of formation. Chemical engineering analysis of the BCL process was continued with primary efforts being devoted to the preliminary process design. Status and progress are reported for base case conditions; process flow diagram; reaction chemistry; material and energy balances; and major process equipment design.

Li, K. Y.↗

NASA NTRS2011

Model-Based Systems Engineering for Capturing Mission Architecture System Processes with an Application Case Study - Orion Flight Test 1

Model-based Systems Engineering (MBSE) is an emerging methodology that can be leveraged to enhance many system development processes. MBSE allows for the centralization of an architecture description that would otherwise be stored in various locations and formats, thus simplifying communication among the project stakeholders, inducing commonality in representation, and expediting report generation. This paper outlines the MBSE approach taken to capture the processes of two different, but related, architectures by employing the Systems Modeling Language (SysML) as a standard for architecture description and the modeling tool MagicDraw. The overarching goal of this study was to demonstrate the effectiveness of MBSE as a means of capturing and designing a mission systems architecture. The first portion of the project focused on capturing the necessary system engineering activities that occur when designing, developing, and deploying a mission systems architecture for a space mission. The second part applies activities from the first to an application problem - the system engineering of the Orion Flight Test 1 (OFT-1) End-to-End Information System (EEIS). By modeling the activities required to create a space mission architecture and then implementing those activities in an application problem, the utility of MBSE as an approach to systems engineering can be demonstrated.

Orion Flight Test 1 (OFT-1)↗

NASA NTRS2002

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↗