Hello, everyone. My name is Graham Dudgeon and I am Principal Product Manager for Electrical Technology at The bat365. In this presentation, I would like to share some information on modeling and simulation of electric aircraft architectures, for both desktop and real time simulation. Throughout my presentation, I will use an example of a notional hybrid electric aircraft. This is a system I put together that reflects certain technology attributes that are important for this discussion, but does not represent a specific type of aircraft.

I'll begin by discussing the relationship between model fidelity and technology readiness. This will help set some context for the choices we make for model fidelity, in relation to where we are in a technology development cycle. Next, I will introduce the Simscape Local Solver, how it is 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 our multi-domain physical system model. This is particularly important when considering real time simulation.

I will then discuss the Notional Hybrid Electric Aircraft System in more detail. I have a number of variants that I will discuss ranging from a DC equivalent system to a system that incorporates thermal response with active cooling on the generation system. Next, I will discuss considerations for making a simulation model real-time compatible, and show the result of real-time simulation using Simulink Real-Time and Speedgoat hardware. I will then discuss how we need to protect the intellectual property of a model, or model segment, using model reference protection and Simulink Coder. And also how we may create FMU Standalone Components using Simulink Compiler. 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. TRL 9 is where you have proven and surface 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 modal fidelity coming in a 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, and that may convey 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 the physical components and control components.

A high fidelity simulation model with a vendor specific architectures including specific dramatization of physical components and control system architectures. The model could also include detailed 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 support 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 readiness. When we look at this view, initial de-risking, and feasibility assessment is typically explored on a desktop before moving to a real time testing environment with [? hardware ?] 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 cogeneration, which deploy straight to target, can offer significant benefits and verification 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 the TRL mapping and it's for illustrative purposes only.

Lets 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, home 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 see 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, so we need no feedback control systems for speed control. With this model, we can set a larger time set 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 model. In this case, a linear permanent magnet synchronous machine. We include an average value converter, which converts duty cycles directly to voltage reforms. 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 built a more representative control system, we can regard this model as TLR 2.

Next, we can introduce a switch linear converter 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 cutting. As we are performing de-risking of the control algorithm and introducing more technology specific behavior, we can regard this model is 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 solver, and 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 their step 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 fitting a resistive load. The switch is controlled through pulse width modulation, with a carrier frequency of five 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. See what I mean by that? I will open the model configuration parameters, go to 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 simulate global solver. So the Simscape model in 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 CONT 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 FiM, 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, but as it's configured to detect zero crossings. Meaning, it can detect very small pulse [? bits. ?] 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 on it.

You can see that, while the voltage response using the global solver accurately captures pulses bits, the voltage response using the local solver cannot capture a pulse bit smaller than the defined sample time, which in this case, is 50 microseconds. 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 for local solver in order to deploy to a real time system, such as Speedgoat.

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 electral thermal 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 over sampling 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 times 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 different sample times in the Solver configuration blocks, and the physical information between the two networks is managed by great transition blocks. You see here, in this particular example, the left side is sampling at D3 and the right side is sampling 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.

In this section, we will discuss a DC Equivalence System Model of the Notional Hybrid-Electric Aircraft. What you can see here is the high level system model and Simscape. We have two main turbines from which power is drawn through the electric generators at 2.7 kilovolts DC. Also at the 2.7 kV level, we have two electric turbines, which are driven from electric motors. We also have a battery so we can manage the flow of electrical power. We then step down from 2.7 kV to 270 volts, with our actuators and cabin load disconnected.

We also have basic command and management functionality. This is a DC equivalent system model, meaning that we are not yet modeling the AC components, and we model the main turbines as ideal rotational speed sources, and the electric turbines as ideal torque. Sources With this model, we can run very rapid simulations, which give us information on high level operational response. We'll now open up the model and take a closer look. First, I'll just click on generator one. You can see here that we are using an ideal electromechanical converter for generator one. And in fact, we are using these ideal converters for all the electromechanical systems.

