Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Model Based 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 271 records · Page 15

Systems Engineering for Space Exploration Medical Capabilities

Human exploration missions that reach destinations beyond low Earth orbit, such as Mars, will present significant new challenges to crew health management. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element's approach to enabling the necessary autonomy. The Element's work must integrate with the overall exploration mission and vehicle design efforts to successfully provide exploration medical capabilities. ExMC is applying systems engineering principles and practices to accomplish its goals. This paper discusses the structured and integrative approach that is guiding the medical system technical development. Assumptions for the required levels of care on exploration missions, medical system goals, and a Concept of Operations are early products that capture and clarify stakeholder expectations. Model-Based Systems Engineering techniques are then applied to define medical system behavior and architecture. Interfaces to other flight and ground systems, and within the medical system are identified and defined. Initial requirements and traceability are established, which sets the stage for identification of future technology development needs. An early approach for verification and validation, taking advantage of terrestrial and near-Earth exploration system analogs, is also defined to further guide system planning and development.

Mindock, Jennifer↗

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

Exploration Medical Capability Systems Engineering Overview and Update

Long duration Lunar and Martian missions will change the way NASA currently practices medicine. The missions will require more autonomous capability compared to current low Earth orbit operations. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element’s approach to enabling the necessary autonomy. The ExMC Systems Engineering (SE) team’s mission is to “Define, develop, validate, and manage the technical system design needed to implement exploration medical capabilities for Mars and test the design in a progression of proving grounds.” The Element’s work must integrate with the overall exploration mission and vehicle design efforts to successfully provide exploration medical capabilities. ExMC is using Model-Based System Engineering (MBSE) to accomplish its integrative goals. The MBSE approach to medical system design offers a paradigm shift toward greater integration between the vehicle and the medical system, and directly supports the transition of Earth-reliant ISS operations to the Earth-independent operations envisioned for Mars. This talk will provide a high-level overview of what the ExMC SE team has accomplished since the last IWS and what they are focusing on for the upcoming year.

Kerry McGuire↗

Architecting the Human Space Flight Program with Systems Modeling Language (SysML)

The next generation of missions in NASA's Human Space Flight program focuses on the development and deployment of highly complex systems (e.g., Orion Multi-Purpose Crew Vehicle, Space Launch System, 21st Century Ground System) that will enable astronauts to venture beyond low Earth orbit and explore the moon, near-Earth asteroids, and beyond. Architecting these highly complex system-of-systems requires formal systems engineering techniques for managing the evolution of the technical features in the information exchange domain (e.g., data exchanges, communication networks, ground software) and also, formal correlation of the technical architecture to stakeholders' programmatic concerns (e.g., budget, schedule, risk) and design development (e.g., assumptions, constraints, trades, tracking of unknowns). This paper will describe how the authors have applied System Modeling Language (SysML) to implement model-based systems engineering for managing the description of the End-to-End Information System (EEIS) architecture and associated development activities and ultimately enables stakeholders to understand, reason, and answer questions about the EEIS under design for proposed lunar Exploration Missions 1 and 2 (EM-1 and EM-2).

scheduling↗

ExMC Digital Engineering

Future missions beyond Artemis II will become increasingly complex as multiple vehicles (e.g., Gateway, Human Landing System (HLS), and Extravehicular Activity and Human Surface Mobility Program (EHP)), each having their own Program requirements and other associated documentation, which will need to be integrated into a single mission. Currently, the Human Health and Performance Directorate (HHPD)Program Support Teams mostly use documents to manage, perform, and archive their analyses. Identifying an opportunity for efficiency, ExMC demonstrated the ability to utilize MagicDraw, a Model-Based Systems Engineering (MBSE) tool, as a requirements database with traceability, dependencies, and relationships in one place. Rather than existing in documents, emails, and historical knowledge, ExMC pursued a Digital Engineering (DE) effort in coordination with HHPD by combining MBSE tools with other digital platforms to manage and develop user-defined databases and interfaces. This DE approach is aimed to simplify processes and reduce risk through the unification of requirements into a centralized digital network, improving collaboration, decision-making, and transparency compared to isolated documents and knowledge. However, manipulating data views and content in MagicDraw requires a steep learning curve not needed by all users and even the user-friendly web view comes with downsides due to the static views. To provide a more dynamic user interface, ExMC investigated the use of Microsoft Power Platform which does not require as steep of a learning curve to become proficient. This introduces analytics to the DE infrastructure, offering customizable and dynamic data dashboards. ExMC continues developing these dashboards and tailoring the DE infrastructure in alignment with HHPD workforce needs.

