Bench Simulator for Bosch EDC15 Diesel Engine Management

[Ruan]

Warning! Lots of incessant typing ahead..

So been meaning to sign up here for quite some time, always watched Dave's videos and enjoy watching them and many other electronics related stuff online. I currently work in the High Performance Computing sector - I'm an integration engineer - so I'm usually trying to make a few hundred computers all play ball together and then provide a bit of support after (read: tea boy) - always been interested in electronics, namely their integration in the automotive sector, namely diesel powered stuff.

I've played about a lot with older Indirect, mechanical injection engines which require spanners only to extract more power from, but recently gotten into the foray of Commonrail Direct Injection engine management systems - I mostly play with/tune Peugeot/Citroen (I think some of the Aus guys might have heard of Peugeot at least!) HDi (High-pressure Direct Injection) engines which were some of the first to use Commonrail and therefore some of the more simple engine management systems going!

EDIT: Forgot to say, for those who are interested - the ECU uses a Siemens/Infineon C167CR-4RM MCU which has 32Kbyte ROM, 2Kbyte XRAM and 1 CAN interface - I do intend at some point to grab the IROM from it and have a look in IDA... It also has a 29F400BT flash hanging off it for it's calibration data.

http://www.keil.com/dd/docs/datashts/infineon/c167cr_ds.pdf

I've started into the foray of reflashing ECUs, which has gone reasonably well so far, but there's always an issue:

The Problem

I need to be able to work on the engine ECU away from the car and be able to simulate what it's going to do, however - they're incredibly complex beasts, even though they're early 2000s technology. Vast quantities of calibration data and all sorts going on inside - there's also a lot of software limitation, so all of the testing needs to be confirmed to see whether it's actually doing what you think you're telling it to!

I can't always pop an ECU on a car and test how it performs and see whether what I've changed is actually working how I expected it to, not only because driving a car up the public road and trying to see whether the injection quantity and injection timing is correct is, well, dangerous - not to mention, if it's not quite right, you'll possibly end damaging the engine.