The energy management is quite simple. In this case, if the electrical system demands more than one megawatt then the battery will supplement the turbine generators. Notice that this is quite contrived, but I have made these settings so we can clearly see functional behavior of the simulation. The control surface commands come from a pre-defined time series, which I created to show stylistic behavior over a period of 2,500 seconds. So let me now run the simulation.

So you can see that it's simulating very quickly. It takes about 15 seconds of real time to simulate a 2,500 second flight profile. In this case, the simulation sample time is 10 milliseconds. So let me open the simulation data inspector. I'm going to select generator 1 power, turbine 2 power, and also battery power. You can see that, as the turbine ramps beyond 500 kilowatts, that the battery kicks in holding the generator at 500 kilowatts. Remember that we have another turbine and another generator that are pulling equal amounts of power. So you'll see the battery power effectively being double, as it's also supplying the other turbine.

From a functional perspective, we are seeing the expected behavior. As we go above 500 kilowatts on the turbine the battery kicks in, and once we drop back below 500 kilowatts, the battery then kicks out because the generators are now below the 500 kilowatt capacity, and so we no longer need the battery.

So with DC equivalent system models where you are using the lowest level of model fidelity, you are able to construct system level architectures, test basic functionality, look at basic energy flows, and make sure component sizings are appropriate for your system. And because those simulations run very fast, you're in a position where you can draw on thousands, or tens of thousands of simulations, in order to gain a statistical significance over wider operational envelopes.

In this section, we will discuss a model of the Notional Hybrid Electric Aircraft. It contains AC and DC components, and uses average value power converters. With this model, we introduce specific generation and actuator technologies, namely permanent magnets synchronous machines with field oriented control. The generators use a constant speed drive, and they're fixed at 400 hertz electrical, with the field oriented controller of the generation system maintaining DC voltage level.

The actuators are variable speed and operate under position control. I have also included more detailed main turbines, which are modeled as Britain's cycle gas turbines. The electric turbines are ideal torque sources, in this case. We'll discuss the inclusion of thermal response in the generators in the next section. First I'll open up the model and we can take a look in more detail.

Let's take a look at the Brayton cycle gas turbines. So their model is using gas and thermal domains, as you can see here, I connect the generator to the main shaft of the turbine using a constant speed drive, where it's just drill in here. The constant speed drive is a basic implementation. I have fixed the generator connection on the left as a constant speed source of 200 hertz mechanical, which relates to 400 hertz electrical as the generators of two full pairs. Power is then transferred to the turbine site on the right, from which reaction torque is calculated.

Note that the two sides are operating at different sample times indicated by D1 and D2. D1 is the electrical sample time, which in this case is 50 microseconds. And D2 is a slower sample time for the gas turbines, which in this case, is 0.5 milliseconds. We use different sample times to reflect the different time constants we have in the different physical systems. We'll also see that using different sample times enables us to run this model in real time, using Simulink real time and SpeedGoat hardware.

Another point I should note, is that the solver configuration for the gas turbine-- I'm using backward Euler with three nonlinear iterations. The reason I'm doing this is the equations for the gas turbines are complex nonlinear equations, and so I need to use Backward Euler to solve these accurately. For the electrical system, on the other hand-- let me just go to the solver configuration for the electrical system. So we are using the partitioning solver with one nonlinear iteration, and this is more than adequate for the level of fidelity we have on the AC DC system on the electrical side.

On the electrical system, let me just drill into one of the aileron-- the left aileron. We drive the PMSMs with field oriented control. So just to drill into the inner torque control loop here, for those of you who are power electronic engineers, you'll recognize the standard configuration for the inner torque loop or inner current loop for field or in the control system. In this case, we are generating modulation waves, so space vector modulation. We'll check that in a moment on the simulation output, but we'll expect to see a certain characteristic here, which we'll check for when we get to it.

