How to check the OBD relevance of input signals

Abstract

A method (10) is proposed for automatically checking whether an input signal (In-Bus) of a control device (21) of a vehicle is potentially related to on-board diagnostics. The method (10) comprises using (11) a signal network representing a signal flow in said control device (21) including an input signal (In-Bus) and an output signal (Out-Bus) related to on-board diagnostics. Furthermore, verifying (12) whether there is a signal coupling (22, 23) between the input signal (In-Bus) and at least one output signal (Out-Bus) related to on-board diagnostics, and indicating (13) that the input signal (In-Bus) is potentially related to on-board diagnostics when there is a signal coupling (22, 23) between the input signal (In-Bus) and at least one output signal (Out-Bus). This method may be advantageous since it is no longer necessary to precisely check all input signals, but instead only those input signals that are automatically indicated (13) as potentially related to OBD.

Description

[Technical field]

[0001] An embodiment relates to a method for automatically checking whether input signals of a vehicle control device are potentially relevant for on-board diagnostics, based on which an automatically provided result can for example be more easily performed for a more detailed further check. Yet another embodiment relates to a computer program product for carrying out the proposed method. [Background technology]

[0002] Modern automobiles contain many interconnected control devices. Some signals transmitted within the vehicle's electrical system may affect the vehicle's emissions. Therefore, the signal properties / attributes of these signals must be disclosed during vehicle registration.

[0003] In the following, important signal properties are grouped under the term On-Board Diagnostics (OBD) properties. This vehicle diagnostic system makes it possible to monitor the signals of devices that affect emissions while the vehicle is being driven. Any faults that occur are displayed to the driver by means of indicator lights and are stored in the respective control device. The notification of a fault can be verified, for example, at a vehicle inspection service. During the vehicle registration procedure, it is necessary to prove that the relevant signals are OBD-compliant, i.e. that the monitoring of these signals meets the legal requirements.

[0004] The difficulty of this proof may be the extreme complexity of modern automotive electrical systems with numerous control devices, often designed and manufactured by different companies. It may be that a distributed system with thousands of interacting signals and millions of signal connections has to be tested for its OBD compliance. As a result, in such a complex system, it may be extremely difficult to prove or find out which input signals have an impact on OBD compliance, i.e. which input signals are OBD relevant. The above term OBD compliance may be understood as signals being monitored to meet certain legislation addressing malfunctions that may lead to worsening emissions. Thus, OBD relevant input signals are understood as signals that necessarily achieve the legally required OBD compliance. OBD relevance (with respect to “signal use”) is a signal property that requires monitoring. If the signal is monitored OBD compliant (with respect to “signal use”), the requirement is met for implementation. Therefore, it helps if information on OBD relevance of existing input signals is available. However, obtaining this information can be quite laborious. Summary of the Invention [Problem to be solved by the invention]

[0005] The objective of the present disclosure is to provide a concept that allows easier checking whether a control device's input signals are OBD-related, even in complex systems. [Means for solving the problem]

[0006] This problem is solved by the subject matter of the independent patent claims. Further advantageous embodiments are set out in the dependent patent claims, the following description and in conjunction with the drawings.

[0007] Accordingly, a method is proposed for automatically checking whether an input signal (or a number of input signals) of a control device of a vehicle is potentially related to on-board diagnostics during the vehicle registration procedure. The input signal may be the first signal of a signal chain, e.g. an In-Bus signal received at the control device, an In-Sensor signal received at the control device or an internal signal of the control device. The method comprises using a signal network (e.g. a graphical signal network (signal graph network) or also any other network representation with a sufficiently high level of detail) representing the signal flow in the control device, including the input signal and at least one output signal related to the on-board diagnostics. The method comprises verifying whether there is a signal coupling between the input signal to be evaluated and at least one signal related to on-board diagnostics, in particular an output signal (e.g. either an output signal or an ECU internal signal; the output signal can be the last signal in the signal chain, e.g. a bus signal (Out-Bus) output from the control device, an actuator signal (Out-Actuator) output from the control device or also the internal signal of the control device itself if the signal is treated as the last element of the signal chain) and further comprising indicating that the input signal is potentially related to on-board diagnostics (the input signal may be related to on-board diagnostics) when there is a signal coupling between the input signal and the at least one output signal. In addition to this, for example an optional step (e.g. a human) can check whether the input signal is really related to OBD.

