Video length is 32:18

Electric Ship Modeling and Simulation

Learn how to model electric ship architectures with varying levels of model fidelity to achieve certain engineering objectives. Through a worked-example of a Two-Zone MVDC Shipboard Power System, this presentation will step you through considerations for aligning model fidelity with engineering task, and provide guidance on modeling constructs for both desktop and real-time simulation.  Multi-domain physical modeling will also be explored by considering thermal response and active cooling of the propulsion system.

Download Simulink models related to this webinar at this link.

Published: 20 Jul 2020

Hello, everyone. My name is Graham Dudgeon, and I am principal product manager for electrical technology at MathWorks. In this presentation, I would like to share some information on modeling and simulation of electric ship architectures, for both desktop and real-time simulation. Throughout my presentation, I will use a worked example of a two-zone medium voltage DC shipboard power system.

I would like to acknowledge that the models described in this presentation are based on information provided by the Electric Ship Research and Development Consortium. You can go to the link shown here for more information. While system architecture and physical parameters have been honored as closely as possible in the models I have developed, differences in the implementation of certain components and control algorithms is to be expected. As a result, simulation results in this presentation should be regarded as being representative, rather than providing an exact engineering match.

I'll begin by discussing the relationship between model fidelity and technology readiness. This will help set some context on the choices we make from model fidelity in relation to where we are in our technology development cycle. Next, I will introduce the Simscape Local Solver, how it's used, and how it relates to the Simulink Global Solver.

I will then give an overview of how we can use different sample times for different portions of a multi-domain physical system model. This is particularly important when considering real-time simulation. I will then discuss the two-zone medium voltage DC shipboard power system in more detail. I have a number of variants I will discuss, ranging from a DC equivalence system to a system that incorporates thermal response with active cooling on the propulsion motor. I will end with a summary.

In this section, I will discuss the relationship between model fidelity and technology readiness. The technology readiness level scale, or TRL scale, was originally developed by NASA and quantifies the maturity of a given technology at a given stage of development. TRL 1 is your eureka moment, where you have the initial idea and begin conducting basic research. And TRL 9 is where you have proven and service technology.

The TRL scale is open to some interpretation. In other words, one person's TRL 5 may be another person's TRL 6. But the scale does consistently follow key development attributes that you can see on the left here. Assigning technology attributes to specific TRL numbers is typically done by the engineering teams working on the technology.

If we first think in terms of model fidelity for desktop simulation, then we typically see different levels of model fidelity coming in at different technology readiness levels. As you begin basic research, you will have models that are low fidelity. For example, you may have models that have basic functionality, in that it conveys some high-level system information, such as power flows and component sizing, but which are technology agnostic, meaning the models do not capture specific technology characteristics.

As your technology matures, then simulation models that capture more specific technology attributes will be created. For example, you may incorporate models of actual technology types, such as permanent-magnet synchronous machines, with field-oriented control. But at the medium fidelity stage, you may still not have vendor-specific information on physical components and control components.

A high fidelity simulation model would have vendor-specific architectures, including specific parameterization of physical components and control system architectures. The model could also include detailed power electronics, thermal and cooling systems, and communication protocols.

Notice that all fidelity levels can track up to TRL 9. The reason for this is as your technology matures, you can develop models with different levels of detail that not only supports implementation of your technology, but can also be used for coaching technicians, as an operator training simulator, or as a digital twin. Each of these applications require different levels of model detail.

The other view we can take is to explore desktop simulation, real-time testing, and production implementation as a function of technology ratings. When we look at this view, initial de-risking and feasibility assessment is typically explored on the desktop before moving to a real-time testing environment where [INAUDIBLE] in the loop and rapid control prototyping is conducted to further de-risk control algorithms and physical architectures.

The production stage is where algorithms are deployed on actual production hardware. And this is where automatic co-generation which deploy straight to target can offer significant benefits, verification, and validation as you near full system deployment.

In this presentation, I will consider only TRL 1 to 4, with only a slight encroachment on TRL 4 as I consider deploying a physical system model on a real-time platform without any hardware interfacing. I should note that this is my own interpretation of TRL mapping and this for illustrative purposes only.

Let's now look at a representative example of an electromechanical drive and consider how modeling attributes relate to technology readiness. I should note here that this is an illustrative example based on my own judgment and should not be regarded as a rigorous mapping. But it will provide some context how modeling detail can evolve as technology readiness evolves.

We begin with an ideal electromechanical drive. This is our lowest level of fidelity, where the relationship between voltage and speed and current and torque is defined by a constant of proportionality. With this model, we set a DC voltage level using an average value converter with a duty cycle input. The duty cycle relates to a specific voltage, and hence a specific speed. And so we need no feedback control systems for speed control.

With this model, we can set a larger time step to achieve a faster simulation, but we only gain high-level information voltage and current, and have no specific technology characteristics. We can therefore regard this model as TRL 1.

Next, we can include a more detailed motor, in this case, a linear permanent-magnet synchronous machine. We include an average value converter, which compares duty cycles directly to voltage waveforms. And so we have not yet introduced power electronic switching. We can now incorporate a more detailed feedback control system, in this case, a field-oriented controller for speed control. And we can perform rapid design iterations. As we have introduced a technology type and have built out a more representative control system we can regard this model as TRL 2.

Next, we can introduce a switch linear converter to with dual power electronic switching. With this model, we introduced specific PWM switching algorithms and verified that the feedback control system will operate effectively in the presence of switching. We can also take an initial look at the impact of switching harmonics on voltage and current. As we are performing de-risking of the control algorithm and introducing more technology-specific behavior, we can regard this model as TRL 3. While this example was fairly basic, I hope it conveyed some of the model fidelity considerations as technology readiness evolves.

In this section, I will explain the relationship between the Simscape Local Solver and the Simulink Global Solver, and how these settings affect simulation performance and accuracy. By selecting local solver on the Simscape solver configuration block, the Simscape network will be simulated using a fixed step and An the Simscape network is presented to Simulink as a discrete system. If local solver is deselected, then the Simscape model is simulated using the global Simulink solver. In a moment, I will show an illustrative example to clarify these points.

There are three local solver types: Backward Euler, Trapezoidal Rule, and Partitioning. Partitioning solver converts the entire system of equations for the Simscape network into several smaller sets of switched linear equations that are connected through nonlinear functions. This can lead to faster simulations for certain networks.

It's important to note that not all networks can be simulated using Partitioning solver. For example, highly nonlinear systems and/or stiff systems may require some adjustment before Partitioning solver could be used. Instead of me talking about solver selection, I should show you in action. So let me bring up an example model.

In this model, I have a simple DC circuit with an ideal switch feeding a resistive load. The switch is controlled through pulse width modulation with a carrier frequency of 5 kilohertz and the modulation wave of 60 hertz. There are two versions of the circuit. The circuit on the left uses the Simulink Global Solver.

So what I mean by that, I will open the Model Configuration Parameters with the solver, and we're set right now for variable step discrete. This means that the Simscape model on the left will update using the variable state discrete solver, which despite the name, is a continuous solver, as it can detect zero crossings or discontinuities.

The circle on the right uses the Simscape local solver. So we see here on the solver configuration, I have use local solver selected. And I'm using the Partitioning solver in this case.

Let me just bring up the solver configuration for the left side model. See, I did not have local solver selected. Therefore, it's using the Simulink Global solver. So the Simscape model on the right is updated using the Partitioning solver, and the Simscape model is presented to Simulink as a discrete system.

Notice that the voltage measurement is highlighted D1 on the local solver circuit, meaning it's discrete. And notice on the left that the measurement is highlighted as C-O-N-T, continuous. Finally, notice that both PWM generators use the Simulink Global Solver, as they are Simulink models. And you can see that the PWM signals are labeled as F-I-M. This means fixed in minor time step, which is a continuous signal.

So what does all this mean? We'll first look at the PWM signals. You can see that the global solver accurately captures the pulse width as it's configured to detect zero crossings, meaning it can detect very small pulse widths.

Now we'll take a look at the voltage measurements. The yellow traces the voltage measurement using the local solver, and the blue traces the voltage measurement using the global solver. Notice that we see differences in the voltage measurements. So let's zoom in a bit.

You can see that while the voltage response using the global solver accurately captures pulses width, the voltage response using the local solver cannot capture a pulse width smaller than the defined sample time, which in this case is 50 microsecond.

Engineering judgment is needed to determine the trade-off between simulation speed and accuracy for a given local solver setting. As a general rule, you need to set Simscape to local solver in order to deploy to a real-time system such as speed [INAUDIBLE].

