When IndyCar vehicles motor around the track this year, microcontrollers are monitoring virtually every component, from the engine to the gearbox to the shock absorbers, but the conditions under which they can provide a competitive edge are being carefully controlled.
To contain costs and maintain relative parity among the cars, IndyCar declared this year that competitors are not allowed to tamper with the software code in the engine control unit (ECU) or the gearbox control unit (GCU). For the most part, the cars will run with the same electronic hardware and software.
"The rules now prevent us from getting into the ECU," Mark Johnson, general manager of KV Racing Technology, told us. "In years past, we had the latitude to work with the code, but we're not allowed to do that anymore."
IndyCar teams aren't allowed to tamper with the software code in the standardized Indy ECU. (Source: Littelfuse)
Under the current rules, competitors must use one of three engines, all of which are limited to a V6 design with 2.2 liters of displacement. All three engine builders (Chevy, Honda, and Lotus) must employ ECUs from McLaren Group, which customizes the controllers for each engine. The software in the McLaren ECUs must also adhere to the turbocharger boost requirements, which change from race to race. "All of the boost for the turbos is electronically controlled," Johnson said. "If someone were able to get in and manipulate the boost, they could change the horsepower and change the outcome of the race. That's why there are tight stop gaps in the ECU to monitor that."
The electronic restrictions don't stop there. All race teams must use identical electronic modules built by the same supplier, Cosworth Group. The modules enable all the controllers inside the vehicle to talk to one another. Engines and gearboxes, for example, communicate via Cosworth electronics. Dashboards, steering wheels, data acquisition cards, and sensors also must employ the same hardware.
"The way it's set up, Cosworth is the only one that's constantly updating the software," Johnson said. "If Chevrolet has an update to its engine -- say, for example, it wants to change its fuel strategies -- then it has to be filtered through Cosworth. Cosworth has to integrate their changes into the system."
However, the new rules don't mean race team engineers have little to do. Most teams keep relatively big engineering staffs. KV, for example, has two electronics engineers, two data acquisition engineers, and a radio engineer. Those five are joined by two mechanical engineers, two simulation engineers, a vehicle dynamics engineer, an aerodynamics engineer, and a parts design engineer who also doubles as a draftsman.
Much of the staff's time is taken up by incorporating sensors on the car and then analyzing the data that comes from them. On race day, the team is allowed to monitor 32 channels of data, including wheel speed, bearing temperature, water temperature, oil temperature, brake rotor temperature, gearbox pressure, and aerodynamic pressures around the vehicle. Such monitoring may provide extra hundredths of a second at all the right times, potentially spelling the difference between victory and defeat.
"Even within all the rules, there's still plenty of electronic activity in the car," Johnson said. "The pulse of the car is built around the electronics."
[Learn more about IndyCar at Littelfuse's Speed2Design site.]
The real engineering for race day is the car handling, as well as no mechanical/electrical problems. If every car did equally well, then every driver/car would be on the lead lap on the final lap, dueling side-by-side to win the race (assuming each driver has equal talent and ability). Many of the crashes are due to ill handling cars, not necessarily driver mistakes.
Having good car handling during one part of the race, does not mean good car handling during the entire race. Race conditions constantly change, requiring adjustments to maintain the car handling and manage tire wear.
I see a lot of room for improvement with the race car engineering despite the rules for seemingly identical equipment.
The race car engineering will never be as "sexy" or exciting as the attention the race car drivers receive.
It would be really interesting if those engineers would be allowed to do some real engineering for race-day. See what sort of surprises they could come up with if the need to have identical designs was removed.
It's good hear to that software is not the technical edge in racing but the actual electronics hardware and the driver's own skills. I'm glad the Indy Car organization has made racing teams play on an even field by allowing a 3rd party supplier to program the ECU's with the same engine performance profiles.
You're correct, RickZ28, there are 12 engineers on the KV Racing team. Between the electronics, aerodynamics, data acquisition, vehicle dynamics and mechanical cocerns, they must be working a tremendous amount of overtime this time of year. To me, 12 engineers sounds like a skimpy team, considering the workload. But I'm sure that a lot of our readers would still love to switch places with them.
It's nice to read about the engineers the IndyCar teams employ. I count 12 engineers listed in the paragraph. (KV has two electronics engineers, two data acquisition engineers, and a radio engineer. Those five are joined by two mechanical engineers, two simulation engineers, a vehicle dynamics engineer, an aerodynamics engineer, and a parts design engineer who also doubles as a draftsman.)
Our design engineer also doubles as a draftsman, generates 2D drawings that are still needed, from the 3D SolidWorks models. I gotta think the IndyCar race teams are also using 3D modeling programs such as SolidWorks or ProEngineer. Using such programs will enable much easier multi-physics engineering of the designs, such as FEA.
I guess the 12 engineers working for KV Racing are involved with all three of KV Racing teams..for drivers Tony Kanaan, Rubens Barrichello, and EJ Viso. I'm sure each of the three race teams has a very knowledgeable and experienced crew chief (engineer) to direct and coordinate the effort for his car/driver.
It would be really interesting to see how a bug or virus into the indy car fleet would really make the race interesting. It would be a race to see who could hobble to the finish line first.
I don't trust the kids writing software in such environments. There is too much temptation to play pranks. I know I would have had a hard time not adding a subroutine that would cause them all to "crash," not wreck, of course, just to make my mark on the race. But I wonder...
I may be stretching a bit to answer this question, Beth, but I believe it's both. Some of the data has to be analyzed in real time, which, of course, makes it difficult to use data tools. For the data that's analyzed after the fact, however, they're using software tools, I believe.
It's amazing how staffed these teams are from an engineering standpoint, yet how seemingly constrained they are in doing of doing any hands-on engineering work. Chuck, you say much of the engineering team's time is spent sifting through sensor data to zero in on slight modifications that could deliver an edge. I'm curious--is this a manual process of drilling down into raw data or, as I would think, are they employing data analytics tools to find patterns and uncover insights that a plain old human might not see initially?
New disc magnet motors fit into the design trend of stepping up to closed loop performance while maintaining the cost advantage of stepper motor technology.
At the Design News webinar on June 27, learn all about aluminum extrusion: designing the right shape so it costs the least, is simplest to manufacture, and best fits the application's structural requirements.
A new battery design, which replaces lithium with abundant and low-cost elemental sulfur, is still in its nascent stages but shows real promise for giving batteries more energy potential.
The push to achieving more intelligent, integrated manufacturing is putting a strong focus on networking and connectivity as key enabling technologies.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
0 
