Die Erfindung betrifft ein Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs sowie ein Diagnosesystem zur Durchführung des Verfahrens nach der im Oberbegriff von Anspruch 7 näher definierten Art.

Komplexe Maschinen wie Fahrzeuge bedürfen einer Vielzahl einzelner Arbeitsschritte zur Fertigstellung in der Montage. Dabei können einzelne Montageschritte fehlerhaft durchgeführt worden sein und/oder fehlerhafte Komponenten verbaut worden sein. Dies erfordert es relevante Fahrzeugfunktionen vor einer Auslieferung des Fahrzeugs auf eine korrekte Funktionsweise zu kontrollieren. Treten Fehler auf, so können Maßnahmen eingeleitet werden, um die Fehler zu beheben, bevor das Fahrzeug ausgeliefert wird

Beispielsweise wird bei einem Fahrzeug vor dessen Auslieferung geprüft, ob auf den jeweiligen im Fahrzeug verbauten Recheneinheiten bzw. Steuergeräten die richtige Software, insbesondere in der aktuellen Version, installiert ist. Zudem werden die im Fahrzeug verbauten Sensoren kalibriert. Die Kontrolle des Fahrzeugs kann vorsehen, dass einzelne Funktionsüberprüfungsschritte manuell, teilassistiert oder vollautomatisch durch ein Rechnersystem durchgeführt werden. Hierzu wird typischerweise ein entsprechendes Rechnersystem kabelgebunden mittels eines sogenannten Onboard- Diagnose-Steckers an eine Recheneinheit des Fahrzeugs angeschlossen. Das fahrzeugexterne Rechnersystem steuert dann die entsprechenden zu überprüfenden bzw. zu kalibrierenden Fahrzeugkomponenten an.

Die Planung, Vorbereitung und Durchführung einer solchen Funktionsüberprüfung ist mit erheblichem Aufwand verbunden. Zuerst gilt es die in der Fahrzeugdiagnose durchzuführenden Prozessschritte zu spezifizieren und zu dokumentieren. Anschließend müssen die entsprechenden Prozessschritte in Programmcode überführt werden, welcher dann auf das Rechnersystem eingespielt werden muss. Anschließend muss der Programmcode ausgeführt werden. Während dieses Vorgangs der Übertragung der Planungsschritte in einen zur Steuerung der Fahrzeugkomponenten verwendeten Programmcode treten sogenannte Medienbrüche auf, wodurch Fehler entstehen können. Beispielsweise kann ein Prozessschritt von einem Programmierer falsch verstanden werden, woraufhin eine falsche Anweisung in den Programmcode integriert wird. Zudem unterscheiden sich die Rechensysteme des Fahrzeugs mit den Entwicklungssystemen, was verstärkt zu Bugs führen kann. So kann ein Diagnoseprogramm in einer Testumgebung einwandfrei funktionieren, jedoch bei einer Ausführung im Fahrzeug fehlerhaft laufen.

Die DE 102009 033 806 A1 offenbart ein Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung. Das Verfahren beschreibt eine zentrale Verwaltung der Durchführung der Funktionsprüfung eines sich in der Fertigung befindenden Fahrzeugs bzw. von Fahrzeugkomponenten durch eine zentrale Recheneinheit. So ist es erforderlich, auf verschiedenen Fertigungs- und/oder Prüfstationen für unterschiedliche Modellvarianten verschiedene Funktionstests durchzuführen. Dabei werden auf der zentralen Recheneinheit für die verschiedenen Modellvarianten und Fertigungs- und/oder Prüfstationen die jeweils relevanten Vorgehensschritte und entsprechender Programmcode vorgehalten. Die während der Prüfung anfallenden Prüfdaten werden ebenfalls zentral gesammelt und ausgewertet, was eine schnelle und direkte Zuordnung von potenziell auftretenden Fehlern zu einer entsprechenden Fehlerquelle ermöglicht. Zudem wird hierdurch das Einleiten von Gegenmaßnahmen zur Behebung eines entsprechenden Fehlers vereinfacht.

Aus der DE 102013 014 878 B3 ist die Wartung von Kraftfahrzeug-Steuergeräten per Mobilfunk bekannt. Das Verfahren sieht das Aufbauen einer auf Mobilfunk basierenden Kommunikationsverbindung zwischen einer fahrzeugexternen Recheneinrichtung und einem fahrzeuginternen Steuergerät vor, wobei über die Kommunikationsverbindung Gerätedaten zwischen der Recheneinrichtung und dem Steuergerät ausgetauscht werden. Bei den Gerätedaten handelt es sich um Konfigurationsdaten für das Steuergerät, Fehlermeldungen des Steuergeräts und/oder Statusmeldungen des Steuergeräts. Die fahrzeugexterne Recheneinrichtung fungiert als zentrales Verwaltungsorgan zur Durchführung der Fahrzeugdiagnose. So kann die Recheneinrichtung einen Befehl an ein jeweiliges Steuergerät übermitteln, welcher dieses veranlasst einen nach einer fest vorgegebenen und im respektiven Steuergerät implementierten Routine definierten Selbsttest durchzuführen.

