Search NASA⌕ Search

SEARCH · Search NASA

Results for “NPR 7123.1”

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 19 records

Multi-Center Implementation of NPR 7123.1A: A Collaborative Effort

Collaboration efforts between MSFC and GRC Engineering Directorates to implement the NASA Systems Engineering (SE) Engine have expanded over the past year to include other NASA Centers. Sharing information on designing, developing, and deploying SE processes has sparked further interest based on the realization that there is relative consistency in implementing SE processes at the institutional level. This presentation will provide a status on the ongoing multi-center collaboration and provide insight into how these NPR 7123.1A SE-aligned directives are being implemented and managed to better support the needs of NASA programs and projects. NPR 7123.1A, NASA Systems Engineering Processes and Requirements, was released on March 26, 2007 to clearly articulate and establish the requirements on the implementing organization for performing, supporting, and evaluating SE activities. In early 2009, MSFC and GRC Engineering Directorates undertook a collaborative opportunity to share their research and work associated with developing, updating and revising their SE process policy to comply and align with NPR 7123.1A. The goal is to develop instructions, checklists, templates, and procedures for each of the 17 SE process requirements so that systems engineers will be a position to define work that is process-driven. Greater efficiency and more effective technical management will be achieved due to consistency and repeatability of SE process implementation across and throughout each of the NASA centers. An added benefit will be to encourage NASA centers to pursue and collaborate on joint projects as a result of using common or similar processes, methods, tools, and techniques.

Hall, Phillip B.↗

NASA Risk Management Handbook

The purpose of this handbook is to provide guidance for implementing the Risk Management (RM) requirements of NASA Procedural Requirements (NPR) document NPR 8000.4A, Agency Risk Management Procedural Requirements [1], with a specific focus on programs and projects, and applying to each level of the NASA organizational hierarchy as requirements flow down. This handbook supports RM application within the NASA systems engineering process, and is a complement to the guidance contained in NASA/SP-2007-6105, NASA Systems Engineering Handbook [2]. Specifically, this handbook provides guidance that is applicable to the common technical processes of Technical Risk Management and Decision Analysis established by NPR 7123.1A, NASA Systems Engineering Process and Requirements [3]. These processes are part of the \Systems Engineering Engine. (Figure 1) that is used to drive the development of the system and associated work products to satisfy stakeholder expectations in all mission execution domains, including safety, technical, cost, and schedule. Like NPR 7123.1A, NPR 8000.4A is a discipline-oriented NPR that intersects with product-oriented NPRs such as NPR 7120.5D, NASA Space Flight Program and Project Management Requirements [4]; NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements [5]; and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements [6]. In much the same way that the NASA Systems Engineering Handbook is intended to provide guidance on the implementation of NPR 7123.1A, this handbook is intended to provide guidance on the implementation of NPR 8000.4A. 1.2 Scope and Depth This handbook provides guidance for conducting RM in the context of NASA program and project life cycles, which produce derived requirements in accordance with existing systems engineering practices that flow down through the NASA organizational hierarchy. The guidance in this handbook is not meant to be prescriptive. Instead, it is meant to be general enough, and contain a sufficient diversity of examples, to enable the reader to adapt the methods as needed to the particular risk management issues that he or she faces. The handbook highlights major issues to consider when managing programs and projects in the presence of potentially significant uncertainty, so that the user is better able to recognize and avoid pitfalls that might otherwise be experienced.

Dezfuli, Homayoon↗

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 Human Systems Integration Handbook

