SIGNALS

Technisches Gebiet

Ausführungsbeispiele betreffen ein Verfahren zum Bestimmen, ob zumindest ein Ausgabesignal eines Steuergerätes eines Fahrzeugs On-Board-Diagnose (OBD)-konform ist. Das Verfahren kann vorteilhaft iterativ eingesetzt werden, um hochkomplexe Systeme mit vielen Steuergeräten einfacher analysieren zu können. Weitere Beispiele betreffen ein Computerprogrammprodukt zum Ausfuhren des 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, ob ein bestimmtes Ausgabesignal eines bestimmten Steuergeräts des Systems OBD-konform ist oder nicht. 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.

Zusammenfassung

Es ist eine Aufgabe der vorliegenden Offenbarung, Konzepte bereitzustellen, die auch in komplexen System einen einfacheren Nachweis ermöglichen, dass ein Ausgabesignal eines Steuergeräts OBD-konform 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 Bestimmen, ob zumindest ein Ausgabesignal eines Steuergerätes eines Fahrzeugs On-Board-Diagnose (OBD)-konform ist, vorgeschlagen. Das Steuergerät kann Teil eines komplexen Bordnetzes des Fahrzeugs sein. Das Verfahren umfasst ein Verwenden eines Signalnetzwerkes, z.B. eines graphischen Signalnetzwerks, welches einen Signalfluss hin zum Steuergerät, innerhalb des Steuergeräts, und weg vom Steuergerät repräsentiert. Es ist umfassend zumindest ein Eingangssignal und das zumindest eine Ausgabesignal. Ferner umfasst das Verfahren ein Überprüfen, ob eine Signalverbindung zwischen dem zumindest einen Eingangssignal und dem zumindest einem Ausgabesignal besteht sowie ein Überprüfen, ob das zumindest eine Eingangssignal On-Board-Diagnose-konform ist. Schließlich ist vorgesehen anzuzeigen, dass das zumindest eine Ausgabesignal On-Board-Diagnose- konform ist, wenn eine Signalverbindung zwischen dem zumindest einen Eingangssignal und dem zumindest einem Ausgabesignal besteht und wenn das zumindest eine Eingangssignal On- Board-Diagnose-konform ist. Das Ausgangs- oder Ausgabesignal ist etwa nur dann vollständig OBD konform, wenn alle Signale zu seiner Bildung OBD konform überwacht wurden. Es handelt sich z.B. bei mehreren Eingangssignalen um eine UND-Verknüpfung der OBD Konformität - nur wenn alle OBD überwacht sind, so ist der Ausgang OBD konform.

Beispielsweise ist das zumindest eine Eingangssignal ein Sensorsignal, das an einem Signaleingang des Steuergeräts anliegt. Im Fall von Sensorsignalen kann bekannt sein, ob das Eingangssignal OBD-konform ist oder nicht, da ein unmittelbares Wissen über die Entwicklung und Art des Sensors oder der verwendeten Sensoreinrichtung beim Hersteller bestehen kann. Somit kann es besonders einfach sein zu ermitteln, ob das Ausgabesignal OBD-konform ist oder nicht.

Beispielsweise ist das zumindest eine Eingangssignal ein BUS-Signal, das an einem Signaleingang des Steuergeräts anliegt. In diesem Fall kann eine Information vorhanden sein, ob das BUS-Signal OBD-konform ist, z.B. wenn Kenntnis über ein das BUS-Signal aussendendes weiteres Steuergerät besteht. Falls keine Kenntnis über das Ausgangssignal des weiteren Steuergerätes besteht, kann das vorgeschlagene Verfahren vorteilhafterweise wiederum verwendet werden, um diese Kenntnis zu erlangen. Mit anderen Worten kann bestimmt werden, ob das Ausgangssignal des weiteren Steuergerätes OBD-konform ist oder nicht.

