How to Accelerate EV Software Release Cycles with AVL E-Motor Emulation Testbeds - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 21:00
Loaded: 0.78%
Stream Type LIVE
Remaining Time 21:00
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 21:00

    How to Accelerate EV Software Release Cycles with AVL E-Motor Emulation Testbeds

    Martin Schmidt, Principal System Line Manager, Copper Car, AVL Deutschland
    Carlos Villegas, Electrification Industry Manager, Speedgoat

    The powertrain industry has traditionally relied on dynamometer testing for robust software releases. With the adoption of electric vehicles, it is essential to have short software release cycles including electrical safety and interoperability. While testing powertrains using internal combustion engines requires a rotating dynamometer, it is possible to test inverters for EV powertrains and the onboard charger at full power by using only electrical emulation of the electric motor and the battery. Such an approach allows all operating conditions to be tested, including driving scenarios, charging, electric faults, and even the interactions with other control units. Due to the need for high testing efficiency, frequent software updates can be carried out in a very short amount of time. The motor inverter testbed from AVL SET replaces the need for electric motors, dynamometers, and battery packs by using power electronics to emulate the electrical behavior of electric motors and battery packs with exceptional fidelity. As powertrain engineers typically use Model-Based Design to develop control designs and generate certified software code from Simulink®, AVL SET has also developed an interface to Speedgoat test systems to provide a seamless real-time interface to MATLAB® and Simulink. The model interface has a very low latency, which is crucial to emulate electrical systems as any delay would significantly disturb the model fidelity. As a result, engineers can use battery pack models from Simscape Battery™ or vehicle models from Powertrain Blockset™ when testing their motor inverter and controllers. In this session, you will learn about the E-Motor Emulator testbed and how to test an automotive inverter at full power for typical operation and fault conditions. We will later combine with Speedgoat test systems to emulate a battery pack using models from Simscape Battery when testing software in a fully powered inverter.

    Published: 3 Jun 2024

    Just to give you an idea, why do we talk about software testing in electric vehicles? Just imagine, you just updated your EV software and you cannot fast charge anymore. And we just learned how complicated fast charging is.

    Your vehicle needs to be towed or you suddenly lose power while driving. This is something you definitely do not want. And Carlos and me are going to show you what you can do to actually avoid these hazards.

    The agenda is I start with some ideas with power testing using e-motor emulators actually means. Then, I will go through the possibilities to accelerate inverter software, release cycles by using inverter test systems. Then, Carlos will take over and talk about the Simulink integration with Speedgoat Test Systems.

    And not to do only power plant engineering, we have some real measurements we did last week just in time for the conference, so brand new results. I work for AVL. AVL is a privately owned company located in Graz, Austria.

    We have something like 11,000 people working for us. It exists 75 years. And what's quite impressive, we have the second CEO, still the son of the founder, who owns the company. Some words about powertrain testing.

    Powertrains are in cars since cars exist. So what's new if I do test electric powertrains? Many people think, well, it's not so different. But shortly, I try to explain why there are significant differences.

    Testing traditional internal combustion engine powertrains-- as the people have long experienced what to do, they have validated design validation plans. They really how to test durability. They know which part of the software they need to test.

    And here are some examples of test beds, how they actually look like. They are quite huge. They need a lot of power, and a lot of energy is transferred in these test beds. And all these tests, as you might see, require test beds with rotating parts.

    Why is it like this? If you look at an internal combustion engine powertrain, you'll see there is fuel coming from the tank. And then we have the internal combustion engine, which changes the power flow from chemical to mechanical rotating energy. So the most important part in the conventional powertrain is rotating.

    Now let's have a look at an electrical drivetrain. Here it's a bit different. We have the battery, which stores electrical energy. We have the inverter, and we have a purely electrical power flow from the battery through the inverter, then to the e-motor.

    And only after the e-motor, we have a rotating part. But we have a big part, which is purely electrical. So having a short look from a software perspective, the e-motor is just dump. It just transforms current to torque and there is no intelligence in there.

    All the intelligence is in the inverter, which is a mini computer, which converts the DC from the battery to the multiphase AC. And we usually say the inverter is the heart, which is the power electronics to pump the energy and the brain, which is the software to actually control this thing. When the first electric cars had their renaissance 20 years ago, everybody was clear-- if I want to test an inverter, I have to test it in combination with the e-motor.

    So they were so used to actually say, if I have power flow, I need to have rotational power flow that they say, OK, my way is I go from model in the loop, to signal in the loop, to signal hardware in the loop because people like test beds, and then jump directly to e-motor test bed. But we at are convinced that there are different ways of doing it. Because as mentioned before, the big difference in an electric vehicle, we have this pure electrical power stage, and now we have the possibility that we say we go from model in the loop, to signal in the loop, to signal hardware in the loop and virtualization is key to be effective.

    But now we can go to a real test bed with real power where we don't need an e-motor. We can test that full power and voltage and really can perform lots of tests much faster. How would such a system look like? In the middle, you see the unit under test the inverter. And like in the car, it needs a DC source.

    Having a battery emulation at test beds is standard since many years because most people don't like real batteries on test cells. They are dangerous. It takes a long time to charge and discharge them. So if you want to do software tests, it's clear you use a battery emulator because then you just say state of charge is 80%, and one mouse click, and it's there.

    What's not so common until now, it's also possible to emulate the electrical behavior of an e-motor. And the good thing is you only have to emulate physics. There's a lot of electromagnetic stuff in there and everything, but nevertheless, it's pure physics. And so several years ago, there was a development that we can actually really emulate the complete behavior, the electromagnetic as well as the mechanical part of an e-motor, in a so-called e-motor emulator, some very fast power electronics, which is fast enough to cheat the inverter also on the AC side.

    To give you an idea how such a system look like, and I'm sure my marketing will murder me for that because it's no high, let's say, resolution video, but this is the real test bed we used for the tests you see. And since usually we are not allowed to use custom inverters, we have a prototype inverter here.

    Here, you see the AC part, the three phases going to the AC part of the inverter, and the DC connection of the inverter. So as a short summary, what we have here-- we are able to operate the inverter with real power on a test bed on pure electrical level. So how does it help to actually accelerate inverter software testing, and why is it necessary?

    Software is something very special. You change a minor part of the software and the behavior might change completely. And therefore software people are used to use so-called regression tests.

    They do much more tests after every single change than mechanical engineers are used to. Here is one example where a customer actually shared which kind of tests he has to perform after every significant software change. He says, I have to retest, diagnose, and network an interface to our in-house developed functions, the system limitations, sensors and actuators, level one and level two safety function, and some other interface function.

    And it's quite rare that people share this information, but they say for each project, we have 1,000 tests, which we need to perform each time we want to release a new software. And if you just imagine what this means, the tests have to be very short. I cannot afford to wait for a battery to charge.

    I cannot wait for an e-motor to actually reach the temperature I want. It has to be all in simulation or emulation. And why is it important to have really e-motor emulators? Because some of these tests show a more realistic behavior if you have the real power flow.

    And now we go through the tests again. And in green, you actually see the percentage of test where our customer says these are tests I have to perform with real power on the power hill or emoto emulator testbed. He says, I do not dare to release any software if I have not seen the level one and level two safety functions with real power since all the sensors of the inverter are involved in the topic.

    So when it comes to powertrain testing, especially software testing, and you might have more than one inverter in the powertrain so you have much more software to test, you have simulation, emulation, mechanical risks in the road, and of course, the fidelity increases from left to right. But from right to left, the testing speed increases, and therefore, we think that having an emulator of an emulator is the most effective environment to do real software testing under real conditions. Now Carlos, it's you.

    Thank you. Thank you, Martin. So now I'll present how you can use Simulink to develop your motor drive and also how you can connect Simulink to the test. So just a few words about Speedgoat. Speedgoat is a MathWorks associated company founded by former MathWorks employees.

    So we basically provide real time test systems that are meant to work with Simulink. We developed this together, MathWorks and Speedgoat. Basically, we provide a unified testing solution to develop the testing controls and also, in this case, motor drives.

    For example, let's say you're trying to design a motor drive. You have a real motor, a real drive, and a real controller for this drive. You can use Speedgoat and Simulink all the way through the development process. You'll be reusing Simulink models and also the Speedgoat test system.

    For example, the models that you use in desktop simulation, later you can use for testing your controllers with control design prototyping, also later on with signal level, hill testing as well. You'll be reusing the models you use for designing this controller. And finally, you can also use it for motor drive testing.

    For example, you normally start with desktop simulation. There everything is in simulation. Everything is virtual. There's no real plant.

    You have the controller, the drive, and the motor drive. In this case, we have a permanent magnet synchronous machine. Once you're happy with your controller, you can automatically generate code to a Speedgoat test system. This would be this silver element. You'll be running your Simulink controls in there and you'll be connecting to the actual hardware in case you have a prototyping hardware to start testing.

    In this case, we have a motor and a drive. Please remember, this blue box is a three phase inverter. We'll be testing it also afterwards. Now it's connected to an electric motor.

    With the Speedgoat test system, basically, you can, for example, run your Simulink models, but you can also have the interfaces to the actual hardware. In this case, we have an interface with analog signals. We also have encoder measurements and several protocol communication.

    In this specific case, we are just using CAN communication. In addition to that, we can always add fault insertion, for example. But once you're happy with the control that you're doing with the, let's say, with your prototype hardware, you can use the same Simulink model and transfer it to an embedded platform.

    In this case, we just have, for this example, a Texas Instrument microcontroller. This is our embedded platform in this case. And you can also, if you're interested, you can see this at our booth downstairs. Feel free to go afterwards.

    We have exactly this hardware setup for signal level hill testing. And in this case, you can test, thoroughly, this unit under test together with the protocol communications, the signal level interfaces, like capture sensor emulation. And also you can model high fidelity models, like with FPGAs.

    And the advantage of all of these is that you can also reuse the models that you were using for desktop simulation. Also, you can integrate fault insertion mechanisms for all of the signals. So that was testing, using the analogy from Martin, would be testing the brain. But if you want to test both the brain and the heart, in this case, the real plant would be your drive and your controller.

    You would need a power interface to connect it. In this case, the only the part we are simulating is the motor, and we're providing the power interface via power amplifiers. This is a sort of toy example below one kilowatt.

    So here inside we have this blue box I was mentioning you before, we were testing with a tiny electric motor. And now instead of this tiny electric motor, we're testing this same motor drive using a motor emulation. We're using power amplifiers.

    And in this case, we were able to thoroughly test these motor drive. And you can just with a click of a button, change your motor drive, your motor model from a PMSM to an induction machine, for example. And in this case, we're using motor Control Blockset models in the FPGA.

    But this is just a toy example, but for an electric vehicle, that's where we can use AVL test bench to connect electric motors at hundreds of kilowatts. And this is done by using a standard interface. We're using Aurora with SFP because AVL testbed uses this standard protocol.

    And jointly, we have developed this proven interface from Simulink to the AVL testbed that will enable you to bring your plant models from Simulink and Simscape to an AVL test bed. The interface has the advantages that it uses fiber optics, so it's not affected by electromagnetic interference, and it has a very high data throughput, so you can get many sensor data, for example.

    The test bench also consists of your motor run drive. And you'll be connecting to it, also, your development computer. That's where you will be having your Simulink models, for example, for your battery plant and the system level plant models that you'll later deploy to the Speedgoat test system in this way. And now your development computer can be your test automation system where you can use Simulink test to thoroughly test this inverter software to achieve full coverage.

    So this has great potential because it provides access to the Simulink and Matlab products. You can use Simulink test automation. The example, in this case, we'll be using Powertrain Blockset. We started from this EV reference application example.

    And we also using Simscape battery. We modify this reference application with-- we basically replace the battery with a battery pack using the single particle battery model that Lorenzo just mentioned. So specifically, this is a single particle model with electrolyte. And it has the advantage that was already mentioned that it captures quite well the effects of fast charging and discharging.

    In this case, we'll be we'll be discharging. And this is our test rig. So basically, we have the Speedgoat test system, which is connected to your development computer. Here you see the example model with some results in Simulink after the test, our unit under test. There, we have the motor drive and the controller. It's a protected environment.

    And then, we have the power amplifiers or from the AVL motor test bed in the back. So this unit under test, which is the inverter control and the 300 kilowatt motor inverter, it's expecting to be connected to a motor, to an electric motor and a battery. And it's also expecting to be connected to a powertrain control unit that is providing the torque references.

    And this power control unit is also will be expecting some sensors, like the motor core and some voltages. For this test, what we have done is replace these elements with the AVL e-motor testbed and the Speedgoat test system. We have the electromagnetic motor model running in from AVL in the AVL test rig.

    And the battery model, the vehicle model and also the powertrain controls are running in the Speedgoat. And we interface using a fiber optic Aurora interface. Oh yes, just a note here, we could have used also vehicle automotive ethernet or can, but in this case, for simplicity, we're using also Aurora.

    This is our model just. It's using Powertrain Blockset for our city driving cycle. And also, inside this passenger car block, we have the single particle model from Simscape battery, which will be everything will be running in real time. And we replace, in this case, the inverter and the motor with the interface to the test bed as we have a real motor drive and the real controller.

    OK, so let's start. So normally, you start your desktop simulation here, but this is not a desktop simulation. We are actually going to be testing with real motor drive at several tens of kilowatts, in this case. So instead of running the modeling simulation, you go to the real time tab and you click on run.

    So you stay in Simulink, but now you're running in real time and you're deploying to the test bed. All of these models will be updating every microsecond. We have accelerated the video of the simulation, the video, by 100 times because the city driving cycle takes 40 minutes.

    And we can see, for example, in the middle, we have the currents. We go up to 100 amps, and this is real current that is flowing through the system, through the motor drive. And on the right, for example, we have the layers of the single particle model. We notice how the anode is losing charge towards the cathode.

    And you see several plots because each of them represents a layer of this sphere that Lorenzo previously showed. And you can also easily connect Simulink dashboard plots. This is what we have done here.

    For example, here we're visualizing voltages and currents from the test. And you could also do the same for the battery model. You could see the state of charge or we could have also tested, shown here, the concentration of charge of different layers of the spheres of the different cathodes.

    So that's the end of the presentation. So our key takeaways are that you can use the testbed to accelerate testing of your inverter software and therefore, accelerate release cycles. And you can use Speedgoat test systems and Simulink to develop electric vehicle software from desktop simulation, to power hill testing or e-motor test beds, and that you can connect Matlab and Simulink to test rigs using Speedgoat test systems. Thank you.

    [APPLAUSE]

    View more related videos