Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Model Based System 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
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

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)↗
NASA NTRS2012

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)↗
NASA NTRS2013

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↗
NASA NTRS2011

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↗
NASA NTRS2016

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 NTRS2016

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↗
NASA NTRS2020

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↗
NASA NTRS2021

System Validation on the Europa Clipper mission in Early Implementation Phase

NASA’s next flag-ship mission - Europa Clipper, will embark on a journey to Jupiter’s icy moon Europa in 2024 to assess its environment and habitability with a highly capable spacecraft. Post Jupiter-Orbit-Insertion, the spacecraft will be commanded to perform intricate, yet meticulously planned Europa flybys to perform science investigations using a suite of instruments, while withstanding Jupiter’s harsh radiation environment. The success of this mission is dependent on a well-coordinated project and its elements such as the flight hardware and software, the ground support and mission operations teams, procedures and other cross-cutting elements. The Europa Clipper project needs to ensure that these elements are realized at a reasonable confidence level prior to launch and other mission critical events. System Validation test and analysis activities exercise and confirm the integrity of the system of all project elements in the expected flight environment with reasonable stressing conditions. These activities go beyond system design requirements verification and are driven by validation objectives that describe the end-to-end functional and operational capabilities required during nominal and off-nominal flight-like scenarios and critical events. The challenges associated with validating that the Europa Clipper project as a whole can function and perform correctly to meet the intended mission objectives with the as-delivered capabilities of all of its elements are daunting. This paper discusses the systematic methodology established in the early implementation phase of the Europa Clipper project for developing System Validation activities and their validation objectives, and addressing any validation-related challenges on the project. Approaches include decomposition of mission objectives using activity timelines in the Mission Design plan for developing nominal scenarios, use of fault trees for exploring off-nominal cases and system boundaries, and use of Model-based Systems Engineering (MBSE) tools for planning and prioritizing these activities.

Wang, Xu↗
NASA NTRSDate not supplied

Analysis of Input from Wildfire Incident Experts to Identify Key Risks and Hazards in Wildfire Emergency Response

The United States Department of Agriculture (USDA) describes wildland fires as, “a force of nature that can be nearly as impossible to prevent, and as difficult to control, as hurricanes, tornadoes and floods.” Existing challenges in managing wildland fires often put first responders’ lives at risk. The emergence of drones and their capabilities to supplement human efforts could alleviate some, if not all, of those risks that first responders face during wildfire management efforts. However, the process of adding drones to wildfire response has come with its own challenges as well. NASA’s System-Wide Safety Project is working towards overcoming these challenges to enable routine transfer of risk from responders to aviation assets. The concept of operations and model-based systems engineering (MBSE) effort for this shift is underway. To inform and to validate the MBSE effort, we delivered a questionnaire to wildland firefighting experts on the hazards they currently face. This questionnaire has given us insight and a better understanding of the challenges related to the use of drones from a first responder’s point of view. We are using this information to better address responders’ concerns, develop a safety management system, and eliminate the roadblocks that prevent the use of drones in wildfire management.

Wildfire↗
NASA NTRSDate not supplied

MBSE Execution of Scalable Autonomous Operations for a High Density Vertiplex

The High Density Vertiplex (HDV) subproject of NASA’s Advanced Air Mobility (AAM) project adopted Model-Based Systems Engineering (MBSE) and NASA SE processes were executed via MBSE using MagicDraw. Since the adoption of MBSE and utilization of MagicDraw, the systems engineering team has made tremendous strides in each pillar of MBSE including, requirements, behavior, and structure. Scalable Autonomous Operations (SAO) was a stage in the development of the High Density Vertiplex focusing on the autonomous terminal operations of a vertiport with sUAS aircraft. MBSE served the systems engineering team to document and verify the physical architecture and capture a logical architecture of SAO for distribution to the AAM community. This paper will detail methodologies that were created to successfully execute NASA SE processes via MBSE in the SAO stage as well as highlight challenges and lessons learned.

Demetrios Katsaduros↗
DOE OSTI2021

Summary of Work on a Software Adapter for Project Requirements and MBSE

The National Reactor Innovation Center (NRIC) has funded the development of a digital pipeline to pull a project’s requirements from IBM’s Rational Dynamic Object Oriented Requirements System (DOORS), save them to Deep Lynx, then push them into the corresponding project in Innoslate. These utilities are accessible from a web browser and allow a project’s functional and business requirements to be tied to its tree of model-based systems engineering (MBSE) data.

