Is Engine Waveform Simulator Useful in Diagnostics? It's Your Call!
Engine simulators are used in automotive engineering to get engine parameters just right. They allow to estimate pressures, gas quantities and other vital physical measures inside the cylinders as the engine goes through its cycles. Can they also be useful for diagnostics?
Well, there are a few issues:
- multi-cylinder versions are expensive or not available to the public at all (in-house software);
- simpler versions focus on operation of only one cylinder;
- a great deal of effort goes into precise simulation of combustion events (spark, flame front, etc.), which is not that important for diagnostics of engine mechanical issues;
- the programs may not be able to produce graphs that are of interest to diagnosticians (for example, waveform for a pressure pulse sensor in the tailpipe).
An engine simulator for diagnostics should:
- be cost-effective;
- simulate the engine as a whole: all cylinders and manifolds at once;
- report waveforms that can actually be produced by sensors and tools used in diagnostics;
- support simulation of the cranking event and other diagnostic tests that may lack combustion (for example, in-cylinder pressure test);
- be fast enough to provide results within a minute.
I have searched and could not find an engine simulator that would satisfy these requirements -- if you know any, let me know! So, out of curiosity, I put together a program to reproduce cranking waveforms. The engine is modelled as a collection of chambers (some with moving pistons, of course), connected by passages (that open and close according to the stroke the engine is in). There is no combustion to simulate, and slower crankshaft speeds allow to ignore certain physical effects that are important at higher RPMs. So, just cold hard math using well-established laws of physics (ideal gas law, conservation of energy, etc.), but without getting too complicated.
How well does it do? Here is an example that Brandon went through at yesterday's Trained-By-Techs live feed. A 6-cylinder engine has an intake valve that is always closed. In my program I basically erase the passage that connected the intake manifold with the affected cylinder, and let it run:
The top-left panel provides a general overview of what's happening in the engine: starter current, instantaneous crankshaft speed (which jumps wildly for this scenario), affected cylinder pressure waveform, and intake manifold pressure. The top-right panel provides pressure waveforms for ALL cylinders, showing how much the affected cylinder stands out among the rest. The bottom-left panel contains manifold and crankcase pressures -- and, yes, this graph gets "busy". So, in the bottom-right panel I only plot the Intake Vacuum trace (because Brandon is using a vacuum transducer) and also add the starter current and in-cylinder pressure traces (with an arbitrary scale, just to fit in nicely). Now, take a look at the intake vacuum graph Brandon presented:
Same shape! When there is no intake pull for the affected cylinder, the vacuum trace goes down. When there is no compression for the affected cylinder, the crankshaft speeds up (see top-left panel), and the vacuum is increased due to stronger intake pulls from the other cylinders.
This is an in-cylinder capture taken by Brandon, same shape on my graph as well:
So, here you go. You can "break" the engine in any way you like and get a feeling for how the waveforms look like. Now where should I take the project? I can:
- make an online system where diagnosticians and/or instructors can specify one or more engine faults, which waveforms they would like to see, and then get back results within a minute;
- bolt some AI on top of it and let users upload their scope captures to be processed and annotated automatically, with possible faults identified and suggestions presented on what to try next.
Ultimately, what matters most is what you think is most useful for you, and I will try to do just that. So, what do you think? Any ideas, questions, suggestions, and criticisms are welcome!
Wow Dimitry! That is impressive, i have no particular comment right off the bat, but that is some useful stuff for sure. Suggestion, whatever you do with it, dont let it get trampled underfoot by an unappreciative crowd..
Thank you for encouraging words, Maynard! Indeed, just the description of the method does not really showcase what possibilities it opens, so it might take a while for it to prove its worth.
Very Impressive work, Dmitriy
Very good annalist
Nice Dimitry! That sounds like a great idea. I've found a lot of technicians get confused by in cylinder captures. That would simply things a lot and save technicians time! One suggestion is if you do create this website, make sure there is a huge disclaimer. I can definitely see someone replacing a part or putting in 6 hours of work for teardown and finding nothing wrong then coming after you…
Thank you, Nelson! I really hope that this method would help to "un-confuse" techs as they would be able to confirm that their diagnostic guess results in the waveform they are seeing on the scope and no other one. The method would be able to process several traces at once, so if one or more captures do not make sense I expect the program to say just that most of the time. But, of course, a…
Hi Dmitriy a good engine simulator for free can be found at electude simulator just google it you will be pleasantly surprised
Thanks George, I should have mentioned that one, if only to clarify what I mean by Engine Simulators. As far as I know (and please correct me if I misunderstand anything), Electude's Engine Management Simulator is an engine troubleshooting simulator (simulates the process of troubleshooting, with waveforms preprogrammed for each scenario), while the engine simulators I talk about simulate…
That is awesome ! I think the AI idea would be more useful for me but either would be another tool in the arsenal
Thanks, Kurt, I will try to put together a demo version soon.
I thought ATS's iEA did some of what you are suggesting?
Hi Bentley, iEA does analyze in-cylinder pressure waveforms (though I have not seen case studies here with its use, unfortunately), and from what I have seen it is done by identifying standard features on the waveform like compression towers, an expansion pocket, etc., and then reporting their positions versus expected ones. Complicated faults (especially if there are several faults) may make it…
Hello Dmitriy, I was wondering if anything has become of the software you show in this post? I have been looking for a way to identify carbon build up on intake valves using pressure pulse sensors, one in the intake and one in the exhaust engine at idle. The reason for the message is I recently posted a carbon study and was wondering if your software could explain or predict what intake valve…
Hi Craig, I haven’t tried to model intake valve deposits yet — I‘ve been focused on reproducing cranking waveforms first, and I’m not sure if carbon deposits would show up on those loud and clear (due to slower crankshaft speed and no combustion). So, I’m watching your carbon studies, and will surely give it a try once I’m comfortable with reproducing running engine waveforms. On the other…
Hello Dmitriy, Thanks for taking time out of your day to respond, so far testing has been done at idle, the next vehicle I will pull a cranking pattern as well. Do you want an ignition sync in the pattern? Or any other information in the capture that could help In interpreting the results? Thanks Craig
Craig, as we are interested in the detailed intake pulse waveform, cranking will likely have to be done with closed throttle and fuel delivery disabled — extra hassle, unfortunately... Starter current is helpful to align TDCs, though ignition sync can be used for that as well. Actually, I think the ignition sync is most important if visual inspection showed that there are specific cylinders…