-
Die Erfindung betrifft ein Verfahren mit den Merkmalen gemäß dem Oberbegriff des Anspruchs 1.
-
Der Einsatzbereich sowie der Verwendungszweck der Erfindung richtet sich auf Kupplungs- und Getriebesysteme insbesondere Doppelkupplungsgetriebesysteme in Kraftfahrzeugen.
-
Inbetriebnahmeprozesse werden in den Produktionsstätten üblicherweise mittels Prüfständen oder mobilen Testgeräten angestoßen und kontrolliert. Die Abarbeitung der einzelnen Prozesse wird im Allgemeinen als EndOfLine (EOL) bezeichnet. Im vorliegenden Fall werden bei der Inbetriebnahme von einem Prüfstand oder einem Tester bestimmte Diagnosebefehle - im Folgenden auch als Basis-Diagnosebefehle bezeichnet - über eine Schnittstelle (vorzugsweise CAN) an das in Betrieb zu nehmende Steuergerät gesendet. In der Regel werden identische Diagnosebefehle für die Inbetriebnahme in den Produktionsstätten (Werk) und im Service (Werkstatt) in diesem Fall allerdings über Werkstatttester beispielsweise nach Tausch oder Reparatur von Fahrzeugen genutzt.
-
Im Rahmen dieser Schrift sei mit Inbetriebnahme stets die Erstinbetriebnahme von ganzen Systemen, wie einem Doppelkupplungsgetriebe, oder einzelner Komponenten wie Steuergeräten oder Aktoren bezeichnet oder die Erstwiederinbetriebnahme nach Reparatur.
-
DE 101 10 729 A1 offenbart eine Vorrichtung zur elektronischen Steuerung einer Getriebebaueinheit, insbesondere eines Automatikgetriebes.
-
DE 10 2011 108 750 A1 offenbart ein Verfahren zum Inbetriebnehmen eines Kupplungs- und/oder Getriebesystems.
-
-
-
Im Rahmen dieser Schrift wird unter der Abkürzung TCU jedes beliebige Getriebesteuergerät zur Steuerung eines Kraftfahrzeuggetriebes, jedes beliebige Kupplungssteuergerät zur Steuerung eines oder mehrerer Kraftfahrzeugschaltkupplungen sowie insbesondere jedes Steuergerät zur Steuerung eines Getriebes sowie zur Steuerung einer oder mehrerer Schaltkupplungen insbesondere jedes Steuergerät zur Steuerung eines Doppelkupplungsgetriebes verstanden. Doppelkupplungsgetriebe sind seit langem bekannt und beispielsweise in der
DE 10 2008 023 360 A1 dargestellt.
-
Im Rahmen dieser Schrift wird unter der Abkürzung HCA jeder beliebige Aktor beispielsweise zur Betätigung einer automatisierten Reibungskupplung insbesondere ein hydrostatisch betriebener Kupplungsaktor (Hydrostatic Clutch Actuator) wie er beispielsweise in der
DE 10 2010 047 801 A1 oder der
DE 10 2010 047 800 A1 offenbart ist, verstanden. Jedem HCA muss jedoch mindestens ein nicht-flüchtiger Speicher eineindeutig, fest zugeordnet sein, beispielsweise in einer Vorortelektronik des HCA. Die Begriffe HCA und Getriebe-HCA werden im Rahmen dieser Schrift synonym verwendet.
-
Im Rahmen dieser Schrift werden die Begriffe Diagnoseroutine, Diagnosefunktion, Diagnoseservice sowie Diagnosebefehl synonym verwendet.
-
Im Rahmen dieser Schrift werden die Begriffe Software, Routine, Funktion, Prozess ebenfalls im Wesentlichen synonym verwendet.
-
Weitere im Rahmen dieser Schrift verwendete Abkürzungen sind:
- GW: Getriebewerk, FW: Fahrzeugwerk, ABS: AntiBlockierSystem, ECU: Motorsteurgerät des Antriebsmotors des Kraftfahrzeugs, MM-Interface, MMI: Mensch-Maschine-Interface, EOL: EndOfLine, UDS, UnifiedDiagnosticServices: Standard-Kommunikationsprotokoll der Standard-Diagnosebefehle.
-
Bei einem TCU-HCA-System - beispielsweise einem Doppelkupplungsgetriebe - werden gemäß dem Stand der Technik wie er beispielsweise in 2 dargestellt ist, die Steuerbefehle via CAN vom Prüfstand im Getriebewerk an die TCU gesendet, welche die Vorgaben entsprechend umsetzt. Hier sind besonders das Erlernen der Getriebegeometrie zu erwähnen.
-
Die Inbetriebnahmevorgänge können auch auf mehrere Stationen oder Produktionsstätten verlagert oder verteilt werden. Somit können bei EOL bereits komplette oder nur teilweise geprüfte/funktionierende Systeme zur Verfügung stehen, wodurch sich der Umfang der Inbetriebnahme an den nachfolgenden Stationen/Produktionsstätten verkürzt.
-
Im vorliegenden Fall können Inbetriebnahmevorgänge bereits im Getriebewerk (GW) stattfinden; die dort durchgeführten Lernvorgänge müssen dann nicht mehr zwingend im Fahrzeugwerk (FW) durchgeführt werden.
-
Die Verwendung von externen Steuerungseinheiten wie Prüfständen oder Testern für EOL-Prozesse ist kostenintensiv, Tester müssen beschafft, ins Werks-IT-Netzwerk integriert, eingerichtet, programmiert und gewartet werden, je nach Prozess sind Mitarbeiter notwendig zur Ansteuerung und Überwachung der EOL-Prozesse, somit ergibt sich ein Kosten- und Zeitnachteil.
-
Es sind bereits Lösungen bekannt, bei denen die EOL-Schritte über Standard-MM-Interface (Mensch-Maschine-Interface) des Fahrzeugs ohne Prüfstand oder Tester angestossen werden. Gänge werden beispielsweise dann gelernt, wenn ein Werker im Fahrzeugwerk, die Bremse betätigt und eine spezielle Wählhebelschaltfolgesequence nach „Zündung ein“ ausführt. Dies ist aber nur möglich, wenn das in Betrieb zu nehmende Steuergerät das Standard-MM-Interface erfasst.
-
Auch erscheint es machbar, einzelne EOL-Schritte vom Steuergerät selbständig ausführen zu lassen, wenn dieses erkennt, dass diese EOL-Schritte noch nicht ausgeführt wurden, da keine EOL-Daten dazu vorliegen. Hier besteht allerdings das Risiko, dass bei Verlust der EOL-Daten im laufenden Fahrzeugbetrieb diese Schritte erneut ausgeführt werden, was zu gefährlichen oder unerwarteten Fahrsituation führen kann. Zusätzliche Absicherungsmaßnahmen sind notwendig.
-
Ferner wurden Inbetriebnahmevorgänge, bei denen Parameter ermittelt werden, gesplittet (Parameter bereits im GW gelernt), um Zeit und damit Kosten im FW einzusparen, so müssen die gelernten Werte ins FW übertragen werden. Optimal ist, wenn die Parameter bereits in dem GW in einem Steuergerät gespeichert werden können, welches zukünftig auch im Fahrzeug verwendet wird. Da dies nicht immer der Fall ist - insbesondere, wenn das Zielsteuergeräte nicht am Getriebe verbaut ist -, müssen die Parameter auf andere Art und Weise in das - dann im Fahrzeug tatsächlich verwendete - Steuergerät übertragen werden.
-
Hierzu sind weitere Diagnose-EOL-Befehle notwendig, um zum Beispiel Barcode-, Datenbanklösungen oder auch die Zwischenspeicherung von EOL-Daten in lokalen am Getriebe verbauten Steuergeräten - wie beispielsweise in der deutschen Offenlegungsschrift
DE 10 2011 108 750 A1 sowie den deutschen Offenlegungsschriften
DE 10 2005 000 888 A1 und
DE 10 2007 040 485 A1 dargelegt - zu ermöglichen und es entsteht ein Testerprogrammieraufwand sowie Bedienungsaufwand.
-
Insbesondere beim Zwischenspeicherungsansatz ist alternativ zum Tester-gesteuerten Auslesen auch ein automatisches Auslesen vorstellbar, ähnlich dem oben beschriebenen Anstoßen von EOL-Prozessen, was aber eventuell sicherheitskritisch sein kann. Außerdem sind hierzu spezielle Handshake Algorithmen zwischen getriebefester Zwischenspeichereinheit und getriebefernem Steuergerät notwendig.
-
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, die Inbetriebnahme ohne Tester für das TCU-HCA-System bei verteilten Inbetriebnahmeschritten auf GW und FW sicher durchzuführen, wobei das TCU-HCA-System nicht über ein MM-Interface verfügt, und man vollständig auf „Spezial-Diagnosebefehle“ verzichten können muss.
-
Die Aufgabe wird durch ein Verfahren mit den Merkmalen gemäß Anspruch 1 gelöst.
-
Erfindungsgemäß wird ein Verfahren zur Inbetriebnahme eines Fahrzeuggetriebes mit einem Getriebeaktor zur Betätigung des Fahrzeuggetriebes und/oder zur Inbetriebnahme einer Fahrzeugkupplung mit einem Kupplungsaktor zur Betätigung der Fahrzeugkupplung und einem ersten Steuergerät zur Steuerung des Kupplungsaktors sowie zur Steuerung des Getriebeaktors sowie einem zweiten Steuergerät vorgeschlagen, wobei der Kupplungsaktor einen dem Kupplungsaktor eineindeutig zugeordneten, nicht-flüchtigen Speicherbereich aufweist und wobei das erste Steuergerät einen dem ersten Steuergerät eineindeutig zugeordneten Speicherbereich aufweist und wobei das zweite Steuergerät einen dem zweiten Steuergerät eineindeutig zugeordneten Speicherbereich aufweist. Erfindungsgemäß ist dabei vorgesehen, dass bei Vorliegen einer vorgegebenen Bedingung das zweite Steuergerät mittels eines Diagnosebefehls veranlasst, dass Daten aus dem nicht-flüchtigen Speicherbereich des Kupplungsaktors in den Speicherbereich des zweiten Steuergeräts übertragen werden, die Daten im zweiten Steuergerät aufbereitet werden, und anschließend mittels eines weiteren Diagnosebefehls die aufbereiteten Daten in den Speicherbereich des ersten Steuergeräts übertragen werden.
-
Nicht-erfindungsgemäß wird auch ein Verfahren zur Inbetriebnahme eines Fahrzeuggetriebes mit einem Getriebeaktor zur Betätigung des Fahrzeuggetriebes und/oder zur Inbetriebnahme einer Fahrzeugkupplung mit einem Kupplungsaktor zur Betätigung der Fahrzeugkupplung und einem ersten Steuergerät zur Steuerung des Kupplungsaktors sowie zur Steuerung des Getriebeaktors vorgeschlagen, wobei der Kupplungsaktor einen dem Kupplungsaktor eineindeutig zugeordneten, nicht-flüchtigen Speicherbereich aufweist und wobei das ersten Steuergerät einen dem ersten Steuergerät eineindeutig zugeordneten Speicherbereich aufweist. Erfindungsgemäß ist dabei vorgesehen, dass bei Vorliegen einer vorgegebenen Bedingung das erste Steuergerät mittels eines Diagnosebefehls veranlasst, dass Daten aus dem nicht-flüchtigen Speicherbereich des Kupplungsaktors in den Speicherbereich des ersten Steuergeräts oder in einen weiteren Speicherbereich des ersten Steuergeräts übertragen werden.
-
Nicht-erfindungsgemäß ist vorgesehen, dass die Daten im ersten Steuergerät aufbereitet werden, und anschließend in den Speicherbereich des ersten Steuergeräts übertragen werden.
-
In einer bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass die Diagnosebefehle Standard-Diagnosebefehle sind.
-
In einer weiteren bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass die Datenübertragung mittels Standard-Diagnosebefehlen über eine UDS-Schnittstelle erfolgt.
-
In einer weiteren bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass die Datenübertragung mittels standardprotokoll-unabhängigen Befehlsfolgen erfolgt.
-
Erfindungsgemäß ist vorgesehen, dass die vorgegebene Bedingungeine, durch eine Person oder einen Roboter ausgeführte, vorgegebene Abfolge von Betätigungen im Fahrzeug ist, eine Person betätigt beispielsweise die Bremse oder den Gangwählhebel.
-
Nicht-erfindungsgemäß ist vorgesehen, dass die vorgegebene Bedingung eine der folgenden Bedingungen ist:
- ein vorgegebenes Signal eines externen Testers, welches durch ein vorgegebenes Steuergerät detektiert wird
-
Detektion von erstmaliger Spannung an einem vorgegebenen Steuergerät oder Ablauf eines vorgegebenen Zeitraums nach erstmaliger Detektion von Spannung an einem vorgegebenen Steuergerät, wobei das vorgegebene Steuergerät bevorzugt das, die Datenübertragung veranlassende Steuergerät ist.
-
In einer weiteren bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass Daten aus dem nicht-flüchtigen Speicherbereich des Kupplungsaktors sowie aus dem nicht-flüchtigen Speicherbereich eines weiteren Kupplungsaktors übertragen werden, oder Daten aus mehreren oder allen getriebefesten Steuergeräten und/oder Aktoren die einen nicht-flüchtigen Speicherbereich aufweisen übertragen werden, falls die Daten auf mehrere Speicher aufgeteilt vorliegen.
-
In einer weiteren bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass das, die Datenübertragung veranlassende Steuergerät die weitere Steuerung der Inbetriebnahme steuert.
-
In einer weiteren bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass das erste Steuergerät das Getriebesteuergerät TCU zur Steuerung des Kupplungsaktors sowie zur Steuerung des Getriebeaktors ist und/oder das zweite Steuergerät das Motorsteuergerät zur Steuerung der Antriebseinheit ist.
-
Auf diese Weise können die EOL-Abläufe vereinfacht werden, der Fahrzeugwerk-Tester entfallen, zudem kann vollständig auf Spezial-Diagnosebefehle verzichtet werden und eine hohe Sicherheit gegen Fehlerbedienung gewährleistet werden.
-
Weitere Vorteile und vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der nachfolgenden Figuren sowie deren Beschreibung.
-
Es zeigen im Einzelnen:
- 1 schematisch Situation im Fahrzeug oder Fahrzeugwerk.
- 2 schematisch Situation im Getriebewerk oder am Prüfstand.
- 3 schematisch: am Prüfstand ermittelte und in prüfstandsfester TCU gespeicherte Parameter auslesen und im getriebefesten HCA speichern
- 4 schematisch: Parameter-Daten gemäß Stand der Technik mittels externen Tester aus HCA auslesen und an TCU übertragen.
- 5 schematisch ein Ausführungsbeispiel der Erfindung: Parameter-Daten mittels externen Tester aus HCA auslesen und an TCU übertragen.
-
Die Lösung wurde erarbeitet für ein TCU-HCA-System. Dieses bekommt seine Sollwerte von einem übergeordneten Triebstrangsteuergerät. Das TCU-HCA-System wechselt gesteuert über eine Gangschnittstelle selbständig Gänge und kontrolliert gesteuert über eine Momentenschnittstelle das gewünschte Kupplungsmoment.
-
Der Hydrostatische Kupplungsaktor (HCA) ist mit einer CPU sowie Speicher ausgestattet. Der HCA kommuniziert mit der TCU und erhält im Normalbetrieb von dieser beispielsweise Positionsanforderungen für die Kupplung, die der HCA entsprechend umsetzt. Die Kommunikation erfolgt über einen separaten CAN-Bus, an den nur die TCU und die beiden HCA angeschlossen sind.
-
Für die Wartung und Inbetriebnahme sind die HCAs mit Diagnose-Services ausgestattet. Mit diesen ist es unter anderem möglich die Steuergerätesoftware auf den aktuellen Stand zu bringen. Hierfür sind unter anderem Download- und Upload-Services im HCA implementiert.
-
Der Download erfolgt üblicherweise durch ein externes Gerät (Tool) wie beispielsweise einen Tester, welches über die TCU und deren Gateway-Funktion den Zugriff auf den privaten CAN und somit den HCA steuert. Durch die Gateway-Funktion der TCU wird der HCA logisch (nicht physikalisch) mit dem Tester verbunden.
-
Situation im Fahrzeug bzw. Fahrzeugwerk. - Diese Situation ist in 1 dargestellt:
- Die TCU 30 kommuniziert über den Fahrzeug-CAN 20 mit anderen Steuergeräten wie z.B. Motorsteuerung (ECU) 40 oder AntiBlockierSystem (ABS) 50. An diesen Bus 20 kann auch ein externer Tester 10 angeschlossen werden und auf die an diesen Bus 20 angeschlossenen Systeme und deren Funktionen zugreifen. Eine Kommunikation einschließlich Flashen zwischen Tester 10 und HCA 80, 90 ist über die Gateway-Funktion 70 der TCU 30 möglich.
-
Situation im Getriebewerk (GW bzw. am Prüfstand. - Diese Situation ist in 2 dargestellt:
- Die TCU 30 - mit Serien-Software - ist im Prüfstand 170 verbaut und damit Bestandteil des Prüfstand 180. Der Fahrzeug-CAN 20 und/oder die fehlenden Steuergeräte können vom Prüfstand 170 simuliert werden.
-
Der Prüfstand 170, welcher einen externen zusätzlichen Tester ersetzt, kommuniziert über Diagnosebefehle mit der TCU 30 und über das Gateway 70 mit dem HCA 80,90. Über Diagnosebefehle an die TCU 30 werden insbesondere Lernprozesse angestoßen. Die Tatsache, dass der Prüfstandsrechner 160 den externen Tester für das TCU-HCA-System ersetzt, ist bekannt und Stand der Technik.
-
Die bei der Inbetriebnahme im GW ermittelten Parameter werden in der - prüfstandsfesten-TCU 30 gespeichert, können aber auch vom Prüfstand 170 aus der TCU 30 ausgelesen werden und stehen somit zur weiteren Verwendung zur Verfügung.
-
Wird nun das Getriebe nach dem Prüflauf ins Fahrzeugwerk (FW) transportiert, so müssen die bereits gelernten Parameter ebenfalls ins FW gelangen. Wenn nun aus logistischen Gründen die TCU nicht mit dem Getriebe ins FW transportiert wird, so muss nach einer Lösung gesucht werden, die Daten trotzdem im FW verfügbar zu machen. Dies ist über Barcode, andere Datentransfermethoden beispielsweise einer Datenbank oder mit den in der deutschen Patentanmeldung
DE 10 2011 108 750 A1 sowie den deutschen Offenlegungsschriften
DE 2005 000 888 A1 und
DE 10 2007 040 485 A1 beschriebenen Verfahren möglich.
-
Dieses wird nachfolgend in 3 nochmals kurz dargestellt, um das Verständnis für die weitere Verbesserung darzustellen.
-
Die während dem Prüflauf am Prüfstand 170 ermittelten und in der prüfstandsfesten TCU 30 gespeicherten Parameter 150 können vom Prüfstand 170 aus der TCU 30 mittels Diagnosebefehl ausgelesen, dort - im Prüfstand 170 - zwischengespeichert 140 werden und per Download-Befehl im getriebefesten HCA 80, 90 nichtflüchtig z.B. im EEPROM 130 gespeichert werden. Hierzu muss im HCA 80, 90 entsprechender Speicherplatz 130 vorgesehen werden.
-
Durch die Speicherung der getriebespezifischen Parameter im getriebefesten HCA 80, 90 können diese ohne Verwechslungsgefahr und Handlingaufwand ins Fahrzeugwerk transportiert werden. Im Fahrzeugwerk wird erstmals das Getriebe mit dem Getriebesteuergerät (TCU) zusammengeführt. Es besteht nun die Aufgabe die Bedatung der „neuen“ TCU - welche beim Lernvorgang im GW nicht vorhanden war - mit den bereits vom Getriebewerk bekannten Parametern durchzuführen.
-
In üblichen Anwendungen, wie sie in 4 schematisch dargestellt sind wird dieser Datenupdate durch Diagnosebefehle eines externen Testers 10 angestoßen und kontrolliert.
-
Mit einem Diagnosebefehl werden die Parameter-Daten aus dem HCA 80, 90 ausgelesen (upload).
-
Dann werden die Parameter-Daten im Tester 10 für die Übertragung an die TCU 30 aufbereitet.
-
Dann werden die Parameter-Daten mit einem weiteren Befehl an die TCU 30 übertragen (geflasht).
-
In der neuen, in 5 dargestellten Lösung wird nun der Datenupdate durch Befehle eines bereits im Steuergeräteverbund vorhandenen Steuergeräts - in einem Ausführungsbeispiel der Erfindung der ECU 40, im Folgenden als übergeordnetes Steuergerät bezeichnet - angestoßen und kontrolliert. Vorteilhafterweise steuert dieses übergeordnete Steuergerät - also in diesem Ausführungsbeispiel die ECU 40 - die Übertragung über Standard-Diagnosebefehle über die UDS-Schnittstelle. Es ist aber auch eine standardprotokoll-unabhängige Befehlsfolge vorstellbar. Anstelle des Testers 10 gemäß obigem Ablauf zu 4 steuert gemäß dieser Ausführungsform der Erfindung das übergeordnete Steuergerät - also die ECU 40:
- Mit einem Diagnosebefehl werden die Parameter-Daten aus dem HCA 80, 130, 90 ausgelesen (upload).
-
Dann werden die Parameter-Daten in der ECU 40, 140 für die Übertragung an die TCU 30 aufbereitet.
-
Dann werden die Parameter-Daten mit einem weiteren Befehl an die TCU 30 übertragen (geflasht).
-
Das übergeordnete Steuergerät - in diesem Ausführungsbeispiel die ECU 40 - kann dabei über verschiedene Methoden zur Auslösung der Datenübertragung von HCA 80, 130, 90 in die TCU 30 aktiviert werden. Dies kann sein:
- ein MMI, wie z.B. durch den Werker betätigte Bremse oder Wählhebel
- ein externer Tester, welche dann nur mit dem übergeordneten Steuergerät - in diesem Ausführungsbeispiel der ECU 40 - kommuniziert
- ein zeitlicher Trigger zum Beispiel erstmals Spannung an einem Steuergerät - beispielsweise am übergeordneten Steuergerät - in diesem Ausführungsbeispiel an der ECU 40.
-
Die vorgeschlagene Lösung zeichnet sich aus durch:
- 1) den Entfall des Fahrzeugwerk-Testers
- 2) eine sehr hohe Sicherheit gegen Fehlerbedienung - insbesondere bei Aktivierung über b) bzw. a). Automatische Routinen zwischen HCA und TCU, wie Update, wenn TCU nicht bedatet ist, könnten fehlerhaft im Fahrzeugbetrieb ausgelöst werden.
- 3) dadurch keinen Mehraufwand in HCA und TCU, da vorhandene Diagnosebefehle zur Kommunikation genutzt werden können. Im HCA-TCU-Verbund müssen weniger Kombinationen entwickelt und getestet werden. Bei geschickter Architektur können die notwendigen ECU-Ansteuerungs- und Verarbeitungsbefehle direkt aus dem Werkstatttester übertragen werden.
-
Das übergeordnete Steuergerät - außerhalb des TCU-HCA-Verbunds - kann nicht nur für die Kontroller der Datenübertragung zwischen HCA und TCU sondern auch für die weitere Steuerung der Inbetriebnahme im Fahrzeugwerk genutzt werden.
-
Sollte der Speicherbedarf der TCU-Parameter größer sein als der in einem HCA dafür verfügbare Speicher, so können die Parameter auf alle getriebefesten Steuergeräte aufgeteilt werden. In dem Ausführungsbeispiel gemäß 5 wäre dies die Aufteilung auf die beiden HCAs HCA1 und HCA2. Die Diagnosebefehle zum Speichern in den HCAs sowie zum Auslesen aus den HCAs sind dann entsprechend mehrfach auszuführen.
-
In einem weiteren Ausführungsbeispiel der Erfindung ist vorgesehen, dass die TCU das übergeordnete Steuergerät ist. In diesem Fall sind die Download-Funktion sowie Upload-Funktion in der TCU implementiert. Anstatt der Download-/Upload-Funktion kann man auch andere Diagnoseservices wählen.
-
Der Upload-Mechanismus ist also selbst in der TCU hinterlegt. Die TCU erkennt anhand bestimmter oben beschriebener Signale und/oder Randbedingungen den Bedarf eines Uploads und führt diesen durch. Dies ist sicherheitstechnisch entsprechend abgesichert, sodass dies beispielsweise nicht im laufenden Fahrbetrieb etc. erfolgt.
-
Durch die Nutzung eines im Steuergeräteverbund vorhandenen Steuergeräts, das beispielsweise mit MMI ausgestattetet ist, zur Vorgabe von Diagnosebefehlen, ist es möglich auf einen ansonsten notwendigen Diagnosetester im Fahrzeugwerk zu verzichten
-
Bezugszeichenliste
-
- 10
- Externer Tester
- 20
- Fahrzeug CAN
- 30
- TCU
- 40
- ECU
- 50
- ABS
- 60
- Privater CAN
- 70
- Gateway
- 80
- HCA1
- 90
- HCA2
- 100
- Getriebeaktor
- 110
- Getriebe
- 120
- RAM Speicher
- 130
- EEPROM/Flash Speicher
- 140
- Zwischenspeicherung
- 150
- Gelernte Parameter
- 160
- Prüfstands-PC
- 170
- Prüfstand
- 180
- TCU ist Teil des Prüfstands