M Krihak↗

Exploration Systems Development Mission Directorate: Moon to Mars Architecture Definition Document

The National Aeronautics and Space Administration (NASA) explores the unknown in air and space, innovates for the benefit of humanity, and inspires the world through discovery. Extending the reach of humanity through the human exploration of the Moon, Mars, and beyond is key to that mission. NASA’s Moon to Mars Strategy and Objectives document establishes long-term goals and objectives for crewed deep space exploration; however, satisfying NASA’s Moon to Mars Objectives requires an innovative approach to the definition, management, and execution of NASA’s Moon to Mars Architecture. An architecture offers a high-level unifying structure and defines a system. It provides rules, guidelines, and constraints that define a cohesive and coherent framework that identifies constituent parts, relationships, and connections and establishes how those parts fit and work together. This Architecture Definition Document (ADD) establishes the process for the decomposition of objectives empowers the agency’s success in achieving human exploration of the cosmos. NASA updates this document annually to reflect the maturation of the architecture and the progress NASA and partners make toward achieving exploration objectives. The ADD is not a manifest or requirements document. Instead, it serves as a tool for the programs, projects, and engineers who will implement and execute NASA’s bold ambitions for crewed exploration of deep space. As established in the Moon to Mars Strategy and Objectives, “Why” we explore encompasses three pillars: Science, Inspiration, and National Posture. Ensuring success in all three areas requires an architectural approach that incorporates innovation, collaboration, and partnerships that can be sustained across a multi-decadal effort. This second revision (Rev-B) of the ADD, developed to support NASA’s 2024 Architecture Concept Review (ACR), incorporates several key updates to support the continued evolution of the architecture. Since the last revision of the ADD, NASA has significantly improved the clarity of the objective decomposition, which distills exploration objectives into the characteristics and needs and use cases and functions needed to achieve them. The updated decomposition incorporates findings from internal studies and diverse stakeholder feedback. A model-based systems engineering approach ensures coherence and consistency, removing inconsistency and repetition. Revision B also incorporates advancements to NASA’s Mars architecture, including insight into initial capabilities, systems, and operations necessary to support the Humans to Mars segment. Updates to objective decomposition for Mars add significant detail to the ADD and hint at areas of forward work and future study. An appendix adds greater depth in the future decisions needed for Mars that will drive lunar needs. They are not the only decisions to be made, but they will have huge effects on subsequent decisions. NASA continues to introduce new exploration systems into the architecture. Two new elements — initial surface habitat and lunar surface cargo lander—successfully passed mission concept review in 2024 as a result of extensive analysis, concept refinement, and studies. These elements and their respective reference missions appear in this revision. NASA also continues to apply architecture processes to cross-agency efforts and coordination with external stakeholders by including definitions of architecture technology gaps — essential areas for engagement across and beyond the agency. The technology gaps appendix identifies areas that need attention and innovation to enable future exploration. In publishing this information, NASA communicates the technologies and capabilities that may benefit from partnership with industry, academia, other U.S. government agencies, and international space agencies. Ultimately, NASA established the Moon to Mars Architecture approach to communicate and facilitate humanity’s journey into the universe according to the principles and recurring tenets of NASA’s Moon to Mars Strategy and Objectives. The NASA architecture team thanks their many stakeholders, participants, and partners for their efforts to review and provide feedback. Their support has been critical to the success of this approach.

Elements↗