99 GENERAL AND MISCELLANEOUS↗
NASA NTRS2005

Achieving control and interoperability through unified model-based systems and software engineering

Control and interoperation of complex systems is one of the most difficult challenges facing NASA's Exploration Systems Mission Directorate. An integrated but diverse array of vehicles, habitats, and supporting facilities, evolving over the long course of the enterprise, must perform ever more complex tasks while moving steadily away from the sphere of ground support and intervention.

control↗
NASA NTRS2004

Explanation Constraint Programming for Model-based Diagnosis of Engineered Systems

We can expect to see an increase in the deployment of unmanned air and land vehicles for autonomous exploration of space. In order to maintain autonomous control of such systems, it is essential to track the current state of the system. When the system includes safety-critical components, failures or faults in the system must be diagnosed as quickly as possible, and their effects compensated for so that control and safety are maintained under a variety of fault conditions. The Livingstone fault diagnosis and recovery kernel and its temporal extension L2 are examples of model-based reasoning engines for health management. Livingstone has been shown to be effective, it is in demand, and it is being further developed. It was part of the successful Remote Agent demonstration on Deep Space One in 1999. It has been and is being utilized by several projects involving groups from various NASA centers, including the In Situ Propellant Production (ISPP) simulation at Kennedy Space Center, the X-34 and X-37 experimental reusable launch vehicle missions, Techsat-21, and advanced life support projects. Model-based and consistency-based diagnostic systems like Livingstone work only with discrete and finite domain models. When quantitative and continuous behaviors are involved, these are abstracted to discrete form using some mapping. This mapping from the quantitative domain to the qualitative domain is sometimes very involved and requires the design of highly sophisticated and complex monitors. We propose a diagnostic methodology that deals directly with quantitative models and behaviors, thereby mitigating the need for these sophisticated mappings. Our work brings together ideas from model-based diagnosis systems like Livingstone and concurrent constraint programming concepts. The system uses explanations derived from the propagation of quantitative constraints to generate conflicts. Fast conflict generation algorithms are used to generate and maintain multiple candidates whose consistency can be tracked across multiple time steps.

Narasimhan, Sriram↗
DOE OSTI2024

Model-Based Approaches to Generate Knowledge from Data in a Plant Reliability Context

One challenge that nuclear power plant system engineers are facing is that the amount of equipment reliability (ER) data being continuously generated are extremely large. These data elements come in different forms: textual (e.g., condition reports) and numeric (e.g., generated by monitoring systems) and they provide system engineers with valuable insights and information regarding the discovery of anomalous behaviors or degradation trends, the identification of the possible causes behind such behaviors and trends, and the prediction of their direct consequences. This paper directly targets the generation of knowledge from ER data by putting “data into context”. Here, we employ model-based system engineering (MBSE) models of systems and assets to represent and capture their architecture and functional (i.e., cause-effect) relations. ER data elements are processed by identifying first which elements of the developed MBSE elements they are referring to. This task is much harder for textual data since the information contained in issue or maintenance reports needs to “be understood” by a computational tool. Here we called this process “knowledge extraction” where our methods to extract knowledge from textual data. Lastly, once numeric and textual ER data elements have been processed and “understood”, we discover possible cause-effect relations among them. This is performed by observing if a logical connection through the MBSE models exists, and if there is a temporal relation among them. The logic and temporal are the two main ingredients to perform “machine reasoning” from ER data.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2013

Systems Engineering Interfaces: A Model Based Approach

Currently: Ops Rev developed and maintains a framework that includes interface-specific language, patterns, and Viewpoints. Ops Rev implements the framework to design MOS 2.0 and its 5 Mission Services. Implementation de-couples interfaces and instances of interaction Future: A Mission MOSE implements the approach and uses the model based artifacts for reviews. The framework extends further into the ground data layers and provides a unified methodology.

Advanced Multi-Mission Operations System (AMMOS)↗
NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

This paper describes the core framework used to implement a Goal-Function Tree (GFT) based systems engineering process using the Systems Modeling Language. It defines a set of principles built upon by the theoretical approach described in the InfoTech 2013 ISHM paper titled "Goal-Function Tree Modeling for Systems Engineering and Fault Management" presented by Dr. Stephen B. Johnson. Using the SysML language, the principles in this paper describe the expansion of the SysML language as a baseline in order to: hierarchically describe a system, describe that system functionally within success space, and allocate detection mechanisms to success functions for system protection.

Breckenridge, Jonathan T.↗