A friend of mine from home has built a dynamometer into his shed and put on some computerised control (if you're interested, he has a YT channel: https://www.youtube.com/user/darrenjlobb) - which is an amazing tuning tool, however, I live about 300 miles from "home" due to my work, so often it's not very practical.

The Solution?

Build myself something, so I can reliably test and monitor the ECU with on a bench - there are a few tools available for the monitoring side, but are usually Chinese one-hung-low knock offs or are absolutely extortionate for the good ones! The Bosch KTS tool which is often used is well over £1000 ($2000 AUD) which is out of the realms of what I'm willing to spend. There's "sanity checks" and "diagnostic limits" which means the diagnostic tool will quite happily tell you that the ECU is performing in a certain way, but in reality there's another system in place, making it do something you're not expecting.

What does it need to do

- Be able to simulate ALL inputs required for normal running of the engine.

Unfortunately these engines are a bit more complex in terms of sensors than a standard SI petrol - since they require precise crank and sync cam timing. I've found a nice open source project that uses an Arduino to chuck out various cam/crank signal combinations, just need to work out the layout of both and possibly scope the output of a running engine to see what it *should* look like!

These engines also have high pressure fuel control which is very closely monitored - since the pump is capable of 1500+bar - it monitors the pressure in the fuel rail closely vs what it expects, if it's below this, it assumes a leak and abruptly shuts the engine down - naturally a leak with 1500bar behind it means the fuel goes pretty much everywhere in a very fine mist and therefore is insanely flammable. This will be one of the main things to get right - probably require a spot of code on with an MCU to simulate this, thankfully most of the sensors are all 0-5v with calibration within it's calibration, which, thankfully, I can adjust as required.

Then just a few simple bits and bobs like the throttle position sensor, which is two inverse pots, which again, I'm sure a small MCU along with the high pressure fuel control simulator, I could rig up - worst case scenario, I'm sure I could just get the original throttle sensor and chuck it on the table and twist by hand.

- Be able to somehow simulate the injectors

This is the problematic part, I'm still not 100% on how this works, I've read varying different reports of how the electronics work - the injectors operate at ~50V and require about 30A peak to open them, and probably 10A or so to hold them open - this high voltage/current is mostly for speed as they work on differential pressure internally for opening/closing.

I've heard and read that they somehow use the coils of another injector that isn't firing to somehow bump the voltage up and store the charge in capacitors internal to the ECU - I'll post some pictures of the inside of the unit later, if anyone has any ideas as to exactly how it works.

The ECU is intelligent enough to know when there is an injector fault - so I probably need some way of sinking the output of the injectors and making it look to the ECU like they're really there - I also need to be able to watch these outputs to monitor the pulse width of the injections it makes. Of course, it's never easy, there's up to 4 injections per cycle for emissions and NVH control.

- Be able to monitor the other outputs of the ECU.

I've got access to a few old analog scopes, although I've been looking for an excuse to get my own - the Rigol DS1054Z is looking like a prime contender. Also combined with a Saleae logic analyser - everything else is pretty simple PWM outputs, nothing too complex at all, which the logic analyser should be more than happy looking at.

Sorry for the large essay - nice to be able to go somewhere and talk a lot and possibly have someone listen to my inane ramblings and give their thoughts and maybe possibly tell me "here's a real simple way of doing this" or "that'll never work" - I'm not the best educated in electronics, my background is mostly IT, but I understand enough to make me a little dangerous and allow me to let the magic smoke out more than expected...

It's all bit of a pipe dream at the moment, but I think this is my best option, unfortunately I'm cheap as hell, if I can do something for half the money, but double the time, I'll probably take the double the time option! Anyone with any ideas, I'd love to hear them!

[Ölrückstoßdämpfung]

What you want to build is usually called a HiL (Hardware in the Loop) simulator. They can be built in various degrees of abstraction: For example, if the purpose of the simulator is to work on the ECU/injector interface, you'd most likely use actual injectors and simulate the rest. What you plan to do is thus the highest degree, simulating everything. You can buy such systems for example from dSPACE, expect a six figure sum.

From someone who has years of experience with the EDC16 and has had a refrigerator size HiL simulator in his office: Don't try it at home. Making such an ECU work outside its natural habitat is tricky even if you have the complete documentation and the source code open to you (ask me how I know). For example, if you have the complete engine with all actuators and sensors working correctly and simply disconnect the rest of the car (brakes, interior electronics etc...), you'll already have to manipulate a three digit number of error detection functions so they don't shut down everything when the ECU notices there's, for example, no ABS ECU connected. That's quite a task if you know everything and can manipulate everything. I wouldn't dare do that stuff if all I had was a hex file.

[Ruan]

Thanks for your response - interesting to speak to someone else who is using these management systems.

In terms of the amount of body systems integration - thankfully there is near enough none, since they are on such early, simple cars! I've helped with a friend of mine's 1988 Peugeot 305 with a retro-fitted EDC15 2.0 HDi motor in, I helped with most of the wiring - immobiliser removed - there's essentially no fault codes. Only one for coolant heater which we disconnected - must get around to disabling the DTC for that!

It's whether I can simulate the engine stuff enough to make it work - that's a whole other question - I'm under no illusions it'll be easy - but thankfully it's purely a case of getting the engine side of things talking. I don't know whether it will be possible, but always worth it to give it a shot?

[Ölrückstoßdämpfung]

If you give it a try, it will be a very interesting learning experience, and I'd love to hear about how you're doing with it! However, be prepared to get stuck in a dead end rather sooner than later, and then it will (will, not may!) become very very frustrating.

The absence of fault codes does not prove that everything is running. Actually, the amount of times when an error triggered an 'official' fault code readable by diagnosis software or even an OBD reader was neglibile compared to the cases when an internal error flag was set and nothing else happened, apart from the engine running like crap. If you don't have specialized software (Google: ETAS INCA) and the possibility to access the ECU's memory and knowledge where in the memory which variable sits, you're in trouble then.

As to simulating the engine stuff: You will have to create a model of every component the ECU interacts with and feed the according signals back. This would easiest (not easy!) be done with rapid prototyping hardware like NI's LabView suite or, if you have too much money, ETAS or dSPACE hardware and Matlab/Simulink. If you want to do this on your own, you have to build the electronics to simulate the behaviour (in the easiest case lots of DACs) and create component models in C, which you have to feed with appropriate parameters.
In an easy case like the accelerator pedal, you'd only statically have to reproduce the characteristic curves of the potentiometer, base voltages etc. As soon as the behaviour gets somewhat dynamic, you'll have to undertake considerable efforts in the area of system identification. No manufacturer will tell you how his component behaves, so you'll have to find out on your own, including building test benches for the component in question and so on.

Modern ECUs do so much double and triple checking of every signal that every simplification you make will have consequences. There are many cross couplings you'd never imagine to be there.
Example: I know of at least one vehicle whose ECU detects unstable engine operation (misfiring etc) by analyzing the pulsation of the exhaust gas pressure, which in turn is not measured directly but calculated based on other signals, I forgot which.
So if your model only assumes a constant value for, let's say, turbocharger speed, in one operating point - which may be totally reasonable at first sight -, and the ECU calculates the exhaust gas pressure based on that and other values, and that calculated pressure lacks the pulsation, the ECU might assume that there's considerable misfire and shut everything down. There may not be an error at all, because 'no pulsation' is so far away from normal operation that it isn't covered by any error code. Or another, even more unrelated error code might pop up, leading you into total confusion.
That example may seem a bit far fetched, but I've dealt with cases like that dozens and dozens of times. And if you don't have the access and can't see what this and that internal variable does, you have no chance of ever finding out what happened.

I hope I don't discourage you too much... as I said, it will be a tremendous learning experience. Nevertheless, I'd be too afraid of massive frustration to try it out at home

[jucole]

since they require precise crank and sync cam timing. I've found a nice open source project that uses an Arduino to chuck out various cam/crank signal combinations, just need to work out the layout of both and possibly scope the output of a running engine to see what it *should* look like!

ah, is that this one? https://gitlab.com/libreems-suite/ardu-stim   I've been simulating some VR crank and cam signals for a car ECU project I'm working on but I ended up rolling my own.  It's been an amazing learning experience - but as a beginner, it's been very painful! lol

[Ruan]

That's the one!! Whether or not it'll be able to do what I want it to is a whole other matter, but at least, I can have a root around it and tweak to my needs and hopefully somebody else might benefit some day.

At least, if nothing else, it wastes my time in the evenings when I'm bored and gives me an excuse to buy the scope I want and maybe learn a little about what can be done and what can't - if all I learn is that I can't do it, then so be it, but it'll be a good learning experience along the way - the only thing it'll essentially cost me is a components and maybe some time. The ECUs are 10 a penny these days - so if I release the magic smoke *SNIFF!* then whoops!

[pickle9000]

If you are going to simulate an entire system strip a working vehicle, wiring harness, components and all.

Before that happens take a scope and check the system at varying speeds. Unplug items one at a time get error codes and see what actually causes failures. Don't neglect things like the security system. Document every ting you can and then double check.

Once you have that pull the harness mount on a big board and start simulating sensors. Some will be simple but things like the gas pedal can be fairly complicated because of redundant operations. Once you have a working system you can run things to limits but don't think you can imagine all failure modes that comes from years of designers and will vary from manufacturer to manufacturer. There is also a possibility of intercepting signals from sensors and using that to alter performance, also tricky because you could end up outside the range of operation for the device.

[max_torque]

Luckily, as you say, by modern standards, the old EDC15 EMS systems on the gen 1 common rail engines like PSA's HDi are relatively simple!  But the word is relative.

I'd split the task down into individual chunks to make it manageable:


1) CAM / CRANK simulation & outputs - relatively simple, should be easy to spoof, but obviously you'll pretty much be spoofing a "perfect" crank signal, not a real one (without effects of trigger wheel offset, crank acceleration due to firing events etc).  A basic AC coupled 0-5v output ought to be enough here for the crank signal, Cam signal is probably hall effect so can be DC coupled 0-5v


2) Injectors - don't bother simulating, drive real injectors, otherwise you will be into a whole world of difficulty!  How you measure the pulse width, and validate the injection end/start/duration against your simulated crank angle clock is a whole different thing, and really needs a fast processor to do (ideally FPGA/XMOS etc but a decent 70Mhz ARM would also do it)

3) Fuel rail pressure control - you need to measure the output of the rail pressure control solenoid, and return a voltage to the rail pressure sensor input that reflects the rail pressure you want the ecu to target.  You could do a simple model on a seperate 8/16b micro if necessary

4) MAF,MAP, Lambda,ECT,ACT - all voltage signals, you might get away with a basic simulation to start off with, but the EMS will be doing some basic plauibility checking on things like MAF vs MAP and engine speed etc


In summary, certainly not trivial, but even doing chunks of it will be a good learning curve etc   

[ozwolf]

Fascinating project idea, I encourage you to do your best and keep us informed.

Ozwolf

[BennVenn]

Nowhere near the complexity that you'll be facing but on my homemade ecu I ended up running a trigger wheel coupled to a high speed BLDC motor. It gave me real world data that helped debug issues that weren't there on a simulated output from a microcontroller (Jitter, noise, mechanical resonance etc...)

An option that I thought quite a bit about was using my USBee logic analyser (clones are cheap!) to re-play captured or synthesised signals from custom software. You could capture all of your engines outputs under a few different conditions, create a simulated model and have your PC re-produce a more or less accurate simulated engine.

