Printer Friendly

Utilizing Behavioral Models in Experimental Hardware-in-the-Loop.


This paper introduces a method for conducting experimental hardware-in-the-loop (xHIL), in which behavioral-level models are coupled with an advanced power emulator (APE) to emulate an electrical load on a power generation system. The emulator is commanded by behavioral-level models running on an advanced real-time simulator that has the capability to leverage Central Processing Units (CPUs) and field programmable gate arrays (FPGA) to meet strict real-time execution requirements. The paper will be broken down into four topics: 1) the development of a solution to target behavioral-level models to an advanced, real-time simulation device, 2) the development of a high-bandwidth, high-power emulation capability, 3) the integration of the real-time simulation device and the APE, and 4) the application of the emulation system (simulator and emulator) in an xHJL experiment. The first topic will be addressed by targeting a behavioral-level model of a brushless dc motor drive with a pulse-width modulated inverter to a real-time simulator. The results of the real-time model will be compared to that of its non-real-time counterpart. For the second topic, hardware descriptions and data will be presented showing the APE's ability to track high-frequency command profiles. The third topic will cover the communication requirements and methods used for integrating the real-time simulator with the APE. Finally, for the last topic, the APE and real-time simulator will be integrated to emulate the brushless motor's dc-link current drawn by the inverter in a hardware experiment. In using the APE and the real-time simulator, it will be shown that it is possible to run detailed electrical models in real-time and emulate detailed electrical characteristics in hardware without requiring the actual hardware component. In following this process, it is possible to reduce risk and accelerate hardware and software development.

CITATION: Miller, C. and Boyd, M., "Utilizing Behavioral Models in Experimental Hardware-in-the-Loop," SAE Int. J. Aerosp. 9(1):2016, doi: 10.4271/2016-01-2042.


Physics-based modeling of integrated systems exists at four levels of detail: device physical, behavioral, functional, and architectural [1]. This paper will focus on behavioral-level models that aim to capture nonlinearities to better understand power quality, peak and regenerative power, and failure modes. The first topic of this paper is to evaluate a procedure to incorporate behavioral-level models of an electrical power system (EPS) into an xHIL system. Behavioral-level models pose a computational challenge, in which results generally take hours, or days, of actual time for fractional amounts of simulation time. In an attempt to mitigate this issue, there are two common solution implemented. In the first method, simulations are typically focused on a short, predetermined time range, in which the states of the system are initialized to known critical events [2]. This presumes there is prior, detailed knowledge of the system and its interactions and that critical events can easily be discovered and reproduced. In the second method, model fidelity and dynamics are removed from the model. This inherently increases the execution speed of the model but does this at a cost of model accuracy. Therefore, there is a desire to increase the execution speed of detailed, behavioral-level models thus decreasing the overall simulation time required. By leveraging the speed of advanced computational devices, it is possible to execute behavioral-level models in real-time so they can be used in xHIL experiments. One could also benefit from increased model execution speeds for simulation-only based analysis since the direct outcome of increased execution speeds is a higher throughput of simulation results. For example, an optimization routine, previously too computationally intensive and not practical, may now be feasible using an advanced computational device. Even running a model at real-time, a run time ratio (RTR) of one, a behavioral model execution would be 10-2000 times faster.

Coupling hardware to software introduces more system interactions that can lead to identifying potentially unknown interactions. xHIL is a technique that focuses on the integration of multiple system components in an attempt to detect unknown interactions early in the development cycle. In an xHIL experiment, both the plant and controller are hardware components with emulated and/or simulated subsystems supplying boundary conditions to each other [1]. Historically, the Air Force Research Laboratory, Aerospace Systems Directorate has primarily focused on using dynamotors to emulate a turbine engine [3., 4, 5., 6, 7, 8]. In these scenarios, a model of an engine is executed on a real-time simulator and is emulated, in hardware, by sending shaft speed commands to a dynamotor that tracks the command. Models of mechanical systems, such as this, are simulated with large time constants lending themselves to a real-time simulator using a traditional CPU based architecture. A communication bandwidth of 200Hz between simulator and emulator is sufficient to track the command [3]. Detailed electrical system models are simulated using much smaller time constants, and therefore are more challenging to execute under a traditional architecture that will need to communicate at a much higher bandwidth. The APE will be used to address the requirement for high-bandwidth emulation of electrical system components. In a similar fashion as the drive stand, the APE can be used in an xHIL experiment to provide dynamic and interactive boundary conditions to the EPS. Command signals from a model can be sent to the APE at a sufficiently high-bandwidth such that the signals are accurately reproduced in hardware. An APE can be commanded to emulate a system component or device under test, creating dynamic stimulus to test hardware, providing a more realistic operating scenario with more relevant boundary conditions. As a result of coupling detailed models with highly-dynamic emulation devices, this capability can be used to identify system integration issues prior to hardware build or system integration, or in support of upgrades to fielded systems [8, 9].


