ni automotive solutions

5/8/2018 Ni Automotive Solutions - slidepdf.com

http://slidepdf.com/reader/full/ni-automotive-solutions 1/18

NI Automotive Solutions

Case Study Selection



National Instruments Automotive Platform

Electronic Control Units Design and Prototyping

Test Cell Measurement and Control

Hardware-in-the-Loop Testing

Production Tests

TABLE OF CONTENTS

One Automotive Engineering Platform from Concept to Crash Test ...............

NI Tools Keep Ford at the Forefront of Innovation .........................................

Testing Car Headlamps with LabVIEW from Elcom .......................................

Building an Engine Knock Analyzer with LabVIEW .........................................

DIAdem Software Accelerates Crash test Analysis .......................................

Bloomy Controls Performs Functional Testing of Battery Management

Systems for Hybrid Electric Vehicles ............................................................

Development of an Electronic Stability Program (ESP) Hardware-in-the-Loop (HIL)

Simulation based on NI PXI and CompactRIO ...............................................

3

4

6

8

10

12

15



3

One Automotive Engineering Platform from

Concept to Crash Test

Automotive engineers face critical development and test challenges as the number of electronic components

continues to increase. High end cars are made of more than 3000 parts that perform highly specified functions

and contain up to 80 different electronic units to control sophisticated active subsystems. These not only include

engine and steering components in brake systems for traction and stability control, but also numerous infotain-

ment devices such as infrared cameras, radios and GPS receivers. Using traditional, fixed-functionality tools for

design and test becomes more and more difficult as scientists and engineers continue to look for open and flex-

ible solutions.

National Instruments provides advanced control and test platforms to rapidly design, prototype and deploy new

technologies. These have been used in many applications to develop and improve automotive components and

their production processes, resulting in a significant decrease of time-to-market.

The core of the NI automotive engineering platform is NI LabVIEW graphical system design environment, a high-

performance graphical language that is easy to code, maintain, and adapt to new applications from small data

acquisition applications to complex hardware-in-the-loop simulation systems and production test systems. Witha common language between applications, you spend less time learning development tools and more time solving

problems, save money and time on training, shorten time to market, and ensure long-term maintenance.

In connection with our 2010 Automotive Symposium we have compiled a set of case studies to show how NI tools

are being used by NI customers in nearly every corner of the automotive industry.

Browse ni.com/automotive for more case studies.



4

NI Tools Keep Ford at the Forefront of Innovation

Author(s):

Kurt D. Osborne - Ford Motor Company

Industry:Automotive, Research

Products:

Execution Trace Toolkit, SCXI-1124, LabVIEW, DIAdem,

cRIO-9022, FPGA Module, Real-Time Module, PXI-8186

RT, cRIO-9012, Control Design and Simulation Module,

SCXI-1160, PXI-8464/1, SCXI-1162HV, PXI-1010

The Challenge:

Developing an electronic control unit (ECU) for an au-

tomotive fuel cell system capable of demonstrating sig-

nificant progress toward achieving a commercially viable

fuel cell system design that is competitive with conven-

tional internal combustion-based power trains.

The Solution:

Designing and implementing a real-time embedded con-

trol system for an automotive fuel cell system using the

NI LabVIEW Real-Time and LabVIEW FPGA modules and

an NI CompactRIO controller, and verifying the system

with LabVIEW and a real-time PXI chassis hardware-in-

the-loop (HIL) system.

“Ford has a long history with NI, and we have used LabVIEW to develop various aspects of every fuel cell elec-

tric vehicle that we produce and to successfully design and implement a real-time embedded control system

for an automotive FCS.”

At the Forefront of Innovation

Since 1992, Ford Motor Company has been dedicated to fuel cell system (FCS)

R&D. Despite our significant progress, several deficiencies have prevented FCSs

from becoming a commercially viable technology that is competitive with con-

ventional internal combustion-based power trains. Our attempt to eliminate

these deficiencies began by demonstrating significant improvements in areas

such as system lifetime and freeze starting.

In conjunction with our groundbreaking FCS design, we developed a new control

system using rapid prototyping. Changes occurred during development while thedesign team iteratively refined the design through verification following the sys-

tems engineering V-model. These design changes often affected the interfaces

between subsystem components such as the air compressor control module and

the fuel cell control module. Even though ECUs have been widely successful for

production vehicles, better choices for rapid prototyping control systems exist.

Instead of modifying production ECU I/O circuits to adapt to interface changes,

we used CompactRIO to rapidly prototype our fuel control unit (FCU). With

CompactRIO, we quickly adapted to the design changes and experimented with

new sensors and actuators for novel design solutions.

We implemented an HIL system comprised of an NI PXI-8186 controller in an

NI PXI-1010 combination PXI/SCXI chassis with associated PXI and SCXI I/O

cards, including a controller area network (CAN), to verify the control strategyfunctionality embedded in the CompactRIO controller. This HIL system, imple-

mented with LabVIEW Real-Time, has a graphical user interface (GUI) that pro-

Contact Ford Motor Company (author) in email: [email protected] the website: www.ford.com

O u r commi t ment t o f u el cel l sy st em ( F C S ) r esear ch r esu l t ed i n v ehi cl es su ch as t he w or l d ’ s f i r st f u l l si z e , f u l l - per f or mance f u el cel l car ( P 2 0 0 0 ) and t he w or l d ’ s f i r st f u el cel l pl u g -i n hy br i d ( F or d E d g e w i t h H y S er i es Dr i v e ).

O u r comm

Ford Motor Company



5

vides manual and automatic input stimuli to the ECU to validate the control strategy operation while displaying

the CompactRIO I/O feedback on the HIL monitor. The HIL system validation was very successful, and we only

had to make minor changes to the strategy after the CompactRIO began controlling the actual FCS plant.

Performance When You Need It

Automotive power train control demands real-time performance. To provide the determinism required for real-

time performance, the LabVIEW Real-Time Module delivers a commercial real-time operating system (RTOS) for

the selected controller. When we switched from using an NI cRIO-9002 to an NI cRIO-9012 embedded real-timecontroller to boost performance, LabVIEW Real-Time automatically switched from a Pharlap RTOS to a VxWorks

RTOS. With NI products working to support the RTOS implementation, our team focused on delivering a fuel cell

control system instead of RTOS details.

The FCS controller receives various inputs from sensors, actuators, and other controllers and systems within

a vehicle. A CAN, now ubiquitous in automotive designs, transmits and receives a significant majority of the

I/O within and outside the FCS. During laboratory testing, we simulated master vehicle control by an extensive

test stand based on LabVIEW, which communicated via CAN to the slave FCS controller. For these reasons,

CompactRIO CAN support is critical for automotive FCS applications. When we needed more performance for

our CAN implementation, NI quickly provided a recently developed method for supporting CAN on the faster,

VxWorks-based platforms, such as the cRIO-9012. In addition to enabling the use of the CAN channel API, the

new CAN frame channel conversion library was even faster than before, thus reducing our development time.

NI products have always been well-known for supporting an open system architecture. NI Measurement & AutomationExplorer (MAX) easily imported CAN message databases developed in a tool by another CAN manufacturer. This

feature allowed us to exchange databases without translating or recoding CAN message databases.

Seamless Technology Integration

For this project, we implemented the control strategy with the LabVIEW Professional Development System

in conjunction with two add-on modules. First, we used the LabVIEW Real-Time Module to implement the

software in real time to program the real-time controller. Next, we implemented the FPGA-based software using

the LabVIEW FPGA Module to conduct all of the I/O including CAN. Both of these add-on LabVIEW modules

seamlessly integrated into the LabVIEW development environment, and graphical differencing was one of the

essential LabVIEW features that we used.

In addition, the NI Real-Time Execution Trace Toolkit quickly became an important tool to help solve chronometric issues.Using this toolkit, we found areas of the real-time embedded code that were not performing as expected, and then opti-

mized the code to ensure correct real-time performance. Without a product like theNI Real-Time Execution Trace Toolkit,

we would have needed expensive external test equipment such as in-circuit emulators and logic analyzers.

While some developers have a difficult experience when implementing version control, due to the excellent inte-

gration of LabVIEW with Microsoft Visual SourceSafe version control program, which we used during software

development, we successfully and seamlessly integrated version control. With a simple right-click on the source

VI icon in the LabVIEW project window, we can display a list of functions such as file check-in or check-out.

Easy-to-use software is critical to gain developer support for version management software.

LabVIEW Everywhere – Our Motivation for Using LabVIEW

We developed the control strategy for our first internally designed FCS using LabVIEW for several additional rea-sons. First, the number of developers required to implement our standard software development process exceeded

the available resources. However, by using LabVIEW, we had a larger pool of resources because several engineers

already had experience with LabVIEW and others had been trained. Second, with the natural synergy between the

software developed for the rapid prototyping controller and the test stands, which were already developed using

LabVIEW, VIs could be shared, the development environments were the same, and the hardware was similar.

Third, because modular LabVIEW VIs were backward compatible, we reused VIs that were developed more than

10 years ago as a basis for our HIL system. In addition, our laboratory test system, based on NI hardware and

LabVIEW, easily stored test data in the technical data management streaming (TDMS) file format for analysis in

NI DIAdem data management software. Along with normal data visualization, we used DIAdem to rapidly and

automatically search through multiple data files to find any performance anomalies and graph them with annota-

tions. Finally, NI technical support – a key criterion for success – has always been the best in the industry.

Ford has a long history with NI, and we have used LabVIEW to develop various aspects of every fuel cell electricvehicle that we produce and to successfully design and implement a real-time embedded control system for an

automotive FCS.

Contact Ford Motor Company (author) in email: [email protected] the website: www.ford.com



6

Testing Car Headlamps with LabVIEW

Author(s):

Michal Harhaj - ELCOM, a.s.

Industry:Automotive

Products:

Image Acquisition and Machine Vision

Bundle for NI Developer Suite, LabVIEW

The Challenge:

Building a stand-alone production test

machine for automatic adjustment of

car headlamps to achieve accurate color

rendition on the upper edge of the light

cone.

The Solution:Using NI LabVIEW and NI-IMAQ vision

to create fully automated image analy-

sis software that provides adjustment

data for programmable logic controller

(PLC)-driven adjustment hardware.

“The software application developed with LabVIEW and NI-IMAQ vision performs the mathematical evaluation

of the picture projected on the focusing screen.”

We developed a fully automated machine with all of the necessary mechanics and electronics for adjusting ED

modules in car headlamps to analyze the projection of a car headlamp and to adjust it according to the results.

We can test and adjust several types of headlamps. We built the machine from ITEM profiles and cast aluminum

parts and its mechanical concept is open for future headlamp tests. We controlled the mechanical and electrical

functions using a Siemens Simatic PLC. The PLC communicates with the machine’s PC through PROFIBUS MPI.

The PC serves as an operator console and runs the vision system while the machine uses two cameras (color and

black/white) for edge image acquisition.

To keep the machine size in reasonable limits, the focusing distance of the light cone from the headlamp is short-

ened by a large achromatic objective to approximately 6 ft and reflected upward by a diagonal mirror.

We manually placed the headlamps in replaceable fixtures positioned on a rotary table. The fixtures can be re-

placed in a few minutes as the production changes. In the first position on the rotary table, we switch the lamp

on and it keeps burning until the light becomes stable (the light color changes as the light starts burning). In the

adjustment position, two stepper-motor-powered screwdrivers move toward the headlamp until they meet thetuning screws. According to the information from the vision system, the screw drivers rotate the screws to adjust

the colors and then the screws are released. In the last position on the rotary table the headlamp is signed in case

it was successfully adjusted, which takes about 40 seconds.

We developed the testing software application that runs on the tester PC with LabVIEW and NI-IMAQ vision to

perform the mathematical evaluation of the picture projected on the focusing screen. The PC software performs

machine parameterization, image acquisition, and analysis and provides the operator interface. Based on this

evaluation, the application controls the stepper motors to adjust the diaphragm of the headlamp to meet the

standards.

Image Analysis

The headlamp light cone edge color evaluation is based on analysis of the edge area image shown on a projectingscreen. The image is in red, green, blue (RGB) representation but we converted it to hue, saturation, luminance (HSL)

representation for analysis purposes because it provides one value for color and one value for brightness per pixel.

Contact Elcom (author) in email: [email protected] the website: www.elcom.cz

T he t est i n g machi ne.



7Contact Elcom (author) in email: [email protected] the website: www.elcom.cz

The two most critical parameters for edge classification are edge color and edge sharpness (gradient). The edge

color is calculated as an averaged value of the hue component of the image in the area near to the edge. Because

hue is expressed as a number in the range from zero to 255, with zero being red and 255 being almost the same

shade of red, the machine uses polar coordinates to represent the color. This allows a continuous color scale for

the hue between 255 and zero. The color difference between the actual and required color is given as an angle

between the two colors on the color circle circumference.

The edge sharpness is an average steepness (derivation) of the luminance across vertical lines rectangular to the

border.

All images used in further analysis are stacked (multiple images averaged into one image) to suppress brightness

noise in the dark field of the black/white camera and to suppress color and sharpness noise in the area near the

edge with low color saturation in images taken by the color camera.

Testing and Adjusting

The test machine operates in two modes. In the “test only” mode, the machine verifies if the inserted headlamp’s

edge color and sharpness are within configurable limits. In the “adjust” mode, the machine will adjust the edge

characteristics by adjusting screws on the headlamp. Internally, the stepper motors driving the screwdrivers get

a command to move a number of steps ahead proportional to the color and sharpness difference between the

actual and desired state. The adjusting algorithm is iterative, using multiple small steps because it does not use

one step adjustment, due to the fact that there is no linear relation between the color differences and tightening

angle. Because the adjusting screws on the headlamp are tapping screws, it is only possible to turn the screwsin one direction and thus the adjusting algorithm must not allow any overshoot.

After the edge test, the machine performs brightness tests in a dark field so that the machine uses a black/white

camera with high gain set. This produces an oversaturated image in the bright field, but yields sufficient sensitivity

and resolution in the dark field.

Conclusion

Using LabVIEW and NI-IMAQ vision, we successfully created fully automated image analysis software that pro-

vides adjustment data for PLC-driven adjustment hardware.



8

Building an Engine Knock Analyzer with LabVIEW

Author(s):

Alfred Collins - Raeburn Technology

Industry:Automotive

Products:

Sound and Vibration Toolkit, LabVIEW

The Challenge:

Designing an automotive engine knock analyzer that is

inexpensive to build, accurate in indicating the presence

and intensity of knock on any engine, easy to transport

from engine to engine, operational in real time as well

as capable of logging data, and intuitive in its operation

so that a typical engine dynamometer technician can be

quickly trained to interpret the results.

The Solution:

Use an FFT analysis from the Sound and Vibration Tool-

set running in LabVIEW and a National Instruments data

acquisition card of sufficient bandwidth and number of

channels to capture and analyze a knock signal.

“Using the graphics capabilities of LabVIEW and the Sound and Vibration Toolset, we quickly and easily devel-

oped a display that communicated the necessary information.”

Knocking in an internal combustion engine is the uncontrolled self-ignition of the air/fuel mixture occurring mid-

way through the combustion cycle, causing extremely high combustion pressure spikes that destroy pistons and

rings in the engine. Small amounts of knock (incipient knock) are acceptable in a highly tuned engine, such as

might be used in a race car, but the possibility of incipient knock going into a run-away knock condition due to

external stress applied to the engine must be thoroughly analyzed. The diameter of the cylinder bore determines

the primary knock frequency. Secondary knock frequencies are controlled by the other dimensions of the com-

bustion chamber, high level harmonics, and the downward motion of the piston.

The universally accepted system to detect engine knock is an engine combustion analyzer that measures the gas

pressure in the combustion chamber in relation to the crankshaft rotational angle. By using a high pass filter on

the pressure signal or its derivative during the period of combustion, we can accurately measure the intensity of

knocking. Each cylinder must have an expensive, high temperature pressure transducer installed in the combus-

tion chamber, optimized in location so that the sensor is not in a “dead” area as far as knock is concerned. Since

4 to 10 channels (one for each cylinder) are normally required and a very high speed data acquisition system

must be used to perform the analysis in real time, the costs for a complete system typically exceeds $50,000

and the engine must be permanently modified to fit the sensors.

An alternative used by most automobile manufacturers in their production engines is to use one or more

accelerometers mounted on the engine block that will sense the high frequency vibrations generated by knock.

Unfortunately, the vibrations created in the valve train are typically in the same primary frequency range as the

knock signal. The placement of the accelerometers is critical to avoid as much valve train noise as possible and

to be as sensitive to the knock vibrations coming from all of the cylinders. The signal from the accelerometers

is passed through a low and high pass filter. The low pass signal is integrated to make a threshold signal to rep-

resent overall vibrations coming from the engine which are proportional to engine speed. The high pass signal

is compared with the threshold signal to determine when knock is occurring. The vibrations from the valve train

cause a great deal of error in this system at high RPM, due to its inability to distinguish between valve noise and

knock. Additionally, this type system can not detect incipient knock.

Contact Raeburn Technology in email: [email protected]

T he u ni v er sal l y acce pt ed sy st em t o d et ect en g i ne k nock i s an en g i ne combu st i on anal y z er t hat measu r es t he g as pr essu r e i n t he combu st i on chamber i n r el at i on t o t he cr ank shaf t r ot at i onal an g l e.

T he u ni v er s



9Contact Raeburn Technology in email: [email protected]

Design

In order to have an accurate indication of engine knock from a block mounted accelerometer, the vibrations from

the valve train and any other vibration causing system (crankshaft and pistons) must be separated from the

knock signal. An IIR filter set from the Signal Processing Library could be used for this purpose, but each engine

would have different frequency characteristics. By using a fast Fourier Transform those frequency characteristics

may be determined and the appropriate cross over frequencies may be applied to the set of IIR filters. This sys-

tem was fully implemented in LabVIEW and gives excellent results, but requires a great deal of skill and training

on the part of the operator to interpret the FFT.The operator’s determination of cross over frequencies for each

engine could be substantially simplified by using an averaging

fast Fourier Transform. The characteristics could quickly be

identified by comparing an averaged FFT at the same RPM when

the engine is audibly knocking to when it is not. The averaging

FFT from the NI Sound and Vibration Toolkit was used to make

these measurements, averaging over 400 combustion cycles

per cylinder. From this information the operator can accurately

determine what unique frequencies to use in the IIR filter set.

Using the graphics capabilities of LabVIEW and the Sound and

Vibration Toolkit, we quickly and easily developed a display

that communicated the necessary information. The averagingFFT system reduced both the skill level of the operator and

training time. However, the averaging FFT still depended on

history to make the cross over frequency determination.

What we ultimately needed was a real time system that was in-

tuitive to the operator. The Sound and Vibration Toolset again

came to our aid with one of the most spectacular displays that

is available for FFT analysis. We used the sliding window FFT

to display the frequency and amplitude relative to time. By us-

ing a wide range of colors to indicate the intensity of the sig-

nal, we make the interpretation intuitive. By using appropriate

examples, we can quickly train the operator to identify not only

intense knock, but also incipient knock. The three dimension-al view allows us to easily separate the valve train vibrations

and any other engine vibrations from the knock signal. The

best feature of the system is the ability to distinguish incipient

knock from high intensity knock.. See Figure 4. Note that the

combustion cycles with high intensity knock have tall, bright

red, yellow and white “totem poles.” The ones with incipient

knock have dark blue and purple spots above the main combus-

tion area.

Application

We modified a 400 horsepower four wheel drive Porsche Twin Turbo to achieve 600+ horsepower with all emis-

sions systems operative and running on 93 octane street gas. It was capable of a quarter mile acceleration timeof mid 10 seconds, top speed of 204 mph and weighed in at 3500 pounds. We entered the car, shown in Figure

5, in the One Lap of America race which included 8 road racing courses and one drag strip, winning 6 of these

events. Unfortunately, the engine blew up at the event at Pikes Peak, while using 91 octane gas. Of course I

blamed the stupid helper who put 91 octane gas in it. Little did I realize that it was the stupid engine builder (me)

who was to blame.

The Engine Knock Analyzer revealed the truth! Even with 93 octane gas, the engine had significant amounts of

knock, as we have shown in the screen shots below. We found that the air flow meter was improperly calibrated,

causing the engine to knock at high boost levels.

By using LabVIEW with the Sound and Vibration Toolkit, we have been able to develop a real time knock analyzer

that with the help of the striking visual display makes the determination of knock intuitive and accurate, and is

low in cost.

Two combustion cycles of severe knock.

A sliding window FFT showing seven combustioncycles, three with severe knock.



10

DIAdem Software Accelerates Crash Test Analysis

Author(s):

Steve Armstrong - Autoliv North America

Industry:Automotive

Products:

DIAdem

The Challenge:

Making automated crash test results avail-

able quickly and efficiently.

The Solution:

Using NI DIAdem software to completely

automate crash test data analysis and re-

porting.

“After a crash test, we have a fully analyzed test data package within minutes. Before we implemented DIAdem,

we sometimes had to wait several hours.”

Crash-Testing 101

Autoliv, a leading automotive safety systems manufacturer, conducts a variety of automotive safety tests – the

most dramatic being the barrier test, where a fully road-ready car is towed into a solid barrier. Barrier tests may

contain up to several hundred sensors that digitally record the crash event data. Other tests vary in complexity,testing specific car subassemblies such as dash panels, or recording airbag pressure.

To use crash data, we measure accelerations and other parameters in several locations on a test article and

record crash test dummy forces, accelerations, and displacements. We then process the crash test data accord-

ing to various standards, including NHTSA, SAE, and FMVSS. Since 1996, we have used an automated system

based on DIAdem to analyze and report thousands of crash test results. DIAdem reduced data processing time

from several hours to half an hour, providing test results within a very short time after running the test, where-

upon we quickly may draw conclusions, run more tests, and ultimately be more productive.

DIAdem Results in Quick Turnaround

Because of the costs and setup involved with crash testing, we are always looking for ways to speed up and

optimize our processes. We use the standard DIAdem functionality coupled with numerous automation scriptsto determine exactly how well the safety system under test performed and quickly make informed decisions.

Automation helps us rapidly analyze different data and report outputs. Because DIAdem incorporates standard

crash analysis functions, we can take advantage of its standard off-the-shelf format, rather then writing our own

custom code to process crash test data.

By utilizing DIAdem scripting capabilities, we condensed a highly repetitive analysis task into a series of scripted

commands. Using the DIAdem dialog editor, we built an intuitive user interface on the front of our data analysis

program to further parameterize how the data is analyzed. For example, after starting DIAdem, the user interface

populates with a series of choices, including test type and crash test dummy start position.

The automated analysis end product is a series of plots and a table that outlines all processed injury values. We

can configure the plots to group similar sensor data together (for example, all dummy head data is on one graph,

and leg data on another). The head injury criterion (HIC) value quantifies how severe an injury would have been if

the crash victim were human. Injury values such as neck injury criteria and femur force criteria help us determine

the severity of the injuries sustained turning the test. One standard specifies an HIC value of at least 700 for

injury requirement failure.

Contact Autoliv North America (author) in email: [email protected]

Check the website: www.autoliv.com

DI Ad em C r ash T est P ar amet er s



11Contact Autoliv North America (author) in email: [email protected] the website: www.autoliv.com

How DIAdem Helps Analyze Crash Test Results

DIAdem has helped us streamline our crash test analysis processes and reduce them to a series of upfront deci-

sions regarding how the data is analyzed. We use DIAdem and its scripting capabilities to automate the complete

data analysis process. This data analysis automation has been the single most important advancement made to

improve our data management capabilities and turnaround time. After a crash test, we have a fully analyzed test

data package within minutes. Before we implemented DIAdem, we sometimes had to wait several hours.

As crash test requirements evolve and the need for tighter safety tolerances increases, we collect more data,

have greater processing requirements, and, as always, look to reduce costs. DIAdem meets all of these needsby helping us rapidly process our crash test data and providing tools to quickly respond to user changes and

requests.



12

Bloomy Controls Performs Functional Testing of

Battery Management Systems for Hybrid Electric

Vehicles

Author(s):

Grant Gothing - Bloomy Controls

Industry:

Automotive, Consumer Goods, Electronics, Energy/Power,

Manufacturing

Products:

TB-2627, LabVIEW, PXI-4071, PXI-1044, PXI-6221,

TB-2706, PXI-2527, PXI-6514, PXI-4110, PXI-8105

The Challenge:

Designing and developing a flexible, cost-effectiveproduction test system for several designs of battery

balancing and management circuit boards with system

requirements including simulating a pack of lithium-

ion batteries (up to 12 series cells), performing high-

accuracy voltage and current measurements, and

communicating with the unit under test (UUT) via serial

and/or a controller area network (CAN).

The Solution:

Creating a general test system based on the NI PXI plat-

form and the NI LabVIEW development environment that

uses modular instrumentation, including six NI PXI-4110

power supplies to simulate battery packs, and provides theflexibility and accuracy needed to test multiple products.

“The NI PXI platform coupled with the LabVIEW development environment delivered the ideal tools to quickly

design and build a BMS test platform that is flexible enough to test multiple customer products, and accurate

enough to meet or exceed BMS testing requirements.”

The rapid growth of the hybrid-electric vehicle industry presents many new oppor-

tunities for product testing and measurement. Many of these opportunities require

production-level test systems with short design times, high accuracy, and strong

reliability. One opportunity involves the production testing of battery managementsystems (BMSs) for lithium-ion battery packs, which power plug-in hybrid electric

vehicles (PHEV).

BMSs handle all of the monitoring, control, and safety circuitry of battery packs and control systems, includ-

ing accurately monitoring cell charges, balancing voltages between cells to maintain a constant voltage across

packs, managing charging and discharging, and protecting the system from over-voltage and over-current condi-

tions for packs of up to 12 cells in series. In addition, BMSs monitor system temperatures, handle system power

saving by entering sleep modes to reduce current draw, and communicate with external controllers to provide

system feedback. While there are several types of battery management boards, including individual pack balanc-

ing and monitoring boards and system control boards, we refer to all types as BMSs in this document.

BMS Features and Requirements

Because the BMS is important to the safety, performance, and longevity of PHEV batteries, it is critical that each

manufactured board perform to strict specifications. Cell voltages must be monitored to millivolt accuracy, safety

faults must occur properly, and the BMS must draw current from individual cells to balance voltages across a

Contact Bloomy Controls, Inc. in email: [email protected] the website: www.bloomy.com

B M S T est er B ase S y st emM



13

whole pack. Functional testing of these processes requires a highly accurate, flexible, and strong test system

capable of simulating packs of cells, applying system voltages, measuring cell and system-level voltages and cur-

rents, and communicating with the UUT.

System Hardware Design

By starting with the Bloomy Controls PXI-based universal test system, we produced a flexible, high-accuracy

base platform consisting of a standard mass interconnect capable of testing multiple models of BMS circuit

boards by using interchangeable fixtures. We centered our system around sixNI PXI-4110 triple-output program-mable DC power supplies, which we used to simulate a pack of up to 12 lithium-ion cells.

We also multiplexed a high-accuracy NI PXI-4071 digital multimeter (DMM) to measure voltages within the

required millivolt specifications, and added an NI PXI-6221 M Series data acquisition DAQ module to provide

analog outputs, TTL digital I/O, and higher-speed analog input measurements. We implemented theNI PXI-6514

industrial digital I/O module to read switches and actuate fixture relays. In addition to the PXI hardware, we

used fixed power supplies and programmable high-voltage and high-current supplies to provide additional system

power as required by the testing specifications.

Finally, we provided a USB connection to the fixtures to allow flexible addition of other UUT-specific communica-

tions and peripheral hardware on a per-model basis. We housed all of our hardware in a standard 19 in. rack. The

test rack provided a system capable of making any measurement and supplying any source required by a BMS

board.

We also used a standard fixture receiver to permit several different BMS designs to be tested using the same

base hardware. Each fixture type was electronically keyed, guaranteeing that the correct test code would run for

the attached fixture. By using interchangeable fixtures, we greatly reduced system cost and lead times through

sharing key instrumentation hardware among UUTs. After we built the base system, we could quickly design and

build new fixtures and their associated test software.

Series Cell Simulation Based on the PXI-4110

To simulate a pack of 12 lithium-ion cells, we linked the isolated ±20 V legs of the six PXI-4110 power supplies

together in series; each leg simulated a single cell of the pack. During cell voltage testing, the power supplies

applied individual cell voltages between 2 and 4 V for a combined pack voltage of up to 48 V. Then, the software

polled the UUT for its reported voltages seen at each cell; we compared these voltages to the voltages measured

by the DMM in the test system to determine UUT accuracy. For tests measuring each cell’s balancing current, the16-bit readback resolution of the PXI-4110 supplies was vital because it eliminated the need for external shunt

or Hall effect current. Overall, the PXI-4110 was an excellent choice for this application because of its low ripple,

fast response, high resolution, and ease of control.

System Software Design

We wrote the test software using LabVIEW and contained all test parameters in a configuration file to allow the

customer to update, tighten, or loosen test specifications without making software changes. In addition, we

stored all of the data acquisition channels and tasks in a separate configuration file, which allowed hardware or

wiring changes to be made without affecting the underlying software. Also, because the user interface is de-

signed for a manufacturing environment, it requires minimal operator interaction and the test technician simply

opens the safety lid of the fixture, scans the barcode serial number of the unit to test, then closes the fixture for

the test to start during standard operation. When testing is complete, the test result is shown, test data is loggedto file, and any failed tests are highlighted for the technician.

Furthermore, we delivered all software with debugging and diagnostic modes, which provided engineers more

manual control over the system. Test engineers can enable the debug mode to run smaller subsets of the main

test to narrow down the possible causes of a failure. The diagnostics control screen provided access to all as-

pects of the system pertaining to the attached fixture. This allowed the engineer to manually read all system

voltages and currents, control all power supplies, actuate relays, and communicate with the UUT.

An Accurate and Flexible Testing Solution

The NI modular instruments and LabVIEW software used in theBloomy Controls BMS functional test system was

critical in designing an accurate, easy-to-use, and flexible system. The six PXI-4110 programmable DC power

supplies were ideal for simulating packs of lithium-ion cells. To date, we have delivered three base systems andnine fixtures including seven unique fixture models. We delivered two of the base systems directly to contract

manufacturers, one of which is currently located in China.




14

Our experience with BMS testing allows for the rapid development of new test systems with low risk and short

lead times. By using a modular approach and interchangeable components, the base system can accommodate

testing a wide range of BMS models. This method reduces cost and new fixture design time and makes it cost-

effective to test even small quantities such as R&D prototypes. In summary, the NI PXI platform coupled with

the LabVIEW development environment delivered the ideal tools to quickly design and build a BMS test platform

that is flexible enough to test multiple customer products, and accurate enough to meet or exceed BMS testing

requirements.




15Contact Tsinghua University (author) in email: [email protected] the website: www.tsinghua.edu.cn/eng/index.jsp

Development of an Electronic Stability Program

(ESP) Hardware-in-the-Loop (HIL) Simulation

based on NI PXI and CompactRIO

Author(s):

Li Hong-zhi – Tsinghua University

Industry:

Automotive, Research

Products:

LabVIEW, CompactRIO, PXI-6722, PXI-8106, FPGA

Module, Real-Time Module, PXI-6229, Report Genera-

tion Toolkit, Control Design and Simulation Module, PXI-

8461/2, PXI-1031

The Challenge:

Creating a hardware-in-the-loop (HIL) simulation plat-

form to accelerate the development of the Electronic

Stability Program (ESP) control algorithm and decrease

the high demand on a testing site due to real vehicle

experiments.

The Solution:

Developing an HIL simulation platform for an ESP based on

NI PXI, CompactRIO, and a host with all devices connect-

ed by network cables using the 15-degrees-of-freedom

(DOF) vehicle model built with NI simulation modules.

“Our ESP HIL simulation platform based on NI PXI and CompactRIO placed the controller in the simulation loop

and allowed us to easily test the algorithm in the controller.”

An automobile ESP is an essential device used to improve automobile driving sta-

bility and safety. It integrates an antilock braking system (ABS), a traction control

system (TCS), and an active yaw control system (AYC) to effectively improve the

driving stability and safety of an automobile during braking, driving, and turning.

The ESP controller periodically detects vehicle movement states during driving, and

when danger is detected, it will promptly send commands to the braking system

and engine through the controller, and reduce danger by proactively controlling the

vehicle.

After conducting an in-depth investigation and considering the performance, price, and ease of implementation,

we chose the NI PXI and CompactRIO platforms to build our system. We compared an xPC system, an NI PXI

system, and a dSpace system and determined that the xPC system is lower in cost but not as easy to use while

the dSpace system is more expensive than the PXI system even though they are similar in performance.

System Architecture

The hardware of the ESP HIL simulation platform consists of five parts: the host computer, target, controller, ac-

tuator, and sensor. We used the host computer to monitor the simulation process using shared variables as well

as to analyze and store simulation results. In addition, the target executes the vehicle model; the controller runs

control algorithms and navigates the vehicle; the actuator serves as a hydraulic control unit, braking pipeline, and

a brake; and the host computer, target, and controller are connected via network cables.

H ar d w ar e-i n-t he-Loo p ( H I L ) si mu l at i on pl at f or m

H ar d w ar e-i n-t -



16Contact Tsinghua University (author) in email: [email protected] the website: www.tsinghua.edu.cn/eng/index.jsp

Hardware System Design

