How to determine if an output signal meets the on-board diagnostics

Abstract

Several examples relate to a method (10) for determining whether at least one output signal (ob1) of a control device (21) of a vehicle is compatible with on-board diagnosis. The method (10) includes using (11) a signal network (20) representing a signal flow in the control device (21), the signal network (20) including at least one input signal (ib1, is1) and at least one output signal (ob1). Further, the method is provided for verifying (12) whether a signal coupling exists between the at least one input signal (ib1, is1) and the at least one output signal (ob1) and for verifying (13) whether the at least one input signal (ib1, is1) is compatible with on-board diagnosis. Finally, an indication (14) that the at least one output signal (ob1) is compatible with on-board diagnosis is provided when a signal coupling exists between the at least one input signal (ib1, is1) and the at least one output signal (ob1) and when the at least one input signal (ib1, is1) is compatible with on-board diagnosis.

Description

[Technical field]

[0001] An embodiment relates to a method for determining whether at least one output signal of a control device of a vehicle complies with On-Board Diagnostics (OBD), which method can be advantageously repeated to allow relatively easy analysis of highly complex systems with many control devices. Yet another embodiment relates to a computer program product for carrying out the 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 certification may be the extreme complexity of modern automotive electrical systems with numerous controllers, often designed and manufactured by different companies. It may be that a distributed system with thousands of interacting signals and millions of signal connections must be tested for its OBD compliance. As a result, in such a complex system, it may be extremely difficult to certify the OBD compliance of a given output signal of a given controller of the system. The above term OBD compliance may be understood as the signals being monitored to meet a given legislation addressing malfunctions that may lead to worsening emissions. Summary of the Invention [Problem to be solved by the invention]

[0005] An object of the present disclosure is to provide a concept that makes it relatively easy to prove that the output signal of a control device complies with OBD, even in a complex system. [Means for solving the problem]

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

[0007] A method is accordingly proposed for determining whether at least one output signal of a control device of a vehicle is compatible with on-board diagnostics (OBD). The control device may be part of a complex on-board electrical system of the vehicle. The method comprises using a signal network, e.g. a graphical signal network, which represents the signal flow to, within and out of the control device. It comprises at least one input signal and at least one output signal. Furthermore, the method comprises verifying whether there is a signal connection between the at least one input signal and the at least one output signal and verifying whether the at least one input signal is compatible with on-board diagnostics. Finally, the at least one output signal is arranged to indicate compatibility with on-board diagnostics when there is a signal connection between the at least one input signal and the at least one output signal and when the at least one input signal is compatible with on-board diagnostics. An output signal or an output signal is, for example, fully OBD-compliant only if all signals forming it are monitored with OBD compatibility. For example, multiple input signals are logically ANDed for OBD compliance - that is, the output is OBD compliant only if all input signals are monitored for OBD.

[0008] For example, at least one input signal is a sensor signal coming into a signal input of the control device, whereby the manufacturer may have readily available knowledge of the development history and type of the sensor or sensor device, and therefore it may be known whether the input signal is OBD compliant or not, and thus it may be particularly easy to determine whether the output signal is OBD compliant or not.

[0009] For example, at least one input signal is a bus signal coming to a signal input of a control device. In this case, for example, if there is knowledge of further control devices which send out the bus signal, then information may be at hand as to whether the bus signal is OBD-compliant or not. If there is no knowledge of the output signal of the further control device, the proposed method can advantageously be used again to obtain this knowledge. In other words, it can be determined whether the output signal of the further control device is OBD-compliant or not.

[0010] In a preferred embodiment, therefore, a method is proposed for iteratively analyzing a complex signal network, where at least one input signal of a control device is an output signal of a further control device, and iteratively determining whether the output signal of the further control device is compatible with the on-board diagnostics is performed, for which purpose the connection of the output signal of the further control device with the input signal of the further control device is verified and the OBD compatibility of the input signal of the further control device is verified, whereby the OBD compatibility of the output signal of the further control device can again be displayed by the proposed method.

[0011] In particularly complex systems, further output signals coming as input signals to further control devices can also be repeatedly determined whether they are compatible with the on-board diagnostics. In this way, the entire system can be investigated step by step in simple individual steps, so that the influence of all relevant signals on the investigated output signal of the control device can be determined.

[0012] According to one example, provision may be made to stop (stop / end) the repetition of the identification as soon as all currently used input signals are sensor signals only, in which case the repetition only needs to go back as far as is known for all used sensor signals, which can allow a particularly reliable answer regarding the OBD conformity of the output signal.