Dementsprechend wird in einem bevorzugten Beispiel ein iteratives Verfahren zum Analysieren eines komplexen Signalnetzwerks vorgeschlagen. Im Fall, dass das zumindest eine Eingangssignal des Steuergerätes ein Ausgangssignal eines weiteren Steuergeräts ist, erfolgt dann ein iteratives Bestimmen, ob das Ausgangssignal des weiteren Steuergeräts On-Board-Diag- nose-konform ist. Dafür können die Verbindungen des Ausgangssignals des weiteren Steuergeräts mit Eingangssignalen des weiteren Steuergeräts überprüft werden und die OBD-Konfor- mität der Eingangssignale des weiteren Steuergeräts überprüft werden. Die OBD-Konformität des Ausgangssignals des weiteren Steuergeräts kann dann wiederum gemäß dem hier vorgeschlagenen Verfahren angezeigt werden.

In besonders komplexen Systemen kann weiterhin iterativ bestimmt werden, ob auch ein weiteres Ausgangssignal, das als Eingangssignal am weiteren Steuergerät anliegt, On-Board-Diag- nose-konform ist. Auf diese Weise kann sukzessive in einfachen Einzelschritten das gesamte System untersucht werden, sodass der Einfluss aller relevanten Signale auf das zu untersuchende Ausgabesignal des Steuergeräts bestimmt werden kann.

Gemäß einem Beispiel kann vorgesehen sein, dass das iterative Bestimmen abgebrochen wird, sobald alle dabei verwendeten Eingangssignale ausschließlich Sensorsignale sind. In diesem Fall kann die Iteration soweit zurückgehen, bis Kenntnis über alle verwendeten Sensorsignale besteht. Dies kann eine besonders zuverlässige Auskunft über die OBD-Konformität des Ausgabesignals ermöglichen.

In anderen Beispielen kann eine Iteration bis zu ursprünglichen Sensorsignalen zu umfangreich sein und z.B. für die Bestimmung nicht erforderlich sein. Daher kann auch vorgesehen sein, dass das iterative Bestimmen abgebrochen wird, sobald ein Ausgangssignal eines Steuergerätes, das nur über das weitere Steuergerät mittelbar mit dem Steuergerät verbunden ist, On- Board-Diagnose-konform angezeigt wird. Dies kann der Fall sein, wenn alle Ausgangssignale von Steuergeräten, die in der Signalkette zwei Steuergeräte (oder drei oder mehr Steuergeräte) weit entfernt sind, On-Board-Diagnose-konform sind. In diesem Fall kann der Einfluss weiter entfernter Signale (die evtl, nicht On-Board-Diagnose-konform sind) auf das zu betrachtende Steuergerät derart gering sein, dass relevante, tatsächliche Auswirkungen auf das zu untersuchende Ausgabesignal ausgeschlossen werden können (z.B. nicht notwendig für den geforderten Nachweis der OBD -Konformität des zu untersuchenden Ausgabesignals; z.B. wenn das Ausgabesignal selbst nur einen geringen Einfluss auf die resultierende Emission des Fahrzeugs hat).

Neben den zwei beschriebenen Abbruchkriterien des iterativen Verfahrens kann ein drittes Abbruchkriterium verwendet werden. Beispielsweise gibt es Steuergeräte, die über kein Signalnetzwerk verfügen, welches ausgewertet werden könnte. In diesem Falle kann man z.B. die Ausgangssignale alle mit „nicht-OBD-konform“ bewerten und die Iteration beenden. Dadurch kann ein worst-case Fall abgebildet werden. Wenn die derart bestimmte Eigenschaft des Ausgabesignals noch zufriedenstellend ist, kann sie verwendet werden, da in der Praxis der tatsächliche Wert nur besser sein kann.

Ferner kann alternativ oder zusätzlich ein viertes Abbruchkriterium verwendet werden. Beispielsweise zählt in einem komplexen System nicht jedes Steuergerät zum sogenannten OBD- Verbund. Das heißt, dass außerhalb dieses Verbundes keine OBD-Diagnose partitioniert ist. Sollte im iterativen Signalfluss ein Steuergerät, welches nicht im OBD-Verbund positioniert ist, ein Ausgangssignal zur Verfügung stellen, dann kann die Iteration beendet werden.

