WO2023169731A1 - Verfahren zum prüfen von obd-relevanz eines eingangssignals - Google Patents

Verfahren zum prüfen von obd-relevanz eines eingangssignals Download PDF

Info

Publication number
WO2023169731A1
WO2023169731A1 PCT/EP2023/051717 EP2023051717W WO2023169731A1 WO 2023169731 A1 WO2023169731 A1 WO 2023169731A1 EP 2023051717 W EP2023051717 W EP 2023051717W WO 2023169731 A1 WO2023169731 A1 WO 2023169731A1
Authority
WO
WIPO (PCT)
Prior art keywords
signal
bus
input signal
obd
relevant
Prior art date
Application number
PCT/EP2023/051717
Other languages
English (en)
French (fr)
Inventor
Sebastian GRASREINER
Original Assignee
Bayerische Motoren Werke Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to CN202380014991.6A priority Critical patent/CN118369903A/zh
Publication of WO2023169731A1 publication Critical patent/WO2023169731A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/24—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using dedicated network management hardware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Definitions

  • Embodiments relate to a method for automatically checking whether an input signal from a control device for a vehicle is potentially relevant for on-board diagnosis. Based on this automatically provided result, a further, e.g. more detailed check can be carried out more easily. Further examples relate to a computer program product for carrying out the proposed method.
  • Modern motor vehicles use a large number of control devices that are connected to one another. Some signals transmitted in the vehicle electrical system can influence the vehicle's emissions. It is therefore necessary to disclose the signal properties of these signals when registering vehicles.
  • OBD on-board diagnostics
  • OBD conformity can be understood to mean that a signal is monitored in accordance with a specific legislation against a malfunction that can lead to a deterioration in emissions. Accordingly, OBD-relevant input signals are understood to be signals that must implement legally required OBD conformity.
  • OBD relevance in terms of “use of the signal” is a signal characteristic that requires monitoring. If the signals are monitored in an OBD-compliant manner (with regard to the “provision of the signal”), then the requirement matches the implementation. It is therefore helpful to have information about the OBD relevance of the existing input signals. However, obtaining this information can be very time-consuming.
  • An input signal can be a signal at the beginning of a signal chain, e.g. a bus signal (In-Bus) that is received at the control unit, a sensor signal (In-Sensor) that is received at the control unit, or an internal signal of the control unit.
  • the method includes using a signal network (eg graphical signal network or other network representation with a sufficiently high level of detail), which represents a signal flow in the control device, comprising the input signal and at least one on-board diagnosis-relevant output signal.
  • the method includes checking whether there is a signal connection between the input signal to be evaluated and the at least one on-board diagnosis-relevant signal, in particular output signal (e.g. either output signal or ECU-internal; an output signal can be a signal at the end of a signal chain, e.g. a bus signal (Out-Bus) that is output by the control unit, an actuator signal (Out-Actuator) that is output by the control unit is output, or an internal signal of the control unit itself if this is treated as the last element of the signal chain) and furthermore an indication that the input signal is potentially relevant for on-board diagnosis if there is a signal connection between the input signal and the at least there is an output signal. For example, based on this, it can be checked in an optional step (e.g. manually) whether the input signal is actually OBD-relevant.
  • output signal e.g. either output signal or ECU-internal; an output signal can be a signal at the end of a signal chain, e.g. a bus signal (
  • the method can be carried out outside the vehicle, for example in a purely virtual software environment.
  • the method does not take place using real control devices and/or sensors of the vehicle, but rather, for example, a simulated signal network is used.
  • it is not relevant what content the input signal to be checked has, but only whether it could have OBD relevance or not due to a specific signal connection.
  • it is sufficient to check the OBD relevance in a software environment (e.g. software relationships are analyzed). For this purpose, no signal content but only signal paths are analyzed and these are used to evaluate signal classes (e.g. Class I “OBD-relevant yes”; Class II “OBD-relevant no”).
  • the method can be advantageous because all input signals no longer have to be checked more closely with regard to their OBD relevance (e.g. in a manual process), but only those that are automatically displayed as potentially OBD-relevant. However, input signals that are displayed as not OBD-relevant can, for example, be ignored. This makes it much easier to carry out a test procedure, especially in highly complex systems, as there is no need to manually pre-test a large number of signal sources.
  • the input signal can be a sensor signal that is present at a signal input of the control device.
  • the input signal (or another input signal) can be a BUS signal that is present at a signal input of the control unit.
  • the at least one output signal is a signal that is output to a BUS line connected to the control device. It can be an out-bus signal or an out-act signal (actuator signal), which is available as an end point in the connection query.
  • OBD relevance the input signal is evaluated depending on the “OBD-known” output signal.
  • a large number of input signals for example several control devices, are checked for their potential OBD relevance. This enables a particularly efficient testing procedure.
  • connection matrix can be used when checking whether there is a signal connection between the input signal and the at least one on-board diagnosis-relevant output signal. Especially when testing a large number of input signals, an efficient and structured test can be carried out.
  • aspects of the disclosure also concern a control mechanism in order to be able to better classify the significance of the test result according to the procedure.
  • the test result i.e. whether an input signal is displayed as potentially OBD-relevant
  • a comparison value or reference value is checked using a comparison value or reference value.
  • the method further comprises the steps of - providing a previously determined property of the input signal with regard to its on-board diagnostic relevance (this can be done, for example, in a reference list, which is advantageously used for very large quantities of input signals in complex systems can be); - Comparing the automatically determined potentially on-board diagnosis-relevant input signal with the previously determined property; the comparison step can be carried out, for example, by comparing entries in the reference list with values determined according to the method with regard to the potential OBD relevance of the input signal; and - issuing a warning if the automatically determined potential on-board diagnostic relevance does not match the previously determined reference property of the input signal.
  • a consistency check of the test result can be carried out according to method 10.
  • values from historical documentation can be used, which can be provided in the reference list. This enables mutual checking of the procedural test results as well as, for example, the previously used attributes of the input signals.
  • the affected input signal can advantageously be specifically checked so that monitoring or validation of the method can be carried out in a focused and efficient manner.
  • the method further comprises - checking whether the input signal is sent from another control device for the vehicle as an output signal (e.g. to the signal input of the affected control device); - an automated check as to whether the output signal of the additional control unit is displayed as monitored by on-board diagnostics (e.g. the OBD conformity of the output signal of the additional control unit can be monitored); and - issuing a warning if the on-board diagnostic properties of the input signal and the output signal checked using both control devices are not consistent.
  • on-board diagnostics e.g. the OBD conformity of the output signal of the additional control unit can be monitored
  • the output signal of one control device corresponds to the input signal of the other control device.
  • the input signal is OBD-relevant
  • the output signal must also be OBD-monitored (OBD-compliant). If this is not the case, an inconsistency can be detected during the automated comparison of the OBD attributes, which causes the warning message to be issued.
  • the warning message can be issued if the input signal is displayed as OBD-relevant, but the output signal is not OBD-compliant.
  • the method can also be used to optimize the control unit: In the event that the input signal is displayed as not OBD-relevant, but the output signal is OBD-compliant, an indication can be given that the system exceeds the requirements.
  • OBD monitoring of the output signal can be dispensed with in order to make the system more efficient and cost-effective.
  • the proposed method can be advantageously used to ensure consistent handling of OBD signals throughout the system.
  • Examples relate to a computer program that includes program code to carry out a disclosed method when the computer program is executed on a processor, a computer, or programmable hardware.
  • Such a computer program can advantageously be provided and executed in the development and documentation of control devices.
  • FIG. 1 shows a flowchart of a method for determining whether an input signal from a control device is potentially OBD-relevant
  • Fig. 2 shows an example of a signal network of a control device
  • Fig. 5 shows an example of a comparison of OBD-relevant input signals with OBD information on corresponding output signals of an upstream control unit.
  • a signal network is used 11, which represents a signal flow in the control device.
  • the signal network includes at least the input signal (e.g. also several input signals) and at least one on-board diagnosis-relevant output signal (e.g. output signal or also ECU internal signal, such as DTCs OBD (MIL-On) shown in Fig. 2; or one Plurality of such output signals, see also the table in Fig. 3a).
  • DTCs OBD MIL-On
  • test procedure is therefore proposed, for example for use in a registration process for a vehicle.
  • the test procedure can in particular be carried out purely software-based.
  • the input signal can have an influence on the OBD properties of the output signal. If the input signal influences the output signal (e.g. to a certain minimum degree), then the input signal is OBD relevant. However, since not all connected input signals have to have a significant influence, a potential OBD relevance of the input signal can first be confirmed. All potentially relevant input signals can then in further steps it will be examined whether they are actually OBD-relevant or not.
  • An advantage here can be that in an automated process using the steps suggested here, a preselection can be carried out, so that, for example, significantly fewer input signals have to be checked manually with regard to their OBD relevance.
  • a signal can be evaluated with regard to its use in the signal network (e.g. source code) (e.g. where does the signal flow go when the code is later executed).
  • the content of the messages or signals is irrelevant to the proposed method.
  • An evaluation of the signals with regard to OBD relevance can be carried out for approval regardless of the signal content.
  • the process works “offline”, i.e. outside of the real vehicle. No control device, no evaluation device, no sensor is required, just code or (virtual or simulated) signal networks that reflect the code behavior.
  • Fig. 2 shows an example of a signal network 20 of a control device 21.
  • An input signal in-bus e.g. bus signal/output signal of another control device or sensor signal
  • An output signal Out-Bus is output from a signal output of the control device 21.
  • control unit 21 has an internal memory in which, for example, error codes (e.g. diagnostic trouble codes DTC) can be stored. If such an error code is stored, a warning light can be switched on by the control unit (e.g. Malfunction indicating light MIL).
  • error codes e.g. diagnostic trouble codes DTC
  • a warning light can be switched on by the control unit (e.g. Malfunction indicating light MIL).
  • MIL Malfunction indicating light MIL
  • There is a signal connection 23 between the error memory and the In-bus input signal Since the entry in the error memory has OBD relevance and there is a signal connection 23 to the In-bus input signal, the In-bus input signal is also displayed as potentially OBD-relevant for this reason ( e.g. even if the control unit does not have a signal output).
  • the connections 22 and 23 shown in FIG. 2 can occur together or individually in any combination form and lead to potential OBD relevance of the evaluated input.
  • FIG. 2 can be a or have multiple optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or with one or more embodiments described above (e.g. Fig. 1) or below (e.g. Figs. 3a-5).
  • 3a, 3b show examples of OBD relevances of various input signals of the signal network determined using a connection matrix 30.
  • the display 13 of whether the respective input signals are potentially OBD-relevant or not can be done by entries in an OBD in-bus list 31.
  • the connection matrix 30 displays exemplary signal connections between targets of the signal (Targets 1 - n) and sources of the signal (Sources 1 - m) in the signal network.
  • the output signals under consideration can be determined accordingly for the signal targets Targets 1 - n and the input signals under consideration come from the respective signal sources Sources 1 - m.
  • signal connection from signal source Source 3 only to signal destination Target n there is none at all a signal connection from the signal source source m to the signal destination target 1 - n.
  • the output signals for the signal targets Target 1 - n are all assumed to be known to be OBD-relevant and were included in the analysis of the connection matrix for precisely this reason.
  • the input signals from the signal sources Source 1 - m are only displayed as potentially OBD-relevant if there is a signal connection to at least one OBD-relevant output signal. Therefore, in this example, the input signals of all signal sources Source 1 - 3 are displayed in the list 30 as potentially OBD-relevant, while the input signal of the signal source Source m is displayed as not potentially OBD-relevant (and therefore not OBD-relevant at all).
  • source 1 has at least one connection to a target 1 - n, then source 1 is also potentially OBD relevant (Bool OR for source connection). Otherwise OBD not relevant in this query.
  • the method 10 for determining whether input signals are potentially OBD relevant can be expressed as follows:
  • Figures 3a and 3b may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or to one or more above (e.g., Figures 1-2) or below (e.g. Fig. 4-5) described embodiments are mentioned.
  • FIG. 4 shows an example 40 of a comparison 41 of OBD relevances determined according to the method with a reference list 43 for checking the consistency of the result according to the method.
  • An input list 42 generated according to the method shows whether the input signals from signal sources sensor 1 - sensor m are potentially OBD-relevant or not.
  • the reference list 43 shows whether the signals from the same signal sources sensor 1 - m are marked as OBD-checked or not according to existing data (e.g. historical documentation, developer know-how).
  • comparison step 41 the attribution of the input signals from signal source sensor 1 and sensor 2 is consistent, so that a reliable test result can be assumed. Comparison results 41a and 41b are therefore positive.
  • signal source sensor 3 is listed as not being OBD-monitored, but the test according to the method indicates that the corresponding input signal is OBD-relevant. Therefore, a comparison result 41c is output as a warning message 41c. In this case, the signal source sensor 3 can be monitored, for example to comply with regulations.
  • an OBD monitoring is displayed in the reference list 43, but the method 10, on the other hand, comes to the conclusion that the corresponding input signal is not OBD-relevant.
  • a comparison result 41d may be displayed suggesting a check.
  • this case is less critical, since in case of doubt there is simply too much OBD monitoring, which requires resources but does not have a negative impact on the Monitoring of emission-relevant functions has.
  • the result can be used to optimize the system, for example to avoid over-fulfillment of the OBD monitoring and thus increase efficiency.
  • For a correct result of comparison 41 it is necessary that the elements of signal sources and signal destinations are identical (name and number).
  • Fig. 4 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or to one or more above (e.g. Fig. 1-3b) or below (e.g. Fig. 5) described embodiments are mentioned.
  • FIG. 5 shows an example 50 of a comparison 51 of OBD-relevant input signals with OBD information on corresponding output signals of an upstream control device (e.g. whether the output signal is OBD-compliant).
  • List 53 shows which input signals of a first control unit (electronic control unit; ECU for short) X are classified as OBD-relevant.
  • Another list 52 shows which output signals of another control unit (ECU) Y are OBD-monitored.
  • the further control device Y is connected upstream of the first control device X in the signal flow. Since in this case the output signals of the further control device Y correspond to the input signals of the first control device .
  • the comparison 51 shows consistent results 51a, 5 Id.
  • the result of comparison 51 is not consistent.
  • a comparison result 51b is displayed, on the basis of which a check can take place, so that, for example, system optimization can be made possible.
  • this is displayed as potentially OBD-relevant, but the corresponding output signal on the other control unit Y is not monitored in accordance with the OBD requirements.
  • a warning message 51c is issued, which can, for example, request that OBD monitoring be continued Check control unit Y in order to obtain a consistent comparison result and thus increased security of correct OBD attribution (e.g. to meet the requirements of OBD specifications).
  • OBD monitoring be continued
  • Check control unit Y in order to obtain a consistent comparison result and thus increased security of correct OBD attribution (e.g. to meet the requirements of OBD specifications).
  • OBD attribution e.g. to meet the requirements of OBD specifications.
  • FIG. 5 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or with one or more embodiments described above (e.g. Figures 1-4) or below .
  • OBD attributes can be preassigned in the signal network.
  • Signal starting points in the signal network can be defined (sources).
  • Signal end points in the signal network can be defined (targets).
  • Connection paths between all sources and targets in the signal network can be checked (connection matrix).
  • a comparison of OBD attributes “conformity” and “relevance” can be made at crucial nodes (compliance check).
  • Examples may further provide a computer program with program code for performing one or more of the above methods when the computer program is executed on a computer or processor. Steps, operations or processes of various methods described above may be carried out by programmed computers or processors. Examples may also include program storage devices, e.g. B. digital data storage media, which are machine, processor or computer readable and encode machine-executable, processor-executable or computer-executable programs of instructions. The instructions perform or cause to be performed some or all of the steps in the procedures described above.
  • the program storage devices can e.g. B. digital storage, magnetic storage media such as magnetic disks and include or be magnetic tapes, hard disk drives or optically readable digital data storage media.
  • FIG. 1 Further examples may also include computers, processors or control units programmed to carry out the steps of the methods described above, or (field) programmable logic arrays ((F)PLAs) or (field) programmable gate arrays ((F) PGAs) programmed to perform the steps of the procedures described above.
  • a functional block that performs a specific function may refer to a circuit designed to perform a specific function.
  • a “means for something” can be implemented as a “means designed for or suitable for something”, e.g. B. a device or a circuit that is designed for or suitable for the respective task.
  • Functions of various elements shown in the figures may be in the form of dedicated hardware, e.g. B “a signal provider”, “a signal processing unit”, “a processor”, “a controller”, etc., as well as implemented as hardware capable of executing software in conjunction with associated software.
  • the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some or all of which may be shared.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • FPGA Field Programmable Gate Array
  • ROM Read Only Memory
  • RAM Random Access Memory
  • non-volatile memory device storage.
  • Other hardware conventional and/or custom, may also be included.
  • a block diagram may represent a detailed circuit diagram that implements the principles of the disclosure.
  • a flowchart, sequence diagram, state transition diagram, pseudocode, and the like can be used. represent various processes, operations or steps, for example, represented substantially in a computer-readable medium and so executed by a computer or processor, regardless of whether such computer or processor is explicitly shown.
  • Methods disclosed in the specification or claims may be implemented by an apparatus having means for carrying out each of the respective steps of these methods.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Evolutionary Computation (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computational Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Es wird ein Verfahren (10) zum automatisierten Prüfen vorgeschlagen, ob ein Eingangssignal (In-Bus) eines Steuergeräts (21) für ein Fahrzeug potentiell On-Board-Diagnose-relevant ist. Das Verfahren (10) umfasst ein Verwenden (11) eines Signalnetzwerkes, welches einen Signalfluss im Steuergerät (21) repräsentiert, umfassend das Eingangssignal (In-Bus) und zumindest ein On-Board-Diagnose-relevantes Ausgabesignal (Out-Bus). Ferner erfolgt ein Überprüfen (12), ob eine Signalverbindung (22, 23) zwischen dem Eingangssignal (In-Bus) und dem zumindest einen On-Board-Diagnose-relevanten Ausgabesignal (Out-Bus) besteht und ein Anzeigen (13), dass das Eingangssignal (In-Bus) potentiell On-Board-Diagnose-relevant ist, wenn eine Signalverbindung (22, 23) zwischen dem Eingangssignal (In-Bus) und dem zumindest einen Ausgabesignal (Out-Bus) besteht. Das Verfahren kann vorteilhaft sein, da nicht mehr alle Eingangssignale genauer geprüft werden müssen, sondern nur solche, die automatisiert als potentiell OBD-relevant angezeigt (13) werden.

Description

VERFAHREN ZUM PRÜFEN VON OBD-RELEVANZ EINES EINGANGS SIGNALS
Technisches Gebiet
Ausführungsbeispiele betreffen ein Verfahren zum automatisierten Prüfen, ob ein Eingangssignal eines Steuergeräts für ein Fahrzeug potentiell On-Board-Diagnose-relevant ist. Basierend auf diesem automatisiert bereitgestellten Ergebnis kann eine weitere, z.B. detailliertere Prüfung einfacher erfolgen. Weitere Beispiele betreffen ein Computerprogrammprodukt zum Ausführen des vorgeschlagenen Verfahrens.
Hintergrund
In modernen Kraftfahrzeugen wird eine Vielzahl an Steuergeräten eingesetzt, die miteinander verbunden sind. Einige Signale, die im Bordnetz übertragen werden, können Einfluss auf die Emissionen des Fahrzeugs haben. Daher ist bei der Zulassung von Fahrzeugen eine Offenlegung der Signaleigenschaften dieser Signale notwendig.
Im Folgenden wichtige Signaleigenschaften sind unter dem Begriff On-Board-Diagnose (OBD)-Eigenschaften zusammengefasst. Bei diesem Fahrzeugdiagnosesystem können während des Fährbetriebes die Signale abgasbeeinflussender Vorrichtungen überwacht werden. Auftretende Fehler werden dem Fahrer über eine Kontrollleuchte angezeigt und im jeweiligen Steuergerät gespeichert. Fehlermeldungen können z.B. im Fahrzeugservice abgefragt werden. Im Zulassungsprozess des Fahrzeugs ist es notwendig nachzuweisen, dass relevante Signale OBD-konform sind, d.h. dass die Überwachung dieser Signale gesetzlichen Anforderungen genügt.
Eine Schwierigkeit bei diesem Nachweis kann die enorme Komplexität von modernen Bordnetzen mit einer Vielzahl an Steuergeräten sein, die häufig von unterschiedlichen Betrieben designt und hergestellt werden. Es kann sein, dass verteilte Systeme mit tausenden interagierenden Signalen und Millionen Signalverbindungen auf ihre OBD-Konformität hin geprüft werden müssen. Folglich kann es sehr schwierig sein, in solchen komplexen Systemen nachzuweisen oder herauszufinden, welche der Eingangssignale überhaupt Einfluss auf die OBD-Kon- formität haben, also welche der Eingangssignale OBD-relevant sind. Unter dem Begriff OBD- Konformität kann verstanden werden, dass ein Signal entsprechend einer bestimmten Gesetzgebung gegenüber einer Fehlfunktion, die zu einer Emissionsverschlechterung führen kann, überwacht ist. Als OBD-relevante Eingangssignale werden dementsprechend Signale verstanden, welche eine gesetzlich geforderte OBD-Konformität umsetzen müssen. OBD Relevanz (hinsichtlich der „Verwendung des Signals“) ist eine Signaleigenschaft, die eine Überwachung erfordert. Wenn die Signale OBD-konform überwacht werden (hinsichtlich der „Zur-Verfü- gungstellung des Signals“), dann passt die Anforderung zur Implementierung. Es ist daher hilfreich, über Informationen über die OBD-Relevanz der vorhandenen Eingangssignale zu verfügen. Jedoch kann es sehr aufwändig sein, diese Informationen zu erlangen.
Zusammenfassung
Es ist eine Aufgabe der vorliegenden Offenbarung, Konzepte bereitzustellen, die auch in komplexen System eine einfachere Prüfung ermöglichen, ob ein Eingangssignal eines Steuergeräts OBD-relevant ist.
Diese Aufgabe wird gelöst gemäß den Gegenständen der unabhängigen Patentansprüche. Weitere vorteilhafte Ausführungsformen werden in den abhängigen Patentansprüchen, der folgenden Beschreibung sowie in Verbindung mit den Figuren beschrieben.
Entsprechend wird ein Verfahren zum automatisierten Prüfen in einem Zulassungsverfahren für ein Fahrzeug, ob ein Eingangssignal (oder eine Vielzahl an Eingangssignalen) eines Steuergeräts für das Fahrzeug potentiell On-Board-Diagnose-relevant ist, vorgeschlagen. Ein Eingangssignal kann ein Signal am Anfang einer Signalkette sein, z.B. ein Bus-Signal (In-Bus), das am Steuergerät empfangen wird, ein Sensorsignal (In-Sensor), das am Steuergerät empfangen wird, oder auch ein internes Signal des Steuergeräts. Das Verfahren umfasst ein Verwenden eines Signalnetzwerkes (z.B. graphisches Signalnetzwerk oder auch andere Netzwerkdarstellung mit ausreichend hohem Detailgrad), welches einen Signalfluss im Steuergerät repräsentiert, umfassend das Eingangssignal und zumindest ein On-Board-Diagnose-relevantes Ausgabesignal. Das Verfahren umfasst ein Überprüfen, ob eine Signalverbindung zwischen dem zu bewertendem Eingangssignal und dem zumindest einen On-Board-Diagnose-relevanten Signal, insbesondere Ausgabesignal (z.B. entweder Ausgangssignal oder ECU-intem; ein Ausgabesignal kann ein Signal am Ende einer Signalkette sein, z.B. ein Bus-Signal (Out-Bus), das vom Steuergerät ausgegeben wird, ein Aktuatorsignal (Out-Actuator), das vom Steuergerät ausgegeben wird, oder auch ein internes Signal des Steuergeräts selbst, wenn dieses als letztes Element der Signalkette behandelt wird) besteht und ferner ein Anzeigen, dass das Eingangssignal potentiell On-Board-Diagnose-relevant ist, wenn eine Signalverbindung zwischen dem Eingangssignal und dem zumindest einen Ausgabesignal besteht. Beispielsweise kann darauf aufbauend in einem optionalen Schritt (z.B. manuell) geprüft werden, ob das Eingangssignal auch tatsächlich OBD-relevant ist.
Das Verfahren kann außerhalb des Fahrzeugs, z.B. in einer rein virtuellen Softwareumgebung ausgeführt werden. Insbesondere ist vorgesehen, dass das Verfahren nicht unter Verwendung von realen Steuergeräten und/oder Sensoren des Fahrzeugs erfolgt, sondern z.B. ein simuliertes Signalnetzwerk verwendet wird. Es ist verfahrensgemäß nicht relevant, welchen Inhalt das zu prüfende Eingangssignal hat, sondern nur, ob dieses aufgrund einer bestimmten Signalverbindung eine OBD-Relevanz haben könnte oder nicht. Gemäß dem vorgeschlagenen Verfahren genügt es, die OBD-Relevanz in einer Softwareumgebung zu prüfen (z.B. werden Softwarezusammenhänge analysiert). Dafür werden keine Signalinhalte sondern nur Signallaufwege analysiert und diese zur Bewertung von Signalklassen (z.B. Klasse I „OBD-relevant Ja“; Klasse II „OBD-relevant Nein“) benutzt. Es sind dafür kein Sensor nötig, kein reales Steuergerät notwendig und keine Signalinhalte notwendig. Für die Zulassung eines Fahrzeugs kann es notwendig sein, nachzuweisen, welche Signale des Fahrzeugs OBD-relevant sind, was verfahrensgemäß z.B. softwarebasiert vor der Zulassung oder Inbetriebnahme des realen Fahrzeugs erfolgen kann.
Das Verfahren kann vorteilhaft sein, da nicht mehr alle Eingangssignale hinsichtlich ihrer OBD-Relevanz genauer geprüft werden müssen (z.B. in einem manuellen Prozess), sondern nur solche, die automatisiert als potentiell OBD-relevant angezeigt werden. Eingangssignale, die als nicht OBD-relevant angezeigt werden können dagegen z.B. ignoriert werden. Dadurch lässt sich vor allem in hochkomplexen System ein Prüfverfahren deutlich einfacher durchführen, da auf die manuelle Vorprüfung einer Vielzahl von Signalquellen verzichtet werden kann. Beispielsweise kann das Eingangssignal ein Sensorsignal sein, das an einem Signaleingang des Steuergeräts anliegt. Alternativ oder zusätzlich kann das Eingangssignal (oder ein weiteres Eingangssignal) ein BUS-Signal sein, das an einem Signaleingang des Steuergeräts anliegt. Beispielsweise ist das zumindest eine Ausgabesignal (oder auch eine Vielzahl von Ausgabesignalen) ein Signal, das auf eine am Steuergerät angeschlossene BUS-Leitung ausgegeben wird. Es kann sich um ein Out-Bus Signal oder auch um ein Out-Act Signal (Aktuatorsignal) handeln, welches als Endpunkt in der Verbindungsabfrage zur Verfügung steht. Bei OBD Relevanz wird das Eingangssignal bewertet in Abhängigkeit zum „OBD-bekannten“ Ausgangssignal. Vorteilhafterweise werden verfahrensgemäß eine Vielzahl an Eingangssignalen, z.B. mehrerer Steuergeräte, auf ihre potentielle OBD-Relevanz hin geprüft. So kann ein besonders effizientes Prüfverfahren ermöglicht werden.
Entsprechend werden gemäß einem Ausführungsbeispiel mehrere Eingangssignale hinsichtlich ihrer jeweiligen potentiellen On-Board-Diagnose-Relevanz geprüft, wobei das Anzeigen umfasst, welche der mehreren Eingangssignale potentiell On-Board-Diagnose-relevant sind. Optional kann beim Überprüfen, ob eine Signalverbindung zwischen dem Eingangssignal und dem zumindest einen On-Board-Diagnose-relevanten Ausgabesignal besteht, eine Verbindungsmatrix verwendet werden. Gerade im Fall des Prüfens einer Vielzahl von Eingangssignalen kann dadurch eine effiziente und strukturierte Prüfung erfolgen.
Aspekte der Offenbarung betreffen ferner einen Kontrollmechanismus, um die Aussagekraft des verfahrensgemäßen Prüfergebnisses besser einordnen zu können. Dazu wird das Prüfergebnis (d.h. ob ein Eingangssignal als potentiell OBD-relevant angezeigt wird) anhand eines Vergleichswertes oder Referenzwertes überprüft.
Gemäß einem Aspekt umfasst das Verfahren hierzu ferner die Schritte - Bereitstellen einer zuvor bestimmten Eigenschaft des Eingangssignals bezüglich seiner On-Board-Diagnose-Rele- vanz (dies kann z.B. in einer Referenzliste erfolgen, die vorteilhaft für sehr große Mengen an Eingangssignalen in komplexen Systemen verwendet werden kann); - Vergleichen des automatisiert ermittelten potentiell On-Board-Diagnose-relevanten Eingangssignals mit der zuvor bestimmten Eigenschaft; der Vergleichsschritt kann z.B. durch Vergleichen von Einträgen der Referenzliste mit verfahrensgemäß bestimmten Werten hinsichtlich der potentiellen OBD-Relevanz des Eingangssignals erfolgen; und - Ausgeben eines Warnhinweises, wenn die automatisiert ermittelte potentielle On-Board-Diagnose-Relevanz nicht mit der zuvor bestimmten Referenz-Eigenschaft des Eingangssignals übereinstimmt. Es kann mit anderen Worten eine Konsistenzprüfung des Prüfergebnisses gemäß Verfahren 10 erfolgen. Dabei kann etwa auf Werte historischer Dokumentationen zurückgegriffen werden, die in der Referenzliste bereitgestellt sein können. Dies ermöglicht ein wechselseitiges Überprüfen der verfahrensgemäßen Prüfergebnisse ebenso wie der z.B. zuvor verwendeten Attribute der Eingangssignale. Im Fall, dass ein Warnhinweis wegen erkannter Inkonsistenz der Attribute oder Werte ausgegeben wird, kann vorteilhaft konkret das betroffene Eingangssignal geprüft werden, sodass eine Überwachung bzw. Validierung des Verfahrens fokussiert und effizient erfolgen kann.
Gemäß einem weiteren Aspekt zur Konsistenzprüfung umfasst das Verfahren ferner ein - Prüfen, ob das Eingangssignal von einem weiteren Steuergerät für das Fahrzeug als Ausgangssignal versendet wird (z.B. zum Signaleingang des betroffenen Steuergerätes); - ein automatisiertes Prüfen, ob das Ausgangssignal des weiteren Steuergeräts als On- Board-Diagnose-über- wacht angezeigt wird (z.B. kann die OBD-Konformität des Ausgangssignals des weiteren Steuergerätes überwacht werden); und - ein Ausgeben eines Warnhinweises, wenn die anhand beider Steuergeräte überprüfte On-Board-Diagnose-Eigenschaft des Eingangssignals und des Ausgangssignals nicht konsistent ist.
Im Fall hintereinander gekoppelter Steuergeräte entspricht das Ausgabesignal des einen Steuergeräts dem Eingangssignal des anderen Steuergeräts. In diesem Fall muss dann, wenn das Eingangssignal OBD-relevant ist, auch das Ausgabesignal OBD-überwacht (OBD-konform) sein. Ist dies nicht der Fall, kann beim automatisierten Vergleich der OBD-Attribute eine Inkonsistenz detektiert werden, die das Ausgeben des Wamhinweises veranlasst.
Beispielsweise kann der Wamhinweis ausgegeben werden, wenn das Eingangssignal als OBD- relevant angezeigt wird, das Ausgangssignal aber nicht OBD-konform ist. Dadurch können z.B. Änderungen vorgenommen werden, um gesetzlichen Vorgaben bezüglich On-Board-Diagnose besser zu entsprechen. Beispielsweise kann das Verfahren auch zur Optimierung des Steuergerätes genutzt werden: So kann im Fall, dass das Eingangssignal als nicht OBD-relevant angezeigt wird, das Ausgangssignal aber OBD-konform ist, ein Hinweis gegeben werden, dass das System die Anforderungen übererfüllt. Hier kann z.B. auf die OBD -Überwachung des Ausgabesignals verzichtet werden, um das System effizienter und kostengünstiger zu gestalten. Gerade in hochkomplexen Systemen kann es wichtig sein, eine konsistente Behandlung der OBD-Eigenschaft der Signale durch den gesamten Signalfluss hinweg durchzuführen. Das vorgeschlagene Verfahren kann vorteilhaft verwendet werden, um die konsistente Behandlung von OBD-Signalen im gesamten System sicherzustellen.
Beispiele beziehen sich auf ein Computerprogramm, das einen Programmcode aufweist, um ein offenbartes Verfahren auszuführen, wenn das Computerprogramm auf einem Prozessor, einem Computer oder einer programmierbaren Hardware ausgeführt wird. Ein solches Computerprogramm kann vorteilhafterweise in der Entwicklung und Dokumentation von Steuergeräten bereitgestellt sein und ausgeführt werden.
Figurenkurzbeschreibung
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. 1 ein Flussdiagramm eines Verfahrens zum Bestimmen, ob ein Eingangssignal eines Steuergeräts potentiell OBD-relevant ist;
Fig. 2 ein Beispiel eines Signalnetzwerks eines Steuergerätes;
Fig. 3a, 3b Beispiele mittels einer Verbindungsmatrix ermittelter OBD-Relevanzen verschiedener Eingangssignale des Signalnetzwerks;
Fig. 4 einen beispielhaften Vergleich von verfahrensgemäß ermittelten OBD-Relevan- zen mit einer Referenzliste für Sensoren am eigenen Steuergerät; und
Fig. 5 ein Beispiel eines Vergleichs von OBD-relevanten Eingangssignalen mit OBD- Informationen zu entsprechenden Ausgangssignalen eines vorgeschalteten Steuergeräts.
Beschreibung
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein. Bei der nachfolgenden Beschreibung der beigefügten Figuren, die lediglich einige exemplarische Ausführungsbeispiele zeigen, können gleiche Bezugszeichen gleiche oder vergleichbare Komponenten bezeichnen.
Ein Element, das als mit einem anderen Element „verbunden“ oder „verkoppelt“ bezeichnet wird, mit dem anderen Element direkt verbunden oder verkoppelt sein kann oder dass dazwischenliegende Elemente vorhanden sein können. Solange nichts anderes definiert ist, haben sämtliche hierin verwendeten Begriffe (einschließlich von technischen und wissenschaftlichen Begriffen) die gleiche Bedeutung, die ihnen ein Durchschnittsfachmann auf dem Gebiet, zu dem die Ausführungsbeispiele gehören, beimisst. Die Verwendung des weiblichen Geschlechts aus Gründen der geschlechtsspezifischen Diversität schließt nicht aus, dass auch männliche Personen betroffen oder gemeint sein können. Insbesondere gilt für die gesamte Offenbarung, dass anstelle einer Nutzerin ebenso auch ein Nutzer offenbart ist.
Fig. 1 zeigt ein Flussdiagramm eines Verfahrens 10 zum Bestimmen, ob ein Eingangssignal eines Steuergeräts potentiell OBD-relevant ist. Verfahrensgemäß erfolgt ein Verwenden 11 eines Signalnetzwerkes, welches einen Signalfluss im Steuergerät repräsentiert. Das Signalnetzwerk umfasst zumindest das Eingangssignal (z.B. auch mehrere Eingangssignale) und zumindest ein On-Board-Diagnose-relevantes Ausgabesignal (z.B. Ausgangssignal oder auch ECU internes Signal, wie bspw. DTCs OBD (MIL-On) in Fig. 2 gezeigt; oder eine Mehrzahl an solchen Ausgabesignalen, s. auch die Tabelle der Fig. 3a). Es erfolgt ein Überprüfen 12, ob eine Signalverbindung zwischen dem Eingangssignal und dem zumindest einen On-Board-Diag- nose-relevanten Ausgabesignal besteht und ein Anzeigen 13, dass das Eingangssignal potentiell On-Board-Diagnose-relevant ist, im Fall, dass eine Signalverbindung zwischen dem Eingangssignal und dem zumindest einen Ausgabesignal besteht. Es wird somit ein Prüfverfahren z.B. zur Verwendung in einem Zulassungsprozess für ein Fahrzeug vorgeschlagen. Das Prüfverfahren kann insbesondere rein softwarebasiert durchgeführt werden.
Wenn eine Signalverbindung zwischen OBD -relevantem Ausgabesignal und dem Eingangssignal besteht, kann das Eingangssignal einen Einfluss auf die OBD-Eigenschaft des Ausgabesignals haben. Wenn das Eingangssignal das Ausgabesignal beeinflusst (z.B. zu einem bestimmten Mindestgrad), dann ist das Eingabesignal OBD-relevant. Da jedoch nicht alle verbundenen Eingangssignale maßgeblichen Einfluss haben müssen, kann zunächst eine potentielle OBD-Rele- vanz des Eingabesignals bestätigt werden. Alle potentiell relevanten Eingabesignale können dann in weiteren Schritten untersucht werden, ob sie tatsächlich OBD-relevant sind oder nicht. Ein Vorteil dabei kann sein, dass in einem automatisierten Verfahren mit den hier vorgeschlagenen Schritten eine Vorselektion erfolgen kann, sodass z.B. deutlich weniger Eingangssignale manuell hinsichtlich ihrer OBD-Relevanz überprüft werden müssen.
Verfahrensgemäß kann z.B. im Rahmen der Entwicklung und/oder Zulassung des Fahrzeugs ein Signal bzgl. seiner Verwendung im Signalnetzwerk (z.B. Sourcecode) bewertet werden (z.B. wohin geht der Signalfluss, wenn der Code später ausgeführt wird). Der Inhalt der Nachrichten bzw. Signale ist für das vorgeschlagene Verfahren irrelevant. Eine Bewertung der Signale bzgl. der OBD-Relevanz kann für die Zulassung unabhängig vom Signalinhalt erfolgen. Das Verfahren funktioniert „offline“, also außerhalb des realen Fahrzeugs. Es wird kein Steuergerät, kein Auswertegerät, kein Sensor benötigt, sondern nur Code bzw. (virtuelle oder simulierte) Signalnetze, die das Codeverhalten widerspiegeln.
Fig. 2 zeigt ein Beispiel eines Signalnetzwerks 20 eines Steuergerätes 21. Ein Eingangssignal In-Bus (z.B. Bus-Signal/Ausgangssignal eines anderen Steuergerätes oder auch Sensorsignal) wird an einem Eingang des Steuergeräts 21 empfangen. Ein Ausgabesignal Out-Bus wird von einem Signalausgang des Steuergerätes 21 ausgegeben.
Im gezeigten Beispiel besteht eine Signalverbindung 22 zwischen Ausgabesignal Out-Bus und Eingangssignal In-Bus. Daher wird im Fall, dass das Ausgabesignal Out-Bus OBD-relevant ist, auch das Eingabesignal In-Bus als potentiell OBD-relevant angezeigt.
Ferner verfügt das Steuergerät 21 über einen internen Speicher, in dem z.B. Fehlercodes (z.B. diagnostic trouble codes DTC) gespeichert werden können. Wenn ein solcher Fehlercode gespeichert ist, kann z.B. ein Warnlicht vom Steuergerät eingeschaltet werden (z.B. Malfunction indicating light MIL). Zwischen Fehlerspeicher und Eingangssignal In-Bus besteht eine Signalverbindung 23. Da der Eintrag des Fehlerspeichers OBD-Relevanz aufweist und eine Signalverbindung 23 zum Eingangssignal In-Bus besteht, wird verfahrensgemäß auch aus diesem Grund das Eingangssignal In-Bus als potentiell OBD-relevant angezeigt (z.B. auch, wenn das Steuergerät keinen Signalausgang aufweisen würde). Die in der Figur 2 gezeigten Verbindungen 22 und 23 können in jeder beliebigen Kombinationsform gemeinsam oder auch singulär auftreten und zu potentieller OBD-Relevanz des bewerteten Eingangs führen.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. Fig. 1) oder nachstehend (z.B. Fig. 3a-5) beschriebenen Ausführungsbeispielen erwähnt sind.
Fig. 3a, 3b zeigen Beispiele mittels einer Verbindungsmatrix 30 ermittelter OBD-Relevanzen verschiedener Eingangssignale des Signalnetzwerks. Das Anzeigen 13, ob die jeweiligen Eingangssignale potentiell OBD-relevant sind oder nicht kann durch Einträge in einer OBD In- Bus-Liste 31 erfolgen.
Die Verbindungsmatrix 30 zeigt beispielhafte Signalverbindungen zwischen Zielen des Signals (Targets 1 - n) und Quellen des Signals (Sources 1 - m) im Signalnetzwerk an. Die betrachteten Ausgabesignale können entsprechend für die Signalziele Targets 1 - n bestimmt sein und die betrachteten Eingangssignale von den jeweiligen Signal quellen Sources 1 - m kommen.
Beispielsweise besteht eine Signalverbindung von Signalquelle Source 1 nur zu Signalziel Target 1. Beispielsweise besteht eine Signalverbindung von Signalquelle Source 2 nur zu Signalzielen Target 2 und Target 3. Beispielsweise besteht eine Signalverbindung von Signal quelle Source 3 nur zu Signalziel Target n. Beispielsweise besteht gar keine eine Signalverbindung von Signal quelle Source m zu den Signalziel Target 1 - n.
Die Ausgabesignale zu den Signalzielen Target 1 - n werden alle als bekannt OBD-relevant angenommen und wurden genau aus diesem Grund in die Analyse der Connection Matrix mit einbezogen. Die Eingabesignale von den Signalquellen Source 1 - m werden nur dann als potentiell OBD-relevant angezeigt, wenn eine Signalverbindung zu zumindest einem OBD-rele- vanten Ausgabesignal besteht. Daher werden in diesem Beispiel die Eingangssignale aller Signalquellen Source 1 - 3 in der Liste 30 als potentiell OBD-relevant angezeigt, das Eingangssignal der Signalquelle Source m dagegen als nicht potentiell OBD-relevant (und damit folglich gar nicht OBD-relevant) angezeigt.
Die Attributierung erfolgt entsprechend folgendermaßen: Wenn Source 1 mindestens eine Verbindung zu einem Target 1 - n hat, dann ist Source 1 auch potentiell OBD relevant (Bool OR für Sourceverbindung). Sonst nicht OBD relevant in dieser Query. In einer Computercode-ähnlichen Ausdrucksweise kann das Verfahren 10 zum Bestimmen, ob Eingangssignale potentiell OBD-relevant sind, wie folgt ausgedrückt werden:
For every In-Bus msg: - For every Out- Actuator (OBD Monitored): -if Connection 22 exists then In-Bus msg== „OBD relevant“; End For;
- For every DTC OBD (MIL-On): if Connection 23 exists then In-Bus msg== „OBD relevant“; End For;
- If NOT In-Bus msg == „OBD relevant“ then In-Bus msg== „not OBD relevant“;
End For.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Die in Fig. 3a und 3b gezeigten Ausführungsbeispiele können ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. Fig. 1-2) oder nachstehend (z.B. Fig. 4-5) beschriebenen Ausführungsbeispielen erwähnt sind.
Fig. 4 zeigt ein Beispiel 40 eines Vergleichs 41 von verfahrensgemäß ermittelten OBD-Rele- vanzen mit einer Referenzliste 43 zur Konsistenzprüfung des verfahrensgemäßen Ergebnisses. In einer verfahrensgemäß erzeugten Input-Liste 42 wird angezeigt, ob die Eingangssignale von Signalquellen Sensor 1 - Sensor m potentiell OBD-relevant sind oder nicht. Die Referenzliste 43 zeigt an, ob gemäß bereits vorliegender Daten (z.B. historische Dokumentation, Entwickler Know-How) die Signale derselben Signalquellen Sensor 1 - m als OBD-überprüft markiert sind oder nicht.
Im Beispiel des Vergleichsschrittes 41 ist die Attributierung der Eingangssignale von Signalquelle Sensor 1 und Sensor 2 konsistent, sodass von einem sicheren Prüfergebnis ausgegangen werden kann. Vergleichsergebnisse 41a und 41b sind somit positiv. In der Referenzliste 43 wird Signalquelle Sensor 3 als nicht OBD-überwacht geführt, dagegen zeigt der verfahrensgemäße Test an, dass das entsprechende Eingangssignal OBD-relevant sei. Daher wird ein Vergleichsergebnis 41c als Wamhinweis 41c ausgegeben. In diesem Fall kann eine Überwachung der Signalquelle Sensor 3 erfolgen, etwa um Vorschriften zu genügen. Im vierten Beispiel des Sensors m wird in der Referenzliste 43 eine OBD -Überwachung angezeigt, das Verfahren 10 dagegen kommt zu dem Ergebnis, dass das entsprechende Eingangssignal nicht OBD-relevant sei. In diesem Fall kann ein Vergleichsergebnis 41d angezeigt werden, dass eine Überprüfung vorschlägt. Jedoch ist dieser Fall weniger kritisch, da im Zweifel lediglich eine OBD-Überwa- chung zu viel stattfindet, die zwar Ressourcen benötigt, aber keinen negativen Einfluss auf die Überwachung von emissionsrelevanten Funktionen hat. Das Ergebnis kann aber für eine Optimierung des Systems genutzt werden, etwa um eine Übererfüllung der OBD -Überwachung zu vermeiden und somit die Effizienz zu steigern. Für ein korrektes Ergebnis des Vergleichs 41 ist es notwendig, dass die Elemente von Signalquellen und Signalzielen identisch sind (Name und Anzahl).
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Die in Fig. 4 gezeigten Ausführungsbeispiele können ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. Fig. l-3b) oder nachstehend (z.B. Fig. 5) beschriebenen Ausführungsbeispielen erwähnt sind.
Fig. 5 zeigt ein Beispiel 50 eines Vergleichs 51 von OBD -relevanten Eingangssignalen mit OBD-Informationen zu entsprechenden Ausgangssignalen eines vorgeschalteten Steuergeräts (z.B. ob das Ausgangssignal OBD-konform ist). Liste 53 zeigt an, welche Eingangssignale eines ersten Steuergerätes (electronic control unit; kurz ECU) X als OBD-relevant eingestuft sind. Eine weitere Liste 52 zeigt an, welche Ausgangssignale eines weiteren Steuergerätes (ECU) Y OBD-überwacht sind. Das weitere Steuergerät Y ist dem ersten Steuergerät X im Signalfluss vorgeschaltet. Da in diesem Fall die Ausgangssignale des weiteren Steuergerätes Y den Eingangssignalen des ersten Steuergerätes X entsprechen, muss im Fall der korrekten verfahrensgemäßen Überprüfung das Ergebnis des Vergleichs konsistent sein (ein OBD-relevantes Eingangssignal muss auch in der Betrachtung als Ausgangssignal bekannt OBD-überwacht sein).
Bei den dargestellten Eingangssignalen Msgl und Msg m zeigt der Vergleich 51 konsistente Ergebnisse 51a, 5 Id an. Bei den Eingangssignalen Msg2 und Msg3 ist das Ergebnis des Vergleichs 51 nicht konsistent. Gemäß der Prüfung nach Verfahren 10 wird aus Sicht des ersten Steuergeräts X angezeigt, dass das Eingangssignal Msg2 nicht OBD-relevant ist, an dem zweiten Steuergerät wird es aber als OBD-überwacht behandelt. In diesem Fall wird ein Vergleichsergebnis 51b angezeigt, aufgrund dessen eine Überprüfung stattfinden kann, sodass z.B. eine Sy stem Optimierung ermöglicht werden kann. Im Fall von Eingangssignal Msg3 dagegen wird dieses als potentiell OBD-relevant angezeigt, aber das korrespondierende Ausgangssignal am weiteren Steuergerät Y nicht gemäß den OBD-Anforderungen überwacht. In Folge wird ein Wamhinweis 51c ausgegeben, der z.B. auffordem kann, die OBD -Überwachung am weiteren Steuergerät Y zu überprüfen, um ein konsistentes Vergleichsergebnis und damit erhöhte Sicherheit der korrekten OBD-Attributierung zu erlangen (z.B. um Anforderungen von OBD- Vorgaben zu erfüllen). Für ein korrektes Ergebnis des Vergleichs 51 ist es notwendig, dass die zwischen beiden Steuergeräten empfangenen/gesendeten Elemente der Listen identisch sind (Namen/ Anzahl), sodass eine Konsistenz besteht.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 5 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale aufweisen, die einem oder mehreren Aspekten entsprechen, die in Verbindung mit dem vorgeschlagenen Konzept oder mit einem oder mehreren vorstehend (z.B. Fig. 1-4) oder nachstehend beschriebenen Ausführungsbeispielen erwähnt sind.
Beispiele betreffen die Überprüfung und Ermittlung von OBD Attributen mit Hilfe von Signalnetzwerken. Die Prüfung kann mehrere Schritte umfassen: auf Basis historischer Dokumentation (z.B. manuell erzeugt) kann eine Vorbelegung von OBD Attributen im Signalnetz erfolgen. Es kann eine Festlegung von Signalstartpunkten im Signalnetz erfolgen (Sources). Es kann eine Festlegung von Signalendpunkten im Signalnetz erfolgen (Targets). Es kann eine Prüfung von Verbindungswegen zwischen allen Sources und Targets im Signalnetz erfolgen (Connection Matrix). Es kann eine BOOL-OR Vererbung der potentiellen OBD Relevanz für alle Signale flussaufwärts bei vorhandenen Verbindungen (von Target nach Source) erfolgen oder eine BOOL-AND Vererbung der OBD Konformität für alle Signale flussabwärts bei vorhandenen Verbindungen (von Source nach Target) erfolgen. Es kann ein Vergleich von OBD Attributen "Konformität" und "Relevanz" bei entscheidenden Knoten (Compliance Check) erfolgen.
Beispiele können weiterhin ein Computerprogramm mit einem Programmcode zum Ausführen eines oder mehrerer der obigen Verfahren bereitstellen, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen, oben beschriebenen Verfahren können durch programmierte Computer oder Prozessoren ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, z. B. Digitaldatenspeichermedien, abdecken, die maschinen-, prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme von Anweisungen codieren. Die Anweisungen führen einige oder alle der Schritte der oben beschriebenen Verfahren aus oder verursachen deren Ausführung. Die Programmspeichervorrichtungen können z. B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren oder Steuereinheiten, die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind, oder (feld-)programmierbare Logik-Arrays ((F)PLAs) oder (feld-)programmierbare Gate-Arrays ((F)PGAs), die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind, abdecken.
Ein als „Mittel für...“ bezeichneter Funktionsblock, der eine bestimmte Funktion ausführt, kann sich auf eine Schaltung beziehen, die zum Durchführen einer bestimmten Funktion ausgebildet ist. Somit kann ein „Mittel für etwas“ als ein „Mittel ausgebildet für oder geeignet für etwas“ implementiert sein, z. B. eine Vorrichtung oder eine Schaltung, die ausgebildet ist für oder geeignet ist für die jeweilige Aufgabe.
Funktionen verschiedener in den Figuren gezeigter Elemente einschließlich jeder als „Mittel“, „Mittel zum Bereitstellen eines Signals“, „Mittel zum Erzeugen eines Signals“, etc. bezeichneter Funktionsblöcke kann in Form dedizierter Hardware, z. B „eines Signalanbieters“, „einer Signalverarbeitungseinheit“, „eines Prozessors“, „einer Steuerung“ etc. sowie als Hardware fähig zum Ausführen von Software in Verbindung mit zugehöriger Software implementiert sein. Bei Bereitstellung durch einen Prozessor können die Funktionen durch einen einzelnen dedizierten Prozessor, durch einen einzelnen gemeinschaftlich verwendeten Prozessor oder durch eine Mehrzahl von individuellen Prozessoren bereitgestellt sein, von denen einige oder von denen alle gemeinschaftlich verwendet werden können. Allerdings ist der Begriff „Prozessor“ oder „Steuerung“ bei Weitem nicht auf ausschließlich zur Ausführung von Software fähige Hardware begrenzt, sondern kann Digitalsignalprozessor-Hardware (DSP-Hardware; DSP = Digital Signal Processor), Netzprozessor, anwendungsspezifische integrierte Schaltung (ASIC = Application Specific Integrated Circuit), feldprogrammierbares Logik-Array (FPGA = Field Programmable Gate Array), Nurlesespeicher (ROM = Read Only Memory) zum Speichern von Software, Direktzugriffsspeicher (RAM = Random Access Memory) und nichtflüchtige Speichervorrichtung (storage) umfassen. Sonstige Hardware, herkömmliche und/oder kundenspezifische, kann auch eingeschlossen sein.
Ein Blockdiagramm kann zum Beispiel ein detailliertes Schaltdiagramm darstellen, das die Grundsätze der Offenbarung implementiert. Auf ähnliche Weise können ein Flussdiagramm, ein Ablaufdiagramm, ein Zustandsübergangsdiagramm, ein Pseudocode und dergleichen ver- schiedene Prozesse, Operationen oder Schritte repräsentieren, die zum Beispiel im Wesentlichen in computerlesbarem Medium dargestellt und so durch einen Computer oder Prozessor ausgeführt werden, ungeachtet dessen, ob ein solcher Computer oder Prozessor explizit gezeigt ist. In der Beschreibung oder in den Patentansprüchen offenbarte Verfahren können durch eine Vorrichtung implementiert werden, die ein Mittel zum Ausführen eines jeden der jeweiligen Schritte dieser Verfahren aufweist.

