Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “model based systems engineering (MBSE)”

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 145 records · Page 8

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↗

Artemis III and IV Crew Health and Performance System Model Development

To maintain Crew Health and Performance (CHP) during an Artemis mission, the NASA Human Research Program (HRP) and Exploration Medical Capabilities (ExMC) element recognize the challenge that many different vehicles, habitats, and operational groups must come together to develop and implement cross program capabilities. To address this challenge, the ExMC team created the prototype 2023 Artemis CHP System Model to analyze how human system requirements are implemented throughout an Artemis mission and help understand the effects of changing an individual vehicle or habitat requirement on a full mission. Since presenting this work at the 2024 HRP Investigators’ Workshop, ExMC has continued this effort, now called the Artemis III and IV CHP System Model, to better support its operational end users within the NASA Human Health and Performance Directorate (HHPD) workforce. In this presentation, we will recapitulate how visualizing requirements and their relationships using a Model-Based Systems Engineering approach (MBSE) serves to improve understanding of an Artemis mission’s CHP capabilities along with discussion on updates made to the model to increase accessibility for users within HHPD so that it may be used in the development of cross program CHP capabilities at NASA.

Crew Health and Performance↗

A Principled Approach to the Specification of System Architectures for Space Missions

Modern space systems are increasing in complexity and scale at an unprecedented pace. Consequently, innovative methods, processes, and tools are needed to cope with the increasing complexity of architecting these systems. A key systems challenge in practice is the ability to scale processes, methods, and tools used to architect complex space systems. Traditionally, the process for specifying space system architectures has largely relied on capturing the system architecture in informal descriptions that are often embedded within loosely coupled design documents and domain expertise. Such informal descriptions often lead to misunderstandings between design teams, ambiguous specifications, difficulty in maintaining consistency as the architecture evolves throughout the system development life cycle, and costly design iterations. Therefore, traditional methods are becoming increasingly inefficient to cope with ever-increasing system complexity. We apply the principles of component-based design and platform-based design to the development of the system architecture for a practical space system to demonstrate feasibility of our approach using SysML. Our results show that we are able to apply a systematic design method to manage system complexity, thus enabling effective data management, semantic coherence and traceability across different levels of abstraction in the design chain. Just as important, our approach enables interoperability among heterogeneous tools in a concurrent engineering model based design environment.

platform-based design↗

A Tool for Model-Based Generation of Scenario-driven Electric Power Load Profiles

Power consumption during all phases of spacecraft flight is of great interest to the aerospace community. As a result, significant analysis effort is exerted to understand the rates of electrical energy generation and consumption under many operational scenarios of the system. Previously, no standard tool existed for creating and maintaining a power equipment list (PEL) of spacecraft components that consume power, and no standard tool existed for generating power load profiles based on this PEL information during mission design phases. This paper presents the Scenario Power Load Analysis Tool (SPLAT) as a model-based systems engineering tool aiming to solve those problems. SPLAT is a plugin for MagicDraw (No Magic, Inc.) that aids in creating and maintaining a PEL, and also generates a power and temporal variable constraint set, in Maple language syntax, based on specified operational scenarios. The constraint set can be solved in Maple to show electric load profiles (i.e. power consumption from loads over time). SPLAT creates these load profiles from three modeled inputs: 1) a list of system components and their respective power modes, 2) a decomposition hierarchy of the system into these components, and 3) the specification of at least one scenario, which consists of temporal constraints on component power modes. In order to demonstrate how this information is represented in a system model, a notional example of a spacecraft planetary flyby is introduced. This example is also used to explain the overall functionality of SPLAT, and how this is used to generate electric power load profiles. Lastly, a cursory review of the usage of SPLAT on the Cold Atom Laboratory project is presented to show how the tool was used in an actual space hardware design application.

power load profile↗

An MBSE Framework to Identify Regulatory Gaps for Electrified Transport Aircraft

A typical aircraft certification process consists of obtaining a type, production, airworthiness, and continued airworthiness certificates. During this process, a type certification plan is created that includes the intended regulatory operating environment, the proposed certification basis, means of compliance, and a list of documentation to show compliance. Earlier work by the authors demonstrated a model-based framework for the management of these certification artifacts for normal category airplanes. Presently, it is expanded and adapted to consider certification for transport category airplanes regulated under 14 CFR Part 25, providing clear transparency and traceability between the text of the regulations and imposed requirements, contextual information, and specified test activities. In particular, a capability to identify potential gaps in the applicability of regulations for novel architectures such as electrified aircraft is proposed. This capability, based on mismatches between the functional intent and the corresponding prescribed physical implementation, is developed. A sample implementation of the proposed capability is presented for a notional electrified powertrain aircraft architecture.