A model of a well-documented and understood brushless DC motor (BLDC) was chosen to assess the performance of a real-time simulator. The BLDC schematic shown in Figure 1 is of a three-phase, Y-connected, permanent magnetic synchronous machine. The particular circuit model is described in detail in [10]. The final evaluation of the solution would use an implementation of a sine-triangle modulated BLDC motor drive, which is described in detail in [11].

This particular system was chosen for several reasons. First, it is representative of power electronic based loads that the APE is primarily designed to emulate. Second, it contains switching level dynamics that cannot be simulated on a standard CPU-based real-time target. The model has an average RTR of 19.6 on a high-power workstation computer. In order to meet real-time requirements, a more advanced computational architecture would need to be utilized. Lastly, the resources exist to provide the hardware power and signal requirements for the various system components. In this case, the hardware/software interface will be established at the dc-link. The dc voltage is supplied physically in hardware, with the inverter, motor, and associated controls simulated on the real-time simulator and [i.sub.dc] emulated by the APE as a load on the dc supply, as shown in Figure 2.

Using the BLDC model as a challenge problem, multiple real-time simulation solutions were investigated in an attempt to find a system that was able to not only meet the real-time simulation requirements, but also be effectively applied to an xHIL experiment. A proposed Opal-RT solution was determined to have the least risk as both the hardware and the software capability existed to fulfill both requirements.

The solution proposed involves combining two different computational architectures into a single real-time simulator. The first, more commonly used architecture, utilizes a commercial off-the-shelf CPU that is used to execute larger time step models. These typically execute at a rate of ten or more microseconds with common examples being basic control algorithms, averaged value circuit models, and basic physical models (e.g. ideal AC power generation and transformers) [13], The second computational architecture uses a FPGA to execute behavioral-level models at time steps faster than a model's switching frequency allowing for accurate convergence. Opal-RT developed a specialized solver, called electric Hardware Solver (eHS), which is capable of solving complex behavioral-level models at time steps in the range of 100ns to l|xs [13], eHS is based on a linearized, discrete equivalent circuit method, in which an ideal switch is represented by a constant conductance in parallel with a current source [14], This method represents a closed switch as a small inductance and an open switch as a small capacitance. In order to keep the parallel conductance constant, thus keeping the solvable netlist equations the same throughout switching events, Equation 1 must hold true throughout the simulation [15]. In Equation 1 ,[G.sub.s] is the parallel conductance, C is the switch-off capacitance, L is the switch-on inductance, and dT is the discrete time step of the simulation.