Durch die vorgeschlagenen Abbruchkriterien kann ein übermäßig langes Verfahren für das Bestimmen der OBD -Konformität vermieden werden und dennoch genügend sicher angezeigt werden, ob das Ausgabesignal OBD-konform ist oder nicht.

Gemäß einem Beispiel kann das Signalnetzwerk eine Mehrzahl an Eingangssignalen (z.B. sowohl BUS-Signale als auch Sensorsignale) aufweisen und das zumindest eine Ausgabesignal wird nur in dem Fall als On-Board-Diagnose-konform angezeigt, wenn die gesamte Mehrzahl der mit dem zumindest einen Ausgangssignal verbundenen Eingangssignale On-Board-Diag- nose-konform ist. Dies kann es ermöglichen, Ausgabesignale von Steuergeräten mit mehreren Eingängen zu analysieren. Beispielsweise können Steuergeräte mit Sensor- als auch Bus-Signalen als Eingangssignale analysiert werden.

Beispielsweise ist das zumindest eine Ausgabesignal 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 bewertet wird.

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 Ausgabesignal eines Steuergeräts OBD-konform ist;

Fig. 2 ein Beispiel eines Signalnetzwerks eines Steuergerätes;

Fig. 3 und 4 Beispiele von verfahrensgemäß ermittelten OBD-Konformitäten eines Ausgabesignals des Signalnetzwerks bei verschiedenen Eingangssignalen;

Fig. 5 ein Beispiel eines Netzwerks mit zwei über einen BUS verbundenen Steuergeräten; und

Fig. 6 ein Beispiel einer iterativen Bestimmung von OBD-Konformität anhand eines Netzwerks mit drei Steuergeräten. 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 Ausgabesignal eines Steuergeräts OBD-konform ist. Das Verfahren 10 umfasst ein Verwenden 11 eines Signalnetzwerkes, welches einen Signalfluss im Steuergerät repräsentiert. Das Signalnetzwerk umfasst dafür zumindest ein Eingangssignal und das zumindest eine Ausgabesignal. Ferner erfolgt ein Überprüfen 12, ob eine Signalverbindung zwischen dem zumindest einen Eingangssignal und dem zumindest einem Ausgabesignal besteht sowie ein Überprüfen 13, ob das zumindest eine Eingangssignal On-Board-Diagnose-konform ist. Schließlich ist ein Anzeigen 14 vorgesehen, dass das zumindest eine Ausgabesignal On-Board-Diagnose-konform ist, wenn eine Signalverbindung zwischen dem zumindest einen Eingangssignal und dem zumindest einem Ausgabesignal besteht und wenn das zumindest eine Eingangssignal On-Board-Diagnose-konform ist.

Durch das vorgeschlagene Verfahren 10 kann eine Bewertung von unbekannten Signal eigen- schaften ermöglicht werden. Beispielsweise kann in Abhängigkeit von Signalflusswegen und deren Richtung sowie bekannten Signaleigenschaften von annotierten Knoten des Signalnetzwerks eine Bewertung der Signaleigenschaften über mehrere verbundene Signalnetzwerke hinweg notwendig sein oder an Schnittstellen zwischen mehreren Signalnetzwerken eine Übergabe von Eigenschaftswerten notwendig sein. Dabei kann ein iteratives Vorgehen erforderlich sein, welches unter Verwendung des vorgeschlagenen Verfahrens 10 vorteilhafterweise durchgeführt werden kann.

Das Verfahren 10 kann eine Repräsentation von Software (z.B. Steuergeräte- SW) als grafische Signalnetzwerke mit Knoten (=Signal) und Kanten (Verbindungen zw. Signalen) in einem einheitlichen Format (bspw. spezielle maschinenlesbare XML Formate) nutzen. Ebenso kann Datenhaltung von Signalnetzwerken in Datenbanken mit Abfragelogik (bspw. Neo4J), Annotation von Eigenschaftswerten zu bestimmten Knoten, oder Suche von Pfaden zwischen zwei festgelegten Knoten im Netzwerk (auch als serielle Stapelverarbeitung zw. mehreren Kno- tentupeln möglich) genutzt werden.

