Addressing Challenges Involved in Developing Battery Management Systems Using Simulink

So welcome to this two-part series, and the second part of it, where we're going to primarily talk about battery management system and what are the various aspects that typically goes into developing such things. A brief introduction about us-- I am Abhisek Roy. I work as an Application Engineer here at MathWorks. I specialize on control system design and plant modeling for various automotive applications. Ramanuja, would you like to introduce yourself?

Yep. Thanks, Abhisek. I'm Ramanuja. I work as an Application Engineer along with Abhisek In the areas of control design and plant modeling for various applications as well. So back to you.

Thank you.

So while preparing for this particular session, we ran a LinkedIn poll. So Ramanuja, why don't you walk us through what was the motivation and how you use this?

Yeah, Abhisek So before starting this webinar, we wanted to understand from our audience what topic is more important to them. So here, you'll find few topics that you typically find in BMS applications such as modeling battery packs, closed-loop battery simulations, SoC estimation and developing BMS functions.

We see that a lot of participants have responded with SoC estimation and BMS functions, which we'll be definitely covering this webinar today. Also, we noticed that, globally, modeling battery packs is an important topic since it is also used to present your BMS functions and tested in real-time scenarios. So we would be covering that as well. Yeah, back to you, Abhisek.

Thank you, Ramanuja. So now, thanks to everyone who participated in that LinkedIn poll. Now, we don't want this webinar to be a one-off series. Instead, what we want is to be a partner. And for-- [AUDIO OUT] put that poll question for you. And we wanted to know where are you in terms of your journey in regards to BMS. So are you working on it currently? Or is it something that you will be working on in a short duration? Or is it something that you are preparing yourself?

So let us know about that. So we will wait for the poll for around 30 to 40 seconds. The idea of this is we would like to understand what is of importance here. And based on that, we will prioritize the content that we work on and update the following sessions as well. Great. So thank you for your responses.

Now, for to decision, since this is a really vast topic, we thought we are going to use divide and conquer. So as you can see here, so I'm going to work as a system engineer. And Ramanuja is going to work as an algorithm development. And the motive behind is that throughout my career, I have been working with a lot of system modeling. And Ramanuja has been supporting a lot of customers on algorithm design and any additional other stuff as well. So we thought, why don't we bring that flavor into this workflow as well?

So we were about to start our journey. Like, I build my plant model, and Ramanuja does his things. But we quickly realize that this is not how it's going to work. And Ramanuja and I really have to have a few discussions about this, like what exactly we really want to do. So Ramanuja reached out to me with this particular thing. And there was a horrible slide or horrible picture that's coming up next. But I understood from Ramanuja what he is looking at. So Ramanuja, why don't you let us know what was the summary of our conversation?

Sure, Abhisek. So me being the algorithm engineer, I work with the BMS applications. So here, you'll see some of the typical tasks which presents itself in the BMS application. So we see something like a supervisory logic. We see the SoC estimation. We see fault detection logic. These are some things what I implement and try to put in my embedded code.

If we could go to the next slide, we would also notice that I am being handed with a big requirements document which they also need to convert it into these specifications, right? Now, my concern at this point is I want to understand the algorithm what I build. Does it really work when I connect it to the battery pack? And can I test for all the edge cases?

Now, this is a big concern to me, and that's why I approached Abhisek to see if he can help me out in part of building some models have been trying to do simulations and do testings. Yeah, that's why I reached Abhisek. And I'm interested to see what he has to say about this.

So what I realize eventually is even if he wants to get this software going, he has certain things that he wants to test. And you also mentioned one key point, was that he needed to check some corner cases. Now, these are really something that should be done in simulation because we know how hazardous those battery packs are.

So what I propose to Ramanuja is that we have something which can look like this. So I could probably give you a battery pack. And so that battery will have cell-level information accessible to you. I will also provide him with certain means through which he can continuously get feedback from each cell.

And now a few things what Ramanuja mentioned is that he wanted to do SoH estimation. He also wanted to do contactor logics-- those, right? So I implemented those things using certain ways. And eventually what I understood is that I will be sending quite a few monitoring information which will be passed on to the BMS slave module. And while Ramanuja works on the master module, he will make sure how it communicates. So this is how we split it. So Ramanuja will be focusing on the left-hand side, and I will be focusing on the right-hand side aspects.