Claims

Patentansprüche
1. Verfahren (10) zum automatisierten Prüfen in einem Zulassungsverfahren für ein Fahrzeug, ob ein Eingangssignal (In-Bus) eines Steuergeräts (21) für das Fahrzeug potentiell On-Board-Diagnose-relevant ist, das Verfahren (10) umfassend:
Verwenden (11) eines Signalnetzwerkes, welches einen Signalfluss im Steuergerät (21) repräsentiert, umfassend das Eingangssignal (In-Bus) und zumindest ein On-Board-Di- agnose-relevantes Ausgabesignal (Out-Bus);
Überprüfen (12), ob eine Signalverbindung (22, 23) zwischen dem Eingangssignal (In- Bus) und dem zumindest einen On-Board-Diagnose-relevanten Ausgabesignal (Out- Bus) besteht; und
Anzeigen (13), dass das Eingangssignal (In-Bus) potentiell On-Board-Diagnose-rele- vant ist, wenn eine Signalverbindung (22, 23) zwischen dem Eingangssignal (In-Bus) und dem zumindest einen Ausgabesignal (Out-Bus) besteht.
2. Verfahren (10) gemäß Anspruch 1, wobei das Eingangssignal (In-Bus) ein Sensorsignal ist, das an einem Signaleingang des Steuergeräts (21) anliegt.
3. Verfahren (10) gemäß Anspruch 1 oder 2, wobei das Eingangssignal (In-Bus) ein BUS-Signal ist, das an einem Signaleingang des Steuergeräts (21) anliegt.
4. Verfahren (10) gemäß einem der vorhergehenden Ansprüche 1 bis 3, wobei mehrere Eingangssignale (In -Bus) hinsichtlich ihrer jeweiligen potentiellen On- Board-Diagnose-Relevanz geprüft werden, wobei das Anzeigen (13) umfasst, welche der mehreren Eingangssignale (In-Bus) potentiell On-Board-Diagnose-relevant sind.
5. Verfahren (10) gemäß einem der vorhergehenden Ansprüche, wobei beim Überprüfen (12), ob eine Signalverbindung (22, 23) zwischen dem Eingangssignal (In-Bus) und dem zumindest einen On-Board-Diagnose-relevanten Ausgabesignal (Out-Bus) besteht, eine Verbindungsmatrix (30) verwendet wird.
6. Verfahren (10) gemäß einem der vorhergehenden Ansprüche, das Verfahren (10) ferner umfassend:
Bereitstellen einer zuvor bestimmten Eigenschaft des Eingangssignals (In-Bus) bezüglich seiner On-Board-Diagnose-Relevanz;
Vergleichen (41) des automatisiert ermittelten potentiell On-Board-Diagnose-relevan- ten Eingangssignals (In-Bus) mit der zuvor bestimmten Eigenschaft; und
Ausgeben eines Wamhinweises (41c), wenn die automatisiert ermittelte potentielle On- Board-Diagnose-Relevanz nicht mit der zuvor bestimmten Eigenschaft des Eingangssignals (In-Bus) übereinstimmt.
7. Verfahren (10) gemäß einem der vorhergehenden Ansprüche, das Verfahren (10) ferner umfassend:
Prüfen, ob das Eingangssignal (In -Bus) von einem weiteren Steuergerät für das Fahrzeug als Ausgangssignal versendet wird; automatisiertes Prüfen (51), ob das Ausgangssignal des weiteren Steuergeräts als On- Board-Diagnose-überwacht angezeigt wird; und
Ausgeben eines Warnhinweises (51c), wenn die anhand beider Steuergeräte überprüfte On-Board-Diagnose-Eigenschaft des Eingangssignals (In-Bus) und des Ausgangssignals nicht konsistent ist.
8. Ein Computerprogramm mit einem Programmcode, um das Verfahren (10) gemäß einem der vorhergehenden Ansprüche auszuführen, wenn das Computerprogramm auf einem Prozessor, einem Computer, oder einer programmierbaren Hardware aus-geführt wird.
PCT/EP2023/051717 2022-03-07 2023-01-24 Verfahren zum prüfen von obd-relevanz eines eingangssignals WO2023169731A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202380014991.6A CN118369903A (zh) 2022-03-07 2023-01-24 用于检查输入信号的obd相关性的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022105249.4A DE102022105249A1 (de) 2022-03-07 2022-03-07 Verfahren zum prüfen von obd-relevanz eines eingangssignals
DE102022105249.4 2022-03-07

Publications (1)

Publication Number Publication Date
WO2023169731A1 true WO2023169731A1 (de) 2023-09-14

Family

ID=85157292

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/051717 WO2023169731A1 (de) 2022-03-07 2023-01-24 Verfahren zum prüfen von obd-relevanz eines eingangssignals

Country Status (3)

Country Link
CN (1) CN118369903A (de)
DE (1) DE102022105249A1 (de)
WO (1) WO2023169731A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015222592A1 (de) * 2015-11-16 2017-05-18 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Bestimmung einer Wirkkette für eine Fahrzeug-Funktion
DE102018117509A1 (de) * 2018-07-19 2020-01-23 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Vorrichtung, Computerprogramm und Computerprogrammprodukt zum Überwachen einer Wirkkette eines Wirknetzes eines Fahrzeuges

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9703955B2 (en) 2014-07-17 2017-07-11 VisualThreat Inc. System and method for detecting OBD-II CAN BUS message attacks
CN207173502U (zh) 2017-08-11 2018-04-03 温州旭展电器有限公司 一种obd汽车数据显示器

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015222592A1 (de) * 2015-11-16 2017-05-18 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Bestimmung einer Wirkkette für eine Fahrzeug-Funktion
DE102018117509A1 (de) * 2018-07-19 2020-01-23 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Vorrichtung, Computerprogramm und Computerprogrammprodukt zum Überwachen einer Wirkkette eines Wirknetzes eines Fahrzeuges

Also Published As

Publication number Publication date
CN118369903A (zh) 2024-07-19
DE102022105249A1 (de) 2023-09-07

Similar Documents

Publication Publication Date Title
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
EP1751637A1 (de) Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
DE112009000439T5 (de) Fahrzeuginformationsaufzeichnungsvorrichtung, Fahrzeuginformationskommunikationssystem und Fahrzeuginformationskommunikationsverfahren
DE102008040461A1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
DE102007010978A1 (de) Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
EP2927819B1 (de) Verfahren zur automatischen verarbeitung einer anzahl von protokolldateien eines automatisierungssystems
EP2770434B1 (de) Verfahren zur Durchführung einer Inventarisierung der an ein Steuergeräte-Testsystem angeschlossenen Hardware-Komponenten
EP3907707A1 (de) Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
DE60002618T2 (de) Verfahren und Analysewerkzeug zur Fehlerortung in einem Rechner
EP2569738A1 (de) Vorrichtung zur verarbeitung von daten in einem rechnergestützten logiksystem sowie entsprechendes verfahren
WO2023169727A1 (de) Verfahren zum bestimmen von obd-konformität eines ausgabesignals
WO2018177526A1 (de) Robustheitsanalyse bei fahrzeugen
WO2023169731A1 (de) Verfahren zum prüfen von obd-relevanz eines eingangssignals
EP2652716B1 (de) Verfahren zur automatischen überwachung zumindest einer komponente eines physikalischen systems
EP1717651B1 (de) Verfahren und Vorrichtung zum Auswerten von Ereignissen aus dem Betrieb eines Fahrzeuges
DE102021114191A1 (de) Verteiltes System
DE102020124194A1 (de) Verfahren zur vorverarbeitung von fehlersignalen sowie computerprogrammprodukt
EP3929554A1 (de) Verbesserte fehlererkennung bei maschinen mittels ki
DE102019201953A1 (de) Verfahren und Detektionsvorrichtung zum Detektieren eines Eingriffs in ein Kraftfahrzeug sowie Kraftfahrzeug mit einer Detektionsvorrichtung
DE102018212801A1 (de) Diagnose komplexer Systeme
DE10038094B4 (de) Vorrichtung und Verfahren zum Generieren und Erweitern der Wissensbasis eines Expertensystems
EP3553679A1 (de) Verfahren zur computergestützten fehlerdiagnose für ein technisches system
DE102017206559A1 (de) Steuergerät und Betriebsverfahren hierfür

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23702757

Country of ref document: EP

Kind code of ref document: A1