electrified transport aircraft↗

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↗

Automated Generation of Fault Management Artifacts from a Simple System Model

Our understanding of off-nominal behavior - failure modes and fault propagation - in complex systems is often based purely on engineering intuition; specific cases are assessed in an ad hoc fashion as a (fallible) fault management engineer sees fit. This work is an attempt to provide a more rigorous approach to this understanding and assessment by automating the creation of a fault management artifact, the Failure Modes and Effects Analysis (FMEA) through querying a representation of the system in a SysML model. This work builds off the previous development of an off-nominal behavior model for the upcoming Soil Moisture Active-Passive (SMAP) mission at the Jet Propulsion Laboratory. We further developed the previous system model to more fully incorporate the ideas of State Analysis, and it was restructured in an organizational hierarchy that models the system as layers of control systems while also incorporating the concept of "design authority". We present software that was developed to traverse the elements and relationships in this model to automatically construct an FMEA spreadsheet. We further discuss extending this model to automatically generate other typical fault management artifacts, such as Fault Trees, to efficiently portray system behavior, and depend less on the intuition of fault management engineers to ensure complete examination of off-nominal behavior.

Spinup and Orient↗

A Model-Based Approach to Engineering Behavior of Complex Aerospace Systems

One of the most challenging yet poorly defined aspects of engineering a complex aerospace system is behavior engineering, including definition, specification, design, implementation, and verification and validation of the system's behaviors. This is especially true for behaviors of highly autonomous and intelligent systems. Behavior engineering is more of an art than a science. As a process it is generally ad-hoc, poorly specified, and inconsistently applied from one project to the next. It uses largely informal representations, and results in system behavior being documented in a wide variety of disparate documents. To address this problem, JPL has undertaken a pilot project to apply its institutional capabilities in Model-Based Systems Engineering to the challenge of specifying complex spacecraft system behavior. This paper describes the results of the work in progress on this project. In particular, we discuss our approach to modeling spacecraft behavior including 1) requirements and design flowdown from system-level to subsystem-level, 2) patterns for behavior decomposition, 3) allocation of behaviors to physical elements in the system, and 4) patterns for capturing V&V activities associated with behavioral requirements. We provide examples of interesting behavior specification patterns, and discuss findings from the pilot project.

SysML↗

NASA Electronic Parts and Packaging (NEPP) Program: Resources for SmallSats on EEE Parts

From the outside looking in, the NEPP program supports NASA's traditional approach to providing electrical, electronic, and electromechanical (EEE) assurance for space missions. Standards (military and commercial) for EEE parts are based on risk averse methodologies, drive higher costs and schedules, and, in general, provide devices that significantly lag behind commercial devices in performance aspects (speed, power efficiency, etc...). This is NOT the model most small missions realistically can use. However, when you look behind the curtain, NEPP has been considering the risk trade space for small missions for over five years and has consistently provided resources that the small mission regime would find useful. In this paper, we provide a brief overview of these resources as well as NEPP's current research/development efforts that are relevant. While we'll primarily discuss radiation assurance related issues such as data availability and usage, assurances processes for not only the radiation effects side, but also the EEE parts reliability will be touched upon.

Electrical↗

Architectural Modeling and Analysis for Safety Engineering

Model-based development tools are increasingly being used for system-level development of safety-critical systems. Architectural and behavioral models provide important information that can be leveraged to improve the system safety analysis process. Model-based design artifacts produced in early stage development activities can be used to perform system safety analysis, reducing costs and providing accurate results throughout the system life-cycle. In this report we describe an extension to the Architecture Analysis and Design Language (AADL) that supports modeling of system behavior under failure conditions. This Safety Annex enables the independent modeling of component failures and allows safety engineers to weave various types of fault behavior into the nominal system model. The accompanying tool support uses model checking to propagate errors from their source to their effect on safety properties without the need to add separate propagation specifications. The tool also captures all minimal set of fault combinations that can cause violation of the safety properties, that can be compared to qualitative and quantitative objectives as part of the safety assessment process. We describe the Safety Annex, illustrate its use with a representative example, and discuss and demonstrate the tool support enabling an analyst to investigate the system behavior under failure conditions.

FTA↗