You probably already have the VE tables in your ECU so working back from there shouldn't be too hard to model flow/turbine speed/rpm etc...



http://bennvenn.com/NewBrain/NewBrain.htm

[Ruan]

max_torque -

Thanks very much for your input! The simulation of the crank signal is one of the parts I'm still not 100% sure on - as you say, the ECU does monitor crank acceleration per injector and thus able to correct each for each injector - but I'm going to blindly hope that the fact that in a high gear, especially whilst in a cruise state, there's so much inertia behind the engine, it's got to smooth the crank speed quite significantly - it's quite happy running in that state... Some of the tools I already have I can monitor the injector correction quantities, so should be able to see if it's very unhappy - but I hoping it won't affect running on the bench. The Bosch EDC15C Funktionsbeschreibung - which I need to upload and put somewhere for people to access (anyone fancy doing a technical German translation to English!?! Hah!) should describe the operation of this better.

I did think this might be the best way, with the injectors in which case, I've a few scrap sets of them, hopefully even with no real fuel pressure, they will operate to the point of working...

With regards to fuel pressure control, I've the vast majority of the rail pressure maps from within the ECU, including the precontrol, PID, requested and also the maximal deviation control maps - so just a case of rigging it up - As you say, a micro reading the simulated RPM, possibly the control valve output and a lookup table of values it should expect under whatever conditions. I certainly know how to make it less sensitive to fluctuations in RP - so should at least be able to stop it from faulting.

Thankfully the version I use doesn't have boost control and is super easy to delimit the MAF, I've already had to do this a few times during tuning to figure out exactly what's holding IQs back. ECT/ACT is mostly a case of getting a pot of the right resistance and wiring it up, going through the motions.

I totally agree - by no means trivial, but the hard work might pay off into learning something new - and that's always a bonus!

BennVenn and joeqsmith - I've not had a chance to read your posts fully yet, but I'm intrigued to have a closer look at what you're doing - looks very interesting and definitely relevant to what I'm doing!

[Swamp]

What you propose is completely possible--I've done it more than once. The people who say it can't be done haven't ever even tried to do it. [Don't tell ME what I can or can't do--I'll be the judge of that. }  max_torque gave a very good summary of what it takes.

 The difficulty is proportional to how sensitive the ECM is to things being a little out of range, and how sensitive it is to having all its systems plugged in and functioning. I work strictly on Ford diesels, so I can't comment directly on Bosch systems.

On the 1995-2007 Fords, the ECM doesn't care whether things like the transmission or ABS system are unplugged--it will "start" and "run" the test bench without any issues.  It does report all sorts of DTC's related to the missing sub-systems, but it "runs" the engine just fine.
I build my test benches using a complete engine wiring harness, and actual injector solenoids. I have used a cam trigger wheel mounted on a small electric motor (from the heater/AC) and a variable speed controller for one test bunch, and as I learned more about electronics used a MCU to generate a 60-2 crank and single tooth cam signal pattern to send to the ECU. On my first test benches, I used a simple circuit to convert the PWM signal from the ECU to the injection pressure regulator into a proportional 0-5v signal, and fed that back into the ECU's injection pressure sensor circuit, to create a true closed-loop system.
For the analog sensors, I used mostly 10k pots to simulate the various engine temperature and pressure sensors, although the 2004-2007 trucks used a 3-output accelerator pedal position sensor, so for them it was easiest to just bolt up a pedal to the test bench and operate it manually.
In addition to using the OBD port, I also put in a lot of test jacks for oscilloscope connections, which has proved invaluable.

