Search NASA⌕ Search

SEARCH · Search NASA

Results for “System Engineering Processes”

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 NTRSDate not supplied

System-Theoretic Analysis of Unsafe Collaborative Control in Teaming Systems

The interactions that occur in human-teaming are inspiring novel aerospace designs aimed at improving how humans and machines, or multiple machines, work together. Unfortunately, current Systems Engineering processes are ill-equipped to handle these complex relationships and are unable to design and assure the safety for these systems. To close part of this gap, this paper introduces a novel system-theoretic analytical process to identify unsafe collaborative control actions. It is part of a broader set of techniques that extend the state-of-the-art in hazard analysis, System Theoretic Process Analysis (STPA), to systematically address collaboration. The method rigorously expresses the different ways multiple commands may be unsafe together. Using Systems Theory, it employs abstraction to manage the combinatorial complexity in enumerating control contributions from multiple collaborating components. An algorithm integrates these concepts into an end-to-end process and is supported by automation to enumerate, refine, prune, and prioritize unsafe combinations of control actions. The output of the method feeds the specification of system requirements to implement safety-guided design starting early in concept development. The process is demonstrated on a manned-unmanned aircraft teaming case study and finds new causal factors that were not previously found in a past hazard analysis of the same system.

System Safety↗
NASA NTRS2022

FY22 X-Hab: Colorado School of Mines: Planetary Resource & In-Situ Material Habitat Outfitting for Space Exploration (PRISM-HOUSE)

The Colorado School of Mines (CSM) was awarded a project under the Moon to Mars eXploration Systems and Habitation (M2M X-Hab) Academic Innovation Challenge on June 10, 2021 for the proposed Planetary Resource & In-Situ Material Habitat Outfitting for Space Exploration (PRISM-HOUSE) lunar habitat system. The project deliverables have been executed concurrently with coursework in the CSM Space Resources program, specifically for the Space Resources Project I & II classes. A team was established in the fall semester of 2021 and a Systems Engineering process was followed to brainstorm initial concepts, determine objectives, flow down top-level requirements, and identify areas for which the project could best further the understanding of the overall system through targeted detailed design and design evaluation testing. This report summarizes the overall project, as well as specific work completed in the spring semester of 2022. PRISM-HOUSE is a lunar habitat system that is deployed on the lunar surface robotically and supports safe, long-term human occupancy while maximizing the use of in-situ resources and minimizing the mass of supplies and equipment that must be delivered from Earth. In this report, the team provides an overview and description of the objectives, the system, and how the current design was selected from various alternatives, as well as the resulting products of systems engineering tasks such as product and specification trees and flow-down requirements. A review of current risks and planned mitigation are reviewed. Four key PRISM-HOUSE systems are explored: the inflatable Habitat, External Structures & Environmental Protection (ESEP), Human Interior Goods (HIG), and ECLSS & Remote Outfitting (E&RO); for each, the team provides a detailed system description and an overview of analyses performed supporting final design, followed by a review of each Design Evaluation Test (DET) performed and resulting conclusions. The report closes with a suggestion of next steps.

Peter Corwin↗
NASA NTRS2016

Functional Fault Model Development Process to Support Design Analysis and Operational Assessment

A functional fault model (FFM) is an abstract representation of the failure space of a givensystem. As such, it simulates the propagation of failure effects along paths between the origin ofthe system failure modes and points within the system capable of observing the failure effects. Asa result, FFMs may be used to diagnose the presence of failures in the modeled system. FFMsnecessarily contain a significant amount of information about the design, operations, and failuremodes and effects. One of the important benefits of FFMs is that they may be qualitative, ratherthan quantitative and, as a result, may be implemented early in the design process when there ismore potential to positively impact the system design. FFMs may therefore be developed andmatured throughout the monitored system's design process and may subsequently be used toprovide real-time diagnostic assessments that support system operations. This paper provides anoverview of a generalized NASA process that is being used to develop and apply FFMs. FFMtechnology has been evolving for more than 25 years. The FFM development process presented inthis paper was refined during NASA's Ares I, Space Launch System, and Ground SystemsDevelopment and Operations programs (i.e., from about 2007 to the present). Process refinementtook place as new modeling, analysis, and verification tools were created to enhance FFMcapabilities. In this paper, standard elements of a model development process (i.e., knowledgeacquisition, conceptual design, implementation & verification, and application) are describedwithin the context of FFMs. Further, newer tools and analytical capabilities that may benefit thebroader systems engineering process are identified and briefly described. The discussion isintended as a high-level guide for future FFM modelers.