This handbook is intended to provide general guidance and information on Human Systems Integration (HSI) for the NASA community and the applicability of HSI to NASA programs and projects. The primary goals are to increase awareness and consistency across the Agency, advance the practice and implementation of HSI principles, and provide invaluable information and guidance to HSI practitioners in the performance of their duties. Specific aims of this handbook are to define HSI, illustrate the value of HSI in programmatic decisions, demonstrate how HSI fits into the NASA project life cycle process, describe how HSI applies across all three NASA Technical Authorities, provide guidance on HSI processes and products, and provide helpful information on HSI resources within the NASA community. Largely within the engineering community, a system is thought of as the integration or assemblance of hardware and software that together perform a function. HSI considers a system to be the integration of hardware, software, humans, data, and processes, where the human in HSI refers to all personnel involved with a given system, including system owners, users/customers, operators, maintainers, assemblers, support personnel, logistics suppliers, training personnel, test personnel, and others. This handbook should be used as a companion for implementing NPR 7123.1, Systems Engineering Processes and Requirements, the NASA Systems Engineering Handbook, NASA directives, and any Center-specific handbooks and directives developed for implementing programs and projects. As of 2021, both NPR 7123.1 and NPR 7120.5 require HSI to be implemented within NASA technical efforts.

Lisa O Rippy↗

Post-Flight Assessment Review (PFAR): Advanced Colloids Experiment (ACE) ACE-T7-1,2

The objective of this PFAR is to: • Provide closure to ZIN DO-237 ACE-T7work and close NASA NPR 7123.1 requirements as listed in the SpaceDOC-II (S2) contract (the S2 CDRL DID No. PM-09 calls for a SEMP which refers backto NPR 7123.1) • Provide closure of SEMP (ZIN’s P40025) requirements for Technical Reviews • Provide plan to complete Informatics requirements. • Provide milestone closure to sponsoring organization. • Document property re-use and transfer decisions. • Transfer raw science data to the designated repository at MSFC. • Transfer required documents to Informatics • Opens an Informatics folder at MSFC to officially receive ACE-T7 information. • Capture open action items. • Create a formal presentation in configuration control. • Provide directions (in a Project Manager Report) how to contact the Project and Science teams through NASA when follow-on grants are awarded by Informatics.

microgravity↗

Development of a Human Systems Integration Plan

NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.

Jackelynne Silva-Martinez↗

Implementation of Human Systems Integration Technical and Management Process for the Lunar Gateway Program

NASA recognizes Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The Lunar Gateway Program is implementing HSI technical and management process across the lifecycle of the mission, as required by NPR 7123.1C NASA Systems Engineering Processes and Requirements, and led by the Gateway HSI team as required by NPR 8705.2C Human-Rating Requirements for Space Systems, now HEOMD-003 Crewed Deep Space Systems Human Rating Certification Requirements and Standards for NASA Missions. NASA has been using HSI principles for many years and has applied them to many of its previous human spaceflight Programs. As NASA returns to the Moon in a more sustainable manner, the Gateway Program is maturing the application of HSI by implementing it more visibly as part of Artemis, with guidance from the NASA/SP-20210010952 NASA HSI Handbook. This paper discusses how HSI is being implemented in the Gateway Program, challenges faced with its implementation during the development phase, and strategies/approaches used to overcome those. The paper also covers HSI implementation for flight systems, vehicle processing, and interfaces across the six identified NASA HSI Domains: human factors engineering, operations, safety, training, maintainability and supportability, habitability and environment. The goal is to provide an overview of the implementation process of HSI in the Gateway Program as an example for other Programs/Projects/Missionsthat are looking to implement HSI.

Jackelynne Silva-Martinez↗

Modeling NASA’s Procedural Requirement Processes – Implications for a Digital Future

The National Aeronautics and Space Administration (NASA) has an ongoing Digital Transformation effort and to leverage and showcase the power of Digital Transformation, an effort is underway to develop an integrated, datacentric, model representing NASA’s key process requirements. The task was divided into three phases: As Is modeling, Analysis, and To Be Planning. As part of this effort, a team has completed the first Phase I of the modeling task and is nearing completion of the second phase. This effort will capture the key elements as requirements, responsibilities, allocations, roles, products, and associated lifecycle elements. The scope of modeling included NASA’s NPR 7120.5 (Project and Program Management), NPR 7123.1 (Systems Engineering) and NPRs 8705.2 (Risk classification for Robotic Missions) and 8705.4 (Human-Rating Requirements for Space Missions).

NPR↗

