Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Hardware in the loop”

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 37 records · Page 2

Design and Benchmarking of a Network-In-the-Loop Simulation for Use in a Hardware-In-the-Loop System

Distributed engine control (DEC) systems alter aircraft engine design constraints be- cause of fundamental differences in the input and output communication between DEC and centralized control architectures. The change in the way communication is implemented may create new optimum engine-aircraft configurations. This paper continues the exploration of digital network communication by demonstrating a Network-In-the-Loop simulation at the NASA Glenn Research Center. This simulation incorporates a real-time network protocol, the Engine Area Distributed Interconnect Network Lite (EADIN Lite), with the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) software. The objective of this study is to assess digital control network impact to the control system. Performance is evaluated relative to a truth model for large transient maneuvers and a typical flight profile for commercial aircraft. Results show that a decrease in network bandwidth from 250 Kbps (sampling all sensors every time step) to 40 Kbps, resulted in very small differences in control system performance.

Networked Systems↗

Design and Benchmarking of a Network-In-the-Loop Simulation for Use in a Hardware-In-the-Loop System

Distributed engine control (DEC) systems alter aircraft engine design constraints because of fundamental differences in the input and output communication between DEC and centralized control architectures. The change in the way communication is implemented may create new optimum engine-aircraft configurations. This paper continues the exploration of digital network communication by demonstrating a Network-In-the-Loop simulation at the NASA Glenn Research Center. This simulation incorporates a real-time network protocol, the Engine Area Distributed Interconnect Network Lite (EADIN Lite), with the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) software. The objective of this study is to assess digital control network impact to the control system. Performance is evaluated relative to a truth model for large transient maneuvers and a typical flight profile for commercial aircraft. Results show that a decrease in network bandwidth from 250 Kbps (sampling all sensors every time step) to 40 Kbps, resulted in very small differences in control system performance.

Networked Systems↗

Multi-Core Microcontroller Hardware In the Loop System for Electric Machine Control

Hardware in the Loop (HIL) is a simulation technique used to reduce the software development cycle and test control systems in a non-destructive environment. This work describes a cost effective HIL simulator on a dual core microcontroller in which one core acts as a controller and the other emulates the system under control. The emulator runs one step per Pulse Width Modulation (PWM) period in real time. To handle the computational burden and prioritize execution of simulation and control tasks, an interrupt-based software architecture with task prioritization has been developed. As a demonstration, the HIL has been implemented on a Texas Instruments TMS320F28379D dual core microcontroller, which emulates a Permanent Magnet Synchronous Machine (PMSM) with resolver feedback. Hardware peripherals are developed and tested concurrently with the control system, providing higher confidence in the software. By using the peripherals in the HIL development, the controller exercises either the HIL emulation or a pin compatible PMSM testbench. To quantify performance and validate the processor based emulator, the HIL results are compared to the preexisting testbench for accuracy benchmarking at no-load and under load for a range of operating points.

33 ADVANCED PROPULSION SYSTEMS↗

Using Hardware-In-The-Loop Methodology to Develop Test Systems

Hardware in the Loop (HIL) testing methodologies have become widespread in industry. Typically, they focus on developing control algorithms for systems such as autonomous vehicles or aircraft. An oft overlooked aspect of product development is the design and fabrication of a test system for validating that the product meets requirements. Abstractly, a test system differs little from a control system—testers provide signals to the unit, monitor feedback, and base decisions on the results. While the time scales may differ, the functionalities are conceptually similar. Viewed in this light, it becomes natural to extend HIL approaches to tester development. By replacing a physical unit with a proxy model deployed to a real-time or pseudo real-time target, test systems can be developed in parallel with the design and fabrication of a first production unit. This saves considerable time in the life cycle from conceptual design to realized product. This manuscript demonstrates the process flow using a capacitive discharge unit as an exemplar.

42 ENGINEERING↗