[0008] The method may be performed outside the vehicle, for example in a purely virtual software environment. In particular, the method is not performed using the real control devices and / or sensors of the vehicle, but for example in such a way that a simulated signal network is used. According to the invention, it is not important what the content of the input signals to be examined is, only whether the signals can have OBD relevance based on the identified signal concatenation. According to the proposed method, it is sufficient that the OBD relevance is examined in a software environment (for example, software relationships are analyzed). To do this, the signal content is not analyzed, but only the signal path, which is used to evaluate the classification of the signal (for example, classification I "OBD relevant"; classification II "not OBD relevant"). Therefore, no sensors are required, no real control devices are required, and no signal content is required. Where it may be necessary to prove which signals of the vehicle are OBD relevant for the registration of the vehicle, this can be done according to the invention, for example on a software basis, before the real vehicle is registered or driven.

[0009] This method may be advantageous because it is no longer necessary (e.g., in a human process) to precisely test all input signals for their OBD relevance, but only those that are automatically indicated as potentially OBD-related (possibly OBD-related), whereas input signals that are indicated as not OBD-related can, for example, be ignored. This allows the testing method to be performed significantly more simply, especially in highly complex systems, since a human pre-test of a large number of signal sources is omitted.

[0010] For example, the input signal can be a sensor signal coming to a signal input of a control device. Alternatively or additionally, the input signal (or further input signal) can be a bus signal coming to a signal input of the control device. For example, at least one output signal (or also a number of output signals) is a signal that is output to a BUS line connected to the control device. This can be an Out-Bus signal or also an Out-Act signal (actuator signal) that can be used as an end point in a connection inquiry. In the OBD relevance, the input signal is evaluated in its dependency on an "OBD known" output signal. Advantageously, according to the invention, many input signals, for example of a number of control devices, are checked for their potential OBD relevance. In this way, a particularly effective method of checking can be made possible.

[0011] According to one embodiment, the input signals are accordingly checked for their respective potential on-board diagnostic relevance, and the indication includes which of the input signals are potentially relevant for on-board diagnostics. Optionally, a connection matrix is ​​used in verifying whether signals are connected between the input signals and at least one output signal related to on-board diagnostics. This allows for an efficient and structured test, especially when many input signals are tested.

[0012] Aspects of the present disclosure also relate to a control mechanism that can facilitate determining the validity of a test result according to the present invention, whereby the test result (i.e., whether an input signal is indicated as potentially OBD related or not) is verified based on a comparison or reference value.

[0013] According to one embodiment, for this purpose the method further comprises: - providing pre-specified properties of the input signals for their on-board diagnostic relevance (this can be done, for example, in a reference list, which can be advantageously used for a fairly large amount of input signals in a complex system), - comparing the automatically determined potentially on-board diagnostics related input signals with pre-specified properties, which comparison procedure can be carried out, for example, by comparing the entries in a reference list with the potential OBD-related values ​​of the input signals identified according to the invention, - Issues a warning message when automatically determined potential on-board diagnostic relevance does not match pre-specified criteria properties of input signals It has procedures.

[0014] In other words, the method 10 allows for a check of the consistency of the test results, whereby reference can be made to values ​​in a history document and these can be presented in a reference list. This allows for a cross-validation of the test results according to the invention with, for example, previously used attributes of input signals. If a warning message is issued due to a discrepancy in attributes or values, the corresponding input signals can advantageously be specifically checked, so that the monitoring or validation of the method can be focused and efficient.

[0015] According to yet another aspect of the consistency check, the method further comprises: - checking whether the input signal is transmitted as an output signal from further control devices for the vehicle (e.g. to a signal input of the control device concerned), - automatically check whether the output signals of further control units are displayed as targets for on-board diagnostic monitoring (e.g. the OBD compliance of the output signals of further control units can be monitored), - issuing a warning message if the on-board diagnostic properties of the input and output signals, verified on the basis of both control units, do not match It has the following.

[0016] When the control devices are connected in series, the output signal of one control device corresponds to the input signal of the other control device, so that in this case, if the input signal is OBD relevant, the output signal must also be OBD monitored (OBD compliant), otherwise, during an automatic comparison of OBD attributes, a discrepancy can be detected which will trigger a warning message.

[0017] For example, if the input signals are indicated as OBD related but the output signals are not OBD compliant, a warning message can be output. This allows changes to be made, for example, to better comply with legal regulations regarding on-board diagnostics. For example, the method can also be used for control unit optimization: Thus, if the input signal is indicated as not OBD related, but the output signal is OBD compliant, it can give an indication that the system is over-fulfilling the requirements, whereby, for example, the OBD monitoring of the output signal can be omitted, making the system more efficient and cost-effective.

[0018] Indeed, in highly complex systems it can be important to enforce consistent handling of OBD properties of signals throughout the entire signal flow. The proposed method can be advantageously used to ensure consistent handling of OBD signals throughout the system.

[0019] An example relates to a computer program having a program code for performing the disclosed methods when the computer program is executed on a processor, computer or programmable hardware. Such a computer program can be advantageously provided and implemented in the development and documentation of a control device.

[0020] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. [Brief description of the drawings]

[0021] [Figure 1] FIG. 2 illustrates a flow chart of a method for identifying whether a controller input signal is potentially OBD related. [Diagram 2] FIG. 2 is a diagram illustrating an example of a signal network of a control device. [Figure 3a] FIG. 13 illustrates an example of OBD associations of various input signals of a signal network, determined using a connectivity matrix. [Figure 3b] FIG. 13 illustrates an example of OBD associations of various input signals of a signal network, determined using a connectivity matrix. [Figure 4] FIG. 10 shows an example comparison of the OBD associations determined by the method with a reference list for sensors in the specific control device. [Diagram 5] FIG. 2 shows an example of a comparison of OBD related input signals with OBD information on the corresponding output signals of an upstream control device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Various embodiments will now be described in more detail with reference to the accompanying drawings in which some embodiments are shown. In the figures, the size of regions, layers and / or line thicknesses may be exaggerated for clarity. In the following description of the accompanying drawings, which show only some illustrative embodiments, the same reference numerals may represent the same or equivalent components.

[0023] An element described as "connected" or "coupled" to another element may be directly connected or coupled to the other element, or there may be elements located between them. Unless otherwise specified, all terms (including technical and scientific terms) used herein have the same meaning as would be given to them by a person of average knowledge in the field to which the embodiment belongs. The use of the female gender due to gender-specific variability does not exclude that a man may also be applicable or intended. In particular, it is true that a male user, rather than a female user, is disclosed throughout the entire disclosure.

[0024] FIG. 1 shows a flow chart of a method 10 for identifying whether an input signal of a control device is potentially OBD related. According to this method, a signal network is used 11, which represents the signal flow in the control device. The signal network comprises at least an input signal (e.g. also a plurality of input signals) and at least one output signal related to on-board diagnostics (e.g. also an output signal or an ECU internal signal, e.g. OBD (MIL-On) of DTC as shown in FIG. 2; or a plurality of such output signals (see also table in FIG. 3a)). A signal link between the input signal and the at least one output signal related to on-board diagnostics is verified 12, and when there is a signal link between the input signal and the at least one output signal, the input signal is indicated 13 as potentially related to on-board diagnostics (may be related to on-board diagnostics). Thus, a test method for use in a vehicle registration procedure is proposed. This test method can in particular be implemented on a purely software basis.

[0025] When there is a signal coupling between an output signal and an input signal relevant for OBD, the input signal may have an influence on the OBD properties of the output signal. An input signal is OBD relevant if it influences the output signal (e.g. even to some minimal extent). However, since not all coupled input signals have a decisive influence, the potential OBD relevance of the input signals may be verified first. Then, all potentially relevant input signals may be investigated in a subsequent step whether they are really OBD relevant. The advantage in that case may be that a much reduced number of input signals need to be manually verified for their OBD relevance, since the pre-screening can be performed in an automated way according to the proposed procedure.

[0026] With this method, for example as part of the development and / or registration of a vehicle, a signal (e.g. source code) can be evaluated with respect to its use in a signal network (e.g. where the signal flow goes when the code is later executed). The content of the message or signal is not important for the proposed method. The evaluation of the signal with respect to OBD relevance can be done for registration purposes independently of the signal content. The method works "offline", i.e. outside the actual vehicle. No control device, evaluation device or sensors are required, just the code or a (virtual or simulated) signal network reflecting the behavior of the code.

