Onboard Battery Pack State of Charge Estimation Using a Trained Neural Network - MATLAB
Video Player is loading.
Current Time 0:00
Duration 15:02
Loaded: 1.10%
Stream Type LIVE
Remaining Time 15:02
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 15:02

    Onboard Battery Pack State of Charge Estimation Using a Trained Neural Network

    Trevor Jones, Gotion, Inc.

    Using battery cell charging data stored in Gotion’s cloud data platform, we train and validate a neural network to estimate pack state of charge (SOC) during vehicle charging with the Deep Learning Toolbox™ and in-house data query API. We create an onboard SOC estimation strategy in Simulink® using the trained neural network. Afterward, we verify the algorithm’s ability to meet functional requirements using Simulink Test™ and deploy it as a “shadow” strategy within an existing AUTOSAR SOC software component. The impact on CPU and memory resources of the microcontroller is evaluated first. Then, we evaluate the neural network-based SOC estimator on test vehicles and find that the results (< 3%) are promising.

    Published: 1 Jun 2022

    Welcome, and my name is Trevor Jones, and on behalf of my colleagues at Gotion and myself, I'd like to thank you for attending. In this talk, we will discuss onboard battery pack state of charge, or SOC estimation, using a neural network.

    In this talk, we will describe our experience at Gotion of evaluating a prototype SOC estimation strategy for use in our production battery management system, or BMS. The project began in late 2020 and ended with vehicle tests in early 2021, using MathWorks tools throughout the course of the project.

    It will begin with an overview, and then highlight some key requirements and aspects of the design. We'll go over test results, including performance on onboard vehicle tests, and we'll wrap up with a summary of the project's findings.

    In late 2020, we began work on a project to test a prototype pack SOC estimation strategy to be deployed on test vehicles in early 2021. We had two primary objectives in mind. One, to assess the feasibility of deploying the estimation strategy and our production BMS, and two, to gather design information that could be helpful for use in further detailed development.

    We identified three high-level requirements for the prototype project. First, we identified a 3% SOC estimation accuracy target based on prior conceptual studies. Second, for the purposes of this project, we limited our focus to BMS charging scenarios, with the thought that once results were in, we could move on to other operating scenarios in future projects.

    Third, we opted to deploy the prototype as a shadow strategy, meaning that the prototype strategy would be added to baseline software, but by design, it should have no impact on the operation of the vehicle. From a logistical standpoint, the algorithm was trained on lab test charging data for Gotion battery cells, shown at top right.

    The algorithm, however, needed to work on the battery pack in the middle, which contained many more cells and with less instrumentation available per cell compared with the lab tests. Throughout the project, MathWorks tools helped automate the design steps, and that made it easier for us to stay focused on meeting the goals of the project.

    Over the course of the prototype project, we followed a lightweight version of the V-model development process. In today's talk we'll highlight steps, beginning with software requirements and design, and then go over testing results, working our way from unit test to system level tests, including onboard vehicle tests. On each of the following slides you'll see the applicable portion of the V-model highlighted in the upper right corner.

    Let's spend a moment here on how we use MathWorks requirement management tools for the prototype project. The screenshot at left is taken from the Requirements Editor tool, shipped with Simulated Requirements Toolbox. Let's focus on one lower level requirement, shown highlighted in the Requirements Editor.

    The requirement is allocated to a Simulink Subsystem, used in the prototype design, which implements an SOC neural network calculation. The requirement specifies that the neural network should predict SOC to within 3% accuracy on training, validation, and test data. Bidirectional links between the model and the Requirements Editor help us to connect the requirements with implementation.

    In the upper right, we have a screenshot of the Requirements Traceability Matrix Tool, provided with Simulink requirements. Taken together, we found these tools helpful in reviewing how requirements were implemented and also flexible to use when making changes.

    Here we will go over a schematic overview of the prototype design. As an overall objective, the SOC estimator prototype is required to estimate pack SOC, based on available pack measurements and knowledge of the battery operating status. It does so with the required accuracy of 3% estimation error under charging conditions.

    The available measurements consist of voltage readings for each set of parallel connected cells, pack current, and temperature readings from sensors located within the pack. Based on these measurements, a neural network calculates a nominal estimate of the pack SOC.

    The final SOC estimate is calculated based on a weighted average of one, a prediction of SOC based on the accumulation of pack current, and two, the nominal SOC calculated by the neural network. When the BMS is charging, the estimator gives weight to the estimate provided by the neural network. So by design, the neural network needs to accurately predict the SOC and BMS charging conditions.

    Let's shift our attention now to the procedure used for optimizing the neural networks weights. We begin by gathering up our data from Gotion self-charging test, which gave us cell voltage, temperature, and current data, and from which we calculated ground truth SOC.

    We inspected the data, shown in the lower left plot, to review the data operating range and to identify gaps in the test data. We then gathered the data into an input array and target array, shown second from the left. At that point, we used the Neural Network Fitting app provided with the Deep Learning Toolbox.

    We found the app to be helpful in guiding us through the training process. Our depiction of its working is shown in the center figure, including shuffling and splitting the data into training, validation and test sets, optimizing the weights based on the training data, and stopping when accuracy on the validation data set stopped improving.

    After running the optimization, we reviewed the accuracy metrics for the three data sets to understand the accuracy and generalization error that we should expect. Finally, we used the app to generate m-Code for the neural network. Overall, we found the workflow to be promising, and that high accuracy and low generalization error could be obtained with comparatively few engineering resources.

    Let's shift our attention now to the testing process. Using Simulink Test, we created model in the loop or MIL test to verify that the prototype design met the requirements. The left-hand screenshot shows the test manager file that we use to manage these tests. Here we focus on a unit test designed to verify that the neural network subsystem discussed earlier should predict SOC within 3% accuracy.

    We used the test case description field to provide a brief summary of how the requirement was verified, in this case by inputting a set of 101 randomly chosen test samples and verifying that the RMS estimation error was less than 3% at all times.

    We linked the test case to the corresponding requirement, and we used the test managers test assessment logic template to define natural language pass/fail criteria based on RMS error, shown in the lower middle figure. Finally, the system under test is shown in the top right, which is a Simulink test harness designed to exercise the neural network subsystem over the set of 100 test points and then calculate the RMS error.

    Here we will stay on the topic of MIL testing, but shift our attention to a qualification test designed to test the higher level requirement that the prototype should be able to estimate pack SOC to within 3% accuracy when the pack is being charged. For the purposes of this test, we ran null simulations based on Gotion cell charging test data.

    The plot at right shows a simulation using data from a cold temperature charging test of almost six hours in duration. Starting from the top right plot, we see cell current, in which the current is zero for the first five minutes and then begins charging the cell, decreasing stepwise from 18 amps, with negative sign indicating current flow in the charging direction.

    Going clockwise to the lower right plot, we see the cell surface temperature between 0 and 2 degrees C. The lower left shows cell voltage from 3.4 to 4.2 volts. The upper left plot shows the ground truth target SOC, shown in blue and the prototype SOC estimate, shown in solid red.

    In the simulation, the prototype associate was initialized with an incorrect value of 50%, where the target value was 10% at the start of the simulation. So we see that although initialized incorrectly, when charging begins at 5 minutes into the simulation, the prototype strategy corrects the SOC as required. In this test, the accuracy was 0.5% RMS SOC error when charging, which was well within the accuracy requirement.

    Let's shift focus now to another objective of the project, which was to assess the feasibility of running the prototype algorithm on our production BMS and gather design information for use in future projects. We began by measuring the neural network execution time.

    To do that, we created a test build of our BMS software and ran a sensitivity test on our hardware in the loop, or HIL test fixture, in which we measured the impact of neural network execution frequency on task execution time. We found that on average the calculation required 51 microseconds per call on our microcontroller.

    Next we measured the memory usage required by the neural network. To do that, we analyzed the memory maps of a baseline build and test build and compared their differences. We found that the neural network required less than two kilobytes of ROM and less than 100 bytes of RAM.

    Finally, we examined the numerical equivalence between numeric neural network calculations performed in our Windows-based MIL tests and tests run on the HIL with our production microcontroller. We found that the MIL and the production microcontroller results differed by a mean absolute error of 1.98e negative 4.

    Our conclusion from the three tests was that yes, the prototype used a manageable amount of resources and was, for our purposes, numerically equivalent to MIL test calculations. Finally, we arrived at the onboard vehicle tests, which were run at the final stage of our prototype project.

    Let's examine how the prototype worked. The plot shown it right showed data gathered from one of the vehicle charging tests, in this case an AC charge test run over the course of 6.5 hours. Going clockwise from the top right, we see the current, which was between 6 and 7 amps for most of the test.

    In the lower right, we see the conditions were cool, starting at 18 degrees C and ending at 11 degrees C. And in the lower left, we see the maximum cell voltage, which ranged from 3.55 to 4.2 volts. In the top left plot, we can see the ground truth or target SOC shown in blue, which was calculated offline during post-processing.

    Finally, we see the onboard prototype SOC estimate is shown in red in the top left plot. We can see that, although the accuracy was lower than for the qualification MIL test, the accuracy was still in spec, with an RMS error of 2% when charging.

    To summarize, we learned the following from our prototype project. First, the neural network memory usage was less than two kilobytes of ROM and 100 bytes of RAM. Second, it required approximately 50 microseconds per call. Third, Windows MIL tests in our production microcontroller agreed to within 2e negative 4 mean absolute error.

    Fourth, the workflow could sustainably be applied to design variants if the accuracy target of 3% while charging on the vehicle was met. Taken together, we concluded that the prototype SOC estimation algorithm could be considered as a feasible design strategy, and there was a good case to be made for detailed development.

    The following tools had a central role in enabling our project. Simulink Requirements, Deep Learning Toolbox, Simulink, Simulink Test, and Embedded Coder. We hope you'll agree that neural networks really are a powerful technology and that MathWorks products enable the engineering community to deploy the technology efficiently. We wish you the best in your own endeavors and look forward to your comments and feedback. Thank you.

    View more related videos