Developing a Medical System Concept of Operations for Level of Care IV: Long-Duration Lunar Orbital and Surface Operations

A goal of the Human Research Program (HRP) Exploration Medical Capability (ExMC) Element Systems Engineering (SE) team is to define the technical system needed to support crew medical system capabilities for future exploration missions, including a mission with lunar orbital and long duration surface operations. The medical system concept of operations (ConOps) is the starting point of creating a foundation for a medical system that meets Level of Care IV requirements, as defined by NASA’s space flight human-system standards. This ConOps illustrates how NASA can provide a Level of Care IV medical system for crews within the various cis-lunar orbit and lunar surface habitat environments. The use case scenarios included in this ConOps illustrate required medical system capabilities for Level of Care IV and enable the ExMC SE team to develop integrated medical system requirements and identify capabilities required to meet those requirements. This discussion will focus on how this concept of operations was constructed – by utilizing the lessons learned from ExMC’s existing Short-Duration Lunar Orbit Medical System Concept of Operations, by employing Model-Based Systems Engineering, and by collaborating with stakeholders in order to ensure the necessary assumptions were made.

M. Kaetzer↗

Defining A Modelling Language to Support Functional Hazard Assessment

Functional Hazard Assessment (FHA) is a key early-stage engineering process that supports the incorporation of safety in design by identifying the high-level functional hazards the system may encounter. While many FHA-like methodologies have been proposed in the design engineering literature, many of these methodologies have had difficulty becoming accepted industry practice. Industry standards, on the other hand, either provide little recommendation on how to represent the function of the system to perform FHA, or rely on readily-available models with little justification in design theory. This paper presents some of the problems with current modelling languages used for FHA which limit the scope, expressiveness, flexibility, and precision of the analysis, as well as desirable principles an FHA-supporting analysis language should embody. It further introduces the Functional Reasoning Design Language (FRDL), a formal modelling language for describing the functional behaviors of a system and their interactions which satisfies these principles. To demonstrate the use of this language, the modelling and hazard analysis of a disaster response drone is presented.

safety analysis↗

Ultra-High Operation Temperature SiC-matrix Solar Thermal Air Receiver (HOTSSTAR) enabled by additive manufacturing: Test Facility & Performance Evaluations

Solar Heat for Industrial Processes (SHIP) cavity receivers are capable of generating electricity or industrial process heat by absorbing thermal energy from solar radiation, focused on a small area. The concentration of solar radiation on the small area of the receiver enables the achievement of high temperatures (ranging from 400°C to 1,100°C) of a working fluid, thus making the SHIP technology thermodynamically comparable with conventional power plants. A volumetric receiver consists of a porous structure-generally made of silicon carbide or metal, which absorbs solar radiation and converts it into heat energy. Heat energy from the porous materials is then transferred to the fluid following through them. A volumetric receiver acts as a convective heat exchanger, transferring heat to the fluid through convection. Open-loop volumetric receivers work with air at atmospheric pressure and are suitable for single-cycle or multi-cycle energy plants. A Model Based Systems Engineering (MBSE) approach was used to develop a test bed at Sandia national Laboratories (SNL) capable of demonstrating an open-loop volumetric air receiver developed by General Electric Aerospace (GE Aerospace). This paper presents the development of the various MBSE methods, test bed, and testing operations for the GE air receiver, which was experimentally demonstrated to achieve 1,350°C for over 3 hours of operation and an approximate 70% receiver efficiency. By being able to achieve such high temperatures >1,000°C, this work provides the potential to support many SHIP industrial use cases.

14 SOLAR ENERGY↗

Test and Verification Approach for the NASA Constellation Program

This viewgraph presentation is a test and verification approach for the NASA Constellation Program. The contents include: 1) The Vision for Space Exploration: Foundations for Exploration; 2) Constellation Program Fleet of Vehicles; 3) Exploration Roadmap; 4) Constellation Vehicle Approximate Size Comparison; 5) Ares I Elements; 6) Orion Elements; 7) Ares V Elements; 8) Lunar Lander; 9) Map of Constellation content across NASA; 10) CxP T&V Implementation; 11) Challenges in CxP T&V Program; 12) T&V Strategic Emphasis and Key Tenets; 13) CxP T&V Mission & Vision; 14) Constellation Program Organization; 15) Test and Evaluation Organization; 16) CxP Requirements Flowdown; 17) CxP Model Based Systems Engineering Approach; 18) CxP Verification Planning Documents; 19) Environmental Testing; 20) Scope of CxP Verification; 21) CxP Verification - General Process Flow; 22) Avionics and Software Integrated Testing Approach; 23) A-3 Test Stand; 24) Space Power Facility; 25) MEIT and FEIT; 26) Flight Element Integrated Test (FEIT); 27) Multi-Element Integrated Testing (MEIT); 28) Flight Test Driving Principles; and 29) Constellation s Integrated Flight Test Strategy Low Earth Orbit Servicing Capability.

Strong, Edward↗

An Altair Overview: Designing a Lunar Lander for 21st Century Human Space Exploration

Altair, the lunar lander element of NASA's Constellation program, was conducted in a different design environment than many other NASA projects of similar scope. Because of this relatively unique approach, there are a number of significant success stories that should be considered during the development of any future lunar landers or human spacecraft. This paper is divided into two separate themes; the first is the approach used during the conceptual design studies, including the systematic analysis cycles and the decision making process associated with each: and the second is a summary of the resulting lessons learned that were compiled after looking back at the lifetime of the Project. Altair was terminated before entering Phase B of its design, and was often criticized for being a very heavy and very large vehicle. While there was specific rationale for all of the decisions that led up to that configuration, future design cycles were specifically planned to re-address the mass challenge. Had the project continued, the deliberate, stepwise design process would have converged on an optimized lander design that balanced mass, risk, cost and capabilities. Some of the specific items that will be addressed in this paper include project development strategy, organizational approach and team dynamics, risk-informed design process, mission architecture constraints, mission key driving requirements, model-based systems engineering process, configuration studies, contingency considerations, subsystem overviews and key trade studies. The paper will conclude with a summary of the lessons identified during the Altair project and make suggestions for application to future studies.

Brown, Kendall K.↗

MBSE in Development: SMAP Pilot Project

Customer-focused objective: Provide value to a flight project using Model-Based Systems Engineering (MBSE) methodology and products. Institution-focused objective: Advance and improve our systems engineering practices, leveraging MBSE where applicable: Streamline our interfaces across JPL Divisions, to provide better cross-organization products; Streamline our interfaces across lifecycle phase boundaries; Update our SE practices to make them more competitive and able to handle systems of ever-increasing complexity.

Soil Moisture Active and Passive (SMAP)↗

Orion Flight Test Architecture Benefits of MBSE Approach

Exploration Flight Test 1 (EFT-1) is an unmanned first orbital flight test of the Multi Purpose Crew Vehicle (MPCV) Mission s purpose is to: Test Orion s ascent, on-orbit and entry capabilities Monitor critical activities Provide ground control in support of contingency scenarios Requires development of a large scale end-to-end information system network architecture To effectively communicate the scope of the end-to-end system a model-based system engineering approach was chosen.

Exploration Flight Test 1 (EFT-1)↗

Failure Modes and Effects Analysis (FMEA) Assistant Tool Feasibility Study

An effort to determine the feasibility of a software tool to assist in Failure Modes and Effects Analysis (FMEA) has been completed. This new and unique approach to FMEA uses model based systems engineering concepts to recommend failure modes, causes, and effects to the user after they have made several selections from pick lists about a component s functions and inputs/outputs. Recommendations are made based on a library using common failure modes identified over the course of several major human spaceflight programs. However, the tool could be adapted for use in a wide range of applications from NASA to the energy industry.

Flores, Melissa↗

The Development of NASA's Fault Management Handbook

Disciplined approach to Fault Management (FM) has not always been emphasized by projects, contributing to major schedule and cost overruns: (1) Often faults aren't addressed until nominal spacecraft design is fairly stable. (2) Design relegated to after-the-fact patchwork, Band-Aid approach. Progress is being made on a number of fronts outside of Handbook effort: (1) Processes, Practices and Tools being developed at some Centers and Institutions (2) Management recognition. Constellation FM roles, Discovery/New Frontiers mission reviews (3) Potential Technology solutions. New approaches could avoid many current pitfalls (3a) New FM architectures, including model-based approach integrated with NASA's MBSE (Model-Based System Engineering) efforts (3b) NASA's Office of the Chief Technologist: FM identified in seven of NASA's 14 Space Technology Roadmaps. Opportunity to coalesce and establish thrust area to progressively develop new FM techniques. FM Handbook will help ensure that future missions do not encounter same FM-related problems as previous missions. Version 1 of the FM Handbook is a good start: (1) Still need Version 2 Agency-wide FM Handbook to expand Handbook to other areas, especially crewed missions. (2) Still need to reach out to other organizations to develop common understanding and vocabulary. Handbook doesn't/can't address all Workshop recommendations. Still need to identify how to address programmatic and infrastructure issues.

Fault Management↗

Integrating MBSE into Ongoing Projects: Requirements Validation and Test Planning for the ISS SAFER

The International Space Station (ISS) Simplified Aid for Extra Vehicular Activity (EVA) Rescue (SAFER) is the spacewalking astronaut's final safety measure against separating from the ISS and being unable to return safely. Since the late 1990s, the SAFER has been a standard element of the spacewalking astronaut's equipment. The ISS SAFER project was chartered to develop a new block of SAFER units using a highly similar design to the legacy SAFER (known as the USA SAFER). An on-orbit test module was also included in the project to enable periodic maintenance/propulsion system checkout on the ISS SAFER. On the ISS SAFER project, model-based systems engineering (MBSE) was not the initial systems engineering (SE) approach, given the volume of heritage systems engineering and integration (SE&I) products. The initial emphasis was ensuring traceability to ISS program standards as well as to legacy USA SAFER requirements. The requirements management capabilities of the Cradle systems engineering tool were to be utilized to that end. During development, however, MBSE approaches were applied selectively to address specific challenges in requirements validation and test and verification (T&V) planning, which provided measurable efficiencies to the project. From an MBSE perspective, ISS SAFER development presented a challenge and an opportunity. Addressing the challenge first, the project was tasked to use the original USA SAFER operational and design requirements baseline, with a number of additional ISS program requirements to address evolving certification expectations for systems operating on the ISS. Additionally, a need to redesign the ISS SAFER avionics architecture resulted in a set of changes to the design requirements baseline. Finally, the project added an entirely new functionality for on-orbit maintenance. After initial requirements integration, the system requirements count was approaching 1000, which represented a growth of 4x over the original USA SAFER system. This presented the challenge - How to confirm that this new set of requirements set would result in the creation of the desired capability.

Anderson, Herbert A.↗

NASA GRC MBSE Implementation Status

This presentation gives a brief overview on GRCs Model Based System Engineering (MBSE) implementation status. This overview covers: history, project usage and implementation, challenges and future work.

MBSE↗

An MBSE-based Approach to Architecting a Robotic Sample Capture System Concept for Potential Mars Sample Return

A model-based systems engineering (MBSE) approach was applied to architecting an orbiting sample Capture and Orient Module (COM) system concept for a Capture, Contain, and Return System (CCRS) payload concept for the notional Mars Sample Return (MSR) campaign at the NASA Jet Propulsion Laboratory. An architecture framework was established, covering multiple organizational layers of the system, along with structural, behavioral, data, and requirements perspectives. A workflow process to implement the architecting activities within the COM engineering team was established. The approach helped maintain consistency in terminology, helped ensure alignment of structural, behavioral, data, and requirements elements within each organization layer, and guided the engineering team through an architecting process that helped develop the architecture for a Capture and Orient Module system concept.

Younse, Paulo↗