We'll just track back up and go to the motor. So we have a linear current magnet synchronous machine here, and we are feeding the duty cycle of the modulation waves straight into an average value inverter. So we have no power electronic switching with this particular implementation. We could readily add power electronic switching at the later stage, as our technology readiness matures.

So let's now take a look at some of those responses. Open the simulation data inspector. First thing I'll do is select generator one power. Negative as far as supplied power, so it ramps around 250 kilowatts. In this scenario, I'm ramping the power consumed by the electric turbines, and I've instructed the energy management system to use battery power when the generators reach 250 kilowatts. So I'm seeing expected response here. Note the ripples that we're seeing, these are a consequence of the actuators cycling from positive to negative angles. I'll show you that in just a moment.

Let's just look at the turbine power. So we just go to motor 1, PDC, so we see that the power is ramping up. This case, of a 1.2 megawatts power motor. So we'll leave that up and we'll take a look at the battery. And you see the battery here is ramping up its power. It's going to about 1.9 megawatts in this particular case. So numbers are a little bit contrived here, but remember as well-- you're wondering, why is the battery power more than the motor? Well, it's because there are two motors. There's two electric turbines, and so we're seeing the battery powered as a consequence of that.

OK. Let's look at the actuators. Look at left aileron, and look at theta. So we see that-- I'm just cycling them positive and negative, as you can see. And that's part of the reason why we're seeing those ripples on the DC voltage that we saw earlier. The other thing I'd like to look at is actually the duty cycle. So there is the duty cycle. I've mentioned that we're looking for a very specific signature on this because we're using space vector modulation. So you can see here, we have this double hump and that's a classic signature for space vector modulation. So again we're seeing what we expect. We're verifying the functional correctness at this level of model fidelity.

In this section, we will discuss a model of the notional hybrid electric aircraft that contains thermal generators and active cooling. We first exposed thermal ports for the permanent magnets synchronous machines that our generators. The ports are HA, HB, HC for the stator windings, and HR for the rotor. As we want to run the thermal circuit a slower sample time than the electrical system, we connect the systems via Simulink signals. You can see here that I am transferring heat flow rate and temperature information across the Simulink boundaries in order to balance energy.

Also note the rate transition blocks, which manage the transfer of data across two different sample times. In this case, D3 is the thermal system sample time, and D1 is the electrical system sample. The thermal model of the rotor and stator windings is shown at the top and uses conduction and convection elements. I should note that I have parameterized the thermal system to show a thermal response in only a few seconds of simulation. And in this sense, it's rather contrived. However, my main purpose is to show the modeling constructs that can be used to create multi-domain physical systems.

The active cooling system shown at the bottom uses thermal fluid, and if a temperature threshold is exceeded, the pump will activate to circulate the fluid through the pipes and cool the system. Here we see the thermal response of phase A stator winding in both generator 1 and generates 2. Only generator 1 has active cooling, so we can see the difference in response and confirm that the active cooling circuit is functioning as expected. In this case, the active cooling circuit is configured to regulate temperature to 60 degrees Celsius. As I said before, I've parameterized this system to show a thermal response in only a few seconds of simulation time. A more rigorous development of this model would include the more appropriate parameter values to observe the expected thermal time constants as a function of dissipated electrical energy and thermal mass.

In this section, we'll discuss real time simulation of the notional hybrid electric aircraft using Simulink real time and SpeedGoat hardware. So what I'm going to do is step through the process you go through to build the model and deploy it to SpeedGoat. The first step on the model is to select the real time tab to build and deploy the model. Next in the MATLAB prompt, we can create a Simulink real time object. So tg equals slrt, now we have that object tg. There's various ways in which we can interact with SpeedGoat. So to run the simulation, you just type tg.start.