[0013] In another example, repeating the original sensor signal may be overkill, e.g. not necessary for identification. It may therefore be provided to stop repeating the identification if the output signal of a control device that is indirectly connected to the control device only via further control devices is indicated as being compatible with on-board diagnosis. This may be the case when all output signals from multiple control devices (which are distantly separated by two control devices (or three or more control devices) in the signal chain) are compatible with on-board diagnosis. In this case, the influence of distant signals (which may not be compatible with on-board diagnosis) on the control device under consideration may be small, so that the relevant real influence on the investigated output signal can be excluded (e.g. not necessary for the necessary certification of the OBD compatibility of the investigated output signal; e.g. when the output signal itself only has a small influence on the final vehicle emissions).

[0014] In addition to the two above-mentioned stopping criteria of the iterative method, a third stopping criterion may be used. For example, there are control devices for which no signal network is available that could be considered to be estimable. In this case, for example, all output signals can be rated as "not OBD compliant" and the iterations can be terminated, thus reflecting the worst case scenario. If the characteristics of the output signals thus determined are still satisfactory, they can be used, since the real values ​​can only be better in practice.

[0015] Furthermore, alternatively or additionally, a fourth stopping criterion can be used. For example, in complex systems, not all control units belong to a so-called OBD association (OBD-Verbund). This means that outside this association no OBD diagnostics are involved. If in the iterative signal flow a control unit that is not located in the OBD association provides an output signal, the iteration may be terminated.

[0016] The proposed stopping criteria allows to avoid overly lengthy methods for determining OBD compliance and still provide a sufficiently reliable indication of whether the output signal is OBD compliant or not.

[0017] According to one example, the signal network may comprise multiple input signals (e.g., both bus signals and sensor signals), and the at least one output signal may be indicated as being compatible with on-board diagnostics only if the entirety of the multiple input signals coupled with the at least one output signal are compatible with on-board diagnostics. This may allow for analysis of output signals from a control device with multiple inputs. For example, a control device may be analyzed that has both sensor and bus signals as input signals.

[0018] For example, the at least one output signal is a signal that is output on a bus line connected to a control device, which may be an Out-Bus signal or an Out-Act signal (actuator signal) that is evaluated.

[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] 4 is a flow chart of a method for determining whether an output signal of a control device is OBD compliant. [Diagram 2] FIG. 2 is a diagram illustrating an example of a signal network of a control device. [Diagram 3]FIG. 2 shows an example of OBD compatibility of an output signal of a signal network for various input signals determined by the method. [Figure 4] FIG. 2 shows an example of OBD compatibility of an output signal of a signal network for various input signals determined by the method. [Diagram 5] FIG. 1 illustrates an example of a network having two controllers connected via a bus. [Figure 6] FIG. 1 illustrates an example of iteratively determining OBD compatibility based on a network having three controllers. 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 output signal of a control device is OBD compliant. The method 10 comprises the use of a signal network 11 representing the signal flow in the control device. The signal network comprises at least one input signal and at least one output signal for this purpose. Furthermore, a verification 12 is performed whether there is a signal connection between the at least one input signal and the at least one output signal, and a verification 13 is performed whether the at least one input signal is compliant with the on-board diagnosis. Finally, provision is made to indicate 14 that the at least one output signal is compliant with the on-board diagnosis when there is a signal connection between the at least one input signal and the at least one output signal and when the at least one input signal is compliant with the on-board diagnosis.

[0025] The proposed method 10 may allow the evaluation of unknown signal properties. For example, depending on the known signal properties of the annotated nodes of the signal network and the signal flow paths and their directions, signal properties may need to be evaluated across multiple connected signal networks or property values ​​may need to be propagated to interfaces between multiple signal networks. Iterative procedures may then be required, which can be advantageously performed using the proposed method 10.

[0026] Method 10 may use the representation of the software (e.g., controller SW) as a graph network of signals with nodes (=signals) and edges (=connections between signals) in a unified format (e.g., a special machine-readable XML format), as well as persisting the signal network in a database using query logic (e.g., Neo4J), annotating property values ​​for specific nodes, or searching for paths between two fixed nodes in the network (possibly as serial batch processing across multiple node tuples).

[0027] Method 10 allows for detailed disclosure of signal properties (e.g., OBD properties). Determining these properties is labor intensive and highly complex, in part because all variables / signals in the software must be related to each other, since they may affect each other (often over 100,000 signals and millions of connections between them). Method 10 allows for automatic "inheritance" or passing of signal properties along the signal flow in such cases.