Ferner offenbart die DE 102012 110 623 A1 ein Messgerät zum Durchführen von Mess- und Prüfaufgaben in vorgebbaren Prozessen. Das Messgerät ist dazu eingerichtet eine Datei einzulesen, welche eine Prozessbeschreibung enthält. Das Messgerät wandelt die Prozessbeschreibung in eine Programmablaufroutine um und führt diese aus. Die Datei kann mit einem Editor für Business Process Model and Notation erstellt worden sein.

Zudem ist aus der DE 102018 203 067 A1 ein Verfahren und eine Fertigungsanlage zum Fertigen eines Kraftfahrzeugs bekannt. Das Verfahren sieht das Erfassen einer Spracheingabe durch eine fahrzeuginterne Steuerungseinrichtung und Zuweisen einer korrespondierenden Bedeutung vor. Anschließend wird über eine Schnittstelle zwischen Steuerungseinrichtung und fahrzeugexterner Prüfeinrichtung der Prüfeinrichtung zur Auswertung ein mit der Bedeutung korrespondierender Datensatz übermittelt.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde ein verbessertes Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs anzugeben, welches eine effiziente und zuverlässige Durchführung der Funktionsdiagnose gewährleistet.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren zur Durchführung einer Funktionsdiagnose mit den Merkmalen des Anspruchs 1 sowie ein entsprechendes hierzu verwendetes Diagnosesystem mit den Merkmalen des Anspruchs 7 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Ansprüchen.

Ein erfindungsgemäßes Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs unterscheidet sich zu einem gattungsgemäßen Verfahren durch die folgenden Verfahrensschritte:

- Erzeugen eines Diagnoseausführungsprotokolls mittels einer ersten fahrzeugexternen Recheneinheit, wobei das Diagnoseausführungsprotokoll maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit umfasst; - Übertragen des Diagnoseausführungsprotokolls auf die fahrzeuginterne Recheneinheit des sich in der Fertigung befindenden Fahrzeugs;

- Ausführung des Diagnoseausführungsprotokolls durch die fahrzeuginterne Recheneinheit, wobei die fahrzeuginterne Recheneinheit wenigstens eine Fahrzeugkomponente zur Überprüfung einer korrekten Funktionsweise der wenigstens einen Fahrzeugkomponente ansteuert, und wobei das Antwortverhalten der wenigstens einen Fahrzeugkomponente automatisiert durch die fahrzeuginterne Recheneinheit oder manuell assistiert durch eine die Fertigung des Fahrzeugs betreuende Person erfasst wird; und

- Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit und/oder eine zweite fahrzeugexterne Recheneinheit.

Das erfindungsgemäße Verfahren sieht vor, die die Funktionsdiagnose ausführende Recheneinheit in das Fahrzeug selbst zu verlegen. Das Fahrzeug führt mit anderen Worten die Funktionsdiagnose selbstständig aus, was eine besonders effiziente Durchführung der Funktionsdiagnose ermöglicht. So wird der Kommunikationspfad der steuernden Recheneinheit zu den angesteuerten Komponenten verkürzt, was eine besonders schnelle Reaktionszeit und damit Absenkung von Latenzen erlaubt. Dies ermöglicht eine effiziente Ausführung zeitkritischer Aufrufe. Zudem werden weniger rechenintensive Ressourcen zur Durchführung der Funktionsdiagnose erfordert, da nicht mehr zeitgleich ein einziges zentrales Rechensystem eine Vielzahl an Steuergeräten zur Durchführung der Funktionsdiagnosen einer Vielzahl an Fahrzeugen ansteuern muss.

Die erste fahrzeugexterne Recheneinheit kann dabei als Entwicklersystem verstanden werden. Bei den maschinenlesbaren Anweisungen handelt es sich um Programmcode, welcher von der fahrzeuginternen Recheneinheit ausgeführt werden kann. Hierdurch wird die fahrzeuginterne Recheneinheit dazu in die Lage versetzt, die zu überprüfenden Fahrzeugkomponenten selbst entsprechend der durchzuführenden Diagnoseschritte anzusteuern. Entsprechende Diagnoseschritte können vollständig automatisiert von der fahrzeuginternen Recheneinheit durchgeführt und protokolliert werden oder auch manuell assistiert durch die die Fertigung des Fahrzeugs betreuende Person. Beispielsweise kann es erforderlich sein, dass die Person das Fahrzeug manuell manipulieren muss, damit die Funktionsprüfung vollständig durchgeführt werden kann und/oder die Person die durch Ansteuerung der Fahrzeugkomponente hervorgerufene Reaktion erfassen und protokollieren muss. Ein entsprechendes Prüfergebnis kann die Person dann im Fahrzeug selbst oder auch über die erste oder zweite fahrzeugexterne Recheneinheit eingeben. Bei der zweiten fahrzeugexternen Recheneinheit kann es sich um ein in der Fertigung verwendetes Rechensystem handeln. Beispielsweise kann es sich um einen zentralen Produktionsrechner oder auch ein Inselsystem handeln, beispielsweise ein an einer Fertigungs- und/oder Prüfstation vorgesehenes Rechnersystem.

Werden während der Funktionsprüfung Fehler entdeckt, so kann das Diagnoseausführungsprotokoll entsprechende Anweisungen zur Reaktion auf Fehler umfassen, wie das erneute Durchführen einzelner Kalibrier- oder Prüfschritte und/oder Nachbearbeitungsschritte, welche dann entsprechend von der fahrzeuginternen Recheneinheit umgesetzt werden. Die entsprechenden Anweisungen können dabei Teil eines gemeinsamen Diagnoseverfahrens sein oder ergänzend hierzu als „Standardantwort“ zur Reaktion auf typische Fehler ausgeführt sein. So können für diese Standardantworten auch individuelle Diagnoseausführungsprotokolle erzeugt und an die fahrzeuginterne Recheneinheit zum Vorhalten übertragen werden, welche dann nach Bedarf ausgeführt werden.

Die vom Diagnoseausführungsprotokoll umfassten Anweisungen können von der fahrzeuginternen Recheneinheit sequentiell und/oder parallel ausgeführt werden. Beispielsweise wird die durchzuführende Diagnose in eine „Vorbereitung“, einen „Hauptteil“ und eine „Nachbearbeitung“ unterteilt. Beispiele für eine Vorbereitung können sein: Aufbau einer Kommunikationsverbindung zwischen fahrzeuginternen und/oder fahrzeugexternen Recheneinheiten, Durchführen einer Authentifizierung und/oder Autorisierung, Aufbau einer sogenannten „Session“ und dergleichen. Beispiele für den Hauptteil können sein: Ansteuerung von Aktuatoren, Lesen von Sensordaten, Auslesen eines Fehlerspeichers eines Steuergeräts, Anpassen von Kalibrierparametern und dergleichen. Beispiele für eine Nachbearbeitung können sein: Beenden einer Kommunikationsverbindung, Schreiben von Ergebnisdaten, Publikation der Ergebnisdaten an ein fahrzeugexternes System, zurücksetzen von Steuergerätzuständen und dergleichen.

Eine vorteilhafte Weiterbildung des Verfahrens sieht vor, dass das Diagnoseausführungsprotokoll auf der ersten fahrzeugexternen Recheneinheit unter Anwendung einer grafischen Spezifikationssprache erzeugt wird, wobei das Diagnoseausführungsprotokoll einen Ablaufplan der von der fahrzeuginternen Recheneinheit durchzuführenden Diagnoseschritte umfasst, wobei die fahrzeugexterne Recheneinheit aus einer fahrzeugexternen Datenbank den Diagnoseschritten entsprechende maschinenlesbare Anweisungen ausliest und in das Diagnoseausführungsprotokoll integriert. Hierdurch wird der Ablauf zur Erzeugung anwendbaren Programmcodes auf der fahrzeuginternen Recheneinheit von der reinen Idee, über das genaue Vorgehen wie ein Prozessschritt durchzuführen ist, über das Erzeugen von Programmcode, bis hin zur finalen Implementierung und Anwendung durch die fahrzeuginterne Recheneinheit effizient ausgestaltet. Insbesondere lassen sich hierdurch Medienbrüche vermeiden, was das Risiko von Fehlern signifikant senkt. So werden die in der Funktionsdiagnose durchzuführenden Prozessschritte mittels der grafischen Spezifikationssprache anwenderfreundlich und leicht verständlich grafisch formuliert und direkt in maschinenlesbare Anweisungen überführt, indem die für die jeweiligen Diagnoseschritte passenden Anweisungen automatisiert durch die erste fahrzeugexterne Recheneinheit aus der fahrzeugexternen Datenbank ausgelesen werden. Die fahrzeugexterne Datenbank kann dabei als sogenanntes Code Repository verstanden werden. In dem Code Repository werden für alle möglichen von einer Maschine ausführbaren Schritte erforderliche maschinenlesbare Anweisungen implementiert. So ist kein manueller Programmieraufwand zur Integration der zur Durchführung einer bestimmten Funktionsdiagnose benötigten maschinenlesbaren Anweisungen in die fahrzeuginterne Recheneinheit mehr erforderlich.