We can also use the task profiler to see the task execution time. So you can see the commands here. I won't continue to read those commands, but you can see here how you would do that and then you would then plot the execution profile The task profiler lets the C task execution time at different rates. The base rate here is the electrical sample time, which is 50 microseconds. sub rate 1 is the sample time associated with the brake and cycle gas turbines, and sub rate 2 is the sample time associated with the generator thermal systems.

There are two things to note here. First, the model sections associated with the different sample times have been distributed to different cores. This is known as implicit concurrent execution. I'll show you in a moment how the user can explicitly control the cores that are used. Second, the thermal system takes around two batteries to execute, and the Brayton cycle gas turbines take around three batteries to execute. This tells us that we would be unable to simulate the fuel system in real time if we did not split the sample times across the different model sections. For the user to have more control over task partitioning across multiple cores, we can use model reference. In this example, I've used three model references to construct the complete system. Let me actually open this model up and show you how the separate model references are connected.

OK, here's the model. So three separate models are connected at the top level through model reference. So just double click on the mechanical, so we have two Brayon cycle gas turbines. Just double click in here to show you. So we've got the Brayton cycles here, and we have a power input. The 1 over z is needed as an algebraic rubric. Thermal system, so we have a thermal model for the windings, and then we transfer the heat flow out through Simulink signals, and we bring the temperature back in. Just double click on the thermal model, we saw this in a previous section. Finally, the electrical system. So you can see we're transferring data in and out of the generators. So temperature heat flow for the thermal system, and power for the Brayton cycle gas turbines.

And so with these signals, we then use go to from in order to get the appropriate signal connectivity for us to complete the full system. Next, we go into configuration parameters, and we select configure tasks, and then select enable explicit model partitioning for concurrent behavior. Once we have done that, we can explicitly define periodic tasks. So we define three in this case. TaskELEC, TaskMECH, and TaskTHERM for the electrical system, the mechanical system, and the thermal system.

Note that your fastest rate needs to be set in each block. Let me actually go back to the model and show this in a little bit more detail, like why that is. So just drill back into the mechanical system. So you see power is coming in here at the electrical rate, then I double click here. We didn't have a rate transition that then transfers it to the mechanical sample time, so across the boundaries of the model references, you need to be transferring the data at the fastest sample time, and then deal with it internally in the model references with rate transitions. That is why you need to define the fastest sample time in each block.

We then build and deploy the model from the real time tab and do what we done before. We create the SLRT object and then interact with SpeedGoat through that object. We now take this system and look at the task execution times. We have parity with the last system, so I've actually done it to deflect what was done with the implicit concurrent execution. So you can see now we have the three tasks. TaskELEC, TaskMECH, TaskTHERM, and we have the same computational behavior because, as I say, I don't parity with the last system. So to re-emphasize with those sample times that we're seeing here. Task execution times tell us that we would be unable to simulate the full system in real time if we did not split sample times across the different model sections, and we were unable to use slower sample rates for the thermal systems and breathing cycle gas turbines.

With explicit partitioning, we have further control of using the computational resources on the real time system. And as model complexity develops, we may consider partitioning the model at different locations and including more than one sample time per core. These choices will, of course, be system specific.

In this section, we'll discuss how we can protect the model reference in order to hide model implementation details, and protect intellectual property. To protect a given model reference, you first right click on the model reference. In this case, the thermal system at the bottom left, select subsystem and model reference on the Context menu, and then create protected model for selected model block. In the Create protected model window, select simulate, and if you want to deploy this protected model, say on-- say using Simulink real time and SpeedGoat, then you would also select User generated code.

There's a few sub options of what to do with the codes. In this case, I've selected obfuscated source code, meaning that the generated code will have reduced readability. So as I said, by selecting use generated codes, and then selecting the SLRT.tlc file for code generation, I'm going to be able to deploy this protected model on SpeedGoat. When you click create an slxp file will be created. This is a protected Simulink model.

You can then refer to the protected model in the model reference. Let me actually bring the model up to show you this without having to go through the slide, so let me come out of this. All right. Here's the actual model. So you know to reference a certain model, you right click, go to block parameters model reference and you can see here, I'm referring to the protected Simulink file. Now if I double click on this, it's not going to open the model up. What it will instead do, is open up a protective model report. So just double click on this now.

So here we have the report. So this is what you will see when you double click, and it gives you some of the attributes, like the selections you made for the supported functionality of the protected model build. So you can now run the system model as you read any model, but note that you won't have access to any internal measurements that you may have defined in the unprotected model. So when I work with model reference, I usually have signals within the model reference that I tagged so I can view them in the simulation data inspector, so that option won't be available with the protected model so make sure that any signals that you do need to view are coming through output ports. Finally, you will notice a shield icon at the bottom left of the model reference,. This is an indicator that this particular model reference is protected.

In this section, we'll discuss creating an FMU standalone component using Simulink compiler. So what we first do, is we create a model that contains the system you want to generate an FMU component for. So in this case, we choose the thermal system. The next step is to select Save, and then select standalone FMU on the dropdown list. From there, we get the FMU user interface, so you just select the directory you want to export the FMU component to, and click Create. Once the FMU component is built, it will be placed in a separate mode. So I should note here that, in a similar way to a protected model reference, you can't access internal signals within the FMU component. So if there are any measurements that you need, then you should bring those out throught output ports.

So in this case, I'm bringing out the temperatures T1 and T2 for both of the internal thermal models out throughout the ports, so I can then view the response. We can then place the FMU component in the fuel system. So when you are using the FMU components, it's for desktop only simulation. FMU components do not deploy. So let me actually show you the model and then show you some of the simulation results from this. OK, so here's my model. I am referring to the FMU component here. I brought out T1 and T2, so what we're looking at here is the thermal response of generator 1 and generator 2 for the stator coils. Generator 2 are these traces that continue ramping, there is no active cooling here. Generator 1, active cooling is engaged to regulate around 60 degrees Celsius. So we are seeing expected behavior.

Through this presentation, we have looked at a number of aspects that are important for Modeling and Simulation of Electric Aircraft Architectures. We started by looking at the relationship between model fidelity, and technology readiness, and an example of how we can build model fidelity as technology readiness matures. We then looked more closely at the Simscape local solver and its relationship with a Simulink global solver to see what impact and value that can have, in terms of achieving certain levels of accuracy with fixed depth solvers. When we can set our physical systems, which are interconnected, but are of different domains, such as interconnecting electrical, mechanical, gas, thermal, we looked at how we can incorporate different sample times for different physical network segments in a full system model.

So what this helps us do, is it helps us more efficiently simulate more complex systems with different physical domains with different time constants. We then spent more time looking at the emotional hybrid electric aircraft. So an example aircraft architecture, which has a number of the technology attributes we would expect to see an electric aircraft architectures, but which did not align with a specific aircraft type. We started looking at DC equivalent system models, system models we could run very quickly, get a high level sense for the functional operation at the system level, and from which we could run potentially tens of thousands of operational scenarios to gain statistical significance on the overall operational response.

We then looked at more detail on the technology. So incorporating permanent magnet synchronous machines with field oriented control, but using average value converters so we did not need to incorporate hybrid electronic switching, although that could obviously be done when you are looking at more detailed modeling. There is a growing level of interests that we are seeing and bringing thermal modeling into electrical simulation. I showed an example of how we could create a thermal model for the permanent magnet synchronous machines and also incorporate an active cooling system. I then spent some time talking about how we set up simulations for real time simulation, specifically using Simulink real time and SpeedGoat, and then I ended discussing model reference protection where we can protect intellectual property of model segments, and also how we can create FMU standalone components using Simulink compiler. To download MATLAB scripts and Simulink models related to this presentation, please visit The bat365 file exchange and search for more electric aircraft and Simscape. Thank you.