Vehicle self diagnostics is developed to facilitate the finding of defects in vehicle electronics systems. Each module of system continuously controls the sensors, actuators, working ability of different modules, in case of problems the system records error messages and/or modifies the operation algorithm, to ensure (as much as possible) performance without interruptions and in max high quality. Lists of error messages in modern vehicles contains thousands, even tens of thousands error message positions.
Control of sensor and actuator connection circuit.
This is the simplest section of self diagnosis – the module controls connection circuits of devices connected to it, their continuity and short circuits. The simplest, because no external conditions, no other devices affect it. Accordingly, if the error message shows, that connection with some sensor is damaged, we could believe in that. Unfortunately also such simple situations can have exceptions. A typical situation: the sensor and/or actuator is connected to control unit, second/other it’s power wire is plugged in to power source (+5 or +14V). In case of connection lose, the outlet voltage drops to 0, and the control unit can not distinguish connection break and short-circuit with ground potential.
A typical sample: light control modules, in case of damaged bulb some diagnostic tools show error message (accordingly to it’s description): short circuit to ground, but of course, there is no short circuit. Why the producer has “saved” one resistor to each module’s outlet (which would allow to identify short circuit) – is not clear. But it is reality, and we have to understand, that self diagnostic system can confuse type of connection damage.
Exactly the same notice (regarding short circuit to ground) can be seen, if the sensor or actuator have lost supply voltage, or the sensor itself is damaged and/or actuator (break in it’s internal circuit) and control module don’t perform correct load voltage measurements (there is no separate power source for connection check).
Conclusion is, that even in simplest situations the self diagnostics can specify incorrect cause of problem,and replacement of details “by list” very often is not the correct solution.
Examples:
2ABC charging pressure sensor, electrical
2E30 injection valve cylinder 1, input signal
Operation control of sensors and actuators.
Actually this section can be reduced to operation control of sensors (and only sensors), because the actuators operation control – directly or indirectly – is performed via control of sensors.
Of course, if the sensor is damaged, self diagnostics will identify this problem. But we have to understand, that the signal of sensor (and conclusions made by electronics module regarding this signal’s conformity/truthfulness) depends on the external conditions. For example: the ABS sensor receives signal from disc, which is placed on wheel hub. If this disc and/or bearing are damaged, the signal will be incorrect. Or, if the exhaust system has an air supply, the oxygen and NOx sensors can display incorrect Lambda value (and self diagnostics will show, that these sensors are damaged).
More complex situation is in cases, when the error message is recorded regarding actuator – it means, that self diagnostics system, based on data from some sensor (or group of sensors) has implicitly concluded, that the defect is not in the sensors, not in the connections of actuator, but in actuator itself.
For example, the throttle with position sensor. The error message regarding throttle motor in fact means, that readings of position sensor are recognized as true, but they show incorrect position of throttle valve. Of course, there is a slight possibility, that there can be specific damages of position sensor or, for example, mechanical damages of throttle valve, which don’t allow normal operation.
If the control unit’s memory contains error messages regarding sensors (or even more relevant – actuators) functionality, the truthfulness of the error message must be evaluated. If possible, live data for the sensors has to be checked, the truthfulness of them evaluated, if possible – perform the test block and evaluate the results (and again – don’t trust the results unconditionally).
Examples:
2AA0 camshaft sensor inlet, signal
2ACC DME digital motor electronics main relay, switch delay
2AF6 nitric oxide sensor, Lambda binary
Functional control.
This is the most complicated section of self diagnostic – the decision regarding error of some component is based on data control of group of sensors and their performance in time. For example, after full control of an engine performance, the decision regarding it’s uneven running or mismatch of any oxygen sensor data is made. These decisions actually are much more complicated, than it look’s at the first moment.
For example: to decide about uneven running, control unit has to be able to balance fuel mixture for all cylinders, to keep it in perfect proportions, to decide, that no other obstacles (for example, changing load, changing opening angle of throttle) can affect the performance of engine, tiny changes in speed of flywheel has to be accurately detected. Due to complexity, the functional errors most often give false problem causes. To detect uneven performance, all systems of N series engines always has to be in work order, efficiency of cylinders has to be balanced, the sensor of flywheel – with performed and completed long-term trims, fuel preparation system – in work order etc. If all conditions are met – only then slight changes in flywheel speed will give information regarding not fully burned fuel in any of cylinders. But, if the fuel will be of bad quality, if the road will be uneven etc. – the error message will not be correct.
Exactly by this reason error messages regarding functionality have to be evaluated very critically, and this evaluation requires serious knowledge and understanding regarding functions of mechanisms.
Examples:
3104 Uneven run, Stratified charge
29E0 fuel mixture control
Serial interface error messages.
First group or errors – communication problems due to software errors or flaws. Only updating of software and/or unit release change can help in this case. Typical problems – timeout (problem and messages about it, f.e., “module not responding”) in case of high network load and/or non-timely switching on of some unit. Peculiarity of CAN serial interface – data senders of higher priority can overload the network in such level, that data senders with lower priority can’t even get to data transmission. Peculiarity of these error messages – they are transient, irregular. In case of these error messages I would suggest to check possibility to update software of master units (possibly, newer software version will perform more frequent network check up, which would “clean” the network from slave unit communication requests) and with CAN interface analyzer check, which groups are overloading the interface, and, if possible, update their software.
Second group of errors – hardware problems. Serial interfaces used in automotive industry by idea are quite safe: in more responsible areas data exchange protocols of 2 lines are used, and they are able to perform, if one of the lines is damaged. They can perform also in high level common mode interference conditions. They use open collector output stage solutions (which exclude possibility of high current flow thru interface chipset outputs in case of conflicts between some units), all units “see” the unit, which has higher data transmission priority (it also decreases possibility of conflict), each units serial interface uses chipset with high output current (Ipeak up to 50 .. 100 mA), high level of permissible transient voltages (2 .. 4 kV human body model test), suppression protection (typically: ~100 W 8/20 us high power suppressors) and much more, ensures quite secure performance.
The most reliable reason of damaged serial interface line: loss/damage of some unit’s GND (ground connection), which can bring (in some cases) to attempt to “feed” this unit via CAN lines. Typical damage in such case – suppression protection diodes of current line are damaged (short circuit) with high current (in rare cases – also output links of driver’s chipset), all line is “settled”.
Peculiarity of this group or errors – they are continuous, data exchange is disturbed in all group of modules, which are using this line.
Note: each group of serial interface modules has one module, which is “last in line” – it means, it keeps the load of serial interface: terminator (resistor, which serves for alignment of load and impedance). It has to be considered, when the exclusion method is used (it means, disconnecting the unit from line to find the damaged one) – the lines will not function without terminator. Load of data lines has to be created according to current specification of data exchange protocol.
Examples:
2E84 elctrical cooling pump, communication
2F4A interface EWS-DME electronic vehicle immobilization/digital motor electronics
The error status.
The error status can be passive or active, it means, the error is not observed in the exact moment, or it’s detected in past and is not identified in current moment. Here has to be remembered, that error status is not real-time parameter. Although INPA upgrades the error message list and status continuously, changes in error message list and/or changes in status may be delayed for several minutes (depending on load of exact unit). For this reasons the status of error can not be used as indicator fop checking the bad connection – it has to be done with multi-meter, oscilloscope or using live data, if such option is available.
It is not possible to delete an active error. Even if it disappears from diagnostics computer monitor, after a little while the error message will return.
The system of self diagnostics registers count of each error message’s appearance. Error messages, which appear multiple times, are marked as sporadic (for example, DIS), both DIS and INPA gives numbers, how many times current error message has appeared, so it allows to understand – this error was a separate case or it’s happening on regular base.
One more important nuance – if we take in account the time delay between error identification and it’s listing in error message list, there is no guaranteed consequences between changes in unit’s functionality and error message list. It means, the module can identify the error message, change the algorithm to other (alternative, emergency), but the error message regarding system’s disorder will appear only in a while.
Depending on current error message, the module can perform continuous (typically – connection check), cyclic (for example, actuators or functionality) identification and control, number of cycles can be limited (for example, attempts to restore even performance for 5 times, if it don’t succeed – stop till next session), error status can be deleted, starting new driving session etc.- the manufacturer don’t gives exact information regarding algorithms of error processing. The understanding, how does each error message “performs” – only question of experience.
Deleting of specific error messages (control unit module errors regarding performance downgrade of catalytic converter, errors regarding LM module connections/load, if the number of sessions, when the error is recorded, is exceeded; part of SRS modules after crash, etc.) is not possible in usual manner of error deleting (the status of such error messages is always displayed as active), they can be deleted only during specific service procedures or using very specific software, intended for this purpose (especially in cases, when manufacturer recommends the replacement of unit as only solution).
Error info.
Error messages of most complicated control units (DME/DDE, LCM/LM, etc.) are stored in several lists. For example, DME errors are stored in error list of pending session, info memory and history memory. History memory actually can not be deleted – it’s just not displayed in common list. If it’s necessary to see error messages of older errors regarding engine (but somebody already has deleted all lists before you), it’s enough to provoke new error message – all error message log will be available again.
INPA allows to see more detailed error info (for example, menu of error message list for pending session – press F2 and/or F3). Additional to basic info (error message code; description; odometer indication, when the error detected; status of error; number of events), appropriate conditions in the moment, when the error was detected, are displayed (for example, error message regarding trim problems for any bank: Lambda value in the exact moment; short-term trim integrator; long-term trim values; engine temperature; speed; RPM; load of engine etc. basic info) – this information is very helpful in evaluation of problem (in sample regarding trim problems – it allows to evaluate, if the cause of problem can be air suction in inlet manifold, fuel pressure in the system or some other problem).
Deleting of error messages and functionality.
In case of deleting the passive error message, functionality of control unit, most probably, will not recover immediately even if all system’s elements are in perfect condition. Only,when the unit (using actual information) will ascertain, that the problem is really gone,it will restore the algorithm of full performance. For example, if the N43/N53 had error messages regarding uneven running, then problem is solved, error messages has been deleted (and don’t appears repeatedly), Stratified charge will be restored only after specific self-test (time delay and control of engine even performance in Homogeneous lean mixture), then – two successful short Stratified charge cycles, additionally – evaluation of Lambda long-term trims, etc.).
Additionally, a series of “restoring” functions will be performed (more than 10 cyclic corrections of cylinder individual Lambda in Homogeneous mode in combination with Stratified charge, then – replenishment of Lambda long-term trims within banks). Manufacturer (software ‘developer) don’t informs regarding such nuances – they have to get to be known by yourself – go into module’s performance nuances (working as diagnostics specialist or developing some tools of functionality). Main conclusion: do not rise anxiety, if the effect of error deleting is not immediate. The same applies to deleting of engine control unit errors – full functionality will be turned on only after several driving sessions (more about his – in topic regarding engine long-term trims).
Deleting of errors and long-term trims.
This section, of course, refers to control units,which has such functionality (for example, engine control units, gear box control units). If there are long-term trim, they also have to be deleted after error message deleting (after the problem is solved). There are several reasons for it:
- It is possible, that because of previous defect, long-term trims are created incorrectly; when the functionality is restored – it is possible, that self diagnostics will find not existing problems (and record incorrect errors in error message lists);
- Long-term trims usually are created from tenths of different factors, which are analyzed during real performance of the vehicle. If the control unit will be forced to create 10 long-term trim in a row – each of them will differ from other. For this reason it is very important to create new long-term trim maps exactly with sensors/actuators, which are used in current moment, exactly in new circumstances;
- Creation of long-term trims takes a lot of time. Immediately after deleting, new long-term trims are created very rapidly, later they modify pace slows down. This is the third reason, why long-term trims have to be deleted – then new long-term trims will be created rapidly, and it will be possible to evaluate the performance of repaired module.
Note – deleting of long-term trims usually delete also status bits (which are unavailable and are not even visible to user) regarding past and also just now deleted error messages and also bits regarding necessary sequence of actual processes (for example, additional control of some sensor because of inadequacy of it’s parameters etc.), it means, deleting of long-term trims returns the control unit (module) to it’s basic (new module) state. The situations is not simple also here – the manufacturer of software (for both – module and diagnostic software) don’t informs, which long-term trims and which bits exactly are deleted.
For example, when the long-term trims of cylinder synchronization are deleted, INPA deletes also long-term trims of flywheel, ISTA doesn’t; in turn, ISTA deletes “lower” layer long-term trims for injectors, changing the factory’s encoding – INPA doesn’t. As already mentioned before, all these nuances can become familiar, only working and researching “behavior” of control units, documentation regarding all of this – 0.
