How to Perform a Fault Analysis of a BMS - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 12:39
Loaded: 1.31%
Stream Type LIVE
Remaining Time 12:39
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 12:40

    How to Perform a Fault Analysis of a BMS

    Fault analysis of battery management systems (BMS) is required in safety standards such as SAE® J2929 to prevent single-point faults from resulting in fires, explosions, or high-voltage hazards.

    Learn how to conduct a systematic fault analysis using Simulink Fault Analyzer for a BMS modeled using Simscape Battery™, Stateflow®, and Simulink®.

    Published: 22 Apr 2024

    I'll be playing the role of a systems engineer because I want to know if the overall system is robust against faults. Now, this is very important for safety critical systems. And it's actually called out in certain standards such as SAE J2929, which requires a completed and documented fault analysis, which shows that plausible single point faults will not result in fires, explosions, ruptures, or high voltage hazards. As an electric vehicle owner, this is very important to me that we don't want to have anything happen, for instance, with our road vehicles with a lot of batteries in them.

    So what I'll do today is I'm going to just sort of jump in and show how you can use simulation and MATLAB and Simulink to start to ensure that your system is robust against these fault conditions. So with that being said, I'm going to jump into MATLAB.

    So here we have a closed-loop model, which includes a battery plant, which has an EV battery pack with two module assemblies and within each module assembly has four modules. And in addition to that, we have a battery management system control. And here we have a few key components that I want to talk about.

    The first is if there is a fault, we need to be able to detect it, and that can be-- that's shown here in this fault monitoring subsystem. Now there's three different categories of faults, which are detected here, battery current monitoring, battery voltage, and battery temperature monitoring, with a helpful little output of fault present, which is just going to indicate to the rest of the controls that a fault has been detected.

    Now if a fault is detected, the supervisory control will mitigate that fault by changing the state of the system or the commanded state of the system. And this is modeled using a state flow state chart here in this supervisory logic state chart. And, basically, this is going to determine when the system should be either in idle, driving, or charging. And if a fault is present, it enters this fault state. It transitions to the fault state.

    And so, again, the goal with my analysis is going to be if a fault is injected, a single-point fault is injected in the system or is detected in the system, is it properly detected and properly mitigated? Is it going to actually, for instance, stop the charging if a fault is detected during charging? So this system is actually a test harness. And one of the important things I also wanted to talk about was this test sequence block which is going to drive the system. It's going to determine the inputs for this requested state of the system.

    The test sequence block is a feature in Simulink test, which allows you to author test cases based on steps. So this is a fairly simple one. It's just basically going to simulate a driving scenario. And it's going to drive the system through standby, driving states, and charging states. I also included this little convenience is charging, which is a simple Boolean, which we'll show later with one of the faults we can trigger.

    And this is going to kind of walk through this using simulation time. You don't have to use simulation time. It's just for demonstration purposes, it's a little easier. So for about the first minute, we're going to be in the standby state. And then we're going to go into driving for a little while. And then we're going to start charging. And now we can inject faults at any point in time during the simulation. But we're going to be sort of driving this through these three steps.

    Now, it's very important if you have a system like this where you're in multiple domains that you understand where the different faults are in the system. Now, I could dive into the battery plant system. And I think there's something maybe in module assembly 2, maybe module 4. But I'm not sure.

    But, hey, right down here at the bottom, we have the fault table, which is a feature in both Simscape, Simscape Electrical, Simscape Battery, and our new Simulink Fault Analyzer product, which allows you to know where and how faults can be injected in a model. And, basically, for demonstration purposes, I just have a few faults modeled in this model here. I can actually see where they are in the system.

    For instance, I have two faults associated with module assembly 2 in module 4, in module assembly 2. And these are both additional resistance faults. One is going to be injected early on in the simulation in the standby phase. And one is going to be injected sometime during the charging phase of the simulation,

    I also have another fault here, which is on a Simulink signal, which is-- just show you where that is. I can also inject faults on the sensor values, for instance, the battery voltage sensor. Let's say I want to have it set to ground, for instance, at some point during simulation. I can actually show you what that looks like.

    This is a separate model. And for more information, please feel free to consult the Simulink Fault Analyzer documentation. But this is what we call a fault model. It's a separate model kept outside the model under test or the model being simulated. And during simulation, when the fault is active and has been triggered, it'll inject a value back to the signal's value. It'll override the signal's value.

    In this case, it'll inject a ground fault here. And I have this configured to be triggered as soon as the system has gone into charging. This is called a conditionally triggered fault.

    Again, feel free to consult our documentation for more information. But the way to think about this is instead of just a time-based fault or a fault that's injected at the beginning of simulation, I can inject this based on a system condition of interest, in this case, when the system has just gone into charging.

    So this is great. But how do I know if a fault once I've injected it has been properly detected and mitigated? Remember, that's my goal here. So I can do that by-- if I wanted to just, for instance, see one fault at a time, I can use the Simulation Data Inspector. And in this case, I've already run the simulation.

    And I know that as soon as the system goes into charging, measured by this BMS state signal, it's gone from idle to driving. And as soon as it-- you can see that little line down there. As soon as it goes into charging, the fault is triggered. I can see the fault is triggered up here. Faults are automatically logged during simulation. And I know it's been detected here.

    So I know it's been triggered. It's been detected and properly mitigated. That's great. But how do I make this systematic? How do I do this systematically and make it repeatable?

    And don't forget, I have to document this if I want to be compliant with standards such as SAE J2929. So let's get organized. And we can do that using the Safety Analysis Manager, which is a feature in our Simulink Fault Analyzer product.

    Now just real quick I'm going to explain what this feature does and why you should consider using it for fault analysis. Now, the feature is designed to support and automate and improve analyzes, specifically tabular analyzes such as fault analysis as well as safety analyzes such as Failure Mode and Effects Analysis or FMEA. But for today, I'm just going to start a fault analysis. And this is just a simple start to kind of get you started here.

    And what it's doing here is I can actually document the location of the fault, for instance, assembly 2, module 4. I can say what type of fault it is, what's the behavior of this fault. For instance, I can do additional resistance or stuck at ground. I can document when it's injected, standby or during charging. And this is just what we call a derived column, which is just concatenating these four columns here to have sort of a unique instance of a fault.

    The other thing I can do is I can link from a cell to anything in the MATLAB ecosystem. This uses our traceability technology from our Requirements Toolbox product. I can link, for instance, the test cases, items in Simulink, requirements within Simulink and Requirements Toolbox, as well as in third-party tools such as IBM Rational DOORS or DOORS Next Generation.

    And then what you can do with that is you can see where this is actually going. For instance, I know this fault here has been linked from that cell. I can monitor-- I can also link to my detection, my detection logic here. So I know this fault should be detected by that, the battery current monitoring subsystem. And the mitigation logic is just the supervisory control system.

    Again, you're leveraging traceability. And you can automate these workflows using the power of MATLAB and validate the assumptions you're making here using simulation. And what I'll show you here is just how you can automate that through callbacks. So every spreadsheet, which can be authored, and edited, and analyzed in the Safety Analysis Manager has a set of callbacks. And the most important one that I always like to talk about is Analyze Spreadsheet.

    So what happens when I click that button is the Analyze function callback runs. And in this case, I have it running a live script from MATLAB, a MATLAB live script, called validateBMSfaultAnalysis. And I'm just going to run this real quick and then tell you what it's doing while it's running.

    So what it's doing is for every row, it's determining whether the fault for that row has been properly detected and mitigated. In this case, I can annotate the table and say, yeah, this is actually correct in that each fault was detected during simulation. And it was properly mitigated. And I also updated the status of this validated cell. It's just a simple checkbox.

    And I can actually export this to Excel for my documentation. So I've automated steps. I've leveraged traceability data. And I've been able to export it. And what actually happened is-- I can show you real quick what that script looks like. This is just a bunch of MATLAB code uses that leverages our APIs, our functions in Simulink Fault Analyzer. And it's loaded-- I already ran the simulation.

    So it loads those simulation results. And it's actually going to just quickly go through for each cell and determine whether it was detected and mitigated. And then if that's the case, if it's both detected and mitigated, it updates the value of that validated cell for reporting purposes.

    So just to summarize here, with Simscape, Simscape Battery, and Simscape Electrical, and Simulink Fault Analyzer, you can manage faults across multiple domains and then automate this and make it repeatable and systematic using the Safety Analysis Manager. So now I'm comfortable that things are working well and I can continue working on my fault analysis to try and be compliant with SAE J2929.

    In addition to that, within Simulink Fault Analyzer, there's other capabilities I just wanted to highlight. So I mentioned this new product, which is my product, Simulink Fault Analyzer. We focus the product in four different areas. And this is areas that you should be able to explore when conducting fault analysis.

    The first is the ability to model faults without modifying the design. This is especially important with cases where you want to do scalable fault injection and really stress test your system, both in Simulink as well as other domains such as Simscape, starting with Simscape Electrical and Simscape Battery, and more to come in coming releases, as well as our System Composer product for architectural analysis. As I showed, you can also use the Simulation Data Inspector to simulate and explore faults and analyze their effects and, finally, be able to perform systematic safety and faults, as you learned today, analysis using simulation.