Werden von einem Fahrzeughersteller neue Fahrzeuge, Fahrzeugkomponenten und/oder Fahrzeugfunktionen entwickelt, so können von einem Programmierer neue maschinenlesbare Anweisungen in die fahrzeugexterne Datenbank, sprich das Code Repository, geschrieben werden, welche auch eine zuverlässige Durchführung der Funktionsdiagnose unter Verwendung der neuen Komponenten erlaubt. Treten Bugs auf, so können entsprechende bestehende maschinenlesbare Anweisungen der fahrzeugexternen Datenbank aktualisiert und überarbeitet werden.

Das Diagnoseausführungsprotokoll beschreibt somit einen Oberbegriff sowohl für den rein gedanklichen Ablauf der in einer Funktionsdiagnose durchzuführenden Prüfschritte, als auch des hierzu zur Ansteuerung von Fahrzeugkomponenten durch die fahrzeuginterne Recheneinheit verwendeten Programmcodes. Die Verwendung einer grafischen Spezifikationssprache führt insbesondere zu einer Reduktion manueller Fehler durch die die Fertigung betreuende Person. So kann die Person die durchzuführenden Prüfschritte grafisch dargestellt auf einer beliebigen Anzeigevorrichtung, beispielsweise auf einem in der Fertigung verwendeten Tablet und/oder einer Augmented-Reality-Brille, betrachten und dadurch die anfallenden Arbeitsschritte leicht verständlich auffassen. Das Diagnoseausführungsprotokoll ist somit sowohl von der Person, als auch von einer Maschine in leicht verständlicher Art und Weise interpretierbar.

Entsprechend einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens wird als grafische Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Hierbei handelt es sich um eine in der Wirtschaftsinformatik und im Prozessmanagement bewährte grafische Spezifikationssprache. Durch den klaren Bezug zwischen den durchzuführenden Prozessschritten und entsprechenden Programmcode lässt sich die für das Testen verschiedener Softwarevarianten erforderliche Zeit reduzieren, was das Durchführen der Funktionsdiagnose in seiner Effizienz weiter verbessert.

Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass die fahrzeuginterne Recheneinheit drahtgebunden und/oder drahtlos an ein gemeinsames Kommunikationsnetzwerk mit einer fahrzeugexternen Recheneinheit angeschlossen ist und die fahrzeuginterne Recheneinheit mit der fahrzeugexternen Recheneinheit mittelbar über einen Kommunikationsserver Informationen austauscht. Bei der fahrzeugexternen Recheneinheit kann es sich um die erste oder auch die zweite fahrzeugexterne Recheneinheit handeln. Beispielsweise kann die fahrzeuginterne Recheneinheit kabelgebunden über ein Ethernet-Kabel oder ein Onboard-Diagnosekabel mit der entsprechenden fahrzeugexternen Recheneinheit verbunden sein. Zur drahtlosen Kommunikation wird bevorzugt WLAN und/oder Mobilfunk, insbesondere unter Nutzung von 5G oder auch künftiger Mobilfunkstandards, eingesetzt. Insbesondere die Verwendung von WLAN und/oder Mobilfunk mit zumindest dem Mobilfunkstandard 5G erlaubt eine Datenübertragung mit vergleichsweise hohen Datenübertragungsraten. Insbesondere wenn die fahrzeuginterne Recheneinheit gleichzeitig sowohl drahtgebunden als auch drahtlos an das gemeinsame Kommunikationsnetzwerk mit der fahrzeugexternen Recheneinheit angeschlossen ist, lassen sich für verschiedene Anwendungen hohe Datenübertragungsraten erzielen. Generell ist es auch möglich, dass die fahrzeugexterne Recheneinheit unmittelbar mit der fahrzeuginternen Recheneinheit kommuniziert. Beispielsweise kann es sich bei der fahrzeugexternen Recheneinheit um ein von der die Fertigung betreuenden Person eingesetztes Tablet oder Desktopcomputer handeln, welcher drahtgebunden oder drahtlos an die fahrzeuginterne Recheneinheit in kommunikativer Art und Weise angeschlossen ist. Beispielsweise kann das Tablet der Person ein ad hoc WLAN aufbauen, in welches sich die fahrzeuginterne Recheneinheit einklinkt. Treten beispielsweise unvorhergesehene Ereignisse ein, welche das manuelle Eingreifen der Person erfordern, so kann die Person beispielsweise auf dem Tablet ein neues Diagnoseausführungsprotokoll unter Anwendung der grafischen Spezifikationssprache erzeugen und dieses unmittelbar zur Anwendung an die fahrzeuginterne Recheneinheit übertragen. Dies ermöglicht ein besonders schnelles Reagieren und Anpassen der zur Durchführung der Funktionsdiagnose durchzuführenden Prozessschritte. Ein solches Vorgehen kann auch in der Entwicklung der in der fahrzeugexternen Datenbank abzulegenden maschinenlesbaren Anweisungen aus den entsprechenden im Ablaufplan integrierten Prozessschritten angewendet werden.