Now, while I got started, I quickly realized that the things that Ramanuja mentioned are not the only things that I need to think about. There are quite a few other things that I have to worry. The first thing is-- so Ramanuja is kind of looking at cell-level information. But I still have to decide what kind of battery pack I'm going to use. What will be the current requirement that is coming out, right?

And so for that, what I really needed was a system-level model. This could be based on what kind of vehicle we're working on-- could be two-wheelers, three-wheelers, four-wheelers, doesn't matter. But as long as we have a longitudinal simulation model, and I can give certain drive cycles as an input to the system and then have a simplified simulation, when I have all the components working at a high level, and at least gives me the what is kind of high-end profile we're looking at, that is something can get me started. So it will help me in understanding what is the amp per hour rating of the battery pack I'm looking at, how many number of cells I need in general, and what should be the parallel, series parallel combination as well.

So to help you with this, what I did-- I used Powertrain Blockset. Some of you may be really familiar with this tool. And in our first session also, we gave a brief of what this does. And what helped me really well was that I had some preassembled models that Powertrain Blockset provides, which helped me in quickly parameterizing my vehicle model.

And based on that, I modeled my driver behavior. And then I worked with certain parameters on a high level what I had. And I made sure that I looked into the current profile. Now, looking at the current profile is not the only thing. There are also some other things that I really needed to take care. A few things that those things were-- the models that I'm going to create since Ramanuja's algorithm is going to rely on them-- I needed the model to be as good as possible. So for that, I needed to also decide what kind of data I have access to. If not, what are the other ways that I have to use, right? So those are all the things that I was thinking.

So after a lot of discussion, we started to get on with our work. And this is something what we ended up with. So there will be a plant model on the right-hand side, which will be our battery pack model. And then we will also have a BMS software model. This is, you can imagine, the master-slave arrangement that I was briefly talking about. And with that model, what I'll be able to do is, for a given current profile, we will be able to understand how each cell behaves, how the SoC of each are changing, and various other related aspects.

Now, key point to note here is that I mentioned with the current profile that I am providing, right? So I deliberately-- I'm choosing a current profile instead of the full vehicle model that I just showed you. But the reason is I really wanted to get into the depth of the components, all right?

One other thing which we kept in mind is that the models that we create, they are also real-time capability. One of the things what Ramanuja also briefly mentioned is that he's going to pass on to another team who's going to do real-time verification of that. So we thought, OK, why not use the same model for it, all right?

So with that context, what we are going to look at primarily today is this-- if you place us in terms of a V diagram, we come around at that component design stage, where I will be walking you through the system-level design. And then we will do the controller design. And we will briefly-- oh, there are also other steps like the implementation and then also the hardware-in-the-loop tests, which we will also look at down the line.

So let's get started with the plant model. So the approach that I'm going to take is equivalent circuit model, OK? So what happens with this is we will have all these components. And here are the significance of that. So first, I have this open-circuit voltage. Then we have our terminal resistance. Then we have our transient dynamics. And if we want, we can also have these parasitic losses taken care by this diode and the resistance part, OK?

Now, based on what we are looking at, we can choose a mix-and-match of all these components. If we want the transient dynamics, then we would need those RC branches. But if you are looking at a high-level system-level simulation where transients are not needed but certain state values are fine, we can get rid of that. But open-circuit voltage and the terminal resistance is something that we should definitely have to have a meaningful representation of our cell.

Capacity losses, which I highlighted-- some cells have that behavior to be quite significant. In our case, we are considering in lithium ion, and our run was quite small. We were not looking at a state of health estimation. So we ignored this particular branch.

So now while the given circuit looks good, life is not as simple, and the batteries are certainly not. So it turns out that all of the parameters that we have, they're not a singular value, but it depends on so many aspects. But a lot of research has gone into, and we have found out that primarily the SoC and the temperature has a very good effect, visible effect, for short duration of the time which we're looking at for all of these parameters.

So what happens is my open-circuit voltage, all the resistances and capacitance values, whatever we have-- they are dependent on the SoC temperature, sometimes also the number of cycles it has gone through, and few other aspects. So what happens is just by formulating this equation is not going to help us. We also need a means by which we can find out each of these parameters which are going to be dependent on other values. So this is where data is going to rescue us. And this data is coming from the field.

But that being said, battery testing is not as simple. There are also various ways that one can do this battery estimation work, the battery testing workflow. So here, I'm highlighting two major things that we have seen. On the left-hand side, what you see is our typical voltage across with respect to time for a certain CA rating.

