DE102022001254B4 - Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem - Google Patents

Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem Download PDF

Info

Publication number
DE102022001254B4
DE102022001254B4 DE102022001254.5A DE102022001254A DE102022001254B4 DE 102022001254 B4 DE102022001254 B4 DE 102022001254B4 DE 102022001254 A DE102022001254 A DE 102022001254A DE 102022001254 B4 DE102022001254 B4 DE 102022001254B4
Authority
DE
Germany
Prior art keywords
vehicle
computing unit
diagnostic
external
internal
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
DE102022001254.5A
Other languages
English (en)
Other versions
DE102022001254A1 (de
DE102022001254B8 (de
Inventor
Simone König
Oliver Kopp
Malte Hahn
Rose Sturm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
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 Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Priority to DE102022001254.5A priority Critical patent/DE102022001254B8/de
Priority to PCT/EP2023/057400 priority patent/WO2023198421A1/de
Publication of DE102022001254A1 publication Critical patent/DE102022001254A1/de
Application granted granted Critical
Publication of DE102022001254B4 publication Critical patent/DE102022001254B4/de
Publication of DE102022001254B8 publication Critical patent/DE102022001254B8/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01MTESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00Testing of vehicles
    • G01M17/007Wheeled or endless-tracked vehicles
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60LPROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L3/00Electric devices on electrically-propelled vehicles for safety purposes; Monitoring operating variables, e.g. speed, deceleration or energy consumption
    • B60L3/12Recording operating variables ; Monitoring of operating variables
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60LPROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L2270/00Problem solutions or means not otherwise provided for
    • B60L2270/40Problem solutions or means not otherwise provided for related to technical updates when adding new parts or software
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C2205/00Indexing scheme relating to group G07C5/00
    • G07C2205/02Indexing scheme relating to group G07C5/00 using a vehicle scan tool
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808Diagnosing performance data

Abstract

Die Erfindung betrifft ein Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs (1). Das erfindungsgemäße Verfahren ist gekennzeichnet durch die folgenden Verfahrensschritte:- Erzeugen eines Diagnoseausführungsprotokolls (2) mittels einer ersten fahrzeugexternen Recheneinheit (RE_1), wobei das Diagnoseausführungsprotokoll (2) maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit (RI) umfasst;- Übertragen des Diagnoseausführungsprotokolls (2) auf die fahrzeuginterne Recheneinheit (RI) des sich in der Fertigung befindenden Fahrzeugs (1);- Ausführung des Diagnoseausführungsprotokolls (2) durch die fahrzeuginterne Recheneinheit (RI), wobei die fahrzeuginterne Recheneinheit (RI) 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 (RI) oder manuell assistiert durch eine die Fertigung des Fahrzeugs (1) betreuende Person erfasst wird; und- Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit (RE_1) und/oder eine zweite fahrzeugexterne Recheneinheit (RE_2).

Description

  • 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 10 2009 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 10 2013 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 10 2012 110 623 A1 ein Messgerät zum Durchführen von Messund 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 10 2018 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:
    • 1 eine schematisierte Darstellung des Ablaufs eines erfindungsgemäßen Verfahrens;
    • 2 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer ersten Ausführung;
    • 3 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer zweiten Ausführung;
    • 4 eine schematisierte Darstellung einer Fertigungsstraße; und
    • 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 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 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 2 und 3 dienen noch einmal zur Veranschaulichung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur des Fahrzeugherstellers. In 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 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. 3 zeigt eine der 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.
  • 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.
  • 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.

Claims (9)

  1. Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs (1), gekennzeichnet durch die folgenden Verfahrensschritte: - Erzeugen eines Diagnoseausführungsprotokolls (2) mittels einer ersten fahrzeugexternen Recheneinheit (RE_1), wobei das Diagnoseausführungsprotokoll (2) maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit (RI) umfasst; - Übertragen des Diagnoseausführungsprotokolls (2) auf die fahrzeuginterne Recheneinheit (RI) des sich in der Fertigung befindenden Fahrzeugs (1); - Ausführung des Diagnoseausführungsprotokolls (2) durch die fahrzeuginterne Recheneinheit (RI), wobei die fahrzeuginterne Recheneinheit (RI) 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 (RI) oder manuell assistiert durch eine die Fertigung des Fahrzeugs (1) betreuende Person erfasst wird; und - Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit (RE_1) und/oder eine zweite fahrzeugexterne Recheneinheit (RE_2).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Diagnoseausführungsprotokoll (2) auf der ersten fahrzeugextern Recheneinheit (RE_1) unter Anwendung einer grafischen Spezifikationssprache erzeugt wird, wobei das Diagnoseausführungsprotokoll (2) einen Ablaufplan der von der fahrzeuginternen Recheneinheit (RI) durchzuführenden Diagnoseschritte umfasst, wobei die erste fahrzeugexterne Recheneinheit (RE_1) aus einer fahrzeugexternen Datenbank (3) den Diagnoseschritten entsprechende maschinenlesbare Anweisungen ausliest und in das Diagnoseausführungsprotokoll (2) integriert.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass als grafische Spezifikationssprache Business Process Model and Notation verwendet wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die fahrzeuginterne Recheneinheit (RI) drahtgebunden und/oder drahtlos an ein gemeinsames Kommunikationsnetzwerk mit einer fahrzeugexternen Recheneinheit (RE_1, RE_2) angeschlossen ist und die fahrzeuginterne Recheneinheit (RI) mit der fahrzeugexternen Recheneinheit (RE_1, RE_2) mittelbar über einen Kommunikationsserver (RKOM) Informationen austauscht.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass eine drahtlose Kommunikation mittels WLAN und/oder Mobilfunk, insbesondere unter Nutzung von 5G, erfolgt.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die fahrzeuginterne Recheneinheit (RI) eine fahrzeugexterne Manipulationsmaschine (4) ansteuert, um zumindest einen Diagnoseschritt durchzuführen und/oder Maßnahmen einzuleiten, wenn die zumindest eine Fahrzeugkomponente in ihrer korrekten Funktionsweise gestört ist.
  7. Diagnosesystem mit einer ersten fahrzeugexternen Recheneinheit (RE_1) und mit einem sich in der Fertigung befindenden Fahrzeug (1), umfassend eine fahrzeuginterne Recheneinheit (RI), dadurch gekennzeichnet, dass die erste fahrzeugexterne Recheneinheit (RE_1) und das Fahrzeug (1) zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 6 eingerichtet sind.
  8. Diagnosesystem nach Anspruch 7, gekennzeichnet durch wenigstens eine zweite fahrzeugexterne Recheneinheit (RE_2), wobei die zweite fahrzeugexterne Recheneinheit (RE_2) dazu eingerichtet ist, von der fahrzeuginternen Recheneinheit (RI) Informationen zu empfangen und/oder angesteuert zu werden.
  9. Diagnosesystem nach Anspruch 7 oder 8, gekennzeichnet durch einen Kommunikationsserver (RKOM), wobei der Kommunikationsserver (RKOM) dazu eingerichtet ist, Informationen zwischen der fahrzeuginternen Recheneinheit (RI) und der ersten fahrzeugexternen Recheneinheit (RE_1) auszutauschen.
DE102022001254.5A 2022-04-12 2022-04-12 Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem Active DE102022001254B8 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102022001254.5A DE102022001254B8 (de) 2022-04-12 2022-04-12 Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem
PCT/EP2023/057400 WO2023198421A1 (de) 2022-04-12 2023-03-23 Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022001254.5A DE102022001254B8 (de) 2022-04-12 2022-04-12 Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem

Publications (3)

Publication Number Publication Date
DE102022001254A1 DE102022001254A1 (de) 2023-10-12
DE102022001254B4 true DE102022001254B4 (de) 2023-12-07
DE102022001254B8 DE102022001254B8 (de) 2024-02-22

Family

ID=85800528

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022001254.5A Active DE102022001254B8 (de) 2022-04-12 2022-04-12 Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem

Country Status (2)

Country Link
DE (1) DE102022001254B8 (de)
WO (1) WO2023198421A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009033806A1 (de) 2009-07-18 2011-01-20 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung
DE102012110623A1 (de) 2012-11-06 2014-05-08 Testo Ag Messgerät zum Durchführen von Mess- und Prüfaufgaben in vorgebbaren Prozessen
DE102013014878B3 (de) 2013-09-06 2014-10-30 Audi Ag Wartung von Kraftfahrzeug-Steuergeräten per Mobilfunk
DE102018203067A1 (de) 2018-03-01 2019-09-05 Audi Ag Verfahren und Fertigungsanlage zum Fertigen eines Kraftfahrzeugs

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19607950A1 (de) * 1996-03-01 1997-09-04 Schenck Rotec Gmbh Verfahren zum Prüfen von Kraftfahrzeugen und Prüfsystem
US6611740B2 (en) * 2001-03-14 2003-08-26 Networkcar Internet-based vehicle-diagnostic system
US9117319B2 (en) * 2005-06-30 2015-08-25 Innova Electronics, Inc. Handheld automotive diagnostic tool with VIN decoder and communication system
DE102015012524A1 (de) * 2015-09-26 2016-05-12 Daimler Ag Verfahren und System zur Diagnose eines Fahrzeuges

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009033806A1 (de) 2009-07-18 2011-01-20 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung
DE102012110623A1 (de) 2012-11-06 2014-05-08 Testo Ag Messgerät zum Durchführen von Mess- und Prüfaufgaben in vorgebbaren Prozessen
DE102013014878B3 (de) 2013-09-06 2014-10-30 Audi Ag Wartung von Kraftfahrzeug-Steuergeräten per Mobilfunk
DE102018203067A1 (de) 2018-03-01 2019-09-05 Audi Ag Verfahren und Fertigungsanlage zum Fertigen eines Kraftfahrzeugs

Also Published As

Publication number Publication date
WO2023198421A1 (de) 2023-10-19
DE102022001254A1 (de) 2023-10-12
DE102022001254B8 (de) 2024-02-22

Similar Documents

Publication Publication Date Title
WO1997012301A1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
DE102004062434A1 (de) System und Verfahren zum automatischen Aktualisieren von Funktionalitäten in einem verteilten Netzwerk
DE10343963A1 (de) Bereitstellung von Diagnoseinformationen
EP3001310B1 (de) Verfahren und Einrichtung zur Aktualisierung von Firmware für Komponenten einer industriellen Automatisierungsanordnung
EP3353650B1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
DE102017205832A1 (de) Verfahren zum Parametrieren eines Feldgeräts sowie parametrierbares Feldgerät
DE102022001254B4 (de) Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem
DE102023118342A1 (de) System und verfahren zum drahtlosen durchführen von softwarebasierten aufgaben an fahrzeugen
DE102012003000A1 (de) Ferndiagnostizierung von Fahrzeugen
EP2701019A2 (de) Verfahren zur Parametrierung eines Feldgerätes und entsprechendes System zur Parametrierung
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
EP4160390B1 (de) Verfahren und anordnung zur inbetriebnahme einer aktualisierten anwendung für eine industrielle automatisierungsanordnung
WO2012028366A1 (de) Verfahren zur sicherstellung der korrekten funktionsweise einer automatisierungsanlage
EP2557464A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
EP1248168A2 (de) Verfahren und Vorrichtung zur Gewinnung von Diagnoseinformationen
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
EP1814763B1 (de) Verfahren und System zur Bereitstellung von internen diagnoserelevanten Informationen in einem Fahrzeug
DE102021205383A1 (de) Verfahren zur Diagnose eines Bordnetzes eines Fahrzeugs
DE102020213809A1 (de) Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
LU500646B1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
DE10140763A1 (de) Verfahren und Anordnung zur Konfiguration von Baugruppen in einer Datenverarbeitungsanlage
AT511297B1 (de) Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe
DE102021123596A1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
DE102022203325A1 (de) Verfahren zur Überprüfung der Ausführbarkeit einer Softwareanwendung
DE10161321A1 (de) Verfahren zur Aktualisierung von elektronisch modifizierbaren Komponenten eines Automatisierungsgerätes

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division