Mit Hilfe des Kommunikationsservers wird ein zentraler Zugang der Vielzahl an fahrzeuginternen Recheneinheiten, auch über verschiedene Fertigungsstandorte hinweg, zu einer zentralen fahrzeugexternen Datenbank ermöglicht. So kann beispielsweise in das an der Fertigungs- und/oder Prüfstation integrierte Tablet eine fahrzeugexterne Datenbank integriert sein. So kann das Tablet nach Erzeugen eines entsprechenden Ablaufplans durch die Person selbst entsprechende maschinenlesbare Anweisungen in das Diagnoseausführungsprotokoll integrieren. Dabei besteht das Risiko, dass veraltete maschinenlesbare Anweisungen aus der tabletinternen fahrzeugexternen Datenbank ausgelesen werden. Durch den Zugriff auf die zentrale fahrzeugexterne Datenbank über den Kommunikationsserver können entsprechende verteilte fahrzeugexterne Datenbanken mit aktualisiertem Programmcode geupdated werden.

Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass die fahrzeuginterne Recheneinheit eine fahrzeugexterne Manipulationsmaschine ansteuert, um zumindest einen Diagnoseschritt durchzuführen und/oder Maßnahmen einzuleiten, wenn die zumindest eine Fahrzeugkomponente in ihrer korrekten Funktionsweise gestört ist. Entsprechende maschinenlesbare Anweisungen zum Ansteuern der fahrzeugexternen Manipulationsmaschine sind dann ebenfalls in das Diagnoseausführungsprotokoll bzw. in weitere Diagnoseausführungsprotokolle integriert. Die Integration erfolgt dabei bevorzugt automatisiert in Abhängigkeit der in der grafischen Spezifikationssprache definierten Prozessschritte des Ablaufplans. Beispielsweise kann es sich bei der fahrzeugexternen Manipulationsmaschine um einen an der Fertigungs- und/oder Prüfstation vorgesehenen Roboter handeln. Eine Manipulation des Fahrzeugs bzw. einer Fahrzeugkomponente kann auf vielfältige Art und Weise erfolgen, beispielsweise kann die fahrzeugexterne Manipulationsmaschine das Fahrzeug oder eine Fahrzeugkomponente bewegen, mit Hilfe fahrzeugexterner Sensoren überprüfen, neue Komponenten hinzufügen oder bereits integrierte Komponenten austauschen, loslösen oder dergleichen. So ist eine Nachbearbeitung des Fahrzeugs bzw. von Fahrzeugkomponenten nach dem Durchführen der eigentlichen Funktionsdiagnose möglich. Das erfindungsgemäße Verfahren ermöglicht es also der fahrzeuginternen Recheneinheit in der Produktion bzw. in der Prüfung verwendete fahrzeugexterne Maschinen selbst ansteuern zu können. Es ist dann keine zentrale Recheneinheit zum Ansteuern der fahrzeugexternen Manipulationsmaschinen mehr erforderlich. Auch dies sorgt für eine gesteigerte Effizienz bei der Durchführung der Funktionsdiagnose. Die fahrzeuginterne Recheneinheit kann die fahrzeugexterne Manipulationsmaschine unmittelbar ansteuern, beispielsweise über eine direkte Kommunikation mittels WLAN oder auch mittelbar über eine fahrzeugexterne Recheneinheit wie einen zentralen Fabrikserver.

Bei einem Diagnosesystem mit einer ersten fahrzeugexternen Recheneinheit und mit einem sich in der Fertigung befindenden Fahrzeug, umfassend eine fahrzeuginterne Recheneinheit, sind erfindungsgemäß die erste fahrzeugexterne Recheneinheit und das Fahrzeug zur Durchführung eines im vorigen beschriebenen Verfahrens eingerichtet. Die fahrzeuginterne Recheneinheit ist dazu in der Lage alle relevanten Fahrzeugkomponenten elektrisch bzw. elektronisch anzusteuern und zu überwachen. Dies erlaubt das besonders ressourcenarme Durchführen zeitlich kritischer Diagnoseprozessschritte mit vergleichsweise geringen Latenzen. Hierdurch wird ein effizienter Funktionsdiagnoseablauf gewährleistet.

Eine vorteilhafte Weiterbildung des Diagnosesystems sieht wenigstens eine zweite fahrzeugexterne Recheneinheit vor, wobei die zweite fahrzeugexterne Recheneinheit dazu eingerichtet ist, von der fahrzeuginternen Recheneinheit Informationen zu empfangen und/oder angesteuert zu werden. Die fahrzeuginterne Recheneinheit kann beispielsweise Ergebnisse der Funktionsdiagnoseprüfung an die zweite fahrzeugexterne Recheneinheit übermitteln, welche dort zur Auswertung gespeichert werden. Auch können in Abhängigkeit der ausgewerteten Ergebnisse durch die zweite fahrzeugexterne Recheneinheit Maßnahmen zur Behebung von Fehlern eingeleitet werden. Die fahrzeuginterne Recheneinheit kann die zweite fahrzeugexterne Recheneinheit auch ansteuern. Beispielsweise handelt es sich bei der zweiten fahrzeugexternen Recheneinheit um das Steuergerät einer fahrzeugexternen Manipulationsmaschine.

Bevorzugt umfasst das Diagnosesystem einen Kommunikationsserver, wobei der Kommunikationsserver dazu eingerichtet ist, Informationen zwischen der fahrzeuginternen Recheneinheit und der ersten fahrzeugexternen Recheneinheit auszutauschen. Dies ermöglicht eine zentrale Verwaltung der fahrzeugexternen Datenbank. So müssen die in die Planung der Funktionsdiagnose eingebundenen Ingenieure nicht örtlich in der Fabrik anwesend sein, um neue Funktionsdiagnoseprozesse zu entwickeln oder zu implementieren. Die entsprechenden neu generierten Diagnoseausführungsprotokolle lassen sich über den Kommunikationsserver an die jeweiligen Fertigungs- und/oder Prüfstationen in der Fertigung übertragen und dort auf die jeweiligen fahrzeuginternen Recheneinheiten einspielen. Generell ist es auch möglich, dass besagte Diagnoseausführungsprotokolle bereits auf der fahrzeuginternen Recheneinheit vorinstalliert sind, bevor die entsprechenden fahrzeuginternen Recheneinheiten im Fahrzeug verbaut werden. Dies ermöglicht das Durchführen bestimmter Funktionsdiagnoseüberprüfungen auch ohne eine bestehende Kommunikation zwischen fahrzeugexterner Recheneinheit und fahrzeuginterner Recheneinheit. Entsprechende Diagnoseergebnisse können auf der fahrzeuginternen Recheneinheit zwischengespeichert werden und sobald eine Kommunikationsverbindung zur ersten und/oder zweiten fahrzeugexternen Recheneinheit besteht an diese übertragen werden.

Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens zur Durchführung der Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs und des Diagnosesystems ergeben sich auch aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben werden. Dabei zeigen:

Fig. 1 eine schematisierte Darstellung des Ablaufs eines erfindungsgemäßen Verfahrens;

Fig. 2 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer ersten Ausführung;

Fig. 3 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer zweiten Ausführung;

Fig. 4 eine schematisierte Darstellung einer Fertigungsstraße; und

Fig. 5 eine schematisierte Darstellung einer verteilten Fertigung.

Kerngedanke des erfindungsgemäßen Verfahrens zur Durchführung einer Fahrzeugdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs 1 ist die selbstständige Durchführung der Funktionsdiagnose durch eine fahrzeuginterne Recheneinheit RI. Bevorzugt wird der vollständige Ablauf der Entwicklung der in der Funktionsdiagnose durchzuführenden Prozessschritte bis hin zur Erzeugung von Programmcode, Implementierung des Programmcodes in der fahrzeuginternen Recheneinheit RI und Ausführung von dieser durch Anwendung einer grafischen Spezifikationssprache, bevorzugt Business Process Model and Notation (BPMN) ausgestaltet.

Ein Ingenieur 5 erstellt an einer ersten fahrzeugexternen Recheneinheit RE_1 einen Ablaufplan der von der fahrzeuginternen Recheneinheit RI durchzuführenden Diagnoseschritte mittels der grafischen Spezifikationssprache. Hieraus wird ein Diagnoseausführungsprotokoll 2 erstellt. Das Diagnoseausführungsprotokoll 2 kann in der grafischen Spezifikationssprache ausformuliert sein und dann in eine Metasprache wie beispielsweise XML gewandelt werden. Dabei liest die erste fahrzeugexterne Recheneinheit RE_1 aus einer fahrzeugexternen Datenbank 3, auch als Code Repository bezeichnet, den Diagnosenschritten entsprechende maschinenlesbare Anweisungen aus und integriert diese in das Diagnoseausführungsprotokoll 2. Dies erfolgt im Verfahrensschritt 101. Dabei kann die fahrzeugexterne Datenbank 3 auf der ersten fahrzeugexternen Recheneinheit RE_1 vorgehalten werden und/oder auf einem Datenspeicher in einem Netzwerk, beispielsweise auf einem zentralen Server. Das Diagnoseprotokoll 2 wird über einen Kommunikationsserver RKOM, beispielsweise einen Proxyserver, an eine Fabrik 6 des Fahrzeugherstellers, in der sich die Fertigung befindet, übertragen. In der Fabrik 6 erfolgt eine Verteilung des Diagnoseausführungsprotokolls 2 an die entsprechende fahrzeuginterne Recheneinheit RI des zu überprüfenden Fahrzeugs 1. Im Verfahrensschritt 102 wird das Diagnoseausführungsprotokoll 2 bzw. die darin enthaltenden maschinenlesbaren Anweisungen von der fahrzeuginternen Recheneinheit RI ausgeführt, wodurch die fahrzeuginterne Recheneinheit RI die zumindest eine zu überprüfende Fahrzeugkomponente ansteuert und das entsprechende Antwortverhalten automatisiert oder manuell assistiert durch eine die Fertigung des Fahrzeugs 1 betreuende Person erfasst. Ist die Funktionsdiagnose erfolgreich, wie in Figur 1 durch ein Häkchen angedeutet, so kann das Fahrzeug 1 für den nächsten Fertigungsschritt bzw. zur Übergabe an den Händler freigegeben werden. Ist die Funktionsdiagnose hingegen wie in Figur 1 durch einen Blitz angedeutet fehlerhaft, so sind weitere Maßnahmen einzuleiten. Dabei können die weiteren Maßnahmen ebenfalls beschrieben durch in das Diagnoseausführungsprotokoll 2 integrierte Anweisungen durch die fahrzeuginterne Recheneinheit RI ausgeführt bzw. angestoßen werden.