Durch Einsatz des Verfahrens 10 kann eine detaillierte Offenlegung von Signal eigenschaften stattfinden (z.B. OBD Eigenschaften). Die Ermittlung dieser Eigenschaften ist teils mit großem Aufwand und hoher Komplexität verbunden, da alle Signale/Variablen einer Software in Zusammenhang miteinander gestellt werden müssen, denn sie können sich gegenseitig beeinflussen (häufig mehr als 100.000 Signale und mehrere Mio. Verbindungen dazwischen). Durch das Verfahren 10 kann eine "Vererbung" oder Weitergabe von Signaleigenschaften entlang der Signalflüsse in solchen Fällen automatisiert erfolgen.

Gemäß einem Beispiel wird zum Verfahren 10 auch ein Computerprogramm mit einem Programmcode vorgeschlagen, um das Verfahren 10 auszuführen, wenn das Computerprogramm auf einem Prozessor, einem Computer, oder einer programmierbaren Hardware ausgeführt wird.

Fig. 2 zeigt ein Beispiel eines Signalnetzwerks 20 eines Steuergerätes 21. Das Signalnetzwerk 20 weist mehrere Signaleingänge auf, drei Bus-Eingänge InBus (z.B. zum Empfangen für über einen Bus oder eine andere Signalleitung empfangene Eingangssignale) und drei Sensor-Eingänge InSens (z.B. zum Empfangen für direkt von Sensoren oder Sensoreinrichtungen empfangene Eingangssignale). Über den zumindest einen Bus-Eingang InBus können etwa verschiedene über eine Signalleitung (z.B. Bus-Verbindung) gesendete Signale ibl, ib2 und ib3 empfangen werden (z.B. voneinander unabhängige Signale; z.B. von verschiedenen Steuergeräten). Über den Sensor-Eingang InSens können etwa verschiedene Sensorsignale empfangen werden (z.B. voneinander unabhängige Signale; z.B. von verschiedenen Sensoren oder Sensoreinrichtungen). Das Steuergerät 21 ist ausgebildet, ein Ausgabesignal obl über einen Signalausgang OutBus auszugeben. Gemäß dem oben beschriebenen Verfahren ist es nun möglich, zu testen, ob das Ausgabesignal obl On-Board-Diagnose-konform ist oder nicht. Dazu wird geprüft, von welchen Eingangssignalen das Ausgabesignal abhängig ist (zu welchen Eingangssignalen eine Signalverbindung besteht) und ob all diese relevanten Eingangssignale jeweils für sich On-Board- Diagnose-konform sind.

Es wird ein konkretes Beispiel zur Bewertung von OBD Konformität eines ECU (electronic control unit; deutsch: elektronisches Steuergerät)- Ausgangs- Signals beschrieben. OBD konform bedeutet hier, dass ein Signal entsprechend der Gesetzgebung ausreichend überwacht ist gegenüber einer Fehlfunktion, die zu einer Emissionsverschlechterung führen kann. Das versendete Bus- Ausgabesignal obl soll bewertet werden. OBD-konform ist das Signal obl nur dann, wenn alle seine Inputs (d.h. verbundene Signale im Signalfluss aufwärts) auch OBD- konform zur Verfügung gestellt werden. Hier gibt es z.B. zwei Arten von Inputs für das Ausgabesignal: a) einkommende In-Sensorwerte isl -is3; und b) einkommende In-Busnachrichten ib 1 -ib3. Sensorwerte is 1 -is3 haben z.B. eine direkte OBD-Eigenschaft zugewiesen (OBD-konform ja/nein?; y/n?), dieses Wissen entsteht im Rahmen des Entwicklungsprozesses (OBD- konform ist ein Sensorsignal nur dann, wenn es mit entsprechenden Überwachungsdiagnosen entwickelt wurde; dies kann bei der Entwicklung der Sensorgröße bekannt sein und diese Eigenschaft kann als Information zur Verfügung gestellt sein). Einkommende Busnachrichten ibl-ib3 haben eine indirekte OBD-Eigenschaft (sie werden von einem anderen Steuergerät - im Signalfluss vorher angeordnet - als Out-Busnachricht (z.B. Ausgangssignal eines weiteren Steuergeräts des Systems) zur Verfügung gestellt und sind teils nicht direkt einsehbar). Deswegen muss eine iterative Neubewertung des relevanten Bussignals (z.B. eines von ib 1 -ib3 ; siehe auch Beispiel 44 in Fig. 4) bzgl. seiner einfließenden Sensoren und signalflussaufwärts gelegenen eingehenden Bussignale erfolgen.

