Application Specific Systems for Automotive Test: EV Battery Pack Validation


[APPLAUSE] OK, we just saw how FlexLogger
addresses manual workflows. Let’s take a look at an
application which requires a more automated workflow. And to do that, please
welcome to the stage Ty Prather and Lynn Sarcione. [APPLAUSE] Hi Ty, Hey, Lynn. I know that both
of you have been working with our
automotive customers on EV Powertrain applications. Can you tell us about why
those applications require more automated workflow? Sure. At a high level, the same
validation workflow steps apply to engineers
testing EV Powertrains. But as we dive in, different
device characteristics drive different test approaches. Yeah. Take the EV Traction
Inverter, for example. To find the optimal
control scheme, you need to emulate the battery
on one side and the motor on the other, while stepping
through a large number of test cases. This requires a high
degree of automation, and the control of measurement
steps of the workflow. In contrast, take a
look at the EV battery. Because the battery is the
most costly and potentially dangerous component
of the powertrain, it’s critical to
validate the performance with actual physical batteries
instead of simulations. To do this with adequate
test confidence and coverage, it requires setting up lots of
these test cells in parallel. Which requires a high
degree of automation in the systems management
and deployment steps of the workflow. So what you’re seeing
here is a focus on a specific application, with
a specific device under test, in a specific industry. And with this focus, it
gives us more possibilities for improving our workflows. Yeah. By being this specific, we
can partner with our customers to identify which
aspects of their workflow are most painful and
prime for optimization. And because we see test teams
building similar pieces over and over again, we can
begin to incorporate those into our standard
system offering, reducing the development
and maintenance costs to our customers. Here you can see three
application-specific systems we’re building, tailored
to the needs of customers in the automotive industry. For battery pack and
module validation, traction inverter validation,
and ECU production test. So we’re lucky enough
to have the battery tester here on stage. Let’s take a look. Sure. So over here we have our battery
cycler, our measurement rack, and then our battery
pack that would normally be inside of a thermal chamber. And there would be
dozens of these. Actually, we’ve been
in labs about the size of this room that’re
packed full of testers, all doing concurrent battery
pack and module validation. So the system’s
built specifically with the needs of EV
Powertrain engineers testing battery packs
and modules in mind. But it’s built on standard
platform products, like CompactRIO and LabVIEW. So it maintains the flexibility
and the customizability that you’re familiar
with from NI. We’re also building
new capabilities in more targeted products
to complete these systems. Including new measurements,
signal conditioning, and third-party
device integration. A good example of
this is the addition of power electronics
components at the right power levels for EV test applications,
like this battery cycler over here. In fact, we’ve just
recently invested in a new R&D center
in Belgium that’s chartered with developing a
line of high-performance power electronics capabilities just
for applications like these. So we’ve talked a
lot about hardware. Now let’s talk about software. Yeah. An application-specific
system wouldn’t be complete without software. So we’ve included the
battery test software here. It incorporates core components,
like third party hardware configuration, system
sequencing, and test monitoring, allowing engineers
to focus on the value add work unique
to their testing, and not on rebuilding
these base components. But true to NI, we’ve built
it to be open, flexible, and customizable. And while unfortunately I can’t
power up a 100-kilowatt cycler here on stage today,
I can walk you through the test and
system configuration steps of the workflow. Battery test labs are
tasked with maintaining a large number of hardware
configurations between battery cyclers, thermal chambers,
and measurement I/O. They also need to ensure that those
configurations match the specific version of the
DUT they’re wanting to test. So here you can see, on the
left, the different systems that we have connected. So we’ve got some
systems here in Austin, as well as systems in Shanghai. Then we’ve also got
some systems that are in Stuttgart right now. Actually, at Automotive
Testing Expo. Over on the right, we’ve
got a list of our tests. We can dive in and
see a wave farm profile of what
we’re actually going to run, as well as our
hardware configuration, and an overview of the
sequence that we’ll actually execute for the test. Since we can’t use the battery
cycler here on stage today, we have to swap it out
for a simulated one, using our configuration editor. This hardware
abstraction layer allows us to decouple the sequence
from the hardware itself, ensuring that we can quickly
and easily adapt to the changing requirements of the test
and capabilities of the lab. Once that’s done, we can go
ahead and select the firmware and run the test. While the test
executes, you can see we can get specific
information related to our DUT, including cell voltages,
impact voltage, and current. We also can see how long we’ve
progressed in the sequence, and whether or
not we’ve exceeded any of our safety limits. And while this is only a local
monitoring UI here today, we recognize these systems are
likely going to end up in labs with dozens, or even
hundreds, of these systems. , And in those scenarios, we
recommend pairing the software with our other tools, like
DIAdem and SystemLink, to add more advanced data
analysis and system management capabilities. Optimization of the hardware
and test configuration steps of the workflow
prevents test engineers from having to reinvent the
wheel over and over again. And that’s really
the goal behind these application-specific
systems, is to provide you with
higher-level starting points that reduce test
development times and enhance your
workflows, which leads to shorter design cycles
and faster time to market. That’s great. Thanks, Ty. Thanks, Lynn. Thanks. [APPLAUSE]