Case Study Selection

NI Automotive Solutions

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

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 infotainment 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 flexible 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 highperformance 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. With a 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.

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 automotive fuel cell system capable of demonstrating significant progress toward achieving a commercially viable fuel cell system design that is competitive with conventional internal combustion-based power trains. The Solution: Designing and implementing a real-time embedded control 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-inthe-loop (HIL) system.

Ou r co mm itm en t to fue l ce ll sys tem (FC fu research resulted in S) vehicles such as the worlds firs t ful lsiz e, ful l-p erf orm an ce fue l ce ll ca r (P2 00 0) and the wo rld s first fue l cel l plu g-i n hybrid (Ford Edge wit h HySeries Drive).

Ford has a long history with NI, and we have used LabVIEW to develop various aspects of every fuel cell electric 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 conventional 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 the design team iteratively refined the design through verification following the systems 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 strategy functionality embedded in the CompactRIO controller. This HIL system, implemented with LabVIEW Real-Time, has a graphical user interface (GUI) that pro-

Contact Ford Motor Company (author) in email: kosborn1@ford.com Check the website: www.ford.com

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 realtime 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-time controller 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 & Automation Explorer (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 optimized the code to ensure correct real-time performance. Without a product like the NI 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 integration 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 reasons. 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 annotations. 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 electric vehicle 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: kosborn1@ford.com Check the website: www.ford.com

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 analysis software that provides adjustment data for programmable logic controller (PLC)-driven adjustment hardware.

The testing m chine. ma hi

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 machines 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 shortened 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 replaced 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 the tuning 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 projecting screen. 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: michal.harhaj@elcom.cz Check 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 headlamps 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 screws in 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 provides adjustment data for PLC-driven adjustment hardware.

Contact Elcom (author) in email: michal.harhaj@elcom.cz Check the website: www.elcom.cz

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 Toolset running in LabVIEW and a National Instruments data acquisition card of sufficient bandwidth and number of channels to capture and analyze a knock signal.

The universally accept ed s t system to detect eng kno ck is an en gin e ine co mb ust ion an aly zer that me asu res the gas pre ssu re in the com bu sti on chamber in relation to the crankshaft rot ational angle.

Using the graphics capabilities of LabVIEW and the Sound and Vibration Toolset, we quickly and easily developed a display that communicated the necessary information. Knocking in an internal combustion engine is the uncontrolled self-ignition of the air/fuel mixture occurring midway 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 combustion 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 combustion 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 represent 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: ALGCollins@aol.com

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 system 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 operators 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 averaging FFT 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 intuitive 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 using a wide range of colors to indicate the intensity of the signal, 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 dimensional 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 combustion area.

Two combustion cycles of severe knock.

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

Application
We modified a 400 horsepower four wheel drive Porsche Twin Turbo to achieve 600+ horsepower with all emissions systems operative and running on 93 octane street gas. It was capable of a quarter mile acceleration time of 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.

Contact Raeburn Technology in email: ALGCollins@aol.com

DIAdem Software Accelerates Crash Test Analysis

Author(s): Steve Armstrong - Autoliv North America Industry: Automotive Products: DIAdem The Challenge: Making automated crash test results available quickly and efficiently. The Solution: Using NI DIAdem software to completely automate crash test data analysis and reporting.
DIAdem Crash T t P Tes Parameters

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 according 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, whereupon 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 scripts to 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: steve.armstrong@autoliv.com Check the website: www.autoliv.com

10

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 decisions 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 needs by helping us rapidly process our crash test data and providing tools to quickly respond to user changes and requests.

Contact Autoliv North America (author) in email: steve.armstrong@autoliv.com Check the website: www.autoliv.com

11

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-effective production test system for several designs of battery balancing and management circuit boards with system requirements including simulating a pack of lithiumion batteries (up to 12 series cells), performing highaccuracy 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 platform and the NI LabVIEW development environment that uses modular instrumentation, including six NI PXI-4110 power supplies to simulate battery packs, and provides the flexibility and accuracy needed to test multiple products.

BMS Tester Base S System

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 opportunities 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 management systems (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, including 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 conditions 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 balancing 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: info@bloomy.com Check the website: www.bloomy.com

12

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 currents, 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 six NI PXI-4110 triple-output programmable 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 the NI 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 communications 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 cells balancing current, the 16-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 designed 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 logged to 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 aspects 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 the Bloomy 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 and nine 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.

Contact Bloomy Controls, Inc. in email: info@bloomy.com Check the website: www.bloomy.com

13

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 costeffective 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.

Contact Bloomy Controls, Inc. in email: info@bloomy.com Check the website: www.bloomy.com

14

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 Generation Toolkit, Control Design and Simulation Module, PXI8461/2, PXI-1031 The Challenge: Creating a hardware-in-the-loop (HIL) simulation platform 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 connected by network cables using the 15-degrees-of-freedom (DOF) vehicle model built with NI simulation modules.

Hardware -in -the-Loop

(HIL) simulation platfo i l rm

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 stability 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, actuator, 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.

Contact Tsinghua University (author) in email: hz-li07@mails.tsinghua.edu.cn Check the website: www.tsinghua.edu.cn/eng/index.jsp

15

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, horizontal acceleration, and yaw angle speed. In addition, the NI PXI-6722 outputs four analog voltage signals and a voltage/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 simulation 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 graphically 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 horizontal, 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 complicated functionalities using a parallel structure. We also used a CompactRIO controller to run an ESP control algorithm to determine if the vehicle state is dangerous 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 that the 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

Contact Tsinghua University (author) in email: hz-li07@mails.tsinghua.edu.cn Check the website: www.tsinghua.edu.cn/eng/index.jsp

16

From Concept to Crash Test

Control Design In-Vehicle Testing and Logging Wireless Systems End-of-Line Test

National Instruments Hungary Kft. H-2040 Budars, Pusks Tivadar utca 14. I. emelet Tel.: +36 23 448 900 Fax: +36 23 501 589 E-mail: ni.hungary@ni.com www.ni.com/hungary 06 80 204 704 National Instruments, Instrumentacija, avtomatizacija in upravljanje procesov d.o.o. Kosovelova ulica 15, 3000 Celje, Slovenija Tel.: + 386 3 425 4200 Fax: + 386 3 425 4212 E-mail: ni.slovenia@ni.com www.ni.com/slovenia HR, MC, BA, RS, ME, ALB: + 386 3425 4200 SLO: 080 080 844 National Instruments Poland Sp. z o.o. Salzburg Center, ul. Grjecka 5, 02-025 Warszawa Tel.: +48 22 328 90 10 Fax: +48 22 331 96 40 E-mail: ni.poland@ni.com www.ni.com/poland 00 800 361 1235

National Instruments (Czech Republic), s.r.o. Dlnick 12, 170 00 Praha 7 Holeovice, esk republika Tel.: +420 224 235 774 Fax: +420 224 235 749 E-mail: ni.czech@ni.com www.ni.com/czech 800 142 699 National Instruments (Czech Republic), s.r.o. organizan zloka Vysok 2/B, 811 06 Bratislava, Slovensk republika Tel.: +421 911 128 255 E-mail: ni.czech@ni.com www.ni.com/czech 0 800 182 362 SC National Instruments Romania SRL B-dul Corneliu Coposu, nr. 167A, et.I, Cluj Napoca, CP 400228 Tel.: + 40 26 440 64 28 E-mail: ni.romania@ni.com www.ni.com/romania 0800 894 308