POLARIS: Helping Managers Get Answers Fast!

This viewgraph presentation reviews the Project Online Library and Resource Information System (POLARIS) system. It is NASA-wide, web-based system, providing access to information related to Program and Project Management. It will provide a one-stop shop for access to: a searchable, sortable database of all requirements for all product lines, project life cycle diagrams with reviews, project life cycle diagrams with reviews, project review definitions with products review information from NPR 7123.1, NASA Systems Engineering Processes and Requirements, templates and examples of products, project standard WBSs with dictionaries, and requirements for implementation and approval, information from NASA s Metadata Manager (MdM): Attributes of Missions, Themes, Programs & Projects, NPR7120.5 waiver form and instructions and much more. The presentation reviews the plans and timelines for future revisions and modifications.

program management↗

Modeling NASA’s Procedural Requirement Processes - Implications for Digital Future

The National Aeronautics and Space Administration (NASA) has an ongoing Digital Transformation effort and to leverage and showcase the power of Digital Transformation, an effort is underway to develop an integrated, datacentric, model representing NASA’s key process requirements. The task was divided into three phases: As Is modeling, Analysis, and To Be Planning. As part of this effort, a team has completed the first Phase I of the modeling task and is nearing completion of the second phase. This effort will capture the key elements as requirements, responsibilities, allocations, roles, products, and associated lifecycle elements. The scope of modeling included NASA’s NPR 7120.5 (Project and Program Management), NPR 7123.1 (Systems Engineering) and NPRs 8705.2 (Risk classification for Robotic Missions) and 8705.4 (Human-Rating Requirements for Space Missions). This paper will summarize the approach, scope, parsing patterns applied, metamodel, and associated workflows for the As-Is modeling. It will also summarize the results and insights gleaned during that phase, including the review process. These insights have informed the analysis and will be discussed. The analysis modeling phase will also be summarized including how the stakeholders were engaged, how the common elements were handled and dispositioned, and will also describe some of the plans for the future of NASA NPDs and NPRs.

Systems Engineering↗

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.↗

A Systems Engineering Approach to Quality Assurance for Aerospace Testing

On the surface, it appears that AS9100 has little to say about how to apply a Quality Management System (QMS) to major aerospace test programs (or even smaller ones). It also appears that there is little in the quality engineering Body of Knowledge (BOK) that applies to testing, unless it is nondestructive examination (NDE), or some type of lab or bench testing associated with the manufacturing process. However, if one examines: a) how the systems engineering (SE) processes are implemented throughout a test program; and b) how these SE processes can be mapped to the requirements of AS9100, a number of areas for involvement of the quality professional are revealed. What often happens is that quality assurance during a test program is limited to inspections of the test article; what could be considered a manufacturing al fresco approach. This limits the quality professional and is a disservice to the programs and projects, since there are a number of ways that quality can enhance critical processes, and support efforts to improve risk reduction, efficiency and effectiveness. The Systems Engineering (SE) discipline is widely used in aerospace to ensure the progress from Stakeholder Expectations (the President, Congress, the taxpayers) to a successful, delivered product or service. Although this is well known, what is not well known is that these same SE processes are implemented in varying complexity, to prepare for and implement test projects that support research, development, verification and validation, qualification, and acceptance test projects. Although the test organization's terminology may vary from the SE terminology, and from one test service provider to another, the basic process is followed by successful, reliable testing organizations. For this analysis, NASA Procedural Requirements (NPR) 7123.1, NASA Systems Engineering Processes and Requirements is used to illustrate the SE processes that are used for major aerospace testing. Many of these processes are also implemented for smaller test projects, and this set of processes will also look familiar to those who have participated in launch site activation and flight demonstrations.

Shepherd, Christena C.↗

Human Systems Integration (HSI) Practitioner's Guide

