During operation, diagnostics permanently monitors the operating states of the mechatronic system and thus represents a vehicle function in its own right. At the same time, it makes the results of its checks available to external devices if required and is thus indispensable for the vehicle manufacturer in production and the workshop. However, it is thus also part of the test methodology. For diagnostic testing, this results in a dichotomy: on the one hand, testing the diagnostics, and on the other, testing using the diagnostics.
The term "diagnostics" describes both ECU-internal algorithms, which are used to determine errors in sensors/actuators and ECU communication, and the transmission protocols to an external diagnostic tester. Both cases must be validated. For this purpose, error conditions must be created, for example, and then it must be checked whether an error is correctly detected and entered in the error memory. With regard to the protocols, transmission properties and data contents must be tested. As soon as diagnostics itself functions reliably, it serves as a testing tool. Via diagnostics it is easy to access internal variables and states in a standardized way - this is exactly what it was designed for. In this way:
The test procedures used must in turn be validated; errors in the test setup would render the entire methodology absurd. The entire test setup consisting of hardware and software must be checked. For many testers, this is by no means done only once. As a rule, new vehicles or ECU variants are integrated on an ongoing basis. The actual status must be subjected to a regression test in each case to ensure that changes do not have any effects. If we take the example of a service tester that is rolled out to 10,000 workshops, it becomes clear that errors lead to a new rollout and thus to enormous costs. This must be avoided. In both cases, experience points to a dilemma: testing the tester requires a counterpart - in diagnostics, a vehicle or ECU. However, this is usually not available. During the initial creation of a tester or test sequence, it is not yet ready, which is not surprising, since it is to be tested by the test first. In regression testing, it is usually no longer available, simply because not all vehicles can be kept in all variants. In training facilities, the picture is similar: the vehicle that fits the exercise cannot be kept in stock and can only be procured at great expense.
The solution is a simulation that recreates the ECU or vehicle in terms of diagnostic behavior. An example of such a diagnostic simulation is Softing TCS. The solution consists of three modules: