EvoX ECU and beyond..
Feb 19, 2008, 03:11 PM
#1
Evolved Member
Thread Starter
iTrader: (1)
Join Date: Jun 2004
Location: Plano, TX
Posts: 1,270
Likes: 0
Received 0 Likes
on
0 Posts
EvoX ECU and beyond..
All:
I thought I'd put this into the EvoX general forums, but it could very well go into Future Evos.
I recently bought a book on Engine Management and I've been reading for the last couple of days on some of the technology that goes behind it. We've moved from OBDII ports to CAN bus ports and from 2D lookup tables to 3D maps (at least for some of the stand alone ECUs).
My background is in Computer Science and I was coming up with ideas on how if I were to work for one of these car manufacturers, how would I program an ECU. Here are a couple of thoughts:
1) Lookup tables are fast, but can cause inaccuracies due to resolution - not to mention they can be easily modified.
Here at work, we use texture maps to give detail to a surface. In a lot of cases, we can represent this surface analytically without using memory for storing the maps and thus have infinite resolution. For example, consider a wood or marble texture. There is a function that exists such that we can create a texture strictly from mathematical inputs and evaluate our "texture" on-the-fly. In the case of an automotive ECU, I can see lookup tables being something of the past. Realtime procedural mapping should be right around the corner.
2) Smarter sensors. As our ECU gets faster (to the point that it is calculating timing and fuel several seconds ahead of the actual motor), our sensors need to be more than just sending a voltage or displaying a resistance. I can see each and every sensor getting some kind of silicon to talk to the ECU and adjust based on realtime conditions.
3) An ECU that can learn to get the most power out of the engine without the need for a tuner. This can probably be done in the near future. With procedural computations happening in my field, I can easily see dynamic on-the-fly tuning to get optimal performance from the car under the emissions constraints. We deal with physics engines here and it's very common to see a computer compute the movement of waves from an ocean if feet were to walk through it with a certain mass, velocity, location, and other aspects to it. How about an ECU that can learn that an intake has just caused an increase in airflow and calculate how much the timing can be advanced (without lookups) and injector pulse lengthened due to this condition without knock.
Overall, we are headed toward the days of "Knight Rider". I can imagine a car full of electronics that all talk to each other and optimize the engine based on several realworld conditions and driving habits. Logs could be stored in memory and evaluated when the car is shut off to come up with long term predictions which would then be used to evaluate outputs to sensors on-the-fly.
Interesting...I'm almost tempted to code up a simulated ECU of this nature that doesn't use lookup tables..almost..
-M
I thought I'd put this into the EvoX general forums, but it could very well go into Future Evos.
I recently bought a book on Engine Management and I've been reading for the last couple of days on some of the technology that goes behind it. We've moved from OBDII ports to CAN bus ports and from 2D lookup tables to 3D maps (at least for some of the stand alone ECUs).
My background is in Computer Science and I was coming up with ideas on how if I were to work for one of these car manufacturers, how would I program an ECU. Here are a couple of thoughts:
1) Lookup tables are fast, but can cause inaccuracies due to resolution - not to mention they can be easily modified.
Here at work, we use texture maps to give detail to a surface. In a lot of cases, we can represent this surface analytically without using memory for storing the maps and thus have infinite resolution. For example, consider a wood or marble texture. There is a function that exists such that we can create a texture strictly from mathematical inputs and evaluate our "texture" on-the-fly. In the case of an automotive ECU, I can see lookup tables being something of the past. Realtime procedural mapping should be right around the corner. 2) Smarter sensors. As our ECU gets faster (to the point that it is calculating timing and fuel several seconds ahead of the actual motor), our sensors need to be more than just sending a voltage or displaying a resistance. I can see each and every sensor getting some kind of silicon to talk to the ECU and adjust based on realtime conditions.
3) An ECU that can learn to get the most power out of the engine without the need for a tuner. This can probably be done in the near future. With procedural computations happening in my field, I can easily see dynamic on-the-fly tuning to get optimal performance from the car under the emissions constraints. We deal with physics engines here and it's very common to see a computer compute the movement of waves from an ocean if feet were to walk through it with a certain mass, velocity, location, and other aspects to it. How about an ECU that can learn that an intake has just caused an increase in airflow and calculate how much the timing can be advanced (without lookups) and injector pulse lengthened due to this condition without knock.
Overall, we are headed toward the days of "Knight Rider". I can imagine a car full of electronics that all talk to each other and optimize the engine based on several realworld conditions and driving habits. Logs could be stored in memory and evaluated when the car is shut off to come up with long term predictions which would then be used to evaluate outputs to sensors on-the-fly.
Interesting...I'm almost tempted to code up a simulated ECU of this nature that doesn't use lookup tables..almost..
-M
Last edited by BOOSTEZ; Feb 19, 2008 at 03:14 PM.
Feb 20, 2008, 06:07 AM
#2
Evolved Member
iTrader: (17)
Join Date: Apr 2004
Location: 41° 59' N, 87° 54' W
Posts: 6,224
Likes: 0
Received 0 Likes
on
0 Posts
I'm a firm believer in the KISS principle and really do not want to see an overly complicated ECU design. It's hard enough trying to work with/around the stock knock detection algorithms on my VIII... 
IMO, if an OEM were to implement a smarter ECU design, then they would still program it to leave plenty of safety margin and it would just make extracting ultimate power much more difficult for tuners. IIRC, Vishnu was toying with some self-tunign features on the venerable XEDE piggyback. Unfortunately the feature never really materialized
In the near future, I think we will see a resurgence of piggyback devices, as more manufacturers move to encrypt information on their ECUs.
l8r)
IMO, if an OEM were to implement a smarter ECU design, then they would still program it to leave plenty of safety margin and it would just make extracting ultimate power much more difficult for tuners. IIRC, Vishnu was toying with some self-tunign features on the venerable XEDE piggyback. Unfortunately the feature never really materialized
In the near future, I think we will see a resurgence of piggyback devices, as more manufacturers move to encrypt information on their ECUs.
l8r)
Feb 20, 2008, 06:18 AM
#3
Evolved Member
Thread Starter
iTrader: (1)
Join Date: Jun 2004
Location: Plano, TX
Posts: 1,270
Likes: 0
Received 0 Likes
on
0 Posts
I was thinking yesterday on the way home about sensors failing. I guess the SMART ECU could behave from past data and driving habits (these could be stored as maps), warn the user, and not be aggressive with the timing or AFRs.
Just imagine your own brain controlling the engine and how you would be able to prevent knock in EVERY situation.