[0028] According to one example, there is proposed for the method 10 a computer program having a program code for causing the execution of the method 10 when the computer program is executed on a processor, a computer or programmable hardware.

[0029] 2 shows an example of a signal network 20 of a control device 21. The signal network 20 comprises a number of signal inputs, including three bus inputs InBus (e.g. for receiving input signals received via a bus or other signal lines) and three sensor inputs InSens (e.g. for receiving input signals directly received from sensors or sensor devices). Via at least one bus input InBus, it is possible to receive various signals ib1, ib2, ib3 (e.g. signals independent of each other; e.g. signals from various control devices) transmitted via a signal line (e.g. a bus connection). Via the sensor input InSens, it is possible to receive various sensor signals (e.g. signals independent of each other; e.g. signals from various sensors or sensor devices).

[0030] The control device 21 is configured to output the output signal ob1 via the signal output OutBus. According to the method described above, it is thus possible to test whether the output signal ob1 is compatible with the on-board diagnostics. For this purpose, it is checked which input signals the output signal depends on (to which input signals there is a signal connection) and whether all these involved input signals are each individually compatible with the on-board diagnostics.

[0031] A concrete example is given for evaluating the OBD-compliance of an output signal of an ECU (electronic control unit; in German elektronisches Steuergeraet). OBD-compliance means in this context that the signal is sufficiently monitored to comply with legislation addressing malfunctions that may lead to poor emissions. The transmitted bus output signal ob1 has to be evaluated. Signal ob1 is OBD-compliance only if all its inputs (i.e. signals that are connected upstream in the signal flow) are also provided OBD-compliance. Here, there are for example two types of inputs for the output signal: a) incoming In-Sens values ​​(sensor values) is1-is3; b) incoming In-Bus messages (bus messages) ib1-ib3. The sensor values ​​is1-is3 are explicitly assigned OBD properties (OBD compliant Yes / No?; y / n?), for example, but this knowledge arises as part of the development process (a sensor signal is OBD compliant only if it has been developed with the appropriate monitoring diagnostics; this can be known during the development of the sensor variables and this property can be made available as information). The incoming bus messages ib1-ib3 have implicit OBD properties (they are provided by another (placed further in the signal flow) control device as OutBus messages (e.g. output signals of further control devices in the system) and some cannot be directly examined). Therefore, the relevant bus signal (e.g. one of ib1-ib3; see also example 44 in Fig. 4) must be repeatedly re-evaluated with respect to the sensors that affect it and to the important incoming bus signals upstream in the signal flow.

[0032] It is possible to introduce two different OBD attributes that can be determined individually and are later combined into an "overall conformance". In case a), the OBD conformance of the output signal ob1 via the output OutBus depends on the input signals is1-is3 via the input InSens. For this, all connected input signals is1-is3 for ob1 are listed in a database query (so-called Connection Matrix). For each sensor of the connected input signals is1-is3, the stored OBD conformance is queried. If all connected sensors are OBD conformant (BOOL AND function), then ob1 is also OBD conformant, in particular depending on the signal received via its (input) InSens from the sensor (see also FIG. 3). In yet another case b), the OBD conformance of the OutBus output signal ob1 depends on the input signals ib1-ib3. Here, all connected signals ib1-ib3 that affect ob1 are listed in a database query. For each associated message ib1-ib3, the OBD conformance can be determined again iteratively if necessary. For this purpose, for example, the proposed method 10 can be performed for all upstream connected control devices until only the sensor as the original signal source is coupled. If all ib1-ib3 messages are finally OBD conformant (BOOL AND function), then ob1 is also OBD conformant, particularly depending on the signal received via its input InBus. Here, iteration of the method can be advantageously applied. Finally, for the signal ob1, the conformance information of the signal inputs InSens and InBus can be Boolean And combined (BOOL AND function), so that the overall conformance of the ob1 signal can be displayed.

[0033] Further specific examples of the determination by this method are shown in detail in the following figures 3 and 4. Here, an example of determining the OBD compatibility of the input signals of the sensor input InSens is shown in connection with figure 3 (bus signals are not considered here). In this case, all signal properties relevant for the OBD compatibility of the sensor signals can be known, so that the compatibility can often be determined conclusively. An example of determining the OBD compatibility of the input signals of the input InBus is shown in connection with figure 4 (sensor signals are not considered here). In this case, it may happen that not all signal properties relevant for the OBD compatibility of the bus signals are known, so that the compatibility can often not be determined conclusively as it is. In this case, the method 10 can advantageously be applied iteratively in order to be able to determine this information completely or to a sufficient extent. The OBD compatibility of the output signals of the control device in question can still be evaluated in this case by repeating the analysis incorporating several control devices.