[0027] 2 shows an example of a signal network 20 of a control device 21. Input signals In-Bus (e.g. bus signals / output signals of other control devices or also sensor signals) are received at the inputs of the control device 21. Output signals Out-Bus are output at signal outputs of the control device 21.

[0028] In the illustrated example, there is a signal connection 22 between the output signal Out-Bus and the input signal In-Bus, so that if the output signal Out-Bus is OBD related, then the input signal In-Bus is also potentially indicated as OBD related.

[0029] Furthermore, the control device 21 can use an internal memory in which, for example, a fault code (e.g. a diagnostic trouble code DTC) can be stored. If such a fault code is stored, for example, a warning light (e.g. a malfunction indicating light MIL) can be turned on by the control device. There is a signal connection 23 between the fault memory and the input signal In-Bus. Since the entries in the fault memory are OBD-relevant and there is a signal connection 23 to the input signal In-Bus, according to the invention, the input signal In-Bus is also indicated for this reason as potentially OBD-relevant (even if, for example, the control device does not have a signal output). The connections 22, 23 shown in FIG. 2 can appear together or alone, respectively in any combination form, which can lead to a potential OBD-relevance of the input to be evaluated.

[0030] Further details and aspects are set out in the context of the embodiments above or below in the description. The embodiment shown in Fig. 2 may comprise one or more optional additional features corresponding to one or more aspects which are set out in the context of the proposed ideas or in the context of one or more of the embodiments above (e.g. Fig. 1) or below (e.g. Figs. 3a-5) in the description.

[0031] 3a and 3b show an example of the OBD relevance of various input signals of a signal network, as determined by the connectivity matrix 30. An indication 13 of whether each input signal is potentially OBD relevant or not can be made by filling in an OBD In-Bus list 31.

[0032] The connection matrix 30 shows exemplary signal connections between signal destinations (Target 1-n) and signal sources (Source 1-m) in the signal network. The output signals of interest can be specified for the corresponding signal destinations Target 1-n, and the input signals of interest can come from the respective signal sources Source 1-m.

[0033] For example, from signal source Source 1, a signal is only connected to signal destination Target 1. For example, from signal source Source 2, a signal is only connected to signal destinations Target 2 and Target 3. For example, from signal source Source 3, a signal is only connected to signal destination Target n. For example, from signal source Source m, a signal is not connected to any signal destinations Target 1-n.

[0034] The output signals to signal destinations Target 1 to n are all assumed to be known to be OBD related and they are taken together in the analysis of the Connection Matrix for this very reason. An input signal from signal sources Source 1-m is indicated as potentially OBD related only if the signal is coupled to at least one OBD related output signal. Thus, in this example, all input signals of signal sources Source 1-3 in list 30 are indicated as potentially OBD related, while the input signal of signal source Source m is indicated as not potentially OBD related (and therefore not OBD related at all).

[0035] Attributes may be legally attached as follows: If Source 1 is connected to at least one of Targets 1 through n, then Source 1 is also potentially OBD related (the Boolean OR of the concatenation of Sources). Otherwise, it is not OBD related for this query. In a computer code-like representation, the method 10 for determining whether an input signal is potentially OBD related can be expressed as follows:

number

[0036] Further details and aspects are set out in the context of the embodiments described above or below. The embodiment shown in Figures 3a and 3b may comprise one or more optional additional features, which correspond to one or more aspects, which are described in the context of the proposed ideas or in the context of one or more of the embodiments described above (e.g. Figures 1-2) or below (e.g. Figures 4-5).

[0037] 4 shows an example 40 of a comparison 41 of the OBD relevance determined according to the invention with a reference list 43 to check the consistency of the results according to the invention. The Input list 42 generated according to the invention shows whether the input signals from the signal sources Sensor 1 to Sensor m are potentially OBD related or not. The reference list 43 shows whether the signals of the same signal sources Sensor 1 to Sensor m are marked as OBD verified or not according to existing data (e.g. history documentation, developer know-how).

[0038] In the example of the comparison procedure 41, the attribution of the input signals from the signal sources Sensor 1 and Sensor 2 is considered to be consistent and based on reliable test results. The comparison results 41a, 41b are therefore valid. The reference list 43 lists the signal source Sensor 3 as not being monitored for OBD, whereas the test according to the invention shows that the corresponding input signal is OBD-related. The comparison result 41c is therefore output as a warning message 41c. In this case, the signal source Sensor 3 can be monitored, for example to meet regulations. In the fourth example of Sensor m, the reference list 43 shows that OBD is monitored, whereas the method 10 has led to the conclusion that the corresponding input signal is not OBD-related. In this case, the comparison result 41d can be shown, which prompts verification. However, this case is not very serious, since in doubt it would only result in an extra OBD monitoring, which requires resources but has no negative impact on the monitoring of the emission-related functions. However, the results can be used to optimize the system to avoid excessive OBD monitoring and thus increase efficiency, etc. For a correct result of comparison 41, it is necessary that the elements (names and numbers) of the signal source and signal destination match.

[0039] Further details and aspects are set forth in the context of the embodiments described above or below. The embodiment shown in Fig. 4 may include one or more optional additional features corresponding to one or more aspects that are described in the context of the proposed concepts or in the context of one or more of the embodiments described above (e.g. Figs. 1-3b) or below (e.g. Fig. 5).

[0040] 5 shows an example 50 of comparing 51 an OBD related input signal with OBD information (e.g. whether the output signal is OBD compliant) for the corresponding output signal of an upstream connected control device. A list 53 shows which input signals of a first control device (electronic control unit, ECU for short) X are classified as OBD related. A further list 52 shows which output signals of a further control device (ECU) Y are subject to OBD monitoring. The further control device Y is connected upstream of the first control device X in the signal flow. In this case, the output signals of the further control device Y correspond to the input signals of the first control device X, so that the comparison must be consistent if the present invention is to perform an accurate verification (if an input signal is OBD related, it must be known that it is also subject to OBD monitoring when looking at it as an output signal).

[0041] For the illustrated input signals Msg1, Msg_m, the comparison 51 gives consistent results 51a, 51d. For the input signals Msg2, Msg3, the comparison 51 gives inconsistent results. The check according to the method 10 shows that the input signal Msg2 is not OBD-relevant from the perspective of the first control device X, whereas in the second control device it is treated as being subject to OBD monitoring. In this case, the comparison result 51b is given, on the basis of which a verification can be carried out, which can allow, for example, an optimization of the system. In contrast, in the case of the input signal Msg3, the input signal is indicated as potentially OBD-relevant, whereas the corresponding output signal is not monitored according to OBD requirements in the further control device Y. As a result, a warning message 51c is output, which can, for example, request a verification of the OBD monitoring in the further control device Y, so that a consistent comparison result is obtained and thus a correct OBD attribution can be made more reliable (for example to meet the requirements of the OBD standard). For the result of comparison 51 to be accurate, consistency is required, i.e. the elements (names / numbers) of the lists received / sent between both control devices must match.

[0042] Further details and aspects are set forth in the context of the embodiments above or in the following description. The embodiment shown in Figure 5 may include one or more optional additional features, which may correspond to one or more aspects, which may be set forth in the context of the proposed concepts or in the context of one or more of the embodiments above (e.g., Figures 1-4) or in the following description.

[0043] Examples involve the verification and validation of OBD attributes using signaling networks. The validation can include several steps: OBD attributes in the signaling network can be pre-assigned based on historical (e.g. human-created) documentation; Signal origins (Sources) in the signaling network can be defined; Signal destinations (Targets) in the signaling network can be defined; Connection paths between all Sources and Targets in the signaling network (Connection Matrix) can be validated; A BOOL-OR inheritance of potential OBD relevance for all signals going upstream in existing (Target to Source) connections can be performed or a BOOL-AND inheritance of OBD compliance for all signals going downstream in existing (Source to Target) connections can be performed. A comparison of "compliant" and "relevant" OBD attributes can be performed at critical nodes (compliance check).

[0044] Examples may further provide a computer program having a program code for performing one or more of the methods described above when the computer program is executed on a computer or processor. The steps, operations or processes of the various methods described above may be performed by a programmed computer or processor. Examples may also extend to a program storage device, e.g. a digital data storage medium, readable by a machine, a processor or a computer and encoding a program of instructions executable by a machine, a processor or a computer, which instructions perform or cause the execution of some or all of the steps of the methods described above. The program storage device may be or include, for example, a digital memory, a magnetic storage medium, e.g. a magnetic disk and magnetic tape, a hard disk drive or an optically readable digital data storage medium. Yet other examples may extend to a computer, a processor or a control unit programmed to perform the steps of the methods described above, or to a (field) programmable gate array ((F)PGA) or a (field) programmable logic array ((F)PLA) programmed to perform the steps of the methods described above.

