IndyCar racing features some of the most technologically sophisticated automobiles in the world today. Weighing just 1,565 pounds and powered by single- or twin-turbocharged 2.2L V6 engines that produce anywhere from 550 to 700 HP, the sleek, aerodynamic vehicles are capable of speeds in excess of 220 mph.

Not surprisingly, all of the space-age technology used in modern IndyCars tends to attract high-tech companies to the sport. Two such companies – Mouser Electronics and Littelfuse – have joined forces this year with the KV Racing Technology team. The team’s chief technology director, Eric Cowdin, spoke with Tech Briefs Media Group editor Bruce A. Bennett to answer some typical questions an engineer might ask.

NASA Tech Briefs: How big a role does electronics play in an IndyCar?

Eric Cowdin: Electronics are actually the backbone of running an IndyCar — everything from the engine management to the data acquisition system. It’s really the basis of controlling everything that’s going on in the IndyCar, as well as feeding us information back to make it perform better. Because of all the electronics on the car, there’s a very important circuit protection system on our car: the PDU, or power distribution unit. That PDU has eight outputs and each one has a pre-set current on it. Each one of those outputs is designed specifically to the electronic system that it’s providing control to, or current to, and that PDU protects every one of those delicate circuits. The other thing that allows us to do is monitor that output, via telemetry or recorded data, which gives us a chance to help the driver avoid a serious problem.

The KV Racing Technology team of engineers checks the car before final practice at Indianapolis. (Photo by Bruce Bennett)

NTB: What type of onboard computers are these cars equipped with, and what do they typically control?

Cowdin: Generally, there are two main systems onboard that actually control the car. One is for the gearbox and clutch assemblies, and the other is the engine control system. Each one controls its own systems initially, but there is communication between the two systems that allows the car to perform at its optimum level.

NTB: When a car comes into the pits during practice sessions, a crewman will often plug a laptop computer into it and download data. What type of data is being downloaded and what do you do with it?

Cowdin: The data that’s coming from the car is up to a thousand points per second of information — driver inputs, performance characteristics of the car, air speed, wheel speed, and lateral, vertical, and longitudinal acceleration. There are over 300 channels being recorded in real time, and that information is being offloaded during the car’s time in the pits.

NTB: Is the use of telemetry legal in IndyCar racing?

Eric Cowdin, KV Racing Technology’s chief technology director. (Photo by Bruce Bennett)

Cowdin: Yes, it is, and it’s actually quite vital to the point where it’s required by the engineers that real-time telemetry be in operation while the car is on the track. We don’t necessarily have quite the data sampling rate we would have with the onboard system. Any of the real-time channels could be sent across the telemetry stream, which is really only limited by the bandwidth of our telemetry system. That information is visually indicative of what the driver is asking from the car — throttle, steering, brakes — all the way down to engine performance, its health, temperatures, pressures, and fuel level. All these aspects are monitored while the driver is on the track, and from a safety standpoint, we look at tire pressure and all of the preventative aspects in case we have to call the car into the pits for safety issues.

NTB: What types of performance adjustments can a driver make during a race?

Cowdin: It depends on the configuration of the track. On road courses, the driver can change the brake bias, which is front-to-rear brake distribution, and often the actual roll bars front and rear, which change the mechanical lateral load distribution of the car. On the ovals, we’ll add what’s called a weight jacker, which is basically a hydraulic slave cylinder located in the right rear spring that will either raise or lower the car as it pertains to that spring. It changes the weight distribution across the two front tires, which will affect the handling of the car as it enters the corner.

NTB: The steering wheel on a modern IndyCar is actually a mini data center. What types of information does it give the driver, and how do you make it available to the driver in real time?

The IndyCar steering well provides drivers with information such as the number of laps completed in a race, engine RPMs, and speed, and can be configured to a driver’s preferences. (Photo by Bruce Bennett)

Cowdin: Some of the information we give the driver is quite basic — the number of laps completed in a race, engine RPMs, speed — but the dash is limited by the number of LED displays. We have four different pages for four different layouts so the driver can configure it to his or her own liking. For races, we provide fuel count, fuel used, and basic information on anything that’s on the car that the driver would need information about, such as tire pressures or temperatures.

NTB: This year saw the introduction of a completely new type of IndyCar and new rules that allow the teams to use different body work and aerodynamics packages. This had to involve a lot of wind tunnel testing and computer simulation. How close did the computer data come to what you actually learned in the wind tunnel?

Cowdin: Well, a lot of the accuracy of our simulations revolves around tire modeling, and getting a very good tire model is a difficult thing to apply into a simulation program. Firestone’s a great partner for us, and they supply us with a very good tire model that we use for our simulations. But part of what we had to adjust for in simulation is track conditions for the grip coefficients for each individual circuit. Those are always a floating target throughout the race weekend. It depends on temperature and the number of laps done on the circuit.

From a wind tunnel standpoint, we had quite a steep learning curve with this new car, and we’ve been using every resource available. Our team is closely associated with Chevy racing, so we get a lot of support from them and their engineering firms. We’ve done everything from computational fluid dynamics (CFD) and 50% model scale testing, to full-scale rolling road testing of the car, so when we go to the race track, we’re pretty confident in the package we’ve put together.

NTB: Is there much, if any, redundancy built into the electronic circuits on a modern IndyCar?

Cowdin: Due to weight restrictions for performance, the only redundancy on the car is the safety equipment. We have an accident data recorder that has builtin backup power, which allows us to keep recording if the car loses power. The voice radio and fire suppression system have their own independent power sources — just batteries. And there is also a master switch that can be manually triggered by safety workers so that after an accident, it turns all the power off and triggers the fire suppression system.

NTB: With all the sensor systems and computer data available to a team today, how critical is the driver’s input?

Cowdin: I think I touched on that when we reviewed our simulation work pre-event. If that were 100% transferable to the track, then we would just show up and race with the drivers driving the optimum car. But each driver has their own preference on how they drive the car and the areas of the circuit where they’re going to maximize their performance based on that style. So we give them the best combination of a mechanical and aero package through all of the work we can do before we arrive, but there’s nothing that replaces a driver’s feedback and helping the driver get the best out of a mechanical package on the track.

Littelfuse is sponsoring a contest that gives winners the chance to spend a weekend at an IndyCar race. For more information, and to enter the Speed2Design contest, visit www.speed2design.com.


NASA Tech Briefs Magazine

This article first appeared in the July, 2012 issue of NASA Tech Briefs Magazine.

Read more articles from this issue here.

Read more articles from the archives here.