[G.sub.s = c/dT = dT*L (1)

[G.sub.s] is a value the must be chosen by the development engineer, and choosing [G.sub.s] requires trial and error estimation as well as an understanding of the assumptions being made in choosing a particular value. Acceptable values of [G.sub.s] range from 0.001 to 10. Optimization of [G.sub.s] may also be required in order to achieve better results for a given circuit topology. For an ideal switch, having very small inductance and capacitance values are preferred, but may not always provide the best solution for a particular circuit.

Since the Opal-RT simulator leverages two separate computational architectures, the BLDC model was separated into multiple parts. The portion of the BLDC model that ran on the FPGA is shown in Figure 2 and was run at a rate of 175 ns. The CPU executed control algorithms for the FPGA model portion as well as the mechanical dynamics of the BLDC model, all of which executed at a rate of 40 [mu]s. Each system's time step is chosen by determining when the system is stable while maintaining real-time execution on its particular computational architecture. During a simulation the two separate computational methods would communicate to each other via an internal high-speed PCI Express (PCIe) bus. This would allow for negligible latency communication between the FPGA and CPU model systems. Using the coupled architectures, Opal-RT was able to achieve real-time, or RTR = 1, with the BLDC model. Since eHS is implemented on an FPGA, it has a finite number of components it can simulate. Out of the 16 inputs, 32 outputs, 64 switches (active and passive), and 170 non-switching devices (NSD) eHS can support for one system, 4 inputs, 16 outputs, 6 switches, and 6 NSDs were used for this example. Therefore, one could easily add to the complexity of the circuit or additional simulated devices. If more components than what is supported in a single solver of eHS, an additional solver may be added to the FPGA fabric space, assuming there is fabric space available for such additions.

The results between the non-real-time model and the real-time model correlate well, as shown in Figure 3. The time shift in the results is expected as it is an artifact from the results not being time synchronized during their execution. The output speed for the real-time model was 103.1 rad/sec that results in an error of 1.51% when compared to the reference, non-real-time model speed of 104.8 rad/sec.

Once the BLDC model was able to achieve real-time, the next step is to integrate the real-time simulator with the functional emulation device. Further description of the integration is described in the Section "Simulator and Emulator Integration".


The APE provides a flexible and reconfigurable dynamic testing capability that not only supports research in robust EPS and energy optimized aircraft, but can also expedite the design and development process for aircraft power systems [9]. The APE is a wideband, bidirectional, 100 kW power supply capable of emulating dynamic, complex sources and loads for power system components and architecture development. Its operating voltage range is 0 - 450V with an operating current range of [+ or -]500A (power limited to 100 kW) [12]. The APE can operate in three selectable modes of operation: (1) load mode, (2) source mode, and (3) fast source mode. In load mode, the APE can be commanded as a constant current, power, admittance, or any combination of the three described units. As previously stated, the APE is bi-directional, meaning that it is capable of producing regenerative energy back on to the experimental electrical bus. This functionality is necessary when investigating the effects of loads that regenerate energy back to the EPS and how they affect system stability. An example of a load that produces regenerative energy onto an electrical bus is an electro-mechanical actuator (EMA) [16], During control surface braking, the motor in the EMA acts like a generator, producing energy. Source mode and fast source mode both are set to provide a bus voltage for units-under-test. The difference is that in source mode, an output capacitance is present, which provides a stiff source increasing system stability but at the cost of the APE's ability to respond dynamically to bus load changes. In fast source mode, the APE's output capacitance is removed allowing for more dynamic regulation, but at the reduction of bus stiffness. The APE also has the ability to scale load power by being configured into a master/slave collection of up to 1.3 MW of rated power capability. In order for the APE to be an effective emulation device, it must be able to reproduce the frequency content present in its command signal, whether the command is from an offline profile or a real-time simulation. The APE has a measureable full-current (370 A @ 270 VDC) -3 dB cutoff frequency at 20 kHz and a small signal (15 A) -3 dB frequency cutoff at 40 kHz [17]. It is able to achieve this high frequency cutoff with low output ripple by utilizing a 10-stage interleaved output converter with a switching frequency of 100 kHz. Most aircraft electrical load characteristics are contained in frequencies lower than the APE's cutoff of 20 kHz, meaning that the APE should be able to accurately represent such aircraft loads. Figure 4 shows an example of the frequency content of a typical aircraft type load. An example of a hardware profile that the APE is capable of representing is shown in Figure 5. The APE is capable of matching not only the frequency content, but the magnitude and bi-directionality of the command signal.

In conjunction with a high-bandwidth emulator, another crucial aspect of dynamic load emulation is the ability to communicate real-time commands deterministically and with low latency. The APE achieves this functionality through the use of a fiber optic connection. With this connection the APE can receive commands from an offline profile containing highly-dynamic data or from live data produced from a real-time model. The rate of transfer for this communication is 2 MHz and required a custom protocol to be developed in order to achieve the high-throughput, low latency, and deterministic communication. The required combination of throughput, latency, and determinism is not possible on other forms of established communication protocols (e.g. GE Reflective Memory, CAN, and EtherCAT), therefore a custom protocol was developed. The same protocol is used to communicate between multiple APEs when the master/slave configuration is used. This means that there is negligible latency difference when commanding a single APE or 13 APEs. In order to achieve the required data throughput that this type of system requires, the custom fiber protocol was implemented on an FPGA.


Integration of the two previously described technologies utilizes the high-bandwidth, low latency fiber communication protocol previously described. The protocol was duplicated on the Opal-RT system in order for the real-time simulator to communicate with an APE deterministically. As was previously stated, the APE communication protocol resides on an FPGA, which is supported and included in the Opal-RT system. However, the FPGA used by Opal-RT had to be updated to one that supported small form-factor pluggable (SFP) devices. An SFP port is commonly used on FPGA devices to interface with fiber optic protocols. In order for Opal-RT to develop and test the APE communication protocol, they were provided a zero-watt APE. This device contains the same communication protocol, hardware boards, and FPGA that the full-scale APE contains, without output power stages providing an easily transportable debugging device that can fit in any computer with a PCIe slot. Aside from aiding APE communication development, the zero-watt APE can also be used as a risk reduction step to verify experiment commands prior to testing.


In order to fully test the emulation system laid out in the previous sections, a bi-directional power supply is required to complete a simple xHIL subsystem. The hardware layout used for the simple xHTL experiment is shown in Figure 6. In this simple hardware system, the APE will load the bi-directional power supply using commands from the Opal-RT real-time simulator. The model running on the simulation system is the same BLDC model that was described in the Real-Time Behavioral Model Simulation section. The command sent to the APE is the input bus current measured in the real-time simulator model. The bi-directional power supply has a much slower response than that of the APE and represents the typical aircraft source/load characteristics of having a slower responding source (e.g. generator) with a highly-dynamic load (e.g. EMA).

Using the simple xHIL system, open and closed-loop tests were run to compare the response of the two control schemes. For both tests, the APE command was the input bus current measured in the BLDC model. For the open-loop test, the input voltage was held constant at 200V and for the closed-loop test, the voltage measured by the APE was fed back via the fiber protocol to the real-time simulator and was used as the input voltage for the next time model step of the BLDC model. Current and voltage responses for each test can be seen in Figure 7. As depicted, there is a large variation in the bus voltage of the closed-loop test case. This was caused by the effect of loading the slower power supply with dynamic loads and the power supply not being able to properly regulate the bus to 200 V. That variation caused the current response of the bus current and Phase A current of the BLDC to contain amplitude modulations. Similar results can be seen in the speed and torque results, shown in Figure 8. Similar oscillations are visible in the closed-loop response that are not present in the open-loop response. If using a stiffer, more capable sourcing system, one would expect the closed-loop response to be more similar to that of the open-loop response with decreased, or nonexistent, oscillations.


Future work using the real-time simulator and emulation device will include expanding the application of emulated devices to those of higher-power and more relevance. Example components are power generation systems, EMAs, and pulse power loads. Each of these different applications provides a unique challenge that must be overcome in order to produce an accurate emulation system. They also provide the opportunity to scale the system allowing for a higher-power system test. Further investigation into how power quality and stability are affected by the application of highly-dynamic loads on an EPS will also be investigated. Finally, in order to represent a hardware component accurately, model accuracy must be at an appropriate level. Therefore, further investigation into how accurate a model must be to provide a particular result and methods of quantifying model accuracy will be performed.


This paper provided a method for conducting xHIL where a behavioral model commands an APE to emulate a component of an EPS. The challenge of executing behavioral models in real-time was accomplished through the use of an Opal-RT system that executed an example brushless dc motor model in real-time by coupling the execution of FPGA and CPU technologies. The APE was used to perturb actual electrical hardware from commands sent from the behavioral model. Due to the high-bandwidth capability of the APE, it was able to reproduce the command's frequency and magnitude content. Without the low-latency, high-bandwidth communication, the system would not be able to achieve the high level of response of which it is capable.


[1.] SAE International Aerospace Information Report, "Aircraft Electrical Power Systems Modeling and Simulation Definitions," SAE AIR 6326, Rev. Aug. 2015

[2.] Zumberge, J., Wolff, J., McCarthy, K., O'Connell, T. et al., "Integrated Aircraft Electrical Power System Modeling and Simulation Analysis," SAE Technical Paper 2010-01-1804. 2010, doi:10.4271/2010-01-1804.

[3.] Bash, M., Boyd, M., and Miller, C, "Transient Engine Emulation within a Laboratory Testbed for Aircraft Power Systems," SAE Int. J. Aerosp. 7(2):191-198, 2014, doi: 10.4271/2014-01-2170.

[4.] Ramalingam, S., Green, A., Lamm, P., Barnard, H. et al., "Integrated Hardware-in-the-Loop Simulation of a Complex Turbine Engine and Power System," SAE Technical Paper 2006-01-3035. 2006. doi :10.4271/2006-01-3035.

[5.] Corbett, M., Williams, J., Wolff, M., Walters, E. et al., "Transient Turbine Engine Modeling and Real-Time System Integration Prototyping," SAE Technical Paper 2006-01-3040. 2006, doi: 10.4271/-01-3040.

[6.] Corbett, M., Lamm, P., Owen, P., Phillips, S.D., Blackwelder, M., Alt, J.T., Mcnichols, J., Boyd, M., and Wolff, M., "Transient Turbine Engine Modeling with Hardware-in-the-Loop Power Extraction," 6th International Energy Conversion Engineering Conference (IECEC). 2008.

[7.] Corbett, M., Lamm, P., McNichols, J., Boyd, M. et al., "Effects of Transient Power Extraction on an Integrated Hardware-in-the-Loop Aircraft/Propulsion/Power System," SAE Technical Paper 2008-01-2926. 2008, doi: 10.4271/2008-01-2926.

[8.] Miller, C, Zumberge, J., Wolff, M., Boyd, M. et al., "Hardware-in-the-Loop Electric Drive Stand Issues for Jet Engine Simulation," SAE Technical Paper 2010-01-1810. 2010, doi:10.4271/2010-01-1810.

[9.] Zumberge, J., Corbett, M., Weimer, J., and Walters, E., "Advanced power emulator specification," April 2011.

[10.] Sudhoff, S. and Krause, P., "Operating modes of the brushless dc motor with a 120 degrees inverter," IEEE Transactions On Energy Conversion 5(3):558-564, 1990.

[11.] Krause, P., Wasynczuk, O, Sudhoff, S., and Pekarek, S., "IEEE Press Series on Power Engineering," Analysis Of Electric Machinery and Drive Systems 661-663, 2013.

[12.] Peterson, W., "APE brochure."

[13.] Belanger, J., Yamane, A., Cense, S., Robert, P. Y., "Validation of eHS FPGA Reconfigurable Low-Latency Electric and Power Electronic Circuit Solver," Industrial Electronics Society, IECON 2013 - 39th Annual Conference of the IEEE 5418-5423, Nov 2013.

[14.] Pejovic, P., "A Method for Fast Time-Domain Simulation of Networks with Switches," IEEE Transactions on Power Electronics Vol. 9, Jul 1994.

[15.] Ould-Bachir, T, Merdassi, A., Cense, S., F.-Blanchette, H, Belanger, J., "FPGA-based Real-Time Simulation of a PSIM Model: An Indirect Matrix Converter Case Study," Nov 2015.

[16.] Racine, E., Lammers, Z., Barnett, S., Murphy, J. et al., "Energy Analysis of Electromechanical Actuator under Simulated Aircraft Primary Flight Control Surface Load," SAE Technical Paper 2014-01-2182. 2014. doi :10.4271/2014-01-2182.

[17.] Bash, M., Pekarek, S., and Zumberge, J., "The Utility of Wide-Bandwidth Emulation to Evaluate Aircraft Power System Performance," SAE Int. J. Aerosp. 9(l):14-22, 2016, doi:10.4271/2016-01-1982.


This research was funded by the Air Force Research Laboratory, Aerospace Systems Directorate, 88ABW-2016-2159. The authors would like to acknowledge E&M Power and Timberlake Design for engineering software and hardware for the advanced power emulator and Opal-RT for engineering hardware and software to create a behavioral-level model real-time solution for xFflL.


APE - Advanced Power Emulator

BLDC - Brushless dc Motor

CPU - Central Processing Unit

eHS - Electrical Hardware Solver

EMA - Electro-mechanical Actuator

EPS - Electrical Power System

FPGA - Field Programmable Gate Array

PCIe - PCI Express

RTR - Run Time Ratio

SFP - Small Form-Factor Pluggable

xHIL - Experimental Hardware-in-the-Loop

Chad N.Miller

US Air Force

Michael Boyd

PC Krause & Associates
COPYRIGHT 2016 SAE International
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2016 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Miller, Chad N.; Boyd, Michael
Publication:SAE International Journal of Aerospace
Article Type:Report
Date:Sep 1, 2016
Previous Article:Validation of a DC-DC Boost Circuit Control Algorithm.
Next Article:Communication Infrastructure for Hybrid Test Systems - Demands, Options, and Current Discussions.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters