Search NASA⌕ Search

SEARCH · Search NASA

Results for “Simulink model”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

SimCheck: An Expressive Type System for Simulink

MATLAB Simulink is a member of a class of visual languages that are used for modeling and simulating physical and cyber-physical systems. A Simulink model consists of blocks with input and output ports connected using links that carry signals. We extend the type system of Simulink with annotations and dimensions/units associated with ports and links. These types can capture invariants on signals as well as relations between signals. We define a type-checker that checks the wellformedness of Simulink blocks with respect to these type annotations. The type checker generates proof obligations that are solved by SRI's Yices solver for satisfiability modulo theories (SMT). This translation can be used to detect type errors, demonstrate counterexamples, generate test cases, or prove the absence of type errors. Our work is an initial step toward the symbolic analysis of MATLAB Simulink models.

Roy, Pritam↗
NASA NTRSDate not supplied

Brayton Cycle Power Conversion Model for MW-Class Nuclear Electric Propulsion Mars Missions

A Brayton cycle based power conversion system for a nuclear electric propulsion application was modeled in Simulink as part of NASA’s space nuclear program in order to explore the impact of technology assumptions on the power conversion system performance and capabilities. The thermodynamic processes and algorithms within the model are documented, including a higher fidelity reactor model. Assumptions are chosen based on literature and subject matter expert review, and example results and capabilities of the model are shown. The effects of the turbine inlet and compressor inlet temperature on radiator area and thermal efficiency are discussed. For a He-Xe closed Brayton cycle, radiator areas as low as 650 m2/MWe are shown, with corresponding thermal efficiences at roughly 20% for the minimal radiator area solutions.

Brayton↗
NASA NTRS2017

Automated Analysis of Stateflow Models

Stateflow is a widely used modeling framework for embedded and cyber physical systems where control software interacts with physical processes. In this work, we present a framework a fully automated safety verification technique for Stateflow models. Our approach is two-folded: (i) we faithfully compile Stateflow models into hierarchical state machines, and (ii) we use automated logic-based verification engine to decide the validity of safety properties. The starting point of our approach is a denotational semantics of State flow. We propose a compilation process using continuation-passing style (CPS) denotational semantics. Our compilation technique preserves the structural and modal behavior of the system. The overall approach is implemented as an open source toolbox that can be integrated into the existing Mathworks Simulink Stateflow modeling framework. We present preliminary experimental evaluations that illustrate the effectiveness of our approach in code generation and safety verification of industrial scale Stateflow models.

Stateflow↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2000

System and Propagation Availability Analysis for NASA's Advanced Air Transportation Technologies

This report summarizes the research on the System and Propagation Availability Analysis for NASA's project on Advanced Air Transportation Technologies (AATT). The objectives of the project were to determine the communication systems requirements and architecture, and to investigate the effect of propagation on the transmission of space information. In this report, results from the first year investigation are presented and limitations are highlighted. To study the propagation links, an understanding of the total system architecture is necessary since the links form the major component of the overall architecture. This study was conducted by way of analysis, modeling and simulation on the system communication links. The overall goals was to develop an understanding of the space communication requirements relevant to the AATT project, and then analyze the links taking into consideration system availability under adverse atmospheric weather conditions. This project began with a preliminary study of the end-to-end system architecture by modeling a representative communication system in MATLAB SIMULINK. Based on the defining concepts, the possibility of computer modeling was determined. The investigations continue with the parametric studies of the communication system architecture. These studies were also carried out with SIMULINK modeling and simulation. After a series of modifications, two end-to-end communication links were identified as the most probable models for the communication architecture. Link budget calculations were then performed in MATHCAD and MATLAB for the identified communication scenarios. A remarkable outcome of this project is the development of a graphic user interface (GUI) program for the computation of the link budget parameters in real time. Using this program, one can interactively compute the link budget requirements after supplying a few necessary parameters. It provides a framework for the eventual automation of several computations required in many experimental NASA missions. For the first year of this project, most of the stated objectives were accomplished. We were able to identify probable communication systems architectures, model and analyze several communication links, perform numerous simulation on different system models, and then develop a program for the link budget analysis. However, most of the work is still unfinished. The effect of propagation on the transmission of information in the identified communication channels has not been performed. Propagation effects cannot be studied until the system under consideration is identified and characterized. To study the propagation links, an understanding of the total communications architecture is necessary. It is important to mention that the original project was intended for two years and the results presented here are only for the first year of research. It is prudent therefore that these efforts be continued in order to obtain a complete picture of the system and propagation availability requirements.