And this helps us-- so if we have this parameter, this is the one parameter that we find predominantly customers have access to. We can make use of this parameter to identify the open-circuit voltage that I showed in my earlier slide and the terminal resistance. So if we are not looking into the dynamics of the cell, this is a good one to get started.

However, there is also another case which needs a lot of investment from the testing side. And there are a lot of facilities in India also which can help you and get this data. But it has a very good effect in our SoC, which is the pulse discharge test. In that, what happens is we give pulses, like of a quite high current rating for a short duration of the time, then let the battery relax and keep doing it multiple runs until it goes out of charge, right?

If we have this, then this can help us in identifying all the parameters that I showed in the earlier slide. The advantage of that is that will give me the most detailed model with all the relaxation gap needed into the picture. And that can also help us a lot in better way to identify the heat losses that you are going to see. So this is something that we are going to talk about towards the end.

So now I happen to have access to the right-hand side, which is the pulse discharge test. Now, so my step is to now choose one model parameter or architecture that I want. So I chose 1 RC given circuit. But then what I should do, theoretically, is I have my model available to me. And I also have my experiment. I had my data from my experimental setup. I need to match them. And the way we typically match them is we try to look at the values, we try to manually tune, and then we find out what's happening.

But it is not that easy for my case, because if you remember, I was having these four parameters, but all of them were lookup tables. So actually, even if you see four, I was kind of dealing with 44 or even more parameters, right? So while this is the approach that I was supposed to take, I was to compare both of the output and then see if I'm good or not and then just move on. I had to rely on some other aspects like automation methods where we could use optimization to give me the parameters instead of manually doing it.

So what I did-- so how was my workflow? So now fortunately, Simulink and Simscape has quite a few battery models for me to explore. Now, here, I have listed a few things for you. If you remember, I try to maintain the same flow. So on the left-hand side, what you see, it has a model where I'm not looking at any RC branches. On the right-hand side, I have all the models. I have all the RC branches model, right?

So based on what is the flexibility or the fidelity level we are looking at, we can choose the model. But what predominantly we are looking at is if you look at each of the parameters, for example, if you look at the SoC, you will see that there are four values that we are providing. So to start the pointer just for this slide-- yeah.

So here, you can see that I have my SoC vector. And then in the bottom, I have my temperature vector, and also then I have my-- all the actual values, my voltage, as well as my resistances to as the function of these. So this is the parameters I was actually talking about. So I need to identify this.

Same thing is also available here on the right-hand side. We have also provided quite a few battery models, which these are the models that are publicly available. And you can use this battery parameterization manager to choose the cell if it is within that list, and the parameters will be automatically populated for you. So you can explore, look at. If this is something that you are using, then it will be quite good for you.

However, in my case, I had to go ahead with the parameter estimation because mine was not in the list. So what I did was I took this particular model on the top, which you see. This is one, again, one of the documentation example, which is set to run a pulse discharge test. So I have my battery current source, and then I have my voltage source, right? So I will be driving the current. And here, you can see at the bottom of your screen what are the pulses that I have given.

Now, interesting to note here-- you will see that there are two waveforms. The yellow one is what my model is producing, and the blue one is what I have from my field. Now, why this discrepancy? I am not sure if it is visible to you, but if you look at the values of the open-circuit voltage, I didn't bother. I just gave one value for all, which is of course, not true and is not going to work, and that's what we see.

So what now my next step is, so I eventually got a simulation model which simulates for the input that I give, input being my pulse discharge current waveform. But I need to do the optimization. Now once I do the optimization, this is what I end up with. Now in our case, in my particular case, I was lucky that the data that I had and the RC branches-- number of RC branches that I chose-- it was pretty good to capture this data.

But when you have access to it, you will see that there are a lot of intermediate steps that are involved from this before to after. I have spent some good amount of time in removing the excessive number of points that I had in this flat range, right? And there are quite a few preprocessing that I needed to do. But once I have done all of those things, this is what I got.

So I also want to take this time and go through what was the process like. So let's see. OK, I'll work with the laser for the time being. So I have put a small video which walks you through the process that I took. So this is the model, and so I started off with this model that I have. And OK, when we do laser, I can also get rid of this. Yeah.

So what you see here is that I have this 1 RC branch, and each of the cells there also-- the blue line what you see is the electrical line. And what is happening is that's the electrical current flowing. You can imagine that here. Now in the parameterization, there what you are seeing is that I have this vector of capacitance, which I'm highlighting. And then I have these SoC break points, which I want to do.

