Deep Learning-Based Reduced Order Models for Electric Motors
Shyam Keshavmurthy, MathWorks
Full vehicle system modeling is used in applications such as electric vehicles and energy systems and plays a pivotal role in understanding system behavior, system degradation, and maximizing system utilization. The behavior of these systems is dictated by multi-physics complex interactions that are well suited for finite-element simulations, but modeling system behavior and system response is computationally intensive and requires high-performance computing resources. Additionally, such models cannot be deployed to hardware (HIL/PIL) to predict real-time system response. Another alternative is reduced order modeling using curve fitting and system identification, which makes subsystem models computationally feasible. However, in many critical systems, this approach is not preferred as these surrogate models are less accurate and do not represent the full spectrum of component behavior. With deep learning, we can now rely on data to develop small footprint, detailed models of components without approaching the problem from first principles. In this presentation, walk through the development of a deep learning– based reduced order model (ROM) for a permanent magnet synchronous motor (PMSM), a popular component for electric vehicles and future green transportation.
Published: 15 May 2024
SHYAM KESHAVMURTHY: Hello, welcome to the MathWorks Automotive Conference. Today is the last session on electrification. We'll talk about deep learning as applied to reduced order models for electric motors. I'm Shyam Keshavmurthy. I'm an AE I've been with MathWorks for five years. I've been working in this area of applying AI to many solutions for quite a few years. So let's start.
Why do we want to do this analysis and build a model that can simulate an electric motor's internal temperature? This is kind of the high-level overview of why we want to do that. We know that PMSM motors are the main traction device. Any temperature excursion in these motors will lead to torque inefficiencies. And these devices need to operate over various thermal regimes, whether it's a high winter cold in Minnesota or warm temperatures out in south Florida. They need to operate at all these temperatures, and they need to produce enough torque on demand.
And a lot of times, what we do is we do a lot of dyno testing, and we build these thermal models based on that. The challenge with these dyno testing is that it's expensive, and it may lead to degraded devices. So another approach is to instrument these units as they are being run and collect some data. That is also quite expensive. And sometimes, you may have to do some FEA or analysis to collect that data. It's expensive as well, both computationally as well as in terms of deployment.
So what do we go after? We go after simulation as an approach because it's much faster and it can build essential results necessary for us. The bonus part of it is because we have a model we can deploy it into through software. It can act as a virtual sensor so you don't have to instrument your devices to get the data.
Moving on, what is reduced order model? Does it mean that we have reduced the efficacy of the model, or what did we do here? Reduced order model is a technique through which we are reducing computational complexity. We are not reducing the accuracy. We are not reducing the ability to predict temperatures over time. We are not reducing the regimes through which it has to predict the temperature, but we just reduce the computational complexity so that we can achieve acceptable fidelity.
For example, for an electric motor, we are looking for a temperature range of anywhere between 4 degrees to 5 degrees variations variance with respect to its internal temperature. So that is the kind of a target we are going after, and we are trying to reduce the complexity. So why are we doing this? Two things-- is to enable FEA models in Simulink so we can build full plants with multiple motors running in there, and second, in order to do hardware-in-the-loop tests so that we can do some basic tests with the targeted hardware so that we can see whether the computational unit can run on it or not. And, last but not the least, to develop virtual sensors and have digital twins in play so that we can have these models generating data in real time.
And, of course, in order to do that, once when you have the temperatures, you can do control system analysis and build optimal controls to cool these systems so that they can be operating at the most efficient regimes possible. And also, though, because it's a fast-learning model now, you can run large-scale simulations for long time. So you can run some long drive cycles. So that's the goal.
So let's look at how it is done. You start with some dataset that is collected, and then you look for your predictors and responses. Predictors are the ones that are used for predicting the outcome, and responses are the one what we are predicting. And we break this into test set, validation dataset, and a training set. And you organize your dataset such a way that you have all the profiles for different drive cycles and build a model-- neural network model-- and train the model.
And once you train the model, you can test the efficacy of the model on a blind data set, look for errors and correlation in the data that comes out of the prediction, compare it for different drive cycles, and once you are done with it, you compress the model to be the required footprint, the target footprint. Here, we are going to use some projection technique to reduce the size of the model, and then we build the model and deploy the model to the targeted hardware. So that's the workflow you would do in MATLAB. But you can also-- since you have saved the model, you can now start consuming it for large-scale simulation in Simulink. Let's see how we do it.
First, we start off with the model as a stateful predict block. We associate the model with the stateful predict block. Since we had used the normalized dataset, we attach some normalization factors to it, and we start streaming the data through the model. And once when we test the efficacy, the model is same as what we got in MATLAB. We are going to do the Codegen Advisor to see what all things we need to do for it. We generate the library free C code coming out of it. And then we can examine the code to see whether the code meets our requirements or not.
As you can see, the code is pretty much an open source. You can see all the weights and biases have been exported properly. And once, when you are satisfied with the examination of the code, now you can take the code and execute a test to see whether you can do a test with it.
So based on this information now, as you can see, I'm examining the weights and biases that are coming out of it and also looking at what all the results I got from the Code Advisor to be sure that we got the correct code. Then we do look at the metrics for the test and see whether it can be run, whether it can meet the accuracy requirement or the timing requirements.
So lo and behold, we started with the raw dataset, and we were able to build the model and test it on a real drive cycle data that is coming into Simulink and actually generate the code and deployed it to a target hardware. So that's the kind of a gist of this talk. So let's see how we got to do this.
So the common challenges when we build any model-- it doesn't matter whether it's a FEA model or whether it's a deep learning model-- it's the hyperloop models such as what we got here are too slow. And sometimes, they're not useful for hardware-in-the-loop testing because they can't keep up with the clock that is there necessary for hardware-in-the-loop test. Number one, we need to speed up these models to actually be deployed.
Second, the challenge is whether we are able to balance between the speed, accuracy, and interpretability properly or not. That's a quite a big of a challenge. And these two challenges play a significant role in terms of whether certain models get deployed or not. Here, we look at MathWorks tools, how they can help you to overcome these challenges.
So if you look at it, integrating AI model into model-based design, we have a complete workflow. Today, we'll focus on only a subsystem part of it, where we are going to take the AI-based and data-driven model and try deploying it to various environments. The thing that really connects all of this is called digital thread. You may see this buzzword.
This is basically the data that is collected and generated by your models and also compared at different locations. This data can exist in different fidelity or different timescales. And so all this data needs to be synchronized and compared with each other. So you need a tool that will help you to link up this dataset. And that's the one that connects all these blocks, starting from requirements to system integration and test. That's the digital thread we talk about. Let's see how we are going to make use of the digital thread here.
So let's look at the AI-driven design as to start off with. We start off with data. Basically, you get data from either tests or from some sources or you can generate some data from simulations. But we are going to add some human insight to it. You'll see what kind of human insight we are going to add to this dataset.
And then we build an AI model. Basically, it's a model-- either it's a machine learning, if it's a static process. If it's a dynamic process, generally a deep learning-- something recurrent neural networks is used. And then we use hardware to accelerate the training so that we don't have to waste a lot of time in just churning up the numbers. And sometimes, you may have to bring the model from outside world because it's already trained, and we have to build on top of it. So these are the things that we do generally in the AI modeling step.
Once that step is done, we are going to take the data, the model and try to integrate with the complex system, see whether it can be integrated, and then we run a system simulation to see whether the data that is getting produced from the model can be consumed by a system-level simulation, and then we do system verification and validation.
Once that is done, we then try deploying it to an embedded device or to an enterprise system if you are working in the cloud or on an edge device. So we have to go through this entire workflow for every model that we need to build. And we need to iterate quite a bit because between the AI model simulation and testing, we will see certain discrepancies, certain deficiencies in terms of speed, accuracy, and whatnot. That's where the optimization comes into being. So there are several iterations that we need to go through between those two steps.
So let's look at the first step in AI-driven design. So we need to get data, clean the data, and put some human insights. Luckily for us, we had a data source coming from a published paper from Paderborn University in Germany. We took that data, and this data was all anonymized, so we didn't know for the temperature data was collected through a thermal imagers. So initially, they had tried with a lumped parameter, but they were not getting good results. So they were beginning to look at neural networks to solve this problem.
So once you had the data source, we looked at the data source, and we looked at the fact that there were a lot of drive cycles, but the drive cycles were all sampled at certain rate. So we wanted to add some more features associated with this lower sampling rate as well as some of the edges that was quite evident in this dataset. So we added a couple more features to it, using moving window and moving average. That is the human part. So human is involved in this stage where we augmented that dataset with additional features. So we got a full dataset of drive cycles.
So we had about 53 profiles out of 53 profiles or profiles that were 45,000 samples. And also, there were samples that were only something like 300. So we had a full set of profiles of different sizes. So we were able to look at it and say, OK, this model that can hold good for all these different profile sets will be generalizable. That's the first set. Whether we got the data that was good enough to build the model that can be generalizable was a challenge. So we had to examine and spend some time on that dataset.
Once we got the dataset, we also looked at the torque and speed profiles to see whether we have covered the entire range. And looking at these profile plots using MATLAB, we were able to quickly judge whether we have covered all the different regimes of operation of an electric motor. This was quite satisfactory to start off with. So we didn't have to augment any other thing in this dataset.
So once when we were satisfied we had a good dataset, we started building the model and started simulating and testing, so on and so forth. This process of iteration needed to be done quite frequently. So what did we do? We used MATLAB. So MATLAB has a nice tool with low code approach to build the network. So we could build several networks in place. And this is one such network that we built to test different models.
Once a network is built, we exported the network into MATLAB as a MATLAB function, and we were able to execute and automate the entire process. As you can see here, this small network was about-- pretty big. It had 2 million learnable, so we'll tackle that learnable part in few slides from now on.
So we took this model, trained the model, and tested it on a blind validation dataset as we were training to be sure the training is consistent, that we are not overtraining it. The results with validation and training being very close to each other indicated that we had not overtrained the model on a given dataset. So once we trained it on around 47 datasets for training and now one dataset for validation, we were able to ascertain that the model was good.
So we took this model, and then now we took the two blind datasets and started testing on it. The one set of data that we took was a long-running 40,000 samples run, and we saw that the results were pretty close to each other. The was quite small. The worst was 0.03 here-- of course, in normalized units, which was like 3% of the entire range, which is pretty encouraging.
And then we also looked at the correlation. The worst correlation was 0.99. And we also examined the error distribution to see whether our error is symmetric and narrow. Except for the permanent magnet temperature, rest of the measurements were pretty narrow and tight. Overall, the model kind of looked generalizable.
Then we took the same model and tested it on a very short drive cycle, and we saw similar phenomenon of errors being evenly distributed and the being within 0.03 and the correlation coefficient of 0.99. This kind of satisfied that, hey, the model can be applied not only to long drive cycles but also short drive cycles. So we had a kind of a model that predicted the internal temperatures of an electric motor with reasonable efficacy.
So once we are satisfied with that model, we pulled into Simulink with a stateful predict block. Now we have a bunch of predict blocks in Simulink that helps you to attach your models from MATLAB or from other sources into Simulink, so you can make it a part of your system simulation. So once we got it in there, we were able to pipe in the data that we had collected before. Same as what we used in MATLAB, we were able to pipe that data in and run with a mini batch size of 1. We were able to stream the data through to the model and were able to predict the results. Of course, I've added some scaling factors here because we had a normalized dataset.
Once we were satisfied with the results coming out of this Simulink model, we then looked at various ways you can export the model. So you can see here, in Simulink now, we can bring the model directly from TensorFlow or Pytorch, or you can bring the model as Open Neural Network Exchange format. If you are not satisfied, you can bring the model for machine learning-- you can build the model through scikit-learn block there. So basically, you attach the model through the block, and now it's part of Simulink.
So you can also bring in custom networks if you want, through that custom block that you have, which is a predict block that is available. So you can attach a Python code to it. So you have various ways to consume the model that you have developed within Simulink.
So once you have that dataset, now let's step into the next level of AI-driven design, which is deploying it to actual hardware. So here, because the model had 2 million learnable parameters, we wanted to reduce it to a target of 850k. That was our target. So we looked at several compression techniques that are available in MathWorks tools. One is called pruning. Basically, it is super helpful for convolutional neural networks, where it looks for the connections between the network layers. And if the connections are weak, and if the interdependencies are weak, it's going to remove those connections and makes the network little sparse and very efficient in terms of computation. So that's one technique here.
Of course, we didn't use convolutional neural network. We used RNN, which is Recursive Neural Network. We had to use a different technique called projection, where we used the PCA analysis of the network weights and biases and eliminate those that were not important weights and biases. And we were able to reduce this network using the projection technique.
Of course, you can also do the data compression through quantization. We'll look into it. Basically, the two data types that are of lower precision and super helpful for bfloat16 and integer 8. Integer 8 is not applicable to our problem because we are applying on a numerical dataset. Integer 8 is super helpful for images, but we use bfloat16 as a technique for looking at quantization as an option.
So using these techniques, we were able to take our network, which originally was 2 million learnable parameters, we were able to project it get to 72.8k, which is below our target of 850k. And you can also see that approximately we were able to reduce the size by 25 times by doing this projection technique.
Did we lose efficacy in the model by doing projection? No. We got almost the same results as the original model with little degradation. You can see our correlation coefficient has dropped down a little bit, but still it's above 90%. So with this, we were able to predict the model.
Now once we had the model within this required footprint, we were able to generate the code using the standard workflow that is available in Simulink for code generation and getting ready for HIL and SIL test.
And another thing we did was we actually examined the code and made sure that the weights and biases we were getting in the generated code or kind of equivalence comparison between what we got in generated code versus what we had in MATLAB to be sure that they were correctly translated back.
Now based on this workflow, we can say key takeaways are MathWorks tools enable us to do hardware-in-the-loop testing of AI models and system-level simulation of high-fidelity models. We can bring in high-fidelity model. Using AI techniques, we can test it.
The second thing comes in is various techniques are available in MATLAB, and now you can apply the best method possible because it's easy to iterate, easy to go back and forth between your results and your data, and that allows this fast iteration, allows you to compare and contrast different ROM techniques so that you can get the best possible model that meets your requirement.
So, in conclusion, MathWorks tools makes data to digital twins from workflow easy. An e-motor ROM predicts e-motor temperatures pretty accurately. And it is running at the real-time speed or close to real-time speed. And because it's a part of Simulink, now you can do large-level system testing, and also do the software-in-the-loop and hardware-in-the-loop testing much easier, much faster, and thus enabling operationalizing the AI model. Thank you.