[0034] Further details and aspects are described in conjunction with the embodiments described above or below. The embodiment shown in Fig. 2 may include one or more optional additional features corresponding to one or more aspects described in conjunction with the proposed ideas or in conjunction with one or more embodiments described above (e.g. Fig. 1) or below (e.g. Figs. 3-6). Figs. 3 and 4 show examples 30, 40 of OBD (On-Board Diagnostics) compatibility of output signal ob1 at various input signals is1, is2, is3, ib1, ib2, ib3 by the signal network 20 shown in Fig. 2.

[0035] In the first examples 31-34, only the input signals received via the input InSens are taken into account. In the first example 31, all three input signals is1-is3 are compatible with on-board diagnostics. Since all input signals coupled to the output signal ob1 are OBD-compliant, the method results in the output signal ob1 for that input sensor also being displayed as OBD-compliant (y is shown in the table instead of yes for “yes, OBD-compliant signal”). In the second example 32, one of the signals coupled to the output signal ob1, the input signal is2, is not OBD-compliant (n is shown in the table instead of no for “no, not OBD-compliant signal”), and as a result the output signal ob1 for that input sensor also being displayed as not OBD-compliant. In the third example 33, none of the input signals is1-is3 are OBD-compliant, and therefore the output signal ob1 for that input sensor also being displayed as not OBD-compliant. In the fourth example 34, there is no information about the OBD compatibility of the input signal is2 (in the table, instead of the English "not available" meaning "information about OBD compatibility is not available"). <na>Therefore, the OBD compatibility of the output signal ob1 cannot be confirmed, and it is displayed as non-compliant with OBD.

[0036] In the following examples 41-44, only the input signals received via the input InBus are taken into account. In the fifth example 41, all three input signals ib1-ib3 are compatible with on-board diagnostics. Since all input signals coupled to the output signal ob1 are OBD-compatible, the method results in the output signal ob1 being also displayed as OBD-compatible for the received bus message (y is shown in the table instead of yes for "Yes, OBD-compatible signal"). In the sixth example 42, the input signal ib2, which is one of the signals coupled to the output signal ob1, is not OBD-compatible (n is shown in the table instead of no for "No, not OBD-compatible signal"), and as a result the output signal ob1 is also displayed as not OBD-compatible for the received bus message. In the seventh example 43, none of the input signals ib1-ib3 are OBD-compatible, so the output signal ob1 cannot be displayed as OBD-compatible either.

[0037] In the eighth example 44, there is no information about the OBD compatibility of the input signal ib3 (in the table, instead of the English "not available" meaning "information about OBD compatibility is not available"). <na>is displayed). Such cases are common in the development of fragmented and complex software functions. The OBD compatibility of the output signal ob1 cannot be verified and the information "Information on OBD compatibility not available" is displayed. In this case, it is possible to carry out repeated tests which can provide information on the OBD compatibility of the signal ib3 (which can be regarded as an output signal of a control device arranged upstream of the control device 21 in the signal flow; see also e.g. Figures 5 and 6 in this regard). This can make it possible, after repeated procedures, to eventually determine the status of the OBD compatibility of the output signal ob1.

[0038] Further details and aspects are set forth in the context of the embodiments described above or below. The embodiments shown in Figures 3 and 4 may include one or more optional additional features, which correspond to one or more aspects, which are described in the context of the proposed concepts or in the context of one or more of the embodiments described above (e.g., Figures 1-2) or below (e.g., Figures 5-6).

[0039] 5 shows an example of a network 50 with two control devices 51, 52 connected via a bus 53. A second control device 52 (further control device) is arranged upstream of the first control device 51 in the signal flow. An input signal ib_target received by the first control device 51 (received at the input InBus) is transmitted by the second control device 52 via the output OutBus onto the bus 53 as an output signal ob_sender.

[0040] If, when checking whether the output signal of the first control device 51 is OBD-compliant, it is determined that no information is available about the OBD-compliance of the input signal ib_target (see also example 44 in FIG. 4), the check can be repeated from the point of view of the second control device 52 on the output signal ob_sender according to the proposed method steps.

[0041] In the example of Figure 5, since the bus signals do not change quality simply by being transmitted over the bus, the input signal ib_target can be marked as OBD compliant if the output signal ob_sender is OBD compliant, the input signal ib_target is marked as non-OBD compliant if the output signal ob_sender is OBD non-compliant, and if there is no information about whether the output signal ob_sender is OBD compliant, it is marked that no information is available about the OBD compliance of the input signal ib_target.

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

[0043] 6 shows an example 60 of iteratively determining OBD compatibility based on a network with three control devices 61, 62, 63. A first control device 61 transmits an output signal sig_ausgabe and can receive an input signal sig_eingang_1 transmitted via a bus (or other signal line) from a second (or further) control device 62 as an output signal sig_ausgang_1. The second control device 62 can itself also receive a signal (e.g. a bus signal) as an input signal sig_eingang_2, which is transmitted from a third control device 63 as yet another output signal sig_ausgang_2.

[0044] By iteratively checking the OBD compliance of the various signals in the illustrated signal network, it can be determined in a complex system whether the output signal sig_ausgabe of the first control device is also OBD compliant. Any of the transmission signals of the various control devices (e.g. the second and third control devices 62, 63) can also be considered as output signals under consideration in their own right, in the sense of the term used, rather than as output signals or further output signals. The different references in this application are intended to provide a better understanding of the iterative method.

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

[0046] 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.

[0047] A functional block referred to as a "means for" performing a certain function may 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.

[0048] 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," a "signal processing unit," a "processor," a "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 plurality 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) for storing software, random access memories (RAMs), and non-volatile memory devices (storage). Other hardware, conventional and / or custom, may also be included.

[0049] 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.< / na> < / na>

Claims

1. A method (10) for determining whether at least one output signal (ob1) of a control device (21) of a vehicle complies with on-board diagnostics, comprising: - using (11) a signal network (20) representing the signal flow within said control device (21), comprising at least one input signal (ib1, is1) and at least one said output signal (ob1); verifying (12) whether there is a signal connection between at least one of said input signals (ib1, is1) and at least one of said output signals (ob1); - verifying (13) whether at least one of said input signals (ib1, is1) complies with the on-board diagnostics, - indicating (14) that at least one of the output signals (ob1) is compliant with the on-board diagnostics when there is a signal coupling between at least one of the input signals (ib1, is1) and at least one of the output signals (ob1) and when at least one of the input signals (ib1, is1) is compliant with the on-board diagnostics or, in the case of a plurality of input signals (ib1, is1), when all of the coupled input signals (ib1, is1) are compliant with the on-board diagnostics. The method (10) comprises:

2. 10. The method (10) of claim 1, A method wherein at least one of said input signals (ib1, is1) is a sensor signal (is1) coming to a signal input (InSens) of said control device (21).

3. 10. The method (10) of claim 1, A method in which at least one of said input signals (ib1, is1) is a bus signal (ib1) coming at a signal input (InBus) of said control device (21).

4. 4. A method (10) according to any one of claims 1 to 3, comprising: The signal network (20) comprises a plurality of input signals (ib1, ib2, is1, is2), and at least one of the output signals (ob1) is indicated as conforming to on-board diagnostics only if the entire plurality of input signals (ib1, ib2, is1, is2) coupled to at least one of the output signals (ob1) conforms to on-board diagnostics.

5. 4. A method (10) according to any one of claims 1 to 3, comprising: A method in which, if at least one of the input signals (ib1, is1, sig_eingang_1) of the control device (21, 61) is an output signal (sig_ausgang_1) of a further control device (62), it is repeatedly determined whether the output signal (sig_ausgang_1) of the further control device (62) complies with on-board diagnostics.

6. 6. The method (10) of claim 5, A method in which a further output signal (sig_ausgang_2) coming as an input signal (sig_eingang_2) to said further control device (62) is further repeatedly identified as being compatible with on-board diagnostics.

7. 10. The method (10) of claim 6, A method of stopping the repeated identification as soon as all input signals (ib1, is1) used are the sensor signals (is1, is2).

8. 10. The method (10) of claim 6, A method for stopping repeated identification when the output signal (sig_ausgang_2) of a control device (63) that is indirectly connected to the control device (21, 61) only via the further control device (62) indicates that on-board diagnosis is met.

9. 4. A method (10) according to any one of claims 1 to 3, comprising: The method, wherein at least one of the output signals (ob1) is a signal output to a bus line connected to the control device (21).

10. 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