In this section, we will explore how to configure a model to use different sample times for different physical network segments. The premise is this. When we are constructing a physical system model that incorporates different physical domains, we recognize that a single sample time across the entire network may not be optimal for efficient execution.

For example, if we have an electrothermal system with one sample time, we must set that sample time to accurately capture the fastest dynamics, which would relate to the electrical system in this case. Thermal time constants are typically much slower than electrical time constants. And so we would be oversampling the thermal portions of the model, leading to slower simulation speeds.

However, by splitting the electrical and thermal systems and connecting them via Simulink signals, we can assign separate and more appropriate sample time to each model segment. The example shown here shows one way in which to split a physical system, using thermal ports for illustration. You can see that we are transferring both heat flow and temperature across the boundary in order to balance energy flow.

You can set a different sample times in the solver configuration blocks, and the physical information between the two networks is managed by rate transition blocks. You see here in this particular example, the left side is sampling at D3, and the right side the sampling at D1. For this example, it's not important which is faster than the other. The point is that we can manage the exchange of information using the rate transition blocks. I will show more detail of this when we explore the two-zone medium voltage DC shipboard power system with the thermal motor model.

In this section, we will discuss a DC equivalence system model of the two-zone medium voltage DC shipboard power system. What you can see here is the Simscape model of the two-zone medium voltage DC system. For those of you familiar with the system, you will notice that it closely resembles the system diagram in the ESR DC publication.

What I have also done here is configured the switchboard breakers to be color-coded depending on their status, red for closed and green for open. In this way, we can quickly see the configuration of the system. The power generation modules, PGM 1 and PGM 2, are modeled as DC sources on the voltage droop. And the propulsion motor module, PMM, is modeled as a single controlled current source.

Here, we see a representation of voltage droop, which is used to control power sharing between the two power generation modules. You could also use power droop to achieve the same power sharing response. Let me open the model so we can take a look at the system and simulate it.

Let me first look under the propulsion motor module. You can see that I have a controlled current source, and they assume an ideal power run based on 12 kilovolts. Let me open the power reference. You can see that I am ramping power up to 40 megawatts. I'll now run the simulation.

The 50-second simulation runs very quickly for two reasons. One, I can set the sample time to be large. In this case, I am using 5 milliseconds, although I could go larger if needed. Two, I am using the Partitioning solver, which is the fastest local solver. So if I just go into PGM 2, this is where I have my solver configuration. And you can see I'm set up for Partitioning with one nonlinear iteration. This is the fastest solver configuration we have.

I'll open the simulation data inspector now. We can look at the power output of the two generation modules. Notice that the power from PGM 2, which is the light blue color here, provides twice as much power as generator one. This is because I have set the droop of PGM 2 be half that of PGM 1. So from a functional perspective, I am seeing the power sharing response that I expect.

Let's now quickly set the droops to be the same, So I can show that both generators provide equal power. So let me just close down the simulation data inspector. We'll just double click here. We're set at 2.5% droop here, with the appropriate scaling factor. I'm going to set this to 5% to match PGM 1, and then we'll just run this again.

All right, the simulation is done. Let's go back now. And so you can see now that the two powers are overlaid. So functionally, we're seeing the response we expect. So by implementing a DC equivalent model, we are able to run very rapid simulations to test functional response.

In this section, we will discuss the two-zone in the medium voltage DC shipboard power system with ideal AC/DC rectification. With this model, we introduce AC generation and control. Each generator consists of a salient pole synchronous machine, a GAST gas turbine, and an AC1A exciter.

For this model, I created an ideal AC/DC rectifier with three objectives in mind. First, I wanted to hold the DC voltage at 12 kilovolts, with only the voltage droop affecting voltage set point. Second, I want the power factor at the AC terminals of the power converter to be unity. Third, I want ideal rectification, meaning no switching harmonics.

As a side note, I did not create the ideal converter with fault studies in mind. Its purpose is to evaluate the functional response of the system and ensure that the power flow between the AC and DC systems is captured appropriately during normal operation. In order to conduct fault studies with this model, I would need to make some adjustments to correctly capture fault behavior. We'll see in the next section, where we consider thyristor rectification, that we can readily evaluate fault response, as the thyristor risk their models are configured for such studies.

Unlike the DC equivalent model, where the propulsion motor module is a controlled current source, I have modeled the PMM as a permanent-magnet synchronous machine with field-oriented control. I've done this to add more fidelity to the overall system, and also so I could evaluate a broader range of operational response. In particular, I wanted to simulate a stylized full-head crash-stop.

