Model Driven System Design JPL - Voice of Experience
Explore the source record for details and available documents.
SEARCH · Engineering Papers
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.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Large, complex projects can identify a significant number and variety of risks, throughout the project life cycle. These risks are analyzed, mitigated, closed or accepted as independent uncertainties. Once closed or accepted, it is easy for projects to lose awareness of their impact. In reality, each of these risks contributes some amount to the overall risk posture of the project. The ability to track and effectively communicate this aggregate risk has represented a challenge to project management. There have been previous attempts to create a schema to communicate the aggregate effect of risks, without notable success. Most of these attempts have centered on some additive metric derived from the scoring of likelihood and consequence values. This, in and of itself, is a logical approach, but all too often the scores were then aggregated to a level where all context was lost. One weakness has been a lack of attempt to create linkages or logical groups of the risks upon which useful aggregation could then occur. The overall move to model-based (systems) engineering (MBSE) has opened up a vast frontier of opportunities to better integrate all project data. MBSE provides an underlying layer that links data items to each other. Objectives link to requirements, which then link to functions, functions to physical architecture items, and so on, as far down as projects want to model. While it started with a focus on modeling requirements based on things like use cases, efforts are now underway to integrate safety and mission assurance (S&MA) information and analyses, such as risks. This effort, called Model Based Mission Assurance (MBMA), is yielding models that are more useful and are a more accurate representations of the systems. MBSE models, with this ability to link related items, provide a new means of tracking and communicating aggregate risks. In the proposed method, risks are added into the models as distinct items, having attributes that communicate a scoring derived from the likelihood and consequence values as charted on the standard NASA 5x5 risk matrix. Like earlier efforts, each box in the 5x5 has an associated scoring, which may include both a current score and potential post-mitigation/control score. The risk items are then linked to elements of the model, such as system objectives/goals, requirements, functions, or physical architecture items, with "Risk to" relationships. These risks will then be communicated by use of reports generated from the model, detailing all risks and/or hazards linked to model elements. These reports can include aggregate impacts, including a current scoring and potential future state scoring based on the planned mitigations and/or controls. These reports will show all risks, open, accepted, and closed, linked to project objectives or requirements. When run as part of an upcoming risk acceptance discussion, these reports will serve to remind the team of all previous risks that relate to the effected portion of the system. When included as part of periodic program or project reviews, risk reviews, and safety reviews, this method can improve the overall understanding of the system's true risk posture. This proposed method takes full advantage of the advances that modern modeling techniques provide, with a minimal investment of additional time. Utilizing the model environment also enables a near constant access to current state of aggregate risks.
TEMS Apollo-Saturn 5 tracking system error model results through the AS-504 flight test
This presentation provides an overview of the Model-Based Systems Analysis and Engineering work to be completed by the Advanced Air Transportation Technology Project, Systems Analysis and Integration team. The work aims to develop an integrated systems analysis and engineering capability that will be used to digitally integrate and evaluate subsonic aircraft technologies being developed by projects comprising the Sustainable Flight National Partnership.
No abstract available
A FORTRAN program that provides the user with a powerful and flexible tool for the linearization of aircraft models is discussed. The program LINEAR numerically determines a linear systems model using nonlinear equations of motion and a user-supplied, nonlinear aerodynamic model. The system model determined by LINEAR consists of matrices for both the state and observation equations. The program has been designed to allow easy selection and definition of the state, control, and observation variables to be used in a particular model. Also, included in the report is a comparison of linear and nonlinear models for a high performance aircraft.
In 2018, as result of a recommendation from the National Academies, NASA began to prototype an In-Time Aviation Safety Management System(IASMS). The purpose of the IASMS is to enable innovative aviation operations and greater heterogeneity of the overall National Airspace (NAS) by automating much of the safety monitoring, assessment, and risk and hazard mitigation functionspresent in today’s Safety Management Systems (SMS). NASA has worked together with early industry collaborators to understand how such a system might work and has published several early Concepts of Operation (ConOps) and other technical memoranda that illustrate the primary considerations for selected aviation domains. The shift from an SMS to an IASMS is predicated on several assumptions, including: 1.) automating safety functions will decrease the amount of time necessary for risk and hazard identification and analysis, making it more likely that safety concerns are understood ‘in-time’ to mitigate them, and 2.) an IASMS will allow easier tailoring of safety management processes to the particular risks and hazards inherent to that aviation operation. In this paper, we begin to validate these assumptions through the use of Model-Based Systems Engineering (MBSE).
The Software Architectures Engineering (SAE) Project at the Software Engineering Institute (SEI) has developed engineering modeling techniques that both reduce the complexity of software for domain-specific computer systems and result in systems that are easier to build and maintain. These techniques allow maximum freedom for system developers to apply their domain expertise to software. We have applied these techniques to several types of applications, including training simulators operating in real time, engineering simulators operating in non-real time, and real-time embedded computer systems. Our modeling techniques result in software that mirrors both the complexity of the application and the domain knowledge requirements. We submit that the proper measure of software complexity reflects neither the number of software component units nor the code count, but the locus of and amount of domain knowledge. As a result of using these techniques, domain knowledge is isolated by fields of engineering expertise and removed from the concern of the software engineer. In this paper, we will describe kinds of domain expertise, describe engineering by domains, and provide relevant examples of software developed for simulator applications using the techniques.
As the world warms due to rising greenhouse gas concentrations, the Earth system moves toward climate states without societal precedent, challenging adaptation. Past Earth system states offer possible model systems for the warming world of the coming decades. These include the climate states of the Early Eocene (ca. 50 Ma), the Mid-Pliocene (3.3–3.0 Ma), the Last Interglacial (129–116 ka), the Mid-Holocene (6 ka), preindustrial (ca. 1850 CE), and the 20th century. Here, we quantitatively assess the similarity of future projected climate states to these six geohistorical benchmarks using simulations from the Hadley Centre Coupled Model Version 3 (HadCM3), the Goddard Institute for Space Studies Model E2-R (GISS), and the Community Climate System Model, Versions 3 and 4 (CCSM) Earth system models. Under the Representative Concentration Pathway 8.5 (RCP8.5) emission scenario, by 2030 CE, future climates most closely resemble Mid-Pliocene climates, and by 2150 CE, they most closely resemble Eocene climates. Under RCP4.5, climate stabilizes at Pliocene-like conditions by 2040 CE. Pliocene-like and Eocene-like climates emerge first in continental interiors and then expand outward. Geologically novel climates are uncommon in RCP4.5 (<1%) but reach 8.7% of the globe under RCP8.5, characterized by high temperatures and precipitation. Hence, RCP4.5 is roughly equivalent to stabilizing at Pliocene-like climates, while unmitigated emission trajectories, such as RCP8.5, are similar to reversing millions of years of long-term cooling on the scale of a few human generations. Both the emergence of geologically novel climates and the rapid reversion to Eocene-like climates may be outside the range of evolutionary adaptive capacity.
The 1/8-scale Ground Transportation System (GTS) model was studied experimentally in the NASA Ames 7- by 10-Ft Wind Tunnel. Designed for validation of computational fluid dynamics (CFD), the GTS model has a simplified geometry with a cab-over-engine design and no tractor-trailer gap. As a further simplification, all measurements of the GTS model were made without wheels. Aerodynamic boattail plates were also tested on the rear of the trailer to provide a simple geometry modification for computation. The experimental measurements include body-axis drag, surface pressures, surface hot-film anemometry, oil-film interferometry, and 3-D particle image velocimetry (PIV). The wind-averaged drag coefficient with and without boattail plates was 0.225 and 0.277, respectively. PIV measurements behind the model reveal a significant reduction in the wake size due to the flow turning provided by the boattail plates. Hot-film measurements on the side of the cab indicate laminar separation with turbulent reattachment within 0.08 trailer width for zero and +/- 10 degrees yaw. Oil film interferometry provided quantitative measurements of skin friction and qualitative oil flow images. A complete set of the experimental data and the surface definition of the model are included on a CD-ROM for further analysis and comparison.
The Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) is a syntactical language for exchanging flight vehicle dynamic model data. It provides a framework for encoding entire flight vehicle dynamic model data packages for exchange and/or long-term archiving. Version 2.0.1 of DAVE-ML provides much of the functionality envisioned for exchanging aerospace vehicle data; however, it is limited in only supporting scalar time-independent data. Additional functionality is required to support vector and matrix data, abstracting sub-system models, detailing dynamics system models (both discrete and continuous), and defining a dynamic data format (such as time sequenced data) for validation of dynamics system models and vehicle simulation packages. Extensions to DAVE-ML have been proposed to manage data as vectors and n-dimensional matrices, and record dynamic data in a compatible form. These capabilities will improve the clarity of data being exchanged, simplify the naming of parameters, and permit static and dynamic data to be stored using a common syntax within a single file; thereby enhancing the framework provided by DAVE-ML for exchanging entire flight vehicle dynamic simulation models.
The high-level abstractions that underlie modern storage systems are identified. The information to generate the model was collected from major practitioners who have built and operated large storage facilities, and represents a distillation of the wisdom they have acquired over the years. The model provides a common terminology and set of concepts to allow existing systems to be examined and new systems to be discussed and built. It is intended that the model and the interfaces identified from it will allow and encourage vendors to develop mutually-compatible storage components that can be combined to form integrated storage systems and services. The reference model presents an abstract view of the concepts and organization of storage systems. From this abstraction will come the identification of the interfaces and modules that will be used in IEEE storage system standards. The model is not yet suitable as a standard; it does not contain implementation decisions, such as how abstract objects should be broken up into software modules or how software modules should be mapped to hosts; it does not give policy specifications, such as when files should be migrated; does not describe how the abstract objects should be used or connected; and does not refer to specific hardware components. In particular, it does not fully specify the interfaces.
This report explores the current state of the art of Safety and Mission Assurance (S&MA) in projects that have shifted towards Model Based Systems Engineering (MBSE). Its goal is to provide insight into how NASA’s Office of Safety and Mission Assurance (OSMA) should respond to this shift. In MBSE, systems engineering information is organized and represented in models: rigorous computer-based representations, which collectively make many activities easier to perform, less error prone, and scalable. S&MA practices must shift accordingly. The “Objective Structure Hierarchies” recently developed by OSMA provide the framework for understanding this shift. Although the objectives themselves will remain constant, S&MA practices (activities, processes, tools) to achieve them are subject to change. This report presents insights derived from literature studies and interviews. The literature studies gleaned assurance implications from reports of space-related applications of MBSE. The interviews with knowledgeable S&MA and MBSE personnel discovered concerns and ideas for how assurance may adapt. Preliminary findings and observations are presented on the state of practice of S&MA with respect to MBSE, how it is already changing, and how it is likely to change further. Finally, recommendations are provided on how to foster the evolution of S&MA to best fit with MBSE.
Contents include the following: Computing Information and Communications Technology (CICT) Systems Analysis. Our modeling approach: a 3-part schematic investment model of technology change, impact assessment and prioritization. A whirlwind tour of our model. Lessons learned.
The pilot study is led by the Integration Engineering group in NASA's Launch Services Program (LSP). The Integration Engineering (IE) group is responsible for managing the interfaces between the spacecraft and launch vehicle. This pilot investigates the utility of Model-Based Systems Engineering (MBSE) with respect to managing and verifying interface requirements. The main objectives of the pilot are to model several key aspects of the Mars 2020 integrated operations and interface requirements based on the design and verification artifacts from Mars Science Laboratory (MSL) and to demonstrate how MBSE could be used by LSP to gain further insight on the interface between the spacecraft and launch vehicle as well as to enhance how LSP manages the launch service. The method used to accomplish this pilot started through familiarization of SysML, MagicDraw, and the Mars 2020 and MSL systems through books, tutorials, and NASA documentation. MSL was chosen as the focus of the model since its processes and verifications translate easily to the Mars 2020 mission. The study was further focused by modeling specialized systems and processes within MSL in order to demonstrate the utility of MBSE for the rest of the mission. The systems chosen were the In-Flight Disconnect (IFD) system and the Mass Properties process. The IFD was chosen as a system of focus since it is an interface between the spacecraft and launch vehicle which can demonstrate the usefulness of MBSE from a system perspective. The Mass Properties process was chosen as a process of focus since the verifications for mass properties occur throughout the lifecycle and can demonstrate the usefulness of MBSE from a multi-discipline perspective. Several iterations of both perspectives have been modeled and evaluated. While the pilot study will continue for another 2 weeks, pros and cons of using MBSE for LSP IE have been identified. A pro of using MBSE includes an integrated view of the disciplines, requirements, and verifications leading up to launch. The model allows IE to understand the relationships between disciplines throughout test activities and verifications. Additionally, the relationships between disciplines and integration tasks are generally consistent. The model allows for the generic relationships and tasks to be captured and used throughout multiple mission models should LSP further pursue MBSE. A con of MBSE is the amount of time it takes upfront to understand MBSE and create a useful model. The upfront time it takes to create a useful model is heavily discussed in MBSE literature and is a consistent con throughout the known applications of MBSE. The need to understand SysML and the software chosen also poses the possibility of a "bottleneck" or one person being the sole MBSE user for the working group. The utility of MBSE will continue to be evaluated through the remainder of the study. In conclusion, the original objectives of the pilot study were to use artifacts from MSL to model key aspects of Mars 2020 and demonstrate how MBSE could be used by LSP to gain insight into the spacecraft and launch vehicle interfaces. Progress has been made in modeling and identifying the utility of MBSE to LSP IE and will continue to be made until the pilot study's conclusion in mid-August. The results of this study will produce initial models, modeling instructions and examples, and a summary of MBSE's utility for future use by LSP.
As a part of it restructuring of the space mission design process, the Jet Propulsion Laboratory is investigating a model-driven concept for capturing system level requirements for space missions.
The National Aeronautics and Space Administration (NASA) is embarking on new, complex, and diverse missions to accomplish its scientific and exploration objectives, and it views digital transformation as a key enabler for those missions. The NASA Model-Based Systems Engineering (MBSE) Lead-ership Team (MLT) is leading the charge in the digital transformation of the systems engineering domain at NASA, and it is using the INCOSE Model-Based Capability Matrix (MBCM) as a roadmap. This paper discusses the modifications and tailoring of the INCOSE MBCM (Hale & Hoheb, 2020) for use at NASA, the process the team has taken on multiple rounds of assessment, findings to date, and work products that have been generated as a result of the assessment. The paper will also discuss findings and potential changes that should be made to the original product.