The NASA/SP-2015-3709, Human Systems Integration (HSI) Practitioner's Guide, also known as the "HSIPG," provides a tool for implementing HSI activities within the NASA systems engineering framework. The HSIPG is written to aid the HSI practitioner engaged in a program or project (P/P), and serves as a knowledge base to allow the practitioner to step into an HSI lead or team member role for NASA missions. Additionally, this HSIPG is written to address the role of HSI in the P/P management and systems engineering communities and aid their understanding of the value added by incorporating good HSI practices into their programs and projects. Through helping to build a community of knowledgeable HSI practitioners, this document also hopes to build advocacy across the Agency for establishing strong, consistent HSI policies and practices. Human Systems Integration (HSI) has been successfully adopted (and adapted) by several federal agencies-most notably the U.S. Department of Defense (DoD) and the Nuclear Regulatory Commission (NRC)-as a methodology for reducing system life cycle costs (LCCs). These cost savings manifest themselves due to reductions in required numbers of personnel, the practice of human-centered design, decreased reliance on specialized skills for operations, shortened training time, efficient logistics and maintenance, and fewer safety-related risks and mishaps due to unintended human/system interactions. The HSI process for NASA establishes how cost savings and mission success can be realized through systems engineering. Every program or project has unique attributes. This HSIPG is not intended to provide one-size-fits-all recommendations for HSI implementation. Rather, HSI processes should be tailored to the size, scope, and goals of individual situations. The instructions and processes identified here are best used as a starting point for implementing human-centered system concepts and designs across programs and projects of varying types, including manned and unmanned, human spaceflight, aviation, robotics, and environmental science missions. The practitioner using this guide should have expertise in Systems Engineering or other disciplines involved in producing systems with anticipated human interactions. (See section 1.6 of this guide for further discussion on HSI discipline domains.) The HSIPG provides an "HSI layer" to the NASA Systems Engineering Engine (SEE), detailed in NASA Procedural Requirement (NPR) 7123.1B, NASA Systems Engineering Processes and Requirements, and further explained in NASA/SP-2007-6105, Systems Engineering Handbook (see HSIPG Table 2.2-1, NASA Documents with HSI Content, for specific references and document versions).

Zumbado, Jennifer Rochlis↗

Systems Engineering and Management Applications of ISO 9001:2015 for Government

The manufacturing segment of the business world is busy assessing the impact of ISO 9001:2015, and updating their management systems to meet the required compliance date. What does the new revision mean for government agencies that deliver large engineering projects rather than mass production? In fact, the standard, especially the new revision, can be used quite readily for government agencies, or applied to specific projects, once it is understood in terms of the similarities with systems engineering and project management. From there it can be extrapolated to "mission realization" systems, and a Quality Management System (QMS) is a logical result that can bring order to processes and systems that likely already exist in some fashion. ISO 9001:2015 is less product-oriented than previous versions. It can be more broadly applied to public organizations as well as private; and to services (missions) as well as products. The emphasis on risk management in the revised standard provides the needed balance for weighing decisions with respect to cost, schedule, technical, safety, and regulatory compliance; so if this is not part of agency governance already, this is a good place to start, especially for large engineering projects. The Systems Engineering standard used for this analysis is from NASA's NPR 7123.1 NASA Systems Engineering Processes and Requirements; however, those who are more familiar with ISO/IEC 26702 Systems Engineering-application and management of the systems engineering process, or SAE/EIA 632 Processes for Engineering a System will also recognize the similarities. In reality, the QMS outlined by ISO 9001 reinforces the systems engineering processes, and serves to ensure that they are adequately implemented, although most of the ISO 9001 literature emphasizes the production and process aspects of the standard. Rather than beginning with ISO 9001and getting lost in the vocabulary, it is useful to begin with the systems engineering lifecycle. Identification of stakeholder expectations, identifying solutions, creating specific product or service designs, production of the product or service, delivery to the public, and the associated management, planning, and control processes, are a familiar place to begin thinking of the overall system of identifying, designing, and competing a project or mission. Lining up this lifecycle with the ISO requirements (see Figure 1) illustrates how a quality management system is concerned with the same processes, and provides a governance and assurance function. If implemented properly, there are cost savings resulting from less rework, repair, reprocessing, failures, misplaced documents, and similar types of deficiencies1. Starting with an organization's systems engineering processes allows the organization to use their own terminology for a QMS plan, and tailor the plan to their own project or organization, so that it is more easily developed, understood, and implemented.

