Now, that you have seen how to implement the different total-capacity estimation algorithms in Octave, we're going to start looking at how these algorithms perform using simulation. In this lesson, we'll look at the first simulation case of a hybrid electric vehicle type of a scenario. In all of the simulations this week, we will use the fading-memory version of the different methods, but I will omit the prefix "FM" to save some room on the slides. In the fading-memory versions, the default fading factor of Gamma is set equal to one, which is really not fading-memory at all. If I use a different value of Gamma, I will make that clear at the time. When we use simulation to find inputs to a scenario, we need to decide on what are the uncertainties and so forth of all of the variables involved. I'm going to begin by assuming that the individual state of charge estimates that are used to construct the x variable can be determined to an accuracy of a standard deviation of one percent. That's probably being a little bit generous, a little bit optimistic. In my experience, the best methods of which I'm aware achieve this level only for lithium-ion chemistries having a highly sloped open-circuit voltage characteristic like an NMC cell, or maybe a cobalt type cell. We would expect more not as good performance for cells having a flatter open-circuit voltage characteristic such as lithium-iron phosphate cells instead. In some scenarios, the Sigma-Point Kalman Filter and the Extended Kalman Filter produced quite similar results. But, in others, the Extended Kalman Filter performs more poorly. This is especially true at cold temperatures and for cells having a high degree of hysteresis, where I would expect this worst performance for the Extended Kalman Filter. So, stating that the SOC accuracy has one percent standard deviation is a little optimistic, but you do have this code available to you and you can experiment with changing this factor to see how much it impacts that performance. A really nice advantage of using some type of Kalman Filter for this state of charge estimation algorithm is that it automatically gives you dynamic estimates of uncertainty on the state of charge outputs from the algorithm just as a byproduct of the method itself. These uncertainties then can be used directly as inputs to the total-capacity estimation methods in the calculation of the uncertainty of the x inputs to the methods. I am going to share with you a way to use computer simulations to demonstrate the performance of algorithms. Now, you might think it would be nicer in some sense to use actual data from cells, but there are some important reasons why using simulation at least initially is a very good idea. The main reason is that simulation allows us to constrain certain factors that would be very difficult to control in a physical battery pack and in a real-time embedded system like a battery management system. First, in the physical implementation, it would not be possible to constrain the state of charge algorithms to give a consistent level of uncertainty in their estimates. It's important to be able to do this, so that we can judge the value of good state of charge estimates versus bad state of charge estimates as input to the total-capacity estimation algorithms. That is, what is the impact of the variance of the x measurements to the algorithms? In a physical implementation, we would also not know the measurement error for the current sensor, for example, and there are challenges including measurement bias and non-linear error and random errors, for example, in a real implementation. In a simulation, we can control the level of measurement error again to see their impact on the output produced by a capacity estimation algorithm to judge how important it is to have a really clean sensor versus maybe a less expensive sensor. In a physical implementation, we could never repeat the same experiment to validate the results. We could never do it exactly to see how results change if we change some algorithm parameter. In a simulation, we can constrain even the random number generators to produce exactly the same sequence of random numbers or pseudo random numbers every time we execute the experiment to see exactly how the result changes if I change one of the tuning values of the experiment. Finally, in a real cell, it's very difficult, maybe impossible, to know the true value of total-capacity in order to validate the accuracy of the algorithm. In a laboratory, we can measure capacity quite carefully by performing a full discharge and charge cycle, but this will interfere with the operation of a physical battery pack embedded in a physical application. Additionally, we also know the actual capacity of a battery cells changes over time, and so we would have to somehow repeatedly measure this capacity of a physical system again and again, and this is difficult or impossible to do well in a physical system. But, in a simulation, we can know what the exact capacity is because we are computing our simulation input values dependent on that value of capacity. So, using a simulated data or synthetic data will isolate the performance of the total-capacity estimation algorithms themselves when all of the other factors involved are in some sense ideal. This week, I will share with you three different hybrid electric vehicle type scenarios and three different plug-in or battery electric vehicle type scenarios. In this lesson, I'll share with you the first hybrid electric vehicle type scenario. From the perspective of desiring to estimate total-capacity, the HEV application is characterized at least in part by the very narrow window of state of charge used by these vehicles. We are going to assume that the vehicle uses the state of charge range between about 40 percent state of charge and 60 percent state of charge for each of its cells. We will simulate this by creating synthetic input data to the total-capacity algorithms, where the x and y are semi-randomly computed. The true change in state of charge is between plus and minus 0.2, which we will simulate by choosing x to be a uniform random variable selected between those two limits. Also, in a hybrid electric vehicle, the battery pack is never fully charged to a precisely known state of charge. So, the values of state of charge used to compute x at the beginning of some time interval and at the end of some time interval are both estimates. So, both have random errors. The state of charge estimated time two is not calibrated to 100 percent because I don't plug in the vehicle. So, it's a uncertain value to some extent, and the state of charge estimate at time one is also uncertain to some extent. So, the variances of a difference of independent random variables is equal to the sum of the variances of those two random variables. So, the variance of the x measurement that we use as input to the HEV scenario is twice the variance of the state of charge uncertainty. So, that's then two times the square of one percent, remembering that the standard deviation was chosen to be one percent. We simulate this uncertainty by computing the so-called measured value of x to be equal to the true clean value of x added to a zero-mean Gaussian random number having this particular variance. So, at this point in the code, or at this point, we know how to compute the x inputs to the algorithms and the variances of those inputs as well. Let's think about how to compute the y inputs to the algorithm. We start by computing the true value of y if everything were ideal, and that is equal to the true capacity of the cell multiplied by the true value of x. That's not the noisy version of x, but the true version of x. The uncertainties of the y measurements are the accumulated quantization errors of all of the measurements of current. We are assuming that all the other noise sources are insignificant compared with quantization error. The variance of a uniform quantization noise is equal to lowercase q, which is the quantizer bin size squared divided by 12. When we're summing m of these measurements over some particular interval of time, the overall variance is m times the variance of quantization divided by 3,600 squared, where 3,600 is the factor that converts between seconds to hours, so that our capacity estimate is in ampere-hours and not an ampere-seconds. For the first simulation scenario we look at, we will assume that the maximum range of the current sensor selected by our battery management system is plus or minus 30 times the 1C rate of the cell. This is again a hybrid electric application. So, we anticipate that in some scenarios, there will be a very aggressive use of the battery cell. We are also assuming a 10-bit analog-to-digital converter, which means that there is 1,024 levels spread across plus or minus 30 times the 1C rate. The 30c rate is large again, but it's not out of question for some HEVs. You're going to have this code, so you can change the code to modify the value, to see what kind of impact that has. Also, most analog-to-digital converters will have more precision than 10 bits, but we will see in the different examples, that the error on the current sensor is not nearly as large a factor in the quality of the result as is the error on the state of charge estimate. So, I'm sharing the code with you. You can feel free to change these numbers and see what the influences and impacts are yourself. So, under these assumptions, the overall range of the current sensor is plus or minus 30 times the 1C rate, which is overall 60 times the 1C rate, and divide it by 10 bits, which is 1,024 levels. For the sake of example, we're going to choose a fixed time interval over which the measurements are taken and capacity is updated once every time we collect this number of measurements. Here, it is going to be five minutes or 300 seconds worth of measurements, and here, we're going to use a total capacity of the cell to be 10 amp-hours. Each of the scenarios that we look at has similar setup code. On this slide, I'll share with you code to set up this first hybrid electric vehicles scenario. The first line defines the capacity of the cell to be 10 ampere hours, the second line defines the maximum value of current to be 30 times that. The following line declares the precision of the current sensor to be 10 bits, or in other words, 1,024 levels. The slope variable will be used eventually to define the change in total capacity over time for a cell that is aging. But here, I define the slope to be zero, which means that the total capacity remains constant throughout the entire simulation. In this particular scenario, we use a value of Q nominal equal to zero when initializing the algorithms, and that means that we're initializing all of the recursive parameters, other recursive algorithms to zero, which is not ideal. So, later, you'll see that we can get better results if we initialize the algorithms with a more accurate nominal value of capacity. I define the overall range that the x variable can take on and the number of data samples that we are going to collect between updates to the total capacity estimation algorithms. I declare a variable called theCase. At this point, it's not at all critical to understand what this variable does, it will have an impact only for some of the plug-in or battery electric vehicle simulations, and so I will explain its function more thoroughly at that point in time. The following line declares the noise that we expect on the x variable, and then we declare a forgetting factor and a title to use on the graph of the results. Then, the final line of code on this slide executes an octave script called runScenario, and I will share that script to you on the next slide. So, the way that this operates is, here, we define some particular elements that specify a scenario. Then, I call runScenario, that script. runScenario runs any one of the generic scenarios, it takes these particular values and has all of the common code for executing a scenario. RunScenario itself executes the xLS algos function that you learned about earlier this week. So, that's the setup. Let's look at runScenario. The code on this slide is the contents of a script called runScenario.m, it's not a function, so it doesn't have a function definition. This script will be used by all of the six different example scenarios that I share with you. Once we set up some variables like we did on the previous slide, this script performs the common computations to execute the different total capacity algorithms and to plot results. The first line declares the number of data points that we want to put in the x and y vectors, this is the number of updates, so the total capacity estimation algorithms. Here, I'm choosing 1,000 updates which might correspond well. Here, it's 1,005-minute driving segments of the car. The second line computes the actual capacity of the cell as a function of time starting with the initial capacity and applying the slope factor. In this scenario, the slope factor is zero, so we get the actual capacity being constant for the entire simulation. The third line computes random x vector inputs between x min and x max, and the fourth line computes the true values of the y vector. So, at this point, we have computed true x and true y. Now, we must add noises and compute variances for these inputs. First, we compute the quantize resolution, which we denoted earlier as a lowercase q. I, then, define a vector of ones which are the default standard deviation for every measurement noise the standard deviations of the x variable are computed as the SOC noise times this default vector. There are different scenarios that we're going to run and the particular scenario we're looking at is a case one scenario, whereby, we compute the noise on the y-variable as discussed earlier in this lesson. Again, later on, I'm going to share with you a different case where we compute the noise on the y variable in a different way and we'll talk about that. Then, finally, on this slide, we add noises to the true values of x and y in order to produce inputs to the xLS methods. The runScenario.m script continues on this page, so this is one continuous section of code. The next thing that it does is to invoke the xLSalgos.m function using the inputs we have computed, and to get the outputs of total capacity estimates and their variances, so then we create a figure and we plot the capacity estimates as well as the three sigma error bounds or uncertainty bounds on those estimates. You'll notice in the Jupyter Notebook code on the Coursera website that this plotting code is slightly different. This has to do with differences between MATLAB and Octave and I wanted to make sure that the code that you are working with on the Coursera website uses consistent colors, but the idea there is exactly the same as the idea here, it's just slightly different commands are used. Let's look at some results. Remember that this scenario does not initialize the recursive parameter values or equivalently, we initialize their values to zero instead of using a synthetic first measurement. The figure on this slide shows the evolution of the capacity estimates from each one of the methods as the estimates change over time. The thicker lines are the estimates themselves and the thinner lines are the three sigma confidence bounds on those estimates. The true capacity is drawn as a dotted black line horizontal at 10 amp-hours. It might appear to you that there are only two estimates that are plotted a, dark blue line and a light blue or cyan colored line. But in fact, all of the four different estimates are plotted here. It turns out that for the assumed simulation scenario, the inputs, the math and the code for the weighted total least squares, and the total least squares, and the approximate weighted total least squares methods are exactly the same. So, even though we went through a lot of different math last week under the assumptions of this scenario, the cost functions turn out to reduce to the same thing, and therefore the solutions turn out to reduce to the same thing. Only the WLS, the weighted least squares method produces a different result. So, all of the total least squares methods converge to the neighborhood of the true total capacity, and all have error bounds that surround the true total capacity. So, we can conclude that these methods are operating reasonably well, within expectations, but the weighted least squares method is biased. It first, does not converge to the neighborhood of the true total capacity. You can see that it is converging to a value of around 9.8, 9.9 amp-hours instead of 10. Its error bounds are absolutely terrible. It's impossible to see them on the scale of this plot. So, I recommend that you run the octave code, the Jupyter Notebooks provided to you on the Coursera website, and then you can change the axes of these plots to zoom in on the estimate and see that the error bounds of the dark blue line are actually really really narrow, really tight. They're so narrow that you cannot distinguish the error bounds from the estimate on this scale plotted on this figure. So, that means that the WLS method has extreme confidence that its estimates are very good, but we can clearly see ourselves from this example that the estimate is not very good at all. Perhaps, you're beginning to see then, why I do not recommend using the weighted least squares method. First, its estimate is not that great. Second, we cannot rely at all on the confidence interval produced by the method when we're using its estimate to compute an energy estimate or something like that later on. To summarize this lesson, I've shared with you and approach to gaining insight into the different algorithms using simulation. For this particular HEV scenario, the range of the x variable is chosen from the maximum change in the state of charge during operation of that vehicle. The noises on the x-variable were assumed to be from state of charge estimation errors. The range of the y-variable corresponds to the true x multiplied by the true total capacity, and the noises on the y-variable are assumed to be the accumulated current sensor quantization errors. For this particular scenario, all of the three total least squares methods give identical results and identical error bounds, and these estimates in bounds are all quite reasonable. On the other hand, the weighted least squares method, instead, gives a very biased estimate and very unrealistic confidence bounds. We're beginning to see that the weighted least squares method does not really perform well under scenarios that are quite realistic themselves, and you will continue to see this in the remaining scenarios that we examine this week.