Ugweje, Okechukwu C.↗
NASA NTRS2011

Quadrocopter Control Design and Flight Operation

A limiting factor in control system design and analysis for spacecraft is the inability to physically test new algorithms quickly and cheaply. Test flights of space vehicles are costly and take much preparation. As such, EV41 recently acquired a small research quadrocopter that has the ability to be a test bed for new control systems. This project focused on learning how to operate, fly, and maintain the quadrocopter, as well as developing and testing protocols for its use. In parallel to this effort, developing a model in Simulink facilitated the design and analysis of simple control systems for the quadrocopter. Software provided by the manufacturer enabled testing of the Simulink control system on the vehicle.

Karwoski, Katherine↗
NASA NTRS2014

Helping System Engineers Bridge the Peaks

In our experience at NASA, system engineers generally follow the Twin Peaks approach when developing safety-critical systems. However, iterations between the peaks require considerable manual, and in some cases duplicate, effort. A significant part of the manual effort stems from the fact that requirements are written in English natural language rather than a formal notation. In this work, we propose an approach that enables system engineers to leverage formal requirements and automated test generation to streamline iterations, effectively "bridging the peaks". The key to the approach is a formal language notation that a) system engineers are comfortable with, b) is supported by a family of automated V&V tools, and c) is semantically rich enough to describe the requirements of interest. We believe the combination of formalizing requirements and providing tool support to automate the iterations will lead to a more efficient Twin Peaks implementation at NASA.

Requirements↗
NASA NTRSDate not supplied

The Troupe System: an Autonomous Multi-Agent Rover Swarm

Autonomous cooperative robotic systems are the future of space exploration. The complexity of such systems makes their development, verification and assurance challenging. The Robust Software Engineering group at NASA Ames has developed the Troupe project that aims to explore the design and development of a swarm of autonomous rovers tasked to perform autonomous exploration and mapping of an unknown terrain. In this paper, we showcase the system design, and accompanying verification and validation tools integrated in the Troupe system development life-cycle.

TROUPE↗
DOE OSTI2025

Autonomous Operations for Advanced Reactors Utilizing Supervisory Control

Automation is a critical tenet of reactor plant operations as reliance on nuclear energy increases. Nuclear power plants require a large workforce which does not scale with output; that is, the cost per megawatt increases as reactor output becomes smaller. The economic viability of advanced reactors, particularly small modular reactors (SMRs) and microreactors, requires a significantly reduced onsite workforce. The logical solution is establishing a systematic process of elimination of reliance on human operators, and to the extent possible, replacing these actions with automated functions. In this paper, we propose a method for such transformation to establish a robust technical basis to enable transition to autonomy. Our method is based on finite state automata (FSA)—also known as finite state machines (FSMs). Relying on this method allows us to exploit the rich set of mathematical proofs available in the field of regular languages. FSA are one of the mathematical tools to model discrete event systems (DES). These properties are applied to produce an automated startup controller for the Massachusetts Institute of Technology Research Reactor (MITR). The startup procedure is captured in terms of discrete changes from one state to another while an independent supervisory control system directs the sequence of states and alerts a human in the event of an abnormal operation. First, the design and behavior of the MITR rod control system were modeled in Simulink. Then, the startup procedure was applied to the rod control system and the DES performed a startup by procedurally withdrawing rods to the subcritical position. The simulation also stops rod motion in response to an uncontrollable event and restarts rod motion once the event has been cleared.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗
NASA NTRS2014

System Testing of Ground Cooling System Components

This internship focused primarily upon software unit testing of Ground Cooling System (GCS) components, one of the three types of tests (unit, integrated, and COTS/regression) utilized in software verification. Unit tests are used to test the software of necessary components before it is implemented into the hardware. A unit test determines that the control data, usage procedures, and operating procedures of a particular component are tested to determine if the program is fit for use. Three different files are used to make and complete an efficient unit test. These files include the following: Model Test file (.mdl), Simulink SystemTest (.test), and autotest (.m). The Model Test file includes the component that is being tested with the appropriate Discrete Physical Interface (DPI) for testing. The Simulink SystemTest is a program used to test all of the requirements of the component. The autotest tests that the component passes Model Advisor and System Testing, and puts the results into proper files. Once unit testing is completed on the GCS components they can then be implemented into the GCS Schematic and the software of the GCS model as a whole can be tested using integrated testing. Unit testing is a critical part of software verification; it allows for the testing of more basic components before a model of higher fidelity is tested, making the process of testing flow in an orderly manner.