[0045] A functional block referred to as a "means for" performing a certain function may also refer to circuitry configured to achieve the certain function. Thus, "means for" may be implemented as "means configured for or suitable for" e.g., a device or circuit configured for or suitable for the respective task.

[0046] The functions of the various illustrated elements, including functional blocks labeled "means," "means for providing a signal," "means for generating a signal," etc., may be implemented in the form of dedicated hardware, such as a "signal generator," "signal processing unit," "processor," "controller," etc., and also as hardware capable of executing software in conjunction with associated software. When provided by a processor, the functions may be provided by a single dedicated processor, a single shared processor, or a number of independent processors, some or all of which may be shared. However, the terms "processor" or "controller" are by no means limited to hardware capable of exclusively executing software, but may encompass digital signal processing (DSP) hardware (DSP=Digital Signal Processor), network processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), read only memories (ROMs), random access memories (RAMs), and non-volatile memory devices (storage) for storing software. Other hardware, conventional and / or custom, may also be included.

[0047] Block diagrams may represent, for example, detailed circuit diagrams implementing the principles of the present disclosure. Similarly, flow charts, sequence diagrams, state diagrams, pseudocode, and the like may represent various processes, operations or steps that are executed by a computer or processor, for example, substantially embodied in a computer-readable medium, whether or not such a computer or processor is explicitly shown. The methods disclosed in the specification or claims may be implemented by an apparatus comprising means for performing each of the steps of the method.

Claims

1. A method (10) for automatically checking whether input signals (In-Bus) of a control device (21) are potentially related to on-board diagnostics during a vehicle registration procedure, comprising: - using a signal network (11) representing the signal flow within said control device (21), including said input signals (In-Bus) and output signals (Out-Bus) related to on-board diagnostics, - verifying (12) whether there is a signal connection (22, 23) between said input signal (In-Bus) and at least one of said output signals (Out-Bus) related to on-board diagnostics, - indicating (13) that said input signal (In-Bus) is potentially relevant for on-board diagnostics when there is a signal connection (22, 23) between said input signal (In-Bus) and at least one of said output signals (Out-Bus); The method (10) comprises:

2. 10. The method (10) of claim 1, The input signal (In-Bus) is a sensor signal coming into a signal input of the control device (21).

3. The method (10) according to claim 1, wherein said input signal (In-Bus) is a bus signal coming to a signal input of said control device (21).

4. 4. A method (10) according to any one of claims 1 to 3, comprising: A method in which a plurality of input signals (In-Bus) are examined for their respective potential on-board diagnostic relevance, and the indication (13) includes which of the plurality of input signals (In-Bus) are potentially relevant to on-board diagnostics.

5. 4. A method (10) according to any one of claims 1 to 3, comprising: The method of the present invention, wherein a connection matrix (30) is used when verifying (12) whether there is a signal connection (22, 23) between the input signal (In-Bus) and at least one output signal (Out-Bus) related to on-board diagnostics.

6. 4. A method (10) according to any one of claims 1 to 3, comprising: - providing pre-specified properties of said input signals (In-Bus) with regard to their on-board diagnostic relevance; - comparing (41) the automatically determined input signals (In-Bus) potentially related to on-board diagnostics with the pre-specified properties; outputting a warning message (41c) if the automatically determined potential on-board diagnostic relevance does not match the pre-specified properties of the input signal (In-Bus); The method (10) further comprising:

7. 4. A method (10) according to any one of claims 1 to 3, comprising: - checking whether the input signal (In-Bus) is transmitted as an output signal from a further control device for the vehicle; - automatically checking (51) whether the output signals of the further control devices are displayed as objects of on-board diagnostic monitoring, outputting a warning message (51c) if the on-board diagnostic properties of the input signals (In-Bus) and the output signals, verified on both the control devices, do not match; The method (10) further comprising:

8. A computer program having a program code for performing the method (10) according to any one of claims 1 to 3 when the computer program is run on a processor, a computer or programmable hardware.

Images