So eventually, what is happening is based on the SoC points, my capacitance value is going to change. Something similar is also done for the resistances and also for all the other parameters.

Abhisek, can I interrupt you here?

Yes, Ramanuja. Go ahead.

Where these parameters do depend upon temperature as well, right? I see only SoC-- dependence on SoC here.

Yeah, yeah. That is a very good question. So the models which I'm going to provide towards the end will have the temperature dependency. But there is a reason I am avoiding it. So my next slide will answer. So I am kind of tricking my tool to give us estimations faster. I'll show you what I mean by that. Thanks for the question.

So if we continue with the workflow, what you will see is that next to what I'm going to do is I'm going to open parameter estimation workflow. But before that, I'm doing a small run. So again, this is just to validate that-- what I showed you earlier, that there are still some discrepancies for the currents, right? And one thing is if you look at the voltage profile, it's easy to also estimate those parameters because it is kind of telling you whatever those voltages are for each of the pulses, right?

So if I were to manual tuning, open circuit is probably the one that I can easily do. OK, but what about other parameters? So what I did, I used the parameter estimation workflow all together, and I have set up my experiment where I have given the same input and output, as you can see. On the left-hand setup, I have also given my parameters.

And now in this case, since we are looking at a mathematical problem of optimization, it is very important that we give the right range of the resistances and capacitance values, right? And so I restricted all the values. So for the resistors, I know I give about 0 to 1, 1 ohm only, right? Not more than that. For open-circuit voltage, is I restricted it to 2.5 to 4.5 or 5. So what happens is this helps with optimization to convert faster.

And so that is also one of the reasons why I excluded the temperature, because if you imagine, when the pulse discharge test is typically done, they are done for a temperature. And they really spent a good amount of time in keeping the temperature constant, so I'm leveraging that. So right now, I am working with one-dimensional lookup table, where each of the parameters, as you can see, they are currently getting estimated. So each of the parameters are dependent on only the SoC. So it's eventually only one-dimensional vector.

So I'll let this run go for a few more seconds. Yeah, one more thing is that I have sped up this video because typically, this does take some amount of time to estimate. And so what I did do is once I have got a certain amount of convergence, I rerun the model with the parameters that I just found. And you can see fairly good matching. There are still ways to go. There are some places where you can probably visually see that this value can improve, a few things, like towards the middle, some values can still improve. But I was happy with what I got.

Now coming to the question what Ramanuja asked. So temperature dependence is very important. So how to do it? So this is how we do it. So the experiment that I just ran-- it was run for 20 degree centigrade, Right? And then I get that lookup table. So if I were to now have the temperature dependence, what I can do is I can gather another temperature value, redo the same thing, and convert that 1D lookup table to 2D lookup table. That's all.

So how it helps is that, because I'm now focusing it on only one, I get faster convergence. And sometimes also what happens is if the convergence parameters or the optimization parameters are not chosen properly, we can run into a significant slow estimation, which I really don't want. So these are the few techniques that I used. So Ramanuja, does this kind of give you the temperature dependency that you're looking at?

It definitely does. Yeah, I mean, I could see that now the open-circuit voltage depends upon SoC and temperature. That's pretty good for me.

Right, so what I did now is I took all the cells and then also connected them in the configuration that I needed. And as you can see here, I have six cells that are connected in series. One thing that you will probably also notice is that the orange line that I have, which is running parallel to itself-- that is the thermal line, OK? So now how this thermal analysis is happening? The cell model that I just created-- it knows the resistance values. It also knows the current value. So what I'm doing-- each of the cell is giving me I squared R losses, OK?

And what I'm doing is I am producing that heat as a heat source. Each of the cell is producing that. And you can see probably the worst effort of designing thermal, which is if you look at the top, the top portion is connected to the environment, and the bottom portion is isolated. And as you can imagine, this cell is not going to thermally behave properly, which is fine for me. And Ramanuja really didn't ask me anything what kind of cooling he was looking at, so I just let it go. But I didn't leave it there. There are a few other things which we have, if needed, I could do. So I'll show you that.

So that was for one cell. Now, if you also remember another question what Ramanuja has was he wanted to also have access to the electronics that controls the part for charge balancing. So this is-- what you see here is the paths that are running parallel to each cell. And all of them, I have a diode. And then I have my register with switches.

So what eventually we are doing is we are using this parallel path if we want to do any passive or active balancing, also using this path to monitor each cell's voltage and current. And now that we have also the thermal model, we could also put a thermal sensor and then a temperature sensor and can get the temperature and pass it on Ramanuja for his processing, right? So this is one module that I created.

Now, one thing to note, since I'm talking about thermal-- in my case, I restricted-- so I looked at each cell as one thermal mass. So I can use that to kind of have an average estimate of what the cell temperature is going to be. But sometimes, you may also look at the gradient of the cell. That's something that we cannot do here. I have not prepared the model for it, right? So this is something that I wanted to highlight. So that is one module, OK? So all the cells, then a poorly designed thermal, and then some parallel electronics which does the measurement.

So what is the next step? You connect them and see the parallel combination based on what I need. Now, this is where-- you should remember, I did the analysis in previously with my system-level model-- where I found out what kind of current profile you are looking at. So this helped me in getting this particular model that you have seen. And then this is the high-level model.

So I have my battery pack on the left-hand side. And then I have the precharge-- I've also introduced a precharge circuit and some loads. Now, these loads, what you see on the right, most is a simplified load, a simple source, and also some chargers. These are voltage sources that you have disconnected with some reactants to them, or impedance to movement. I didn't get into the really detail of charger dynamics, but if needed, we can do it. But the idea of this precharge circuit, really-- I mean, I'm sure Ramanuja is going to talk about it in his algorithm design. But it is to control the inverse current when you're switching between different modes.

So now with this, we have got a battery pack model. And here is a quick snippet of how the model's precharge circuits look like. I'll not get into the details of it, but I want to draw your attention to this particular example. I did not explore it, but this is definitely something that you can explore, is the cells that I have created. You can also take it to design a detailed battery module with proper like, placement, cooling, thermal, everything.

So this particular model that I'm showing you, it has the capability for you to arrange them and/or do thermal analysis to find out the hot spots within the pack and design a cooling network. The cooling network and even go as detailed as you see here. So if you notice the blue circle towards the right-hand side image, that's where the big battery pack model which I just showed. And the rest of the components what you're seeing are all the cooling lines that I got in my vehicle.

Now, this thermal model is really pushing the limit, where I really have a detailed thermal design of-- and then cooling part, including the HVAC of the vehicle. This could be very well overkill for you. But this is an example that exists in our tools. So in case you want to do that study, please have a look at that. If you need any help in understanding how we have designed the cooling packs and then cooling plates, all the pipes, then reach out to us. We'll be happy to walk you through this.

And also, this is an example for your reference and which I'm also going to send Ramanuja to ask him to change this model because if he really needs a detailed thermal model. But for me, it was not needed, so I just had these as references and also something for you which you can go and download and use it for your purpose. So these are all, as you can see, uploaded in the File Exchanges. So with that, I think I kind of got a system or the plant model which can help Ramanuja in doing thermal analysis and then also understand how each cells behave in the overall pack, which is what he requested.

So at this point then, I'll probably introduce Ramanuja again and ask him to also walk us through how he did the rest of the plan. I'm pretty sure while I was doing all this, he was not sitting there. He was also-- he did some of the stuff. So Ramanuja, over to you, and so I'll stop sharing. And let's see. So, yeah you should be able to share your screen now.

Yeah, got it. I--

Great.

--need to start sharing my screen now. Can you let me know if you can see the V diagram?

Yes, it's up.

OK, great. Yeah, so thanks, Abhisek, for building that battery pack model for me. Now, as Abhisek was building the battery pack, I was involved parallelly in building the BMS algorithms, right? Now, with the help of Abhisek's battery pack model, I'll be able to perform closed-loop simulations and verify that my BMS algorithms works better. So in this V cycle, the next portion we'll be covering is on how to design these BMS algorithms.

So when I talk about BMS algorithms, you would see several modules as shown on the screen. One module could be the supervisory logic which determines the state active during the operation of the battery. Then you would see the fault detection module. Then you also see the SoC module and quite a few others. I will go down into few of these modules and then show you how these modules are built.

So starting with the supervisory logic, so supervisory logic typically determines what state is active during the operation of the battery. Typically in a vehicle, you find the vehicle moving between standby mode, the driving mode, and then the charging mode. And if at all there is a fault, then you eventually end up in the fault mode.