Es können zwei verschiedene OBD-Attribute eingeführt werden, die einzeln zu ermitteln sind und im Nachhinein zu einer "Gesamtkonformität" kombiniert werden. Im einen Fall a) besteht für die OBD-Konformität des über den Ausgang OutBus ausgegebenen Ausgabesignals obl Abhängigkeit von den Eingangssignalen is 1 -is3 über Eingang InSens. Dafür werden alle angebundenen Eingangssignale is 1 -is3 für obl aufgelistet in einer Datenbank Abfrage (sog. Connection Matrix oder Verbindungsmatrix). Für jeden angebundenen Sensor der Eingangssignale is 1 - is3 wird die hinterlegte OBD-Konformität abgefragt. Wenn alle verbundenen Sensoren OBD- konform sind (BOOL AND -Funkti on), dann ist obl in Abhängigkeit der spezifisch über seine von Sensoren (via Eingang) InSens empfangenen Signale auch OBD konform (s. auch Fig. 3). Im weiteren Fall b) besteht für die OBD -Konformität des OutBus Ausgabesignals obl Abhängigkeit von den Eingangssignalen ib 1 -ib3. Hier werden alle angebundenen Signale ib 1 -ib3 , die Einfluss auf obl haben, aufgelistet in einer Datenbank Abfrage. Für jede angebundene Nachricht ib l-ib3 kann bei Bedarf die OBD-Konformität iterativ neu ermittelt werden. Dazu kann beispielweise das vorgeschlagene Verfahren 10 auf alle vorgeschalteten Steuergeräten solange durchgeführt werden, bis nur noch Sensoren als Ursprungsquelle des Signals angebunden sind. Wenn alle ib 1 -ib3 Nachrichten letztendlich OBD konform sind (BOOL AND-Funktion), dann ist obl in Abhängigkeit der spezifisch über seinen Eingang InBus empfangenen Signale auch OBD-konform. Hier ist das iterative Verfahren vorteilhaft anwendbar. Am Ende können für das Signal obl die Konformitäts-Informationen von den Signal eingängen InSens und InBus Boolesch AND-verknüpft werden (BOOL AND-Funktion) und somit die Gesamtkonformität des obl Signals angezeigt werden.

Weitere konkrete Beispiele zu dieser verfahrensgemäßen Bestimmung sind in den folgenden Figuren 3 und 4 detailliert dargestellt. Dabei ist in Verbindung mit Fig. 3 ein Beispiel über das Bestimmen der OBD-Konformität der Eingangssignale des Sensor-Eingangs InSens dargestellt (Bus-Signale sind hierbei ignoriert). Hier kann die Konformität mitunter abschließend bestimmt werden, da alle Signaleigenschaften hinsichtlich OBD-Konformität von Sensorsignalen bekannt sein können. In Verbindung mit Fig. 4 ist ein Beispiel über das Bestimmen der OBD- Konformität der Eingangssignale des Eingangs InBus dargestellt (Sensor-Signale sind hierbei ignoriert). Hier kann die Konformität mitunter nicht direkt abschließend bestimmt werden, da es vorkommen kann, dass nicht alle Signaleigenschaften hinsichtlich OBD-Konformität von Bussignalen bekannt sind. In diesem Fall kann vorteilhafterweise das Verfahren 10 iterativ angewendet werden, um diese Informationen ganz oder in genügendem Maße bestimmen zu können. Durch eine iterative Analyse, die mehrere Steuergeräte einbezieht, kann in diesem Fall die OBD-Konformität des Ausgabesignals des betrachteten Steuergerätes dennoch bewertet werden.

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. 3-6) beschriebenen Ausführungsbeispielen erwähnt sind. Fig. 3 und 4 zeigen Beispiele 30, 40 von OBD (On-Board-Diagnose)-Konformitäten eines Ausgabesignals obl bei verschiedenen Eingangssignalen isl, is2, is3, ibl, ib2, ib3 gemäß dem in Fig. 2 dargestellten Signalnetzwerk 20.

In ersten Beispielen 31-34 werden nur die Eingangssignale, die über den Eingang InSens empfangen werden betrachtet. Im ersten Beispiel 31 sind alle der drei Eingangssignale isl -is3 On- Board-Diagnose-konform. Entsprechend sind alle mit dem Ausgabesignal obl verbundenen Eingangssignale OBD-konform, sodass verfahrensgemäß auch das Ausgabesignal obl als OBD-konform gegenüber seiner Eingangssensoren angezeigt wird (in der Tabelle steht y für engl. yes i.S.v. „ja, OBD-konformes Signal“). Im zweiten Beispiel 32 ist das Eingangssignal is2 als eines der mit Ausgabesignal obl verbundenen Signale nicht OBD-konform (in der Tabelle mit n für engl. no i.S.v. „nein, nicht OBD-konformes Signal“ dargestellt), sodass im Ergebnis auch das Ausgabesignal obl als nicht OBD-konform gegenüber seiner Eingangssensoren angezeigt wird. Im dritten Beispiel 33 ist keines der Eingangssignal isl-is3 OBD-konform, sodass auch das Ausgabesignal obl nicht als OBD-konform angezeigt werden kann. In einem vierten Beispiel 34 besteht keine Auskunft über die OBD-Konformität des Eingangssignals is2 (in der Tabelle mit <na> für engl. not available i.S.v. „keine Information bzgl. OBD-Konfor- mität verfügbar“ dargestellt). Somit kann die OBD-Konformität des Ausgabesignals obl nicht bestätigt werden und es wird als nicht OBD-konform angezeigt.

In weiteren Beispielen 41-44 werden nur die Eingangssignale, die über den Eingang InBus empfangen werden betrachtet. Im fünften Beispiel 41 sind alle der drei Eingangssignale ibl- ib3 On-Board-Diagnose-konform. Entsprechend sind alle mit dem Ausgabesignal obl verbundenen Eingangssignale OBD-konform, sodass verfahrensgemäß auch das Ausgabesignal obl als OBD-konform gegenüber seiner empfangenen Busnachrichten angezeigt wird (in der Tabelle steht y für engl. yes i.S.v. „ja, OBD-konformes Signal“). Im sechsten Beispiel 42 ist das Eingangssignal ib2 als eines der mit Ausgabesignal obl verbundenen Signale nicht OBD-konform (in der Tabelle mit n für engl. no i.S.v. „nein, nicht OBD-konformes Signal“ dargestellt), sodass im Ergebnis auch das Ausgabesignal obl als nicht OBD-konform gegenüber seiner empfangenen Busnachrichten angezeigt wird. Im siebten Beispiel 43 ist keines der Eingangssignal ibl-ib3 OBD-konform, sodass auch das Ausgabesignal obl nicht als OBD-konform angezeigt werden kann.

In einem achten Beispiel 44 besteht keine Auskunft über die OBD-Konformität des Eingangssignals ib3 (in der Tabelle mit <na> für engl. not available i.S.v. „keine Information bzgl. OBD- Konformität verfügbar“ dargestellt). Dieser Fall kommt üblicherweise in der Entwicklung von komplexen verteilten Softwarefunktionen vor. Somit kann die OBD-Konformität des Ausgabesignals obl nicht bestätigt werden und es wird die Information „keine Information bzgl. OBD- Konformität verfügbar“ angezeigt. In diesem Fall kann ein iterativer Test erfolgen, der Auskunft über die OBD-Konformität des Signals ib3 bringen kann (gesehen als Ausgangssignal eines im Signalfluss vor dem Steuergerät 21 positionierten Steuergerätes; s. dazu z.B. auch Fig. 5 und 6). Dadurch kann ermöglicht werden, nach dem iterativen Schritt doch den Status bzgl. OBD-Konformität des Ausgabesignals obl zu bestimmen.

Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Die in Fig. 3 und 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. 1-2) oder nachstehend (z.B. Fig. 5-6) beschriebenen Ausführungsbeispielen erwähnt sind.

Fig. 5 zeigt ein Beispiel eines Netzwerks 50 mit zwei über einen BUS 53 verbundenen Steuergeräten 51, 52. Das zweite Steuergerät 52 (weiteres Steuergerät) ist im Signalfluss aufwärts vor dem ersten Steuergerät 51 angeordnet. Ein am ersten Steuergerät 51 empfangenes Eingangssignal ib target, das am Eingang InBus empfangen wird, wird vom zweiten Steuergerät 52 als Ausgangssignal ob sender über den Ausgang OutBus auf den BUS 53 gesendet.

Falls beim Prüfern, ob Ausgabesignale des ersten Steuergeräts 51 OBD-konform sind, festgestellt wird, dass über die OBD-Konformität des Eingangssignals ib target keine Information verfügbar ist (s. auch Beispiel 44 in Fig. 4), so kann ein iteratives Prüfen hinsichtlich des Ausgangssignals ob_sender aus Sicht des zweiten Steuergeräts 52 gemäß den vorgeschlagenen Verfahrensschritten erfolgen.

Im Beispiel der Fig. 5 kann das Eingangssignal ib target als OBD-konform angezeigt werden, wenn das Ausgangssignal ob sender OBD-konform ist, da das Bussignal auf dem Bus lediglich übermittelt aber in seiner Qualität nicht verändert wird. Fall das Ausgangssignal ob sender nicht OBD-konform, wird das Eingangssignal ib target als nicht OBD-konform angezeigt; falls keine Information darüber besteht, ob das Ausgangssignal ob sender OBD-konform ist oder nicht, wird hinsichtlich der OBD-Konformität des Eingangssignals ib target angezeigt, dass keine Information verfügbar ist. 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 (z.B. Fig. 6) beschriebenen Ausführungsbeispielen erwähnt sind.

Fig. 6 zeigt ein Beispiel 60 einer iterativen Bestimmung von OBD-Konformität anhand eines Netzwerks mit drei Steuergeräten 61, 62 und 63. Das erste Steuergerät 61 kann ein Ausgabesignal sig ausgabe versenden und ein Eingangssignal sig eingang l empfangen, das über einen BUS (oder sonstige Signalleitung) vom zweiten (oder weiteren) Steuergerät 62 als Ausgangssignal sig_ausgang_l gesendet wird. Das zweite Steuergerät 62 selbst kann wiederum als Eingangssignal sig_eingang_2 ein Signal empfangen (z.B. BUS-Signal), das als weiteres Ausgangssignal sig_ausgang_2 vom dritten Steuergerät 63 gesendet wird.

Über iteratives Prüfen der OBD-Konformität der verschiedenen Signale im gezeigten Signalnetzwerk kann ermittelt werden, ob im komplexen System auch das Ausgabesignal sig ausgabe des ersten Steuergerätes OBD-konform ist. Jedes der gesendeten Signale der verschiedenen Steuergeräte (z.B. zweites und drittes Steuergerät 62, 63) kann statt als Ausgangssignal oder weiteres Ausgangssignal in der verwendeten Nomenklatur auch selbst als zu betrachtendes Ausgabesignal angesehen werden. Die verschiedenen Bezeichnungen in dieser Anmeldung dienen dem besseren Verständnis des iterativen Verfahrens.

Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 6 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-5) oder nachstehend beschriebenen Ausführungsbeispielen erwähnt sind.

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, ab decken.

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