Shepherd, Christena C.↗

Expanded Guidance for NASA Systems Engineering. Volume 1: Systems Engineering Practices

This document is intended to provide general guidance and information on systems engineering that will be useful to the NASA community. It provides a generic description of Systems Engineering (SE) as it should be applied throughout NASA. A goal of the expanded guidance is to increase awareness and consistency across the Agency and advance the practice of SE. This guidance provides perspectives relevant to NASA and data particular to NASA. This expanded guidance should be used as a companion for implementing NPR 7123.1, Systems Engineering Processes and Requirements, the Rev 2 version of SP-6105, and the Center-specific handbooks and directives developed for implementing systems engineering at NASA. It provides a companion reference book for the various systems engineering-related training being offered under NASA's auspices.

Steven R Hirshorn↗

State-of-the-Art: Small Spacecraft Technology

When the first edition of NASA’s Small Spacecraft Technology State-of-the-art report was published in 2013, 247 CubeSats and 105 other non-CubeSat small spacecraft under 50 kilograms (kg) had been launched worldwide, representing less than 2% of launched mass into orbit over multiple years. In 2013 alone, around 60% of the total spacecraft launched had a mass under 600 kg, and of those under 600 kg, 83% were under 200 kg and 37% were nanosatellites (1). Of the total 1,849 spacecraft launched in 2021, 94% were small spacecraft with an overall mass under 600 kg, and of those under 600 kg, 40% were under 200 kg, and 11% were nanosatellites (1). Since 2013, the fight heritage for small spacecraft has increased by over 30% and has become the primary source to space access for commercial, government, private, and academic institutions. The total number of spacecraft launched in the past 10 years is 5,681 and 45% of those had a mass. As with all previous editions of this report, the 2022 edition captures and distills a wealth of new information available on small spacecraft systems from NASA and other publicly available sources. This report is limited to publicly available information and cannot reflect major advances in development that are not publicly disclosed. We encourage any opportunity to publish mission outcomes and technology development milestones (e.g., via conference papers, press releases, company website) so they can be reflected in this report. Overall, this report is a survey of small spacecraft technologies sourced from open literature; it does not endeavor to be an original source, and only considers literature in the public domain to identify and classify devices. Commonly used sources for data include manufacturer datasheets, press releases, conference papers, journal papers, public filings with government agencies, news articles, presentations, the compendium of databases accessed via NASA’s Small Spacecraft Systems Virtual Institute (S3VI) Information Search, and engagement with companies. Data not appropriate for public dissemination, such as proprietary, export controlled, or otherwise restricted data, are not considered. As a result, this report includes many dedicated hours of desk research performed by subject matter experts reviewing resources noted above. Content in this 2022 edition is based on data available by October 2022. This report should not be considered as a comprehensive overview of all the technologies but a great reference for the current state-of-the-art SmallSat technologies. The organizational approach for each chapter is relatively consistent with previous editions and includes an introduction of the technology, current development status of the technology’s procurable systems, and summary tables of technologies surveyed. The content in each chapter is uniquely organized to present a mini-stand-alone report on spacecraft subsystems. As in previous years, chapters include information from previous editions but are updated with new and maturating technologies and reference missions. Tables in each section provide a convenient summary of the technologies discussed, with explanations and references in the body text. The authors have attempted to isolate trends in the small spacecraft industry to point out which technologies have been adopted after successful demonstration missions. Lastly, the authors tried to use the terms “SmallSat,” “microsatellite,” “nanosatellite,” and “CubeSat” in a consistent manner, even as these terms are often used interchangeably in the space industry. Every subsystem chapter contains updated information to reflect the growth in the small spacecraft market. Significant changes are included in several chapters. The “Complete Spacecraft Platforms” chapter now includes information on the two main market options, hosted payload services and dedicated buses. The “Power” chapter provides information on the development of solid-state batteries with significantly higher energy than the current state-of-theart lithium-ion batteries. A large effort was made to update the “Communications” chapter to appropriately capture the recent technology maturation of optical communications for SmallSats. The “Ground Data Systems and Mission Operations” chapter was updated to reflect the recent establishment of the Near Space Network and influx of SmallSat Optical Ground Stations. The “Guidance, Navigation and Control” chapter was updated to include Lidar sensor technology. The “Deorbit Systems” chapter includes a discussion of recently proposed changes by the Federal Communications Commission (FCC) to limit a spacecraft’s lifetime to no longer than 5 years after end-of-mission. The “Identification and Tracking” Chapter includes updated information on the progress of SmallSat tracking. Finally, this report now encompasses technology funded by NASA’s Small Spacecraft Technology (SST) program’s SmallSat Technology Partnerships (STP) initiative which is described further in this Introduction. The reader can find the included SST technology in the “On the Horizon” section of the “Thermal Systems”, “Communications”, and “Guidance, Navigation, and Control” chapters. A central element of this report is to list state-of-the-art technologies by NASA standard Technology Readiness Level (TRL) as defined by the 2020 NASA Engineering Handbook, found in NASA NPR 7123.1C NASA Systems Engineering Processes and Requirements. The authors have endeavored to independently verify the TRL value of each technology by reviewing and citing published test results or publicly available data to the best of their ability. Where test results and data disagree with vendors’ own advertised TRL, the authors have attempted to engage the vendors to discuss the discrepancy. Readers are strongly encouraged to follow the references cited in the literature describing the full performance range and capabilities of each technology. Readers of this report should reach out to individual companies to further clarify information. It is important to note that this report takes a broad system-level view. To attain a high TRL, the subsystem must be in a flight-ready configuration with all supporting infrastructure—such as mounting points, power conversion, and control algorithms—in an integrated unit. An accurate TRL assessment requires a high degree of technical knowledge on a subject device, and an in-depth understanding of the mission (including interfaces and environment) on which the device was flown. There is variability in TRL values depending on design factors for a specific technology. For example, differences in TRL assessment based on the operating environment may result from the thermal environment, mechanical loads, mission duration, or radiation exposure. If a technology has flown on a mission without success, or without providing valid confirmation to the operator, such claimed “flight heritage” was discounted. The authors believe TRLs are most accurately determined when assessed within the context of a program’s unique requirements. While the overall capability of small spacecraft has matured since the 2021 edition of this report, technologies are still being developed to make deep space SmallSat missions more routine and more cost effective. Future editions of this report may include content dedicated to the rapidly growing fields of assembly, integration, and testing services, and mission modeling and simulation–all of which are now extensively represented at small spacecraft conferences. Many of these subsystems and services are still in their infancy, but as they evolve and reliable conventions and standards emerge, the next iteration of this report may also evolve to include additional chapters.

Bruce Yost↗

Using Model-Based Systems Engineering to Provide Artifacts for NASA Project Life-cycle and Technical Reviews

This paper is for the AIAA Space Conference. The ability of systems engineers to use model-based systems engineering (MBSE) to generate self-consistent, up-to-date systems engineering products for project life-cycle and technical reviews is an important aspect for the continued and accelerated acceptance of MBSE. Currently, many review products are generated using labor-intensive, error-prone approaches based on documents, spreadsheets, and chart sets; a promised benefit of MBSE is that users will experience reductions in inconsistencies and errors. This work examines features of SysML that can be used to generate systems engineering products. Model elements, relationships, tables, and diagrams are identified for a large number of the typical systems engineering artifacts. A SysML system model can contain and generate most systems engineering products to a significant extent and this paper provides a guide on how to use MBSE to generate products for project life-cycle and technical reviews. The use of MBSE can reduce the schedule impact usually experienced for review preparation, as in many cases the review products can be auto-generated directly from the system model. These approaches are useful to systems engineers, project managers, review board members, and other key project stakeholders.

MBSE↗