So let me bring the model up and simulate it. I'll then go back to the slides to give more detail on the full-ahead crash-stop profile.

So here is the model. All I'm going to do right now is run the simulation. And while that's setting up and running, I'm now going to go back to the slides. We'll take a look at the simulation results in a moment.

My primary interest in full-ahead crash-stop is to evaluate the performance of the drive during quadrant two regeneration. For the purposes of this example, I created a stylized piecewise linear torque speed curve, where you can see an incursion into quadrant two during the crash-stop maneuver. The other thing I'd done was dramatically condense the time period of the maneuver, so we could see the response in a reasonable time.

As you can see in this slide, we expect to see a regenerated power during the quadrant two incursion. So let's go back to the simulation model. I just heard it finish. And we'll take a look at the simulation data inspector for more detail.

So here's the power, where we see negative power between around 18 and 20 seconds. We'll now select shaft speed. And you can see between 18 and 20 seconds, we are still at positive rotation, but then crossing to reverse rotation after that. This is what we expect to see for the torque speed profile I'm using. So we confirm that the propulsion motor module response is functionally correct for this scenario.

Looking at the response of power generation module one, we see that we have zero reactive power, hence a power factor of unity, and that the AC and DC power are overlaid. This confirms the operation of the ideal AC/DC rectifier. Also note that we are getting a bit light on the power output during the regeneration period of the full-ahead crash-stop. We don't go negative, as there is sufficient auxiliary load in the system to absorb the regenerated power, but we would certainly want to explore options for maintaining baseload of the generators, perhaps using energy storage systems.

Looking at phase A current from power generation module one, we see that the demand looks appropriate and that we have no harmonics, as we expect.

As we have implemented fuel loading to the control, we can also confirm the duty cycle response. In particular, we verify that we are seeing the double hump on the duty cycles that we expect to see when using space vector modulation.

What we are looking at here is the task execution time for the model. And we can see that are two rates. The base rate is 25 microseconds. That is what we are simulating the electrical system at. From this, what we can see here, the task execution time is round about 10 microseconds. So we have plenty of overhead on the electrical response.

Sub-rate one, which is 0.2 milliseconds, that's for the control systems. So while this model is deployment only of the physical system model, we can see that when the time is right to move the hardware in the loop testing, where we are connecting physical hardware and have appropriate communication channels set up, we have sufficient overhead with which to work with.

In this section, we will discuss the two-zone medium voltage DC shipboard power system with thyristor rectifiers. I've architected this model using model reference. What this means is that I created a separate model for the excitation systems and a separate model for the electrical system.

There are several benefits to using model reference. First, we can have different engineering teams working on different sections of the system, without any need to access the full system model. Second, the different sections can be evaluated in test harnesses, which provides a more efficient route to verifying the operation of the different components in a controlled test environment. Third, using Simulink real-time and Speedgoat, we can assign each model reference to a separate core for concurrent execution.

And so, this provides user-defined flexibility in the way that a model can be architected for real-time simulation across multiple cores. While model reference is important for concurrent execution for real-time, I should note that this particular model is for desktop simulation only, as it has a time step of 1 microsecond in order to have parity with the model described in the ESR DC documentation.

Here is the AC1A model. Note that I define different sample times for the control systems and the electrical systems, with the control systems running at a slower rate. We can highlight the different sample times in the model. Actually, let me bring up the model to show this more clearly.

So we go to debug, then information overlays. I've already got colors and text in play here. I can also select Legend. And so we see here, we have two sample times in our model, D1, which is 1 microsecond, relating to the electrical system, and D2, relating to the control systems, which is 0.2 milliseconds.

If I then look at AC1A, we can see here that we use rate transition blocks to manage the transfer of data across the different sample time. So we have D1 to D2, D2 back to D1.

Let me now open the electrical system. This model has thyristor rectifiers, and the AC system operates at 240 hertz But this model will run a fault scenario, with the fault being located just below the AC DD breaker of the zone one port side switchboard. The fault is applied at 0.2 seconds, and its duration is 0.1 second.