Melcher, Kevin J.↗
NASA NTRSDate not supplied

Adopting an Objectives-Driven Assurance Case Approach for Achieving Space Flight Mission Planetary Protection Objectives

Traditionally, NASA has utilized prescriptive technical and process requirements to ensure safety and mission assurance performance objectives for space flight missions are achieved. While prescriptive re-quirements may be easier to communicate and manage throughout the systems engineering process, the highly-constrained nature of prescriptive requirements can limit the ability to take advantage of cost-saving opportunities and offer limited ability to explore other options or alternative designs, processes, and methods. It can also be difficult to develop prescriptive requirements for objectives that are prob-abilistic in nature or that cannot be satisfied by direct verification. In contrast, the development of an assurance case allows for a compelling, comprehensible, and valid argument to be developed with support-ing evidence that shows safety and mission assurance objectives have been satisfied. Analogous to how patent applications are constructed for inventions, an assurance case has a high-level claim of meeting a safety and mission assurance objective, followed by a more specific set of sub-claims and technical evidence which supports the claims. The objectives-driven assurance case approach allows for a better understand-ing and exploration of the trade space, more flexibility to balance trades, and the ability to realize and implement technical and process innovations for resource, time, and cost savings. The assurance case is a living case that evolves over the entire program life cycle. Recently, NASA’s Office of Planetary Pro-tection (OPP) has adopted the assurance case approach as an acceptable methodology for demonstrating avoidance of contamination of target solar system bodies explored by NASA space flight missions. This methodology has been incorporated into NASA’s new technical standard for planetary protection and is currently being utilized by the Mars Sample Return campaign for safe sample containment during sample return. This presentation will explore the development and implementation of an assurance case approach in the context of planetary protection, the shift from prescriptive requirements and the ongoing culture change in the technical community, and the support and guidance from NASA’s OPP in adopting the assurance case approach for achieving planetary protection objectives on NASA’s space flight missions.

Elaine Seasly↗
NASA NTRS2007

An Airborne Communications Roadmap for the U.S. Federal Air Marshal Service: Overview and Status

Following the events of September 11, 2001, the responsibilities, operations and numbers of the U.S. Federal Air Marshal Service (FAMS) wer e greatly expanded. With this expansion, new critical research and te chnology needs were identified, including the need for air to ground telecommunications capabilities. To address this need, the FAMS has cr eated a working group to develop, deploy and enhance aviation communi cations with respect to security and law enforcement. This paper presents the working group's progress to date in generating a FAMS air-gro und communications roadmap identifying expected communications servic es, technology maturity, and technology gaps over a timeline. The paper includes a communications preliminary requirements summary and syst em performance characteristics needed to meet identified operational needs. The system engineering process utilized is presented beginning with the identification of users, their operational needs and relevant constraints. The operational needs are translated to desired airbor ne communications services. System technical performance requirements associated with the identified services are summarized. In addition, notional communications architectures addressing the requirements are presented. Finally, future plans to identify and assess potential ca ndidate systems and their associated technical architectures, gaps and barriers to implementation are discussed. The paper addresses the cu rrent, near term (within 5 years) and far term (10 years) timeframes for such an airborne communications system.

Martzaklis, Konstantinos S.↗
NASA NTRSDate not supplied

Adopting an Objectives-Driven Assurance Case Approach for Achieving Space Flight Mission Planetary Protection Objectives

Traditionally, the National Aeronautics and Space Administration (NASA) has utilized prescriptive technical and process requirements to ensure safety and mission assurance performance objectives for planetary protection are achieved during space flight missions. While prescriptive requirements may be easier to communicate and manage throughout the systems engineering process, the highly constrained nature of prescriptive requirements can limit the ability to take advantage of cost-saving opportunities and offer limited ability to explore other options or alternative designs, processes, and methods. It can also be difficult to develop prescriptive requirements for objectives that are probabilistic in nature or that cannot be satisfied by direct verification. In contrast, the development of an assurance case allows for a compelling, comprehensible, and valid argument to be developed with supporting evidence that shows safety and mission assurance objectives have been satisfied. Analogous to how patent applications are constructed for inventions, an assurance case has a high-level claim of meeting a safety and mission assurance objective, followed by a more specific set of sub-claims and technical evidence which supports the claims. The objectives-driven assurance case approach allows for a better understanding and exploration of the trade space, more flexibility to balance trades, and the ability to realize and implement technical and process innovations for resource, time, and cost savings. The assurance case is a living case that evolves over the entire program life cycle. Recently, NASA’s Office of Planetary Protection (OPP) has adopted the assurance case approach as an acceptable methodology for demonstrating avoidance of contamination of target solar system bodies explored by NASA space flight missions. This methodology has been incorporated into NASA’s new technical standard for planetary protection and is currently being utilized by the Mars Sample Return campaign for safe sample containment during sample return.

Assurance Case↗
NASA NTRS1991

A generic trade study methodology for the system analysis of regenerative life support systems

The performance of engineering tradeoffs is a key technique in a rigorous system engineering process used to develop advanced regenerative life support technology by NASA Ames Research Center. The trade study methodology consists of several steps that include deriving relevant life support system functional requirements from a given space exploration mission scenario and synthesizing a set of design options to be analyzed during the study. Examples relevant to life support technology are used to describe the trade study methodology.

Bilardo, Vincent J., Jr.↗
NASA NTRS2002

Architecting Systems for Human Space Flight

Human-system interactions have been largely overlooked in the traditional systems engineering process. Awareness of human factors (HF) has increased in the past few years, but the involvement of HF specialists is still often too little and too late. In systems involving long-duration human space flight, it is essential that the human component be properly considered in the initial architectural definition phase, as well as throughout the system design process. HF analysis must include not only the strengths and limitations of humans in general, but the variability between individuals and within an individual over time, and the dynamics of group interactions.

Wocken, Gerald↗
NASA NTRS2002

Second Generation RLV Space Vehicle Concept

NASA has a long history of conducting development programs and projects in a consistent fashion. Systems Engineering within those programs and projects has also followed a given method outlined by such documents as the NASA Systems Engineering Handbook. The relatively new NASA Space Launch Initiative (SLI) is taking a new approach to developing a space vehicle, with innovative management methods as well as new Systems Engineering processes. With the program less than a year into its life cycle, the efficacy of these new processes has yet to be proven or disproven. At $776M for phase 1, SLI represents a major portion of the NASA focus; however, the new processes being incorporated are not reflected in the training provided by NASA to its engineers. The NASA Academy of Program and Project Leadership (APPL) offers core classes in program and project management and systems engineering to NASA employees with the purpose of creating a "knowledge community where ideas, skills, and experiences are exchanged to increase each other's capacity for strong leadership". The SLI program is, in one sense, a combination of a conceptual design program and a technology program. The program as a whole doesn't map into the generic systems engineering project cycle as currently, and for some time, taught. For example, the NASA APPL Systems Engineering training course teaches that the "first step in developing an architecture is to define the external boundaries of the system", which will require definition of the interfaces with other systems and the next step will be to "define all the components that make up the next lower level of the system hierarchy" where fundamental requirements are allocated to each component. Whereas, the SLI technology risk reduction approach develops architecture subsystem technologies prior to developing architectures. The higher level architecture requirements are not allowed to fully develop and undergo decomposition and allocation down to the subsystems before the subsystems must develop allocated requirements based on the highest level of requirements. In the vernacular of the project cycles prior to the mid 1990's, the architecture definition portion of the program appears to be at a generic Phase A stage, while the subsystems are operating at Phase B. Even the management structure of the SLI program is innovative in its approach to Systems Engineering and is not reflected in the APPL training modules. The SLI program has established a Systems Engineering office as an office separate from the architecture development or the subsystem technology development, while that office does have representatives within these other offices. The distributed resources of the Systems Engineering Office are co-located with the respective Project Offices. This template is intended to provide systems engineering as an integrated function at the Program Level. the program management of SLI and the MAT agree that "program/project managers and the systems engineering team must work closely together towards the single objective of delivering quality products that meet the customer needs". This paper will explore the differences between the methods being taught by NASA, which represent decades of ideas, and those currently in practice in SLI. Time will tell if the innovation employed by SLI will prove to be the model of the future. For now, it is suggested that the training of the present exercise the flexibility of recognizing the new processes employed by a major new NASA program.

Bailey, Michelle↗
NASA NTRS2014

Cutting More than Metal: Breaking the Development Cycle

New technology is changing the way we do business at NASA. The ability to use these new tools is made possible by a learning culture able to embrace innovation, flexibility, and prudent risk tolerance, while retaining the hard-won lessons learned of other successes and failures. Technologies such as 3-D manufacturing and structured light scanning are re-shaping the entire product life cycle, from design and analysis, through production, verification, logistics and operations. New fabrication techniques, verification techniques, integrated analysis, and models that follow the hardware from initial concept through operation are reducing the cost and time of building space hardware. Using these technologies to be more efficient, reliable and affordable requires we bring them to a level safe for NASA systems, maintain appropriate rigor in testing and acceptance, and transition new technology. Maximizing these technologies also requires cultural acceptance and understanding and balancing rules with creativity. Evolved systems engineering processes at NASA are increasingly more flexible than they have been in the past, enabling the implementation of new techniques and approaches. This paper provides an overview of NASA Marshall Space Flight Center's new approach to development, as well as examples of how that approach has been incorporated into NASA's Space Launch System (SLS) Program, which counts among its key tenants - safety, affordability, and sustainability. One of the 3D technologies that will be discussed in this paper is the design and testing of various rocket engine components.

Singer, Chris↗
NASA NTRS2011

Systems Engineering Using Heritage Spacecraft Technology: Lessons Learned from Discovery and New Frontiers Deep Space Missions

In the design and development of complex spacecraft missions, project teams frequently assume the use of advanced technology or heritage systems to enable a mission or reduce the overall mission risk and cost. As projects proceed through the development life cycle, increasingly detailed knowledge of the advanced or heritage systems and the system environment identifies unanticipated issues that result in cost overruns or schedule impacts. The Discovery & New Frontiers (D&NF) Program Office recently studied cost overruns and schedule delays resulting from advanced technology or heritage assumptions for 6 D&NF missions. The goal was to identify the underlying causes for the overruns and delays, and to develop practical mitigations to assist the D&NF projects in identifying potential risks and controlling the associated impacts to proposed mission costs and schedules. The study found that the cost and schedule growth did not result from technical hurdles requiring significant technology development. Instead, systems engineering processes did not identify critical issues early enough in the design cycle to ensure project schedules and estimated costs address the inherent risks. In general, the overruns were traceable to: inadequate understanding of the heritage system s behavior within the proposed spacecraft design and mission environment; an insufficient level of experience with the heritage system; or an inadequate scoping of the system-wide impacts necessary to implement the heritage or advanced technology. This presentation summarizes the study s findings and offers suggestions for improving the project s ability to identify and manage the risks inherent in the technology and heritage design solution.

Barley, Bryan↗
NASA NTRS2010

Design and Testing of a Prototype Lunar or Planetary Surface Landing Research Vehicle (LPSLRV)

This handbook describes a two-semester senior design course sponsored by the NASA Office of Education, the Exploration Systems Mission Directorate (ESMD), and the NASA Space Grant Consortium. The course was developed and implemented by the Mechanical and Aerospace Engineering Department (MAE) at Utah State University. The course final outcome is a packaged senior design course that can be readily incorporated into the instructional curriculum at universities across the country. The course materials adhere to the standards of the Accreditation Board for Engineering and Technology (ABET), and is constructed to be relevant to key research areas identified by ESMD. The design project challenged students to apply systems engineering concepts to define research and training requirements for a terrestrial-based lunar landing simulator. This project developed a flying prototype for a Lunar or Planetary Surface Landing Research Vehicle (LPSRV). Per NASA specifications the concept accounts for reduced lunar gravity, and allows the terminal stage of lunar descent to be flown either by remote pilot or autonomously. This free-flying platform was designed to be sufficiently-flexible to allow both sensor evaluation and pilot training. This handbook outlines the course materials, describes the systems engineering processes developed to facilitate design fabrication, integration, and testing. This handbook presents sufficient details of the final design configuration to allow an independent group to reproduce the design. The design evolution and details regarding the verification testing used to characterize the system are presented in a separate project final design report. Details of the experimental apparatus used for system characterization may be found in Appendix F, G, and I of that report. A brief summary of the ground testing and systems verification is also included in Appendix A of this report. Details of the flight tests will be documented in a separate flight test report. This flight test report serves as a complement to the course handbook presented here. This project was extremely ambitious, and achieving all of the design and test objectives was a daunting task. The schedule ran slightly longer than a single academic year with the complete design closure not occurring until early April. Integration and verification testing spilled over into late May and the first flight did not occur until mid to late June. The academic year at Utah State University ended on May 8, 2010. Following the end of the academic year, testing and integration was performed by the faculty advisor, paid research assistants, and volunteer student help

Murphy, Gloria A.↗
NASA NTRS1996

Space Mission Operations Concept

Developing a mission operations concept for a space mission is a system engineering process which involves multiple disciplines, working together to describe, in terms of the operators and the users (recipients of the data from the mission), the operational attributes of the flight and ground elements of the mission. A space mission operations concept emphasizes the way the mission is operated/used.

space mission operations mission concepts systems ↗
NASA NTRS2011

Requirement Assurance: A Verification Process

Requirement Assurance is an act of requirement verification which assures the stakeholder or customer that a product requirement has produced its "as realized product" and has been verified with conclusive evidence. Product requirement verification answers the question, "did the product meet the stated specification, performance, or design documentation?". In order to ensure the system was built correctly, the practicing system engineer must verify each product requirement using verification methods of inspection, analysis, demonstration, or test. The products of these methods are the "verification artifacts" or "closure artifacts" which are the objective evidence needed to prove the product requirements meet the verification success criteria. Institutional direction is given to the System Engineer in NPR 7123.1A NASA Systems Engineering Processes and Requirements with regards to the requirement verification process. In response, the verification methodology offered in this report meets both the institutional process and requirement verification best practices.

Alexander, Michael G.↗
NASA NTRS2017

How Should Life Support Be Modeled and Simulated?

Why do most space life support research groups build and investigate large models for systems simulation? The need for them seems accepted, but are we asking the right questions and solving the real problems? The modeling results leave many questions unanswered. How then should space life support be modeled and simulated? Life support system research and development uses modeling and simulation to study dynamic behavior as part of systems engineering and analysis. It is used to size material flows and buffers and plan contingent operations. A DoD sponsored study used the systems engineering approach to define a set of best practices for modeling and simulation. These best practices describe a systems engineering process of developing and validating requirements, defining and analyzing the model concept, and designing and testing the model. Other general principles for modeling and simulation are presented. Some specific additional advice includes performing a static analysis before developing a dynamic simulation, applying the mass and energy conservation laws, modeling on the appropriate system level, using simplified subsystem representations, designing the model to solve a specific problem, and testing the model on several different problems. Modeling and simulation is necessary in life support design but many problems are outside its scope.