Unit Test↗
NASA NTRS2001

Crops Models for Varying Environmental Conditions

New variable environment Modified Energy Cascade (MEC) crop models were developed for all the Advanced Life Support (ALS) candidate crops and implemented in SIMULINK. The MEC models are based on the Volk, Bugbee, and Wheeler Energy Cascade (EC) model and are derived from more recent Top-Level Energy Cascade (TLEC) models. The MEC models simulate crop plant responses to day-to-day changes in photosynthetic photon flux, photoperiod, carbon dioxide level, temperature, and relative humidity. The original EC model allows changes in light energy but uses a less accurate linear approximation. The simulation outputs of the new MEC models for constant nominal environmental conditions are very similar to those of earlier EC models that use parameters produced by the TLEC models. There are a few differences. The new MEC models allow setting the time for seed emergence, have realistic exponential canopy growth, and have corrected harvest dates for potato and tomato. The new MEC models indicate that the maximum edible biomass per meter squared per day is produced at the maximum allowed carbon dioxide level, the nominal temperatures, and the maximum light input. Reducing the carbon dioxide level from the maximum to the minimum allowed in the model reduces crop production significantly. Increasing temperature decreases production more than it decreases the time to harvest, so productivity in edible biomass per meter squared per day is greater at nominal than maximum temperatures, The productivity in edible biomass per meter squared per day is greatest at the maximum light energy input allowed in the model, but the edible biomass produced per light energy input unit is lower than at nominal light levels. Reducing light levels increases light and power use efficiency. The MEC models suggest we can adjust the light energy day-to- day to accommodate power shortages or Lise excess power while monitoring and controlling edible biomass production.

Jones, Harry↗
NASA NTRS2013

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗
NASA NTRS2003

Point to Point Control of the Hydrogen Mixer

We continue to build on the theoretical modelling of a liquid hydrogen (LH2) and gas hydrogen (GH2) mixer subsystem. The mixer described in this work is responsible for combining high pressure LH2 and GH2 to produce a hydrogen flow that meets certain thermodynamic properties. The desired properties are maintained by precise control of the LH2 and GH2 flows. The mixer is modelled as a general multi-flow lumped volume for single constituent fluids using density and internal energy as states. The set of nonlinear differential equations is modelled in the SIMULINK environment including a table look-up feature of the fluid thermodynamic properties. A small signal (linear) model is developed based on the nonlinear model and simulated as well. Pulse disturbances are introduced to the valve positions and the quality of the linear model is ascertained by comparing its behavior against the nonlinear model simulations. Valve control strategies that simulate an operator-in-the-loop scenario are then explored demonstrating the need for automatic feedback control. Finally, optimal single-output and multi-output Proportional/Integral controllers are designed based on the linear model and applied to the nonlinear model with excellent results to track simultaneous, constant setpoint changes in desired exit flow, exit temperature, and mixer pressure, as well as to reject unmeasureable but bounded additive step perturbations in the valve positions.

Barbieri, Enrique↗
NASA NTRS2003

Small Signal Point-to-Point Tracking of a Propellant Mixer

This paper addresses some theoretical modelling and control issues for a mixing chamber used in rocket engine testing at NASA Stennis Space Center. The mixer is responsible for combining high pressure LH2 and GH2 to produce a hydrogen flow that meets certain thermodynamic properties before it is fed into a test article. The desired properties are maintained by precise control of the LH2 and GH2 flows. The mixer is modelled as a general multi-flow lumped volume for single constituent fluids using density and internal energy as states. The set of nonlinear differential equations is modelled in the SIMULINK environment including a table look-up feature of the fluid thermodynamic properties. a small-signal (linear) model is developed based on the nonlinear model and simulated as well. Pulse disturbances are introduced to the valve positions and the quality of the linear model is ascertained by comparing its behavior against the nonlinear model simulations. Valve control strategies that simulate an operator-in-the-loop scenario are then explored demonstrating the need for automatic feedback control. Finally, classical optimal single-output and multi-output Proportional/Integral controllers are designed based on the linear model and applied to the nonlinear model with excellent results to track simultaneous, constant setpoint changes in desired exit flow, exit temperature, and mixer pressure, as well as to reject unmeasurable but bounded additive step perturbations in the valve positions.