Die Figuren 2 und 3 dienen noch einmal zur Veranschaulichung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur des Fahrzeugherstellers. In Figur 2 sind mehrere erste fahrzeugexterne Recheneinheiten RE_1 dargestellt. Dabei umfasst jede der ersten fahrzeugexternen Recheneinheiten RE_1 eine eigene fahrzeugexterne Datenbank 3. In diesem Falle kann es sich bei den ersten fahrzeugexternen Recheneinheiten RE_1 beispielsweise um den Entwicklungs-PC eines Ingenieurs 5 handeln. Über einen solchen PC kann ein Diagnoseausführungsprotokoll 2 erzeugt werden und über den Kommunikationsserver RKOM an eine jeweilige Fabrik 6 übertragen werden. In einer jeweiligen Fabrik 6 kann ein Kommunikationsrelais 7, beispielsweise ein WLAN-Router oder ein 5G Modem, vorgesehen sein, über dass der Kommunikationsserver RKOM an ein gemeinsames Kommunikationsnetzwerk mit der fahrzeuginternen Recheneinheit RI angeschlossen ist. Eine entsprechende Übertragung des Diagnoseausführungsprotokolls 2 an die fahrzeuginterne Recheneinheit RI ist in Figur 2 durch eine gepunktete Linie dargestellt.

Die fahrzeuginterne Recheneinheit RI kann auch eine fahrzeugexterne Manipulationsmaschine 4, beispielsweise einen Manipulationsroboter, ansteuern. So kann der Manipulationsroboter Teile des Fahrzeugs bewegen oder auf eine sonstige Art und Weise manipulieren. Auch kann die fahrzeugexterne Manipulationsmaschine 4 einen oder mehrere Sensoren zur Überprüfung des Zustands des Fahrzeugs 1 bzw. von Fahrzeugkomponenten umfassen. Bei einem solchen Sensor kann es sich beispielsweise um eine Kamera, einen Leitfähigkeitssensor, einen Temperatursensor, einen Kraftsensor, einen Ultraschallsensor oder dergleichen handeln.

Ein Steuergerät der fahrzeugexternen Manipulationsmaschine 4 kann dabei als zweite fahrzeugexterne Recheneinheit RE_2 bezeichnet werden. In der Fabrik 6 können auch weitere zweite fahrzeugexterne Recheneinheiten RE_2 vorgesehen sein wie beispielsweise ein zentraler Fabrikserver RE_2_Zentral. Auf dem zentralen Fabrikserver RE_2_Zentral können von den fahrzeuginternen Recheneinheiten RI zu fertigender und/oder zu überprüfender Fahrzeuge 1 erzeugte Ergebnisse einer jeweiligen Funktionsdiagnose gespeichert und ausgewertet werden. So kann zum einen die fahrzeuginterne Recheneinheit RI oder auch der zentrale Fabrikserver RE_2_Zentral entsprechende fahrzeugexterne Manipulationsmaschinen 4 ansteuern, um im Falle eines Fehlers automatisiert Gegenmaßnahmen zur Behebung des Fehlers einzuleiten. Es können auch Personen benachrichtigt werden, welche eine manuelle Fehlerbehebung einleiten können.

Ferner kann eine erste fahrzeugexterne Recheneinheit RE_1 auch unmittelbar mit der fahrzeuginternen Recheneinheit RI kommunizieren. So ist beispielhaft ein Tabletcomputer RE_2_Tab dargestellt, welcher von einer die Fertigung des Fahrzeugs 1 betreuenden Person zur Interaktion mit der fahrzeuginternen Recheneinheit RI genutzt werden kann. Dies erlaubt besonders kurze Kommunikationswege zwischen erster fahrzeugexterner Recheneinheit RE_1 und fahrzeuginterner Recheneinheit RI.