Jones, Harry W.↗
NASA NTRS2006

Validation (not just verification) of Deep Space Missions

ion & Validation (V&V) is a widely recognized and critical systems engineering function. However, the often used definition 'Verification proves the design is right; validation proves it is the right design' is rather vague. And while Verification is a reasonably well standardized systems engineering process, Validation is a far more abstract concept and the rigor and scope applied to it varies widely between organizations and individuals. This is reflected in the findings in recent Mishap Reports for several NASA missions, in which shortfalls in Validation (not just Verification) were cited as root- or contributing-factors in catastrophic mission loss. Furthermore, although there is strong agreement in the community that Test is the preferred method for V&V, many people equate 'V&V' with 'Test', such that Analysis and Modeling aren't given comparable attention. Another strong motivator is a realization that the rapid growth in complexity of deep-space missions (particularly Planetary Landers and Space Observatories given their inherent unknowns) is placing greater demands on systems engineers to 'get it right' with Validation.

verification↗
NASA NTRS2012

Automated Sequence Processor: Something Old, Something New

High productivity required for operations teams to meet schedules Risk must be minimized. Scripting used to automate processes. Scripts perform essential operations functions. Automated Sequence Processor (ASP) was a grass-roots task built to automate the command uplink process System engineering task for ASP revitalization organized. ASP is a set of approximately 200 scripts written in Perl, C Shell, AWK and other scripting languages.. ASP processes/checks/packages non-interactive commands automatically.. Non-interactive commands are guaranteed to be safe and have been checked by hardware or software simulators.. ASP checks that commands are non-interactive.. ASP processes the commands through a command. simulator and then packages them if there are no errors.. ASP must be active 24 hours/day, 7 days/week..

Automated↗
NASA NTRS2001

The Use of Human Modeling of EVA Tasks as a Systems Engineering Tool

Computer-generated human models have been used in aerospace design for a decade. They have come to be highly reliable for worksite analysis of certain types of EVA tasks. In many design environments, this analysis comes after the structural design is largely complete. However, the use of these models as a development tool is gaining acceptance within organizations that practice good systems engineering processes. The design of the United States Propulsion Module for the International Space Station provides an example of this application. The Propulsion Module will provide augmentation to the propulsion capability supplied by the Russian Service Module Zvezda. It is a late addition to the set of modules provided by the United States to the ISS Program, and as a result, faces design challenges that result from the level of immaturity of its integration into the Station. Among these are heat dissipation and physical envelopes. Since the rest of the Station was designed to maximize the use of the cooling system, little margin is available for the addition of another module. The Propulsion Module will attach at the forward end of the Station, and will be between the Orbiter and the rest of ISS. Since cargo must be removed from the Payload Bay and transferred to Station by the Canadarm, there is a potential for protrusions from the module, such as thruster booms, to interfere with robotic operations. These and similar engineering issues must be addressed as part of the development. In the implementation of good system design, all design solutions should be analyzed for compatibility with all affected subsystems. Human modeling has been used in this project to provide rapid input to system trades of design concepts. For example, the placement of radiators and avionics components for optimization of heat dissipation had to be examined for feasibility of EVA translation paths and worksite development. Likewise, the location of and mechanism for the retraction of thruster booms was partly driven by available Orbiter, robotic arm, and other module envelopes; worksite analysis was required for early assessment of task success. Since these trade studies included the EVA analysis as part of the decision criteria, the design had a high degree of assurance of EVA supportability from the outset. This approach contributes greatly to mission success.

Dischinger, H. Charles, Jr.↗