The standby, driving, and charging mode are typically changed by the driver's input. For example, when I start the vehicle, I'm changing from the standby to the driving mode. And those transitions, what you see here, are defined by the driver. These state block what you see, they also can define the logic which needs to be active when the corresponding mode is active.

For example, if you look into the charging mode, we see the logic of that. Here, you see that we initialize charging. Then we start with constant current charging. Then we go on with a constant voltage charging, and then the charging gets done. So here, you also see the implementation of that charging logic into this charging state.

Now this state chart gives me an idea pictorially which state is active and which transitions are activated based upon the inputs. The output from this state chart is typically to understand what state is active and the current requested on the battery. Let's go to one more state and then see how that's built. And here, I'll be talking about the fault monitoring logic.

So in fault monitoring logic, I see that there are three sublogics. Each logic should determine the current, voltage, and temperature faults. For example, if you were to go into the current monitoring logic, I see that typically we initialize with the No Fault, which is the default fault when you start the vehicle. And then when the current exceeds or when the current goes to a fault limit-- let's say the current exceeds the charging limit-- then we wait for some time. And if the error process, we declare that we have a current fault. And the subsequent steps will be taken care of via supervisory logic.

So in a similar way, we also see that the voltage monitoring and temperature monitoring logic implemented. You would also notice that each of these logic has a dashed border line surrounding that. And that indicates that these logics are running in parallel, in tandem with each other. A typical outcome of such a model for fault monitoring is to understand if a fault is present, and if so, what kind of fault is present.

So having dealt with the supervisory and the fault monitoring logic, let's move on to our top diagram and just focus on the SoC logic. The SoC is pretty important because you want to know how much charge is left for you to drive the vehicle. The SoC algorithms have been implemented in this model over here. And you would see quite a few algorithms, such as coulomb counting, and then the unscented Kalman filter and extended Kalman filter.

The coulomb counting works in such a way that you basically integrate the current coming out of the battery. Now, that acts as a proxy for the charge discharge, and hence you could calculate the state of charge of the battery. We also have the Kalman filter-based algorithms, which are very good in correcting for any errors or initial gives which happens in this overall estimation process, which we will see it in a while.

Well, when the BMS algorithm is ready, now I'm ready to integrate that with the plant model what I will built and then tested it in simulations. So here I show you a model with the VMs and the plant model. So in order to test it, first, I need to create a test harness for the overall model. A test harness is a way to instrument your model in such a way that you could use several test conditions and see the outputs for those conditions. Here, I have predefined three different test conditions, and I could select one among them.

Once I selected any one, I could go and see what that test condition is actually about. So here, I go into the implementation. And then here, you would see that this test condition is basically changing between transitions from Driving mode. And then after 3,000 seconds, it goes on to the Balancing mode. Then after some time, it goes on to the ChargingAndBalancing mode and then to the PostChargeBalancing mode. In a similar way, I could change different states and the duration between transitions and create different scenarios to test my battery logic.

So once the test condition is defined, the next step is for me to simulate the model and understand how the model works in that scenario. So here, I'm simulating the model for around 40,000 seconds. And you could see how quick the simulation is getting done from the bottom progress bar. Once the simulation is completed, now I can go and check on the outputs.

So over here, you could see different charts coming up, like the input state, what I requested. You could see that first. And then following to that, you could see the overall pattern. Then you could see the individual cell temperatures. Then you are seeing the battery pack voltage output, then individual cell voltages, and finally the SoC as estimated by three different algorithms.

Now, over here, I also have a flexibility to change the state manually during simulations. So here, whatever state I request gets activated during simulation. And let's see how that works. So using the knob, what you see here, you could change between various states. And this change is happening during simulation because you could see the plot getting progress. Now, in this scenario I could create different situations in such a way that I could create a fault condition and then understand how the BMS responds to that particular fault.

Now, having seen this graph the method in which I'm going to test, but let me go into the particular plots and then see how I would interpret the results. So first, I'm going to show you the discharge plus charge view. Here, first, I will bring your attention to the SoC plot. And here, you would see that the SoC's decreasing during the discharge then increasing during the charge. That's pretty clear. You could see the temperature almost constantly increasing throughout the operation of the battery pack. And you could also see the current demand based upon the driving pattern and the voltage of the packs accordingly.

In the discharge only mode, you could see that SoC is monotonically decreasing over here. I could see a corresponding temperature increase towards the through battery operation. And then I could also see the temperature difference between each individual cells, which is also important for me to understand the health of the cells. I could also see the current and voltage profiles, which also is dependent upon the driving pattern.

In the charge only mode, again, I could SoC monotonically increasing. I could see temperature increasing but then going back to normal once the charging stopped. And then in the current and the voltage profiles, I could see portions of constant current and constant voltage charging.

But once all that test is done, next, let's run a test to evaluate the SoC estimation algorithms. Over here, you find a comparative study of three different algorithms what we choose. You could also see a golden line which indicates the true SoC. And my objective is to find out which algorithm estimates closer to the true SoC value.

So the coulomb counting, you could notice that it starts at 0.8, and then it goes on forever without touching the two SoC line. But whereas the Kalman filter-based algorithms, even though this chart had an incorrect value, eventually they catch up, and then they are following the true SoC line. This is because of the feedback nature worked into the Kalman filter, which corrects the initial bias of the estimations.

Now, there is also an approach that you can use neural networks to find out SoC, which I won't be covering this discussion. But I would urge you to go to this video series which talks about that.

Once SoC estimation is done, we could extend and then find out SoH and also the remaining useful life of a battery pack. And this will help us determine when to replace the battery pack or not. Again, this is a deep-dive topic. And if you want to have a session on this, I would ask you to reach out to MathWorks staff. Now once--

So Ramanuja, I have a question before you go to the implementation. So all whatever you showed, you used the model that I provided. Is that correct? Or did you do any modification or additions?

No, so I just used the model what you provided. I didn't have to make-- so the interfaces are defined well for me. And then I just connect my BMS algorithm and then run the test.

And how is the performance? I mean, I really was not able to optimize it, but was it good enough? Did you have to do anything to have it a fast-running model? Or how was it expected? Do you think that it's ready for it to be deployed? Or do I still need to do some optimization?

OK, OK. For the deployed conditions, when you want to deploy these models to real time, I think we do need to make some changes. We can't take this model as it is. But then I will be coming to that in a while, and thanks for giving me that view.

Yeah, great, great.

So, all right. OK, now, once the algorithm was designed, and before I go to the real-time testing, the in-between stage is where I go for implementation, right? Now here, I want to deploy the logic what I build into my embedded hardware. Well, typically, it so happens that any control engineer like me may not be having the ability to do a C program for all these logics what I showed to you. And typically, my engineering colleague may not have much experience with BMS functions to design these modules.

And you need to bridge this gap. That's where we see the code generation technology coming to help. And then with that, I will be able to convert these algorithms into an equivalent C code. But once the code is generated, I could just click on some of the variables over here. And it would point me back to the model that that particular logic or that statement is implemented. Now, this shows that we have a bidirectional traceability between the model and the generated code. And this helps me to review, debug, and report my generated code.

So once the code generation is done, now, I would be a little bit anxious to understand if there are any bugs present in my code. And if there are some bugs into it, I really want to understand how to find it and try to find it. To get through this process, now, typically I would be following a rigorous testing approach, a verification and validation approach, which is also supported. And then to know more about that, I would urge you to join this webinar which talks about the foolproof electric vehicle software design process.

Now, specifically BMS and where we apply this process, we also have a video series which talks about how we can apply verification and validation techniques to BMS algorithms here.

Now, once I understand that my embedded hardware is really-- the code is really tested and deployed to the embedded hardware, next, I go on to test my embedded hardware for real-time simulations. Now, over here, let's see what traditional simulation looks like. Well, here, I have the BMS hardware. Now, I connect that to the actual battery pack and then subject the hardware to different test conditions and then test my hardware.

Well, there could be some sort of challenges here. Now, one could be that it might take longer time to test. For example, let's say if I'm testing the charging cycle, and if the battery is already fully charged, then I have to discharge my battery and then proceed with my test, right? Sometimes, this would be difficult to reproduce. We all know a situation where something doesn't work in front of us, and then when we bring in a colleague, and it works in front of them brilliantly.

And it could be difficult to test fault conditions. With batteries, it's a really serious issue. Sometimes, people run into thermal runaways. And we need to make sure that we are running safe testing environments. And if you are doing hardware testing, you are always limited with the ability not to introduce just automations.

Let's see how hardware-in-the-loop testing is able to help us here. Now, over here, I'll be having my BMS module, right? But then instead of the actual battery pack, I'm replacing that with a BMS simulator. So first, I reused the model what Abhisek had built. Then I generate C code for that model. Then I deploy it into a real-time emulator such as the performance target machine from Speedgoat.