The PXI system runs the vehicle model and provides reference signals to the controller. The controller captures

several signals including brake signals, main cylinder pressure, four-wheel speed, steering wheel angle, horizontal

acceleration, and yaw angle speed.

We used an NI PXI-6229 multifunction M Series data acquisition (DAQ) module to acquire the analog pressure

signal from all cylinders, including the main cylinder, and the digital brake signal. We also used an NI PXI-6722

arbitrary waveform generator to output analog voltage, which represents the angle of the steering wheel, hori-

zontal acceleration, and yaw angle speed. In addition, the NI PXI-6722 outputs four analog voltage signals and avoltage/frequency converter alters voltage into the corresponding frequency signal to simulate the speed of the

four wheels. For the actuators, we used an ESP 8.0 hydraulic control unit from Bosch. The brake system consists

of the braking pipeline and brakes of a Jinbei van.

Host Computer Monitoring Software

The software controls the simulation start and stop through shared variables and records the data from the target

in some global variables. We divided the host computer monitoring software into two main parts – simulation

process monitoring and simulation data viewing. Simulation process monitoring includes the functionality of

parameter restore, control simulation, real-time parameter monitoring, and input of the drivers during the simula-

tion process. It can also configure the simulation mode, gear strategy, simulation time, initial state, and ground

attachment to easily conduct simulation under all conditions. Simulation data viewing allows the user to observe

and compare simulation data, play back the vehicle movement during simulation, and save and restore data.

We can use the interface to observe the curve for 70 parameters in the simulation process and store and restore

simulation data. By clicking the “Simulation Playback” button on the bottom right of the window, we can graphi-

cally show the running track of the vehicle. The interface program also records the yaw angle information while

conducting a real vehicle experiment and sends the information through the simulation process according to the

actual time intervals, which then provides the simulation results of the vehicle response.

Target Simulation and Controller Software

The target uses a vehicle model with 15 DOF to run the vehicle model. The 15 DOF include six degrees for hori-

zontal, vertical, and positional transition and rotation; eight degrees of the rotation and vertical transition of four

wheels; and one degree of rotational system.

During simulation, the target acquires the pressure signal from the main cylinder and four-wheel cylinders at 1 ms

intervals to calculate the vehicle force and achieve the movement states of the vehicle. It also transfers the state

parameters to the controller through the PXI-6229. At the same time, the target stores the vehicle movement

state parameters in the memory and transfers data to the host computer at the end of the simulation. It also

continuously detects the control signals sent from the host computer. We easily implemented all of these compli-

cated functionalities using a parallel structure.

We also used a CompactRIO controller to run an ESP control algorithm to determine if the vehicle state is danger-

ous based on the received sensor signals. If danger is detected, it will control the vehicle movement and resolve

the crisis.

Successful Development of a Simulation Platform

The simulation results matched well with the results of the real vehicle experiments, which demonstrates thatthe HIL simulation platform can effectively simulate the vehicle movement.

Our ESP HIL simulation platform based on NI PXI and CompactRIO placed the controller in the simulation loop and

allowed us to easily test the algorithm in the controller. Building the simulation workbench greatly accelerated the

development of an ESP control algorithm.Our system consists of a PC as the host computer, a PXI target marked in the red frame,

and a CompactRIO controller marked in the yellow frame



From Concept to Crash Test

Control Design

In-Vehicle Testing and Logging

Wireless Systems

End-of-Line Test



National Instruments Hungary Kft.H-2040 Budaörs, Puskás Tivadar utca 14. I. emelet

Tel.: +36 23 448 900Fax: +36 23 501 589

E-mail: [email protected]

www.ni.com/hungary

06 80 204 704

National Instruments,Instrumentacija, avtomatizacija in upravljanje procesov d.o.o.

Kosovelova ulica 15, 3000 Celje, SlovenijaTel.: + 386 3 425 4200

Fax: + 386 3 425 4212


www.ni.com/slovenia

HR, MC, BA, RS, ME, ALB: + 386 3425 4200SLO: 080 080 844

National Instruments Poland Sp. z o.o.Salzburg Center, ul. Grójecka 5, 02-025 Warszawa

Tel.: +48 22 328 90 10

Fax: +48 22 331 96 40


www.ni.com/poland

00 800 361 1235

National Instruments (Czech Republic), s.r.o.Dělnická 12, 170 00 Praha 7 – Holešovice,Česká republika

Tel.: +420 224 235 774Fax: +420 224 235 749


www.ni.com/czech

800 142 699

National Instruments (Czech Republic), s.r.o.

organizačná zložka

Vysoká 2/B, 811 06 Bratislava, Slovenská republikaTel.: +421 911 128 255


www.ni.com/czech

0 800 182 362

SC National Instruments Romania SRLB-dul Corneliu Coposu, nr. 167A, et.I, Cluj Napoca, CP 400228

Tel.: + 40 26 440 64 28


www.ni.com/romania

0800 894 308

ni automotive solutions

Documents