Barbieri, Enrique↗
NASA NTRS2011

Thermal Management Tools for Propulsion System Trade Studies and Analysis

Energy-related subsystems in modern aircraft are more tightly coupled with less design margin. These subsystems include thermal management subsystems, vehicle electric power generation and distribution, aircraft engines, and flight control. Tighter coupling, lower design margins, and higher system complexity all make preliminary trade studies difficult. A suite of thermal management analysis tools has been developed to facilitate trade studies during preliminary design of air-vehicle propulsion systems. Simulink blocksets (from MathWorks) for developing quasi-steady-state and transient system models of aircraft thermal management systems and related energy systems have been developed. These blocksets extend the Simulink modeling environment in the thermal sciences and aircraft systems disciplines. The blocksets include blocks for modeling aircraft system heat loads, heat exchangers, pumps, reservoirs, fuel tanks, and other components at varying levels of model fidelity. The blocksets have been applied in a first-principles, physics-based modeling and simulation architecture for rapid prototyping of aircraft thermal management and related systems. They have been applied in representative modern aircraft thermal management system studies. The modeling and simulation architecture has also been used to conduct trade studies in a vehicle level model that incorporates coupling effects among the aircraft mission, engine cycle, fuel, and multi-phase heat-transfer materials.

McCarthy, Kevin↗
NASA NTRS2024

Summary of Model-based Attitude Control of LUVOIR in Modular Dynamic Analysis (MDA) Simulink Environment

This document overviews the work I completed in the second half of my summer 2018 internship experience in Code 591 at NASA Goddard Space Flight Center. Please see the former memorandum for additional context on the project. The take away point is that LUVOIR A has been modeled as three rigid bodies linked by 1-DOF rotary joints. An LQR attitude controller was designed for precision pointing of the spacecraft with the design requirement that steady state oscillations have amplitude less than a miliarcsecond. The performance of the algorithm was tested in the Modular Dynamic Analysis Simulink library developed by J. Roger Chen at NASA Goddard. While the initial simulations were of rigid bodies, subsequent simulations included flexible body modes on all three bodies of the model. The simulated structural deformations initially destabilized the LQR controller thus requiring a redesign of the K gain matrix. The final simulation demonstrated a stabilizing feedback gain with miliarcsecond precision within 400 minutes. This run used 20 modes on the spacecraft, 9 on the bus, and 100 on the payload. Future recommended work includes the development of a Vibration Isolation and Precision Pointing System (VIPPS) Simulink model. Armed with this model, the system should be modeled as four bodies whose associated flexible files must be generated from the spacecraft through Gimbal 1, Gimbal 1 through Gimbal 2, Gimbal 2 through the VIPPS interface, and the VIPPS interface through the payload.

William Bentz↗
DOE OSTI2024

The Digital Engineering Vision for DOME: Facilitating Design, Deployment, and Operations [Poster]

DOME is a planned microreactor test facility at INL’s Materials and Fuels Complex. It is a complex system with several interdependent sub-systems such as the reactor (up to 20 MWth), radioactive confinement, temperature and pressure regulation system, ventilation system, etc. The engineering design process for such a system traditionally involves several documents from various sources and the system information is scattered across these documents. Digital engineering represents a paradigm shift through which systems are designed using digital models and integrated data. The digital engineering vision for DOME utilizes a model-based systems engineering (MBSE) approach. The system architecture, physical components, control logic, and verification experiments are all designed using MathWorks MATLAB and Simulink. This hierarchical model can combine data from multiple sources at various levels of abstraction. It can be used to simulate the facility’s operations and to test the system using different sets of parameters. Its capabilities can be expanded by interfacing it with high-fidelity multi-physics models, risk analysis tools, etc. The same model can evolve into a digital twin that can monitor operations and conduct predictive analysis using real-time sensor data from the facility. The eventual goal of this effort is to transform the end-to-end engineering of nuclear facilities in every phase of their lifecycle, including design, deployment, and operations.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