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 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↗
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↗
NASA NTRSDate not supplied

Evaluation of Precision Landing Performance Using A Generalized Aerospace Simulation in Simulink Framework

NASA’s science and exploration goals to return to the Moon and beyond will need to perform precision landings to place humans and cargo supplies near places of scientific interest, surface resources, or pre-established basecamps. With the maturation of new navigation technology, such as terrain relative navigation, precision landing is now feasible, enabling new exploration sites, such as the lunar poles. However, verification of precision landing performance becomes crucial since not reaching the designated landing site would have a high risk of loss of mission. Therefore, having a high-fidelity simulation platform to evaluate six degrees of freedom vehicle performance during high-risk phases of flight such landing is a fundamental part of the system verification and risk reduction. The NASA Marshall Space Flight Center has developed the GeneraLized Aerospace Simulation in Simulink® (GLASS) tool which incorporates guidance, navigation, and control algorithms, as well as vehicle and environmental models, such as gravity, vehicle mass properties, navigation sensors, propulsion, and terrain models. GLASS uses the MathWorks® Simulink® environment which provides a model-based design framework that allows the incorporation of vehicle models in a modular architecture. The Simulink® environment provides seamless integration with all the MathWorks® capabilities and toolboxes, such as control design toolboxes and Simscape™ Multibody™ dynamics toolbox. The MathWorks® environment also allows for guidance, navigation, and control algorithms to be auto coded in C language, enabling quick software and hardware in the loop testing. This paper provides an overview of GLASS capabilities for analyzing precision landing performance, including navigation trades applied to a NASA human lander reference design architecture.

Guidance↗
NASA NTRS2008

Tool Support for Parametric Analysis of Large Software Simulation Systems

The analysis of large and complex parameterized software systems, e.g., systems simulation in aerospace, is very complicated and time-consuming due to the large parameter space, and the complex, highly coupled nonlinear nature of the different system components. Thus, such systems are generally validated only in regions local to anticipated operating points rather than through characterization of the entire feasible operational envelope of the system. We have addressed the factors deterring such an analysis with a tool to support envelope assessment: we utilize a combination of advanced Monte Carlo generation with n-factor combinatorial parameter variations to limit the number of cases, but still explore important interactions in the parameter space in a systematic fashion. Additional test-cases, automatically generated from models (e.g., UML, Simulink, Stateflow) improve the coverage. The distributed test runs of the software system produce vast amounts of data, making manual analysis impossible. Our tool automatically analyzes the generated data through a combination of unsupervised Bayesian clustering techniques (AutoBayes) and supervised learning of critical parameter ranges using the treatment learner TAR3. The tool has been developed around the Trick simulation environment, which is widely used within NASA. We will present this tool with a GN&C (Guidance, Navigation and Control) simulation of a small satellite system.

Schumann, Johann↗
NASA NTRSDate not supplied

Capturing and Analyzing Requirements with FRET

FRET is an open source tool, developed at NASA Ames, for writing, understanding, formalizing, and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. FRET helps users write FRETish requirements both by providing grammar information and examples during editing, but also through English and diagrammatic explanations to clarify subtle semantic issues. For each requirement, FRET automatically produces formalizations and supports interactive simulation of produced formalizations to ensure that they capture user intentions. Through its analysis portal, FRET connects to analysis tools by exporting verification code. Currently FRET connects to (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs. FRET also supports the consistency/realizability analysis of requirements for identifying conflicting requirements. In this tutorial, we introduce FRET and learn to speak and analyze FRETish through several examples.

FRET↗