Let me now drill down into power generation module one. Note that because I'm running the simulation only for a short duration of time, that I am holding the speed of the generator constant at 60 hertz mechanical. The generator has four pole pairs to give us 240 hertz electrical. For longer-duration simulations, where we expect to see an electromechanical dynamic response, we could easily add the gas turbine model to capture the appropriate dynamic response. Also, note here we have the thyristor converter, and we have the firing circuit here, where we have DC voltage being controlled, and the firing angle being adjusted appropriately to maintain 12 kilovolts.

I'll now open the simulation data inspector so we can take a look at some responses. First, we'll look at AC current on PGM 2. We'll look at the three phases. I'll just zoom in on normal operation and start.

What we see is a clean six-pulse response. And for those with keen eyes, we can also see firing angle activation. This response meets our expectations. If I just zoom back out, also note the increase in current when the fault is applied.

Next, we'll take a look at current flowing through the zone one port-side switchboards. I'll just zoom in on the fault region.

These responses also align with expectation, and you will see similar results to those shown in the ERS DC documentation. You won't see a perfect match, because I've made some assumptions in the creation of my model and so there will be some functional differences in the models, but overall the responses are compatible.

In this section, we'll discuss the two-zone medium voltage DC shipboard power system where we have implemented a thermal motor with active cooling. In this example, a thermal circuit and a thermal fluid cooling system is added to the permanent-magnet synchronous machine, which is acting as a propulsion [INAUDIBLE]. Let me just open up the model, and we'll take a closer look at this.

With the PMSM, we're able to expose thermal ports for the stator coils, HA, HB, HC, and the rotor, HR. The thermal circuit-- I'll just open that. Thermal circuit includes conduction and convection, and the cooling circuit uses thermal fluid circulating around a simple pipe structure. We have a pump, which we activate if a certain temperature has exceeded.

I should note that I've sized this thermal system to show a response in only a few seconds of simulation. In that respect, the parameterization is rather contrived and should not be taken as representative of an actual thermal system for a ship propulsion system. We can, however, use this model as a representative example of the modeling constructs that are used to simulate such a system.

The thermal circuit is connected via Simulink signal. So let me just double click on one of these. So we can see here that we are transferring energy across the Simulink boundary, transferring heat flow rate in one direction and temperature in the other direction. And you see here, we have rate transition blocks.

By doing this, we can set the sample time of the thermal system to be slower than that of the sample time of the electrical system. It makes sense to simulate the different physical networks at different sample times, because the thermal time constants are much larger than the electrical time constants. We'll also see in a moment how this modeling construct allows us to simulate this model in real time.

But before we move on, let me just show you the solver configuration for the thermal system. I'm using Backward Euler with one nonlinear iteration. So the thermal equations are a little bit more complex in this case than the electrical equations. So I need to use Backward Euler. I can't use Partitioning solver.

So I expect some computational overhead because of that, but because I'm running at a slower rate, then I shouldn't be compromised by that. I'll show you more details in a moment.

So what we see here is the thermal response of the phase A stator coil, with and without thermal cooling. So the red response is without thermal cooling, and green is with thermal cooling. So we trigger the thermal cooling system about 56 degrees Celsius. As I mentioned earlier, I scaled the system specific with this new thermal response in only a few seconds. And so these responses are illustrative only.

What we see here is the task execution time when we run this system using Simulink real-time and Speedgoat. Note that the thermal system, with a sample time of 1 millisecond, is running on one core, while the electrical system, with a sample time of 25 microseconds, is running on another core.

There are two things to note here. First, the system runs comfortably in real time by utilizing two cores. Second, we could not have achieved real time if we ran the thermal system at 25 microseconds. Note that the task execution time of the thermal system takes at least four of the electrical time steps. And so to achieve real time, it was necessary for us to split the model with two different sample times and to use two cores.

A final point to note is that because the thermal time constants are larger than the electrical time constants, we have not compromised simulation accuracy by using two sample times.

To summarize, model fidelity is closely related to technology readiness. Low levels of model fidelity can be effectively used to run rapid simulations that give insights on broad operational response and component sizing, while higher levels of fidelity give you specific information on the technology choices you are making. Real-time simulation is enabled by selecting appropriate model fidelity, modeling architectures, and different sample times for different model elements.

Finally, multi-domain simulation is of increasing importance, for example, the inclusion of thermal modeling with electrical components from which you can develop active cooling circuits.

To download MATLAB scripts and Simulink models related to this presentation, please visit MathWorks File Exchange and search for Two-Zone-MVDC-Electric-Ship. Thank you.

Related Products