On the 2008-2010 Fords, the ECU is very, very sensitive to having absolutely everything plugged in and working. These require the ABS module, air bag module, instrument cluster and a few other things to be present, and all from the same vehicle, before the ECU will even try to start the engine.

The 1995-2003 injectors are solenoid operated; 2008-2011 are piezo / high-pressure common rail. As long as the ECU / IDM / FICM have the correct injector solenoids plugged in, they run fine on the test bench. The 2011 and newer engines come with individually calibrated injectrors, so when I get working on them, I'll have to make sure that I get the injectors with the ECU, or use the Ford IDS scan tool & software to program things so they will work together.

In addition to building 4 different test benches for testing & repairing ECMs, FICMs, etc I've built several injector flow benches and set up a dyno cell for the same engines, and in about 2 weeks I'll be setting up my dyno cell to start running the 2008-2011 engines.

[joeqsmith]

   

Mine is fairly simple.   Custom board in the PC does most of the work.   I simulate all of the loads including the injectors.   The first video talks a little bit about the model. 

The board does pretty much all the real time work in hardware. 

This video explains a little on the waveform generator.

[joeqsmith]

Very early on in the project.  Showing the load box and playing some Christmas music towards the end.   

https://www.youtube.com/watch?v=wbrNoFeAMU0&feature=youtu.be

[Ruan]

Swamp -

Thanks very much for your input - I'm guessing most of your work is with the earlier HEUI Powerstrokes? We never got them in the UK, never actually seen a HEUI system, some larger lorries/trucks have it, but by no means common here. As you say, it's mostly about how sensitive the ECU is about things - I know the EDC15C implementation here isn't very sensitive at all, at least in terms of what body systems are needed to make it work! Most of what you've done is exactly what I'm intending to do. Hopefully the injector solenoids just being plugged in will get the ECU to start up. I know the ECU I use uses a 60-2 crank and a 3 trigger cam wheel - the ECU only needs the cam sensor briefly during starting, once it has started, naturally it has it's crank synchronisation and is happy to run without it whilst the engine is running. Naturally once stopped, it needs that sensor again to start - some later ECUs I've seen don't actually have a cam position sensor and purely monitor crank acceleration to get the crank synchronisation!

Joe -

Had a brief 20 minutes to watch some of your videos, especially interested in your waveform generator - that looks exactly like the sort of thing I'm intending to do - you appear a vast amount more competent than I when it comes to building rigs like that in hardware - really very impressive! The Scilab software you're using also looks brilliant, I wasn't aware there was such a thing - along with Xcos, looks like a very powerful tool for what I'd be looking to do!

Thanks all for the encouragement - it's definitely a case of now playing about and seeing what I can get working!

[joeqsmith]

I made a video that just shows the main program but it was very early on and it has changed a lot.    There is one thing that video showed that the signal generator video doesn't.    I mentioned simulating the torsional noise using FM to modulate the cam and crank signals synchronous with the crank position.  I can also perform a double modulation.   This allows me at any location of the crank to change the speed.  So, if I wanted to simulate cylinder imbalance,  it's no problem.   

I can also simulate chipped teeth, running the motor backwards, and a slew of other functions. 

Again, this is all in hardware so there is no problem to this this all in real time up to several 10's of thousands of RPMs.   

This board then drives the computer's interrupt synchronous with the engine position which triggers the model.    This is what I was attempting to explain at the start of the XCOS video.   

The whole reason to simulate it all electronically is I can do things with the simulation that would cause damage to the motor.   

My system as good as it is really is very simple.   As nice as the hardware and software is, the models are the key.  This is the parts I am working on now.   It's been very helpful to have as I make changes to the ECM's code.     

You can buy systems like this from D-SPACE, National Instruments, ADI and others.   If you have deep pockets....   

[0xdeadbeef]

As this is somewhat related, I also built a small open source 4ch crank/cam simulator some time ago based on an LPC1768 Cortex M3 which can be controlled via USB (HID) through a Java application:
http://lemmini.de/NGen/NGen.html
Everything (HW, µC SW, Java SW) is released under the Creative Commons license.

It's meant for hall sensors though (0..5V). Then again, it can also simulate bidirectional crank sensors and you can use it to create PWMs or time based arbitrary (digital) signals. I included an option in the Java program to create (static) SENT signals.
This is mainly directed towards the developers of engine control units who don't need a full fledged HIL but want still want to use crank/cam/SENT signals at their own mini-testbench.