PBE-HIL (Powering the Blue Economy Hardware-in-the-Loop models) [SWR-25-37]

Powering the Blue Economy Hardware-in-the-Loop models (PBE-HIL) is a repository of Power Hardware-in-the-loop models developed for typical Powering the Blue Economy market loads and power requirements. The HIL models were developed to be as generic and functional as possible, meaning that the user can easily configure these models to represent their unique PBE design. These PBE load and power requirement HIL models can then be used to inform marine energy converter (MEC) and power electronics design, as well as be used in laboratory testing using HIL equipment, leading to improved understanding of MEC performance and lower risk prior to open-water MEC deployment.

Labuschagne, Hannes [National Renewable Energy Lab↗

Integrated Application of Active Controls (IAAC) technology to an advanced subsonic transport project: Test act system validation

The primary objective of the Test Active Control Technology (ACT) System laboratory tests was to verify and validate the system concept, hardware, and software. The initial lab tests were open loop hardware tests of the Test ACT System as designed and built. During the course of the testing, minor problems were uncovered and corrected. Major software tests were run. The initial software testing was also open loop. These tests examined pitch control laws, wing load alleviation, signal selection/fault detection (SSFD), and output management. The Test ACT System was modified to interface with the direct drive valve (DDV) modules. The initial testing identified problem areas with DDV nonlinearities, valve friction induced limit cycling, DDV control loop instability, and channel command mismatch. The other DDV issue investigated was the ability to detect and isolate failures. Some simple schemes for failure detection were tested but were not completely satisfactory. The Test ACT System architecture continues to appear promising for ACT/FBW applications in systems that must be immune to worst case generic digital faults, and be able to tolerate two sequential nongeneric faults with no reduction in performance. The challenge in such an implementation would be to keep the analog element sufficiently simple to achieve the necessary reliability.

Source record↗

Advanced Power-Hardware-in-the-Loop Evaluation of Inverter-Based Resources (IBRs)

Power-hardware-in-the-loop evaluation of IBRs has become more and more important as it provides reliable testing results to investigate the real responses of inverters with interconnected systems. A successful laboratory PHIL testing gives confidence of the hardware system to be deployed and de-risk technology integration prior to field deployment. So far, there are two important applications for PHIL evaluation: (1) test stability and functionality of large utility inverters into the system when it interconnects to the distribution systems/microgrids; and (2) test the collective grid service that inverters can provide to the grid. For the first application, the PHIL evaluation has high requirements for the stability and accuracy of the PHIL interface as the close-loop in digital real time simulator (DRTS) should replicate the actual current and voltage dynamics in the inverter. This is challenging because of the delays, sensing errors, nonlinearities of inverters, and hardware bandwidth limitations of the elements in the HIL loop. For the second application, multiple inverters will be tested resulting in multiple PCCs, which naturally causes competing dynamics and oscillations among hardware inverters if traditional PHIL interface is used. Therefore, new PHIL interface should be developed to compromise between stability and accuracy and represent the dispatched grid services for the hardware inverters. In this presentation, we will share our latest work in developing PHIL interface in these two applications to address the two key challenges.

DERMS↗

Orion Hardware In The Loop OIMU Stimulation Latency Effect on Navigation State Estimation

Because Hardware In The Loop (HITL) testing involves the integration of flight software and flight hardware on the ground, non-flight-like effects may arise. One of these non-flight-like effects includes Inertial Measurement Unit (IMU) stimulation latency that affects the time in which the measurement is received by the Extended Kalman Filter (EKF). This paper seeks to present the extent to which this stimulation latency affects the navigational state estimate from the Orion navigation system for all phases of flight for Artemis II.

Christopher A Ertl↗

Orion Hardware In The Loop OIMU Stimulation Latency Effect on Navigation State Estimation

Because Hardware In The Loop (HITL) testing involves the integration of flight software and flight hardware on the ground, non-flight-like effects may arise. One of these non-flight-like effects includes Inertial Measurement Unit (IMU) stimulation latency that affects the time in which the measurement is received by the Extended Kalman Filter (EKF). This paper seeks to present the extent to which this stimulation latency affects the navigational state estimate from the Orion navigation system for all phases of flight for Artemis II.

Christopher A Ertl↗

An Environmental for Hardware-in-the-Loop Formation Navigation and Control

Recent interest in formation flying satellite systems has spurred a considerable amount of research in the relative navigation and control of satellites. Development in this area has included new estimation and control algorithms as well as sensor and actuator development specifically geared toward the relative control problem. This paper describes a simulation facility, the Formation Flying Test Bed (FFTB) at NASA Goddard Space Flight Center, which allows engineers to test new algorithms for the formation flying problem with relevant GN&C hardware in a closed loop simulation. The FFTB currently supports the inclusion of GPS receiver hardware in the simulation loop. Support for satellite crosslink ranging technology is at a prototype stage. This closed-loop, hardware inclusive simulation capability permits testing of navigation and control software in the presence of the actual hardware with which the algorithms must interact. This capability provides the navigation or control developer with a perspective on how the algorithms perform as part of the closed-loop system. In this paper, the overall design and evolution of the FFTB are presented. Each component of the FFTB is then described. Interfaces between the components of the FFTB are shown and the interfaces to and between navigation and control software are described. Finally, an example of closed-loop formation control with GPS receivers in the loop is presented.

Burns, Rich↗

An Environment for Hardware-in-the-Loop Formation Navigation and Control Simulation

Recent interest in formation flying satellite systems has spurred a considerable amount of research in the relative navigation and control of satellites. Development in this area has included new estimation and control algorithms as well as sensor and actuator development specifically geared toward the relative control problem. This paper describes a simulation facility, the Formation Flying Testbed (FFTB) at NASA's Goddard Space Flight Center, which allows engineers to test new algorithms for the formation flying problem with relevant GN&C hardware in a closed loop simulation. The FFTB currently supports the injection of GPS receiver hardware into the simulation loop, and support for satellite crosslink ranging technology is at a prototype stage. This closed-loop, hardware inclusive simulation capability permits testing of navigation and control software in the presence of the actual hardware with which the algorithms must interact. This capability provides the navigation or control developer with a perspective on how the algorithms perform as part of the closed-loop system. In this paper, the overall design and evolution of the FFTB are presented. Each component of the FFTB is then described in detail. Interfaces between the components of the FFTB are shown and the interfaces to and between navigation and control software are described in detail. Finally, an example of closed-loop formation control with GPS receivers in the loop is presented and results are analyzed.

Burns, Rich↗

Grid impact analysis using controller-hardware-in-the-loop for high-power vehicle charging stations

A controller-hardware-in-the-loop (CHIL) architecture for the evaluation of grid impacts arising from high-power vehicle charging stations is presented in this paper. Unlike simulation-based studies, the proposed method can be used to capture the interactions of the grid and the charging load along with charger controllers in real time. The proposed method can be used to evaluate the impact of charging load on the grid in terms of voltage variations and line congestion. The proposed CHIL platform allows for de-risking the vehicle charging station deployment by simulating the complex interactions among all the components of a vehicle charging station - i.e., the grid, vehicle, and charger controller - in a realistic manner before using the charging station in a grid. Further, the proposed CHIL approach can be used to evaluate the voltage regulation causalities of the vehicle charging station. Experimental results are presented in the paper to illustrate the applicability of the proposed method in a laboratory environment.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

Novel Power-Hardware-in-the-Loop Interface Method for Grid-Forming Inverter Systems

Power-hardware-in-the-loop (PHIL) simulations of grid-forming (GFM) inverter systems facilitate the testing of drastic scenarios, such as on-grid to off-grid transitions and islanded microgrid operations without a stiff grid. To the authors’ best knowledge, most studies in the literature focus on PHIL simulations for grid-following inverter systems. Only a few studies focus on GFM inverters, and those are challenging and problematic, especially for high-power applications. This article proposes a novel PHIL simulation platform that enables interfacing high-power GFM inverter systems. The paper proposes the concept of a virtual GFM inverter as a part of the proposed PHIL interface. This addition of a virtual GFM inverter in the PHIL interface expands the conventional ideal transformer model (ITM) method and enables it to overcome the issues of instability of existing ITM methods. In the validation stage, a PHIL experiment is conducted on a three-phase, 480-V, 125-kVA GFM inverter system with the proposed interfacing method. The results corroborate that the proposed PHIL simulation method performs well and is stable for GFM inverter systems.

droop control↗

BENEFIT with Northeastern University: HVAC Hardware-in-the-Loop Experimental Testing of a Heat Pump and Air Conditioner

This dataset includes HVAC Hardware-in-the-Loop (HIL) experimental results for a single stage, SEER 16, HSPF 9.5, 3-ton single-speed air source heat pump with 15 kW of backup auxiliary heating tested in both cooling and heating mode, and a two stage, SEER 21, 2-ton central air conditioner tested in cooling mode for a set of outdoor temperatures and indoor setpoint temperatures. In addition to these tests, experimental tests focused on the operation of auxiliary heating for the heat pump for winter condition were also conducted. The laboratory experiments for transient testing of the heat pump and air conditioner were conducted using the two HIL systems in the Systems Performance Laboratory (SPL) at NREL’s Energy Systems Integration Facility (ESIF). Further information on laboratory design and capabilities of the SPL along with the architecture of HVAC HIL system can be found in: Sparn, B. F. 2018. Laboratory Resources and Techniques to Evaluate Smart Home Technology (No. NREL/CP-5500-71696). National Renewable Energy Laboratory (NREL), Golden, CO (United States). https://www.nrel.gov/docs/fy18osti/71696.pdf and the experimental setup and validation of HVAC HIL platform can be found in: Ramaraj, S. and Sparn, B. 2022. Validation of HVAC Hardware-In-the-Loop Simulation for Advanced Control Strategies in Smart Homes (No. NREL/CP-5500-82562). National Renewable Energy Lab (NREL), Golden, CO (United States). https://www.nrel.gov/docs/fy22osti/82562.pdf. These experimental results can be used to validate how we currently model the cycling behavior of heat pumps and air conditioners. Additionally, many demand response programs implement heat pump and air conditioner control by changing the thermostat set point – these data may also be used to verify our models for heat pump and air conditioner demand response control are implemented correctly. The Test_Matrix file describes all the indoor and outdoor test conditions for heat pump and air conditioner and the file names of data sets include information about the test conditions. A wide range of outdoor air temperatures were chosen to accommodate summer and winter conditions. In addition to operating the HVAC equipment with different outdoor temperatures, we also operate the system with different indoor temperature set points to represent different grid signals or different operating conditions. For cooling conditions, the baseline set point is 72°F. To represent Load Up signals, the setpoint is changed to 68°F. The Load Shed set point is 76°F. For heating conditions, the baseline set point was assumed to be 68°F. The Load add set point is 72°F and the Load shed set point is 64°F. The starting indoor temperature for cooling conditions was set ~2°F above the indoor setpoint temperature so that the equipment turned on quickly. Similarly, the initial indoor temperature was set ~2°F lower than setpoint for heating mode tests to ensure that heating began quickly. The return air temperature was assumed to be equal to the indoor setpoint temperature in all cases. The experimental data are sampled at 1-second intervals. The data from ecobee thermostat at 5-minute interval are resampled and added to the corresponding file. The content of each data set is as follows: • T_Return (C): Measured return air temperature [C] • T_Return_SP (C): Return air temperature setpoint from E+ model, sent to HIL [C] • T_Supply (C): Measured supply air temperature at evaporator outlet [C] • T_Outdoor (C): Measured outdoor air temperature [C] • T_Outdoor_SP (C): Outdoor air temperature setpoint from weather file, sent to HIL [C] • T_Indoor (C): Measured indoor air temperature [C] • T_Indoor_SP (C): Indoor air temperature setpoint from E+ model, sent to HIL [C] • Outdoor Unit Power (W): Measured power of the outdoor unit [W] • Indoor Unit Power (W): Measured power of the indoor unit [W] • Evaporator Airflow Rate (CFM): Measured evaporator or indoor unit airflow rate sent to E+ model [CFM] • Cooling/Heating Capacity (kW): Calculated cooling/heating capacity sent to E+ model [kW] • T_SP_Thermostat (C): Thermostat cooling/heating setpoint temperature [C] • T_Indoor_Thermostat (C): Thermostat indoor air temperature [C]

24 POWER TRANSMISSION AND DISTRIBUTION↗

A Novel Power-Hardware-in-the-Loop Interface Method for Grid-forming Inverter Systems: Preprint

Power Hardware-in-the-Loop (PHIL) simulation of grid-forming (GFM) inverter systems facilitates the testing of drastic scenarios like on-grid to off-grid transition, islanded microgrid operation without stiff grid etc. To the authors best knowledge, most of studies in literature are focused on PHIL simulation for grid-following inverter systems and only few studies are focused on GFM inverters and those are challenging and problematic especially for high-power applications. In this article, a novel PHIL simulation platform is proposed that enables interfacing of high-power GFM inverter systems. It proposes the concept of a virtual GFM inverter as a part of the proposed PHIL interface for GFM inverter. This addition of virtual GFM inverter in the PHIL interface expands the conventional Ideal Transformer Model (ITM) method and enables it to overcome the issues of instability of existing ITM methods. In the validation stage, a PHIL experiment is conducted on a 3-phase 480 V, 125 kVA GFM inverter system with proposed interfacing method. The results corroborates the fact that the proposed PHIL simulation method performs well and stable for GFM inverter system.

grid-forming inverters↗

A full-scope, high-fidelity simulator-based hardware-in-the-loop testbed for comprehensive nuclear power plant cybersecurity research

Nuclear power plant (NPP) cybersecurity research often relies on hardware-in-the-loop (HIL) testbeds that integrate real hardware components into simulated environments. These testbeds allow researchers to identify vulnerabilities, evaluate attack impacts, and test security measures in a controlled setting. Furthermore, previous HIL testbeds lacked fidelity to accurately represent real nuclear systems, limiting the scope of cybersecurity analysis. This study presents the creation of a HIL testbed, devised upon a full-scope, high-fidelity NPP simulator, to facilitate realistic and comprehensive cybersecurity research. To demonstrate its capabilities, the control logic for the steam generator water level was migrated from the simulator to an external programmable logic controller. As a practical application of the developed testbed, supply chain attack scenarios were simulated by injecting malicious code into the controller logic, and the effects of manipulating sensor inputs and control commands were observed. While this HIL testbed provides more detailed simulations, enhanced realism, and wider applicability compared to other options utilizing a less complex simulator, it is also more intricate and costly. For this reason, we include a detailed comparison with some alternative architectures to aid fellow researchers and practitioners in the selection of a suitable HIL architecture based on specific research objectives.

47 OTHER INSTRUMENTATION↗

NASA MSFC hardware in the loop simulations of automatic rendezvous and capture systems

Two complementary hardware-in-the-loop simulation facilities for automatic rendezvous and capture systems at MSFC are described. One, the Flight Robotics Laboratory, uses an 8 DOF overhead manipulator with a work volume of 160 by 40 by 23 feet to evaluate automatic rendezvous algorithms and range/rate sensing systems. The other, the Space Station/Station Operations Mechanism Test Bed, uses a 6 DOF hydraulic table to perform docking and berthing dynamics simulations.

Tobbe, Patrick A.↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