José Ramón Gómez laconcha, Tknika
When the ECU controlling the injection and/or ignition systems of a vehicle combustion engine stop working correctly, there is widespread lack of knowledge among mechanics and electronics technicians about how to address the problem. We want to give them a tool that they can use to diagnose said ECUs in a simulated environment outside the vehicle.
We have built a vehicle emulator using an NI sbRIO-9636 device programmed in LabVIEW with a signal adapting card of our own design. This emulator is capable of sending the most important signals required by an injection and/or ignition ECU to function outside the vehicle and of observing its correct functioning in different situations.
José Ramón Gómez laconcha - Tknika
David Garrido Diez - Mondragon Unibertsitatea
In recent years electronics have been progressively introduced to vehicles. Today it would be impossible to imagine a vehicle that does not have numerous electronic control units (ECUs) fitted to control all kinds of vehicle systems such as the combustion engine injection and/or ignition systems, ABS brakes, etc.
One of the most important ECUs is engine injection and/or ignition given that in the majority of cases its breakdown implies immobilization of the vehicle.
The development of vehicle electronics has not been accompanied by the appropriate training in electronic knowledge among the professionals of vehicle repair workshops or dealers, and this generates a certain amount of respect when it comes to addressing these systems. The mission of this project was therefore to give vehicle repair professionals greater insight to the world of automotive electronics.
The emulator must permit the same inputs as when it is actually in the vehicle. Such inputs must be suitably protected against potential short circuits caused involuntarily when making the necessary connections.
Next, the emulator must send the ECU signals simulating those that it would receive from the different sensors in a combustion engine when running inside a vehicle. Here we refer to signals such as engine revolutions per minute, camshaft position, engine temperature, engine draw-through, intake manifold pressure, etc. Some of these signals are considered primary and must be sent if the ECU is to start functioning, while others are secondary and help to vary the engine operating conditions. Another necessary condition is that the vehicle repair technican must be able to easily vary these signals in order to simulate different engine running conditions and observe how the ECU responds to them.
It is also important that the emulator permits the rapid connection of some of the actuating elements normally found in a combustion engine, such as injectors, ignition coils, etc. with a view to verifying correct running of the ECU by means of observing in an oscilloscope contained within the emulator itself the form of the electric signals sent by the ECU to the former, signals which are in turn saved on a disc for their subsequent processing and analysis.
Finally, the emulator must be designed for fast and simple connection to a vehicle diagnostic machine in order to communicate with the ECU and establish whether or not it responds to the stimuli sent to it from the emulator.
Although the first prototype was made using an NI cRIO-9076 device together with modules NI 9221, NI 9264 and NI 9225, the final version of the ECU emulator/simulator has been made using anNI sbRIO-9636 device to which a signal adapting card of our own design has been connected. This card, in addition to isolating the signals coming from the vehicle, adapts their tension to permit their correct interpretation by the NI cRIO-9076. This has also allowed us to reduce costs when envisaging mass production of the ECU emulator.
We have used LabVIEW both to programme the emulator and to programme the distributable executable in order that it may be used by workshop personnel.
Being able to programme at FPGA level permits the acquisition of very high frequencies with no data loss. Furthermore, by using the LabVIEW tools for the real-time management of high volumes of data (mainly RT FIFOs and networksteams), we have succeeded in creating an interface on which the end user can observe the details of the sensors and actuators operating at high frequency.
The ECU must firstly be correctly connected to the emulator. Next, the type of ECU to be diagnosed must be selected using the corresponding menu on the computer working with the emulator. This step is important given that each ECU requires a particular set of signals to start operating. The emulator is prepared to work with the ECUs most commonly found today and it is relatively simple to add new models.
Finally, we will launch the simulation process. The emulator will send the corresponding signals to the ECU and it will start working. This can be both seen and heard. The oscilloscope appearing on the computer screen will indicate whether the form of these signals is correct. The operator will adapt the parameters to obtain the desired simulation signals, such as the engine turning speed, engine temperature, etc. They will then verify whether the ECU output signals accompany these changes in the signals sent. They will also be able to connect a diagnostic machine to the ECU by means of the ECU console and, using its parameters menu, observe that the ECU understands and reacts to the changes made by the operator to the signals sent to it.
The entire test is recorded in a file that can be consulted once the test has been completed.
José Ramón Gómez laconcha
Tknika
Zamalbide auzoa s/n
Errenteria 20100
Spain
Tel: +34 688654947
jrgomez@tknika.net