What? A virtual engine? What is that?
One definition of virtual is “not real”. So I suppose one could think I am talking about an “unreal” engine. Well, not really. (Virtually!). Read on to find out more…
Many people are aware of the work I have done in the past with piggyback ECU’s, and most will be unaware of the work I have been doing lately regarding ECU programming. There are two ways to test the changes made to the “software” inside the ECU that controls the engine.
The first way is to try the ECU out on a proper engine. That would be the same as changing the landing software of an aircraft and doing a physical flight test to see if it worked! Who would do that? Using this method, if we made an error in re-calibrating the ECU, we could potentially let the smoke out of the engine. And we all know that the smoke is what makes them work. Don’t believe me? Try to get anything to work properly after you have let the smoke out!!
The other way is to put the landing software in a test harness, or simulator that provides the required inputs to the landing system, and see how the outputs behave. That is exactly how they do it in places like Boeing, as I learned on a recent visit to an air force base. It was pretty amazing, and was partially the stimulus to take on this project.
Lets start by thinking what the ECU inside you car is actually doing. What it really is doing is looking at a whole bunch of inputs, such as engine RPM, Throttle/Pedal position, Air Flow, Air Temp, Coolant Temp etc and making a number of decisions based upon these. These decisions manifest themselves as outputs, mainly fuel injection and ignition signals. There are of course a few other things, like fans, fuel pump voltage, metering oil pump stepper motors etc.
Since all these inputs and outputs essentially go to and from the ECU in the form of electrical signals, it is a fairly straight forward task in simulating them.
Since in my “lab” I already can place an ECU on the bench (a fine topic for another Hymee Homily), and communicate with it with my sCANalyser, it would be handy to also plug in the other “inputs” and “outputs”. Then I can also validate much of the ECU’s operation via the OBDII communications. All this without a real car in site.
So that is one tool I am building at the moment, and have started making some of the components. The main one is something to simulate the “crank” angle sensor. On the real Renesis engine of the RX-8, this is a 30 tooth wheel (10 degree teeth, 6 missing, aka 36-2-2-2) and a hall effect sensor. And I suppose it is really called an “Eccentric Shaft Position Sensor” in the world of rotary engines – but I can use this other engines as well. I’m going to simulate this using a notched wheel and a IR sensor. If that doesn’t work, I can go hall effect as well. Or I could just use a signal generator and output the waveform that matches the hall effect sensor. In my initial practical approach. the toothed wheel / chopper disk is being spun by a 12V electric motor. I have built a variable speed controller, so at the turn of a knob, I can dial in any RPM from about 600 to about 14,000. I also have a laser RPM counter that I can use to cross-check the RPM against what the ECU thinks is going on. So far I have only had one prototype chopper wheel explode at close to 15,000 RPM – it was a blank CD, and a bad vibration caused a wobble which eventually caused a stress fracture in the plastic disc, and she let go. I have only found enough shrapnel to peice together 50% of the disc. And I only suffered cuts to my leg, stomach and forehead. Go on – laugh now. Could you imagine a more terrible week…
The other inputs are much more simple, as they generally are based on voltage levels. So I can set up a control panel with dials and gauges, where I can dial in the desired voltage for one of the sensors (e.g. Mass Air Flow or Throttle Position), which translates into a digital signal to the ECU via it’s internal ADC.
Then for the outputs, the main ones I want to watch for now are the fuel injectors and the ignition. I will just hook up some LED’s that will flash when the these devices are “pulsed” by the ECU - 6 green LED’s for a Renesis “6-port” and 4 red LED’s for the spark plugs.
What this means is that when I make changes to the PCM and, for example, reduce the fueling requirements at a certain load point, I can run the virtual engine at that load point, and validate that the changes are in fact taking place as predicted. I can further validate the changes by using the sCANalyser to log the fuel injectors “pulse width” or “duty cycle” to see if the before and afters do actually change.
Neat, yeah?
Now I must stress, this is not to measure or simulate the performance of an engine. We are not making fuel burn, and measuring the torque/power of an output shaft. But when we go through all the load points on the virtual engine, and optimise the fuel/spark and check it is at safe levels, then we can go try it out in the actual vehicle for the “flight test”. That will be the virtual proof in the pudding.
Cheers,
Hymee