Figur 3 zeigt eine der Figur 2 ähnliche Darstellung. Dabei sind in das Rechnernetz der ersten fahrzeugexternen Recheneinheiten RE_1 eine zentrale fahrzeugexterne Datenbank 3.1 sowie gegebenenfalls, angedeutet durch eine gestrichelte Linie, ein Zentralserver RE_1_Zentral integriert. Entwickler können in der zentralen fahrzeugexternen Datenbank 3.1 gespeicherte maschinenlesbare Anweisungen, sprich Codebausteine, pflegen. Die entsprechenden ersten fahrzeugexternen Recheneinheiten RE_1 , also beispielsweise Entwickler- PCs, können dann ihre jeweilige fahrzeugexterne Datenbank 3 durch Auslesen der zentralen fahrzeugexternen Datenbank 3.1 aktualisieren. Dabei können auch einige der Entwickler- PCs über keine integrierte fahrzeugexterne Datenbank 3 verfügen und sind auf eine direkte Anbindung an die zentrale fahrzeugexterne Datenbank 3.1 angewiesen.

Das gesamte Verfahren ist auch durch den Zentralserver RE_1_Zentral verwaltbar. Beispielsweise können die von den fahrzeuginternen Recheneinheiten RI der einzelnen Fahrzeuge 1 übermittelten Ergebnisse der Funktionsdiagnosen gespeichert und ausgewertet werden. Dies ermöglicht eine zentrale Analyse der Daten aus der Fertigung. So können die Vorteile der dezentralen Steuerung der Durchführung der Funktionsdiagnose und das zentrale Auswerten der entsprechenden Ergebnisse kombiniert werden.

So lassen sich besonders einfach systematische Fehlerursachen ermitteln, welche beispielsweise auf eine fehlerhafte Charge einzelner Bauelemente schließen lassen. Auch können hierdurch Prozessschritte ermittelt werden, welche eine erhöhte Fehleranfälligkeit aufweisen, beispielsweise weil eine Sensorkalibrierung zu viel Zeit beansprucht.

Figur 4 zeigt die zu einer Fertigungsstraße 8 in Reihe angeordneten Fertigungs- und/oder Prüfstationen 9. Dabei können an einer Fertigungs- und/oder Prüfstation 9 einzelne Fertigungsschritte eines Fahrzeugs 1 bzw. einer Fahrzeugkomponente durchgeführt werden und/oder ein Fahrzeug 1 bzw. Fahrzeugkomponenten einer Funktionsdiagnose unterzogen werden. Dabei kann jede Fertigungs- und/oder Prüfstation 9 eine eigene zweite fahrzeugexterne Recheneinheit RE_2 aufweisen, beispielsweise einen zentralen Computer, welcher die an der jeweiligen Fertigungs- und/oder Prüfstation 9 verwendeten Maschinen steuert. Auch kann eine jede solcher Maschine, beispielsweise eine fahrzeugexterne Manipulationsmaschine 4, ein eigenes Steuergerät in Form einer zweiten fahrzeugexternen Recheneinheit RE_2 umfassen.

Entsprechende Steuerbefehle können auch von dem zentralen Fabrikserver RE_2_Zentral ausgegeben werden und insbesondere über WLAN, 5G oder einen künftigen Mobilfunkstandard in der Fabrik 6 an die einzelnen zweiten fahrzeugexternen Recheneinheiten RE_2 übermittelt werden. Von den fahrzeuginternen Recheneinheit RI in Abhängigkeit der durchgeführten Funktionsdiagnose erzeugte Daten lassen sich dann entsprechend auf den zentralen Fabrikserver RE_2_Zentral zur Auswertung rückübermitteln. Figur 5 zeigt eine alternative oder ergänzende Ausführung der Fabrik 6. So können einzelne oder auch alle Fertigungs- und/oder Prüfstationen 9 verteilt angeordnet sein. Dies ermöglicht eine besonders flexible und effiziente Fertigung und/oder Prüfung von Fahrzeugen 1 entsprechend des Gedankenguts von Industrie 4.0. So ist ein zu fertigendes Fahrzeug 1 nicht darauf angewiesen, die einzelnen Fertigungs- und/oder Prüfstationen 9 sequentiell hintereinander zu durchlaufen, sondern kann für mehrere Produktions- bzw. Prüfschritte einer einzelnen Fertigungs- und/oder Prüfstation 9 zugeordnet bleiben und/oder flexibel zwischen diesen wechseln, wodurch freie Kapazitäten bezüglich ihrer Effizienz optimal genutzt werden.