DE60019383T2

DE60019383T2 - Diagnostik- und Aktualisierungs-system für Bauelemente eines Kraftfahrzeugs

Info

Publication number: DE60019383T2
Application number: DE60019383T
Authority: DE
Inventors: Kevin D. Snow; Matt W. Starks; Steven L. Melvin; Douglas C. Gooch; Edward F. Handley
Original assignee: Eaton Corp
Current assignee: Eaton Corp
Priority date: 1999-08-06
Filing date: 2000-08-04
Publication date: 2006-03-09
Anticipated expiration: 2020-08-05
Also published as: DE60019383D1; BR0003657A; BR0003657B1; US6434455B1; EP1089179A1; EP1089179B1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft die Diagnose und Neukonfiguration eines Fahrzeugkomponentenmoduls, wie es bspw. einem automatisierten Getriebe eines Schwerlastfahrzeugs zugeordnet ist, mittels eines lokalen Computers, der mit einem zentralen Server in Kontakt steht.
HINTERGRUND DER ERFINDUNG
Fahrzeugkomponentenmodule, die unterschiedlichen Fahrzeugkomponenten zugeordnet sind, sind bspw. aus der US-Patentschrift 5 884 073 allgemein bekannt. Diese Druckschrift beschreibt ein Fahrzeug, das ein wiederprogrammierbares Fahrzeugmodul aufweist, das einen nicht flüchtigen Speicher enthält, dessen Inhalt modifiziert werden kann. Ein Service Computer PCB ist über eine Telefonleitung mit dem Fahrzeugmodul zu verbinden. Der entfernt installierte Service Computer erlangt einen Fernzugriff auf das wiederprogrammierbare Fahrzeugmodul über die Telefonleitung, die eine erste Datenverbindung zu dem fahrzeugeigenen Fahrzeugmodul herstellt. Derartige Module werden programmiert, um Fahrzeugkomponenten zu steuern, mit denen sie verbunden sind, und um Komponentenfehlerinformationen abzuspeichern, die als Fehlercodes bekannt ist. Die Module sind wiederum in der Lage, wahlwiese mit einem angeschlossenen lokalen Computer zu kommunizieren, der die Fehlercodeinformation abrufen kann.
Unglücklicherweise ist lediglich eine begrenzte Di agnostik zwischen dem Service Computer und dem Modul, mit dem er kommuniziert, möglich. Ein Techniker ruft häufig einen Fehlercode ab und versucht anschließend selbst, diesen in einer Problembeseitigungsanleitung oder einem Servicemanual nachzuschlagen. Selbst wenn er dabei erfolgreich ist, gehen die durch den Techniker unternommenen Schritte verloren, sobald der Prozess beendet ist und ein beliebiger anderer Techniker, der eine ähnliche Diagnoseprozedur in der Zukunft vornimmt, den Diagnoseprozess neu erzeugen muss.
Darüber hinaus werden Module durch einen lokal angeordneten Service Computer, der keinen Zugriff auf einen zentralen Server aufweist, nicht ohne Weiteres aktualisiert. Störungsbeseitigungen und Änderungen von Komponentenmerkmalen werden meistens durch den Einbau eines kompletten, neu programmierten Moduls durch einen Techniker und nicht durch Aktualisierung des vorhandenen Moduls bewerkstelligt. Eine derartige Vorgehensweise ist durch eine Reihe von Erwägungen erforderlich. Beispielsweise sind im Allgemeinen so viele Parameter verfügbar, dass ein lokaler Computer nicht in der Lage ist, diese zu speichern. Außerdem sind einige Parameter höchst empfindlich, so dass es unpassend wäre, wenn sie auf einem bleibigen möglichen Komponentenmodul installiert werden könnten. Ferner können, wenn bestimmte Parameter in einem Modul installiert sind, andere Parameter vollständig ungeeignet sein, wobei eine teilweise Überschreibung zuvor installierter Parameter durch einen zum Teil neuen Parametersatz die Programmierung des Moduls unterminieren und das Verhalten der Komponente selbst beeinträchtigen kann.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Servicelogistiksystem, das ein wiederprogrammierbares fahrzeuggetragenes Modul, einen Service Computer und einen zentralen Server aufweist, wie dies in dem beigefügten Anspruch 1 definiert ist. Der Service Computer ist mit dem Modul über eine erste Datenverbindung verbunden, während der Service Computer wiederum mittels einer zweiten Datenverbindung mit dem Server verbunden ist. Eine Komponenteninformation, die dem Modul zugeordnet ist, wird durch den Service Computer abgerufen und dann an den zentralen Server übermittelt. Der zentrale Server ist in der Lage, die Komponenteninformation dazu zu verwenden, angepasste Diagnoseszenarios zu liefern, die Eigenschaften des Moduls und ihrer zugehörigen Komponenten mit berücksichtigen. Somit wird der Diagnoseservice stark verbessert. Gemäß einem Aspekt der Erfindung werden Fehlercodes verwendet, um angepasste Debugging-Szenarios zu liefern. Gemäß einem weiteren Aspekt der Erfindung wird ein Listing aller verfügbaren Symptome an einen Servicetechniker geliefert, wobei anschließend eine Auswahl der geeigneten Symptome, die zu verwendenden Debugging-Szenarios bestimmt.
Eine Abspeicherung der Komponenteninformation auf dem Server führt ebenfalls zu einer weitgehend verbesserten Komponentenmodulaktualisierung. Beispielsweise kann die Komponenteninformation dazu verwendet werden, die verfügbaren Parameter zu bestimmen, die zu dem Modul von einer Liste aller möglichen Parameter herunterzuladen sind. Außerdem kann der Server in dem Fall, wenn empfindliche oder private Parameter herunterzuladen sind, die Parameter unter Verwendung der Komponenteninformation derart verschlüsseln, dass lediglich das Modul, für das die Parameter bestimmt sind, die Parameter entschlüsseln kann. Es ist sogar möglich, neu entwickelte Parameter als Reaktion für eine Zahlung zu liefern, ohne dass die Parameter zu einem neuen Modul heruntergeladen werden müssen und das Modul unmittelbar zu dem Servicetechniker des Fahrzeugs geliefert werden muss.
Das erfindungsgemäße Servicelogistiksystem bietet ein Mittel zur Aufzeichnung erfolgreicher Diagnose- oder Aktualisierungsprozeduren, so dass verbesserte Debugging- oder Aktualisierungsszenarios entwickelt werden können. Falls im Feld Probleme mit einer Komponente bemerkt werden, können die Probleme schnell eingegrenzt und für sämtliche Servicetechniker neue Aktualisierungen oder Debuggingszenarios sofort zur Verfügung gestellt werden.
Die Erfindung hilft sogar, eine Fahrzeugkomponente über ihre gesamte Nutzdauer hinweg zu verfolgen, selbst wenn sie in unterschiedlichen Fahrzeugen verwendet wird. Eine Abspeicherung einer derartigen historischen Information kann geeignete Debuggingszenarios oder Komponentenaktualisierungen liefern, die allein aus einer Überprüfung der dem Modul zugeordneten Komponenteninformation nicht bestimmt werden können.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und erfinderischen Aspekte der vorliegenden Erfindung erschließen sich beim Studium der folgenden detaillierten Beschreibung, Ansprüche und Zeichnungen, von denen im Folgenden eine Kurbeschreibung angegeben ist:
1 zeigt ein Flussdiagramm einer bevorzugten Ausführungsform eines Servicelogistiksystems entsprechend der vorliegenden Erfindung.
2 zeigt eine Flussdiagrammdarstellung einer bevorzugten Ausführungsform einer Diagnostik gemäß der vorliegenden Erfindung.
3 zeigt eine Flussdiagrammdarstellung einer bevorzugten Ausführungsform einer Komponentenaktualisierung entsprechend der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
In 1 ist ein Servicelogistiksystem 10 veranschaulicht, das eine oder mehrere miteinander verbundene elektronische Kommunikationseinheiten oder -module 12 aufweisen, von denen jede einer Fahrzeugkomponenten zugeordnet ist, die zu warten ist oder von der eine Information abzurufen ist. Das System 10 enthält einen lokalen Computer, bspw. einen Service-PC 14, und einen entfernt angeordneten Computer, bspw. einen Server 16. Das Modul 12 ist mit dem Service-PC 14 über einen Fahrzeugdatenlink 18 verbunden, um ein Service-Interface 19 zu bilden, während der Service-PC 14 mit dem entfernten Server 16 über eine Ferndatenverbindung 20 verbunden ist, um ein Client-Server-Interface 21 zu bilden, das entweder eine dedizierte Kommunikationsverbindung oder das Internet enthalten kann.
Das System 10 ist dazu eingerichtet, für das Außendiensthilfspersonal unterschiedliche mit dem Fahrzeug verbundene logistische Dienstleistungen bereitzustellen. Für die Zwecke der nachfolgenden Beschreibung wird das System 10 in Verbindung mit einem Fahrzeuggetriebe eingesetzt. Es kann jedoch eine beliebige geeignete Fahrzeugkomponente in ähnlicher Weise unter der Verwendung des Systems 10 gehandhabt werden.
Wie in einem Hauptmenü Optionen 22, das von dem Service-PC 14 auswählbar ist, veranschaulicht, enthalten verfügbare Services eine Fahrzeug- oder Komponentenidentifikation/-historie 24, eine Diagnose 26, eine Komponentenaktualisierung 28, eine Teilebeschaffung 30, eine elektronische Literaturbibliothek 32, eine Aktualisierung der Service-PC/Server-Datenuntermenge 34, geschäftliche Kommunikationen 36 und ein Verlassen des Systems 37 (Ende).
Das Client-Server-Interface 21 ist in erster Linie dazu vorgesehen, eine Information zwischen den Service-PCs 14 und dem Server 14 in Echtzeit zu übermitteln. Somit sollte die Ferndatenverbindung 20 so schnell wie möglich sein.
Vorzugsweise enthält der Service-PC 14 die folgende minimale Konfiguration: einen Intel^® Pentium^® II Prozessor, ein Betriebssystem, wie bspw. Microsoft^® Windows^®, 64 Megabyte Direktzugriffsspeicher, ein CD-ROM- oder DVD-Laufwerk oder dergleichen, ein Modem oder eine Netzwerkschnittstellenkarte, eine Festplatte mit wenigstens 1 Gigabyte Speicherplatz und einen RS232-Kommunikationsanschluss. Das Modem oder die Netzwerkkarte ist für die Kommunikation mit dem Server 14 erforderlich. Wenn eine Hochgeschwindigkeits-Ferndatenverbindung 20 verfügbar ist, benötigt der Service-PC 14 im Allgemeinen lediglich ausreichend Plattenspeicherraum, um eine lokale Datenwarteschlange 40 und eine kleine Serverdatenuntermenge 42, die hauptsächlich eine Auflistung der momentanen Softwarefassung für jedes Modul 12 aufweist, das sie einliest, und gegebenenfalls eine Kopie der neuesten Version für jedes Modulmodel zu unterstützen. Ein derartiges Vorgehen kann gewünscht sein, um das Erfordernis, den Service-PC 14 ständig zu aktualisieren, auf ein Minimum zu reduzieren. Nichtsdestoweniger ist auch ein eine relativ hohe Geschwindigkeit aufweisendes CD-ROM- oder DVD-Laufwerk 38 oder dergleichen spezifiziert, um wenigstens einige Diagnostik oder Aktualisierungen in den Fällen bereitzustellen, wenn die Ferndatenverbindung 20 langsam ist. Wenn die Datenverbindung 20 langsam ist, speichern sowohl das Festplattenlaufwerk als auch das CD-ROM- oder DVD-Laufwerksmedium eine wesentlich größere Untermenge der Serverdaten 42.
In jedem Fall, wenn der Service-PC 14 mit dem Server 16 kommuniziert, bestimmt der Server den Status der Information in der Serverdatenuntermenge 42 und bietet an, die in der Datenuntermenge abgespeicherte Information zu aktualisieren, um ihre Aktualität aufrechtzuerhalten. Wenn die Information nicht aktuell ist, wird der Benutzer aufgefordert, einen Download der aktualisierten Information zuzulassen. Der Benutzer hat jedoch auch die Option, den Download auf einen geeigneteren Zeitpunkt zu verschieben. Außerdem kann der Benutzer eine komplette neue Synchronisierung der verfügbaren Information, die in der Serverdatenuntermenge 42 und dem Server 16 enthalten ist, zu erzwingen, indem er aus den Menüoptionen 22 die Aktualisierung der Service-PC-/Server-Datenuntermenge 34 auswählt.
Der Server 16 ist ein schneller Computer, der verwendet wird, um Applikationen für einen Client, bspw. den Service-PC 14, auszuführen, interne Applikationen auszuführen und große Menge von Daten zu speichern. Der Server 16 sollte zumindest eine standardgemäße Serverhardwareplattform, eine Netzwerkschnittstellenkarte oder ein Modem bzw. Modems, die bzw. das dazu eingerichtet ist/sind, mit mehreren Service-PCs 14 bei größtmöglichen Übertragungsgeschwindigkeiten verbunden zu werden, ein CD-ROM- oder DVD-Laufwerk oder dergleichen und ausreichend Direktzugriffsspeicher und Einrichtungen zur Abspeicherung einer Information aufweisen. Wie in 1 veranschaulicht, enthält der Server 16 eine Komponentenverfolgungsdatenbank 44, eine Konfigurationsabrufdatenbank 46 und eine Diagnosedatenbank 48.
Die Komponentenverfolgungsdatenbank 44 wird dazu verwendet, eine Benutzerautorisierung festzulegen, eine Produktbetriebshistorie (z.B. Histogramme/Aufzeichnungen kritischer Betriebsparameter oder Konfigurationen und früherer Servicemaßnahmen) und eine Produktinhaberschaft zu verfolgen. Parameter, die gespeichert werden, umfassen Fahrzeugidentifikationsnummern, eine Modulidentifikationsinformation, Modulsoftwareversionsinformation und sehr spezielle Produkt- oder Komponentenkonfigurationsinformationen sowie eine Verhaltenshistorie. Es ist sogar möglich, Angelegenheiten im Zusammenhang mit dem Ersatz von Teilen zu verfolgen.
Die Konfigurationsabrufdatenbank 46 wird dazu verwendet, für die Module 12 verfügbare Modifikationen und Aktualisierungen zu halten. Die Diagnosedatenbank 48 enthält eine computerunterstütze Software zur Störungsbeseitigung und Fehlereingrenzung mit einer Fehlerbaumausführung, Teilebeschreibungen, Leitlinien für die Problembeseitigung, Anwendungsrichtlinien, ein Manual mit veranschaulichten Teilen und sogar Trainingmaterialien.
Um die Verwendung der unterschiedlichen Datenbanken und die Kommunikation mit den Service-PCs 14 zu erleichtern, sollte sowohl der Service-PC 14 als auch der Server 16 gewöhnlich eine geeignete Applikations- oder Client-Server-Software enthalten, um die folgenden Servicemaßnahmen zu unterstützen. Die erforderliche Applikationssoftware enthält: (1) Informationslieferung (z.B. die Fähigkeit, Informationen oder Berichte im „HTML" (Hypertext Marked Up Language) – Format, im „XML" (Extensible Marker Langauge) – Format und im Adobe^® Acrobat^® .pdf-Format zu liefern); (2) Sicherheit (z.B. eine Datenverschlüsselung für die Sicherheit und Integrität zwischen dem Server 16 und dem Service-PC 14); (3) Geschäftstransaktion (z.B. elektronische Mail, Berechtigungs- und Autorisierungsinformation, Information über die autorisierte Stelle, Daten über den administrativen Kontakt, den Service-PC-Administrator und die zugeteilten Nutzer sowie ihre Autorisierungsstufe und eine elektronische kommerzielle Schnittstelle, bspw. eine Kreditkartenbestellung und -autorisierung); und (5) Kommunikationen (z.B. die Fähigkeit, Datenpakete unter Verwendung des „HTTP"-Protokolls (Hyper-Text Transfer Protocol) zu übertragen. Gewöhnlich wird zur Vornahme der erwähnten Servicemaßnahmen durch jeden Service-PC 14 ein Web-Browser, bspw. Netscape^® Communicator^® oder Microsoft^® Explorer^®, verwendet.
Die dem Service-PC 14 zugeordnete Benutzerschnittstelle ist überwiegend eine graphische Schnittstelle. Es dominieren Menüs und Listenauswahlmöglichkeiten, wie dies in den Figuren veranschaulicht ist. Wenn möglich, sollte die in einem Teil des Systems (z.B. dem Modul 12) verfügbare Information ohne Weiteres zu einem anderen Teil (z.B. dem Server 16) übertragbar sein, um die Notwendigkeit einer erneuten Eingabe per Tastatur sowie mögliche Eingabefehler zu vermeiden. Somit wird eine manuelle Dateneingabe, bspw. über eine Tastatur, auf ein Minimum reduziert. Ferner beruht das System 10 stark auf der Verwendung von Eingabenaufforderungen und Unterprogrammaufrufen, wie bspw. Zeitablaufwarnungen und dergleichen, um sicherzustellen, dass spezielle Tasks ordnungsgemäß zu Ende geführt werden.
Um die Service-Schnittstelle 19 zu vereinfachen, benötigen sowohl der Service-PC 14 als auch das Modul 12 die geeigneten Hardware- und Software-Ausstattungen, um eine Zweiwege-Übertragung über den Fahrzeugdatenlink 18 zu unterstützen. Eine Zweiwege-Übertragung ist erforderlich, um Betriebskonfigurationsänderungen des Moduls, Betriebsversionsänderungen des Moduls und unterschiedliche Formen einer Diagnoseprüfung zu unterstützen. In einer bevorzugten Ausführungsform weisen beide Komponenten eine Hardware und Software auf, die verfügbar sind, um den SAE-Standard J1708 für serielle Datenübertragungen zwischen Mikrocomputersystemen in Anwendungen für Schwerlastfahrzeuge, jedoch mit Verschlüsselung, den SAE-Standard J1587 für den gemeinsamen SAE/TMC elektronischen Datenaustausch zwischen Mikrocomputersystemen in Anwendungen für Schwerlastfahrzeuge und die Netzwerkspezifikation J1939 zu unterstützen.
In 1 ist auch die Initialisierung des Systems 10 veranschaulicht. Der Service-PC 14 kommuniziert zuerst mit dem Modul oder den Modulen 12, um die erforderliche Komponenten- oder Fahrzeuginformation 50 zu erhalten, die jede beliebige zusätzlich erforderliche Information 52 enthält, die entweder durch den Benutzer per Tastatur einge geben oder unmittelbar von dem lokalen Computer abgerufen wird. Gewöhnlich enthält die Information 50: (1) Serien-/Identifikationsnummer der Komponente; (2) Serien-/Identifikationsnummer des Fahrzeugs; (3) Modulrevisionsstand (Applikation und Revision); (4) Information über die momentane Komponentenkonfiguration; (5) Hersteller und Identifikation der Motorsteuerung; (6) Fahrzeugherstellung; (7) Meilen- oder Kilometerstand des Fahrzeugs; (8) Servicestellen-Identifikationsinformation; (8) Systembenutzer-Identifikationsinformation und (9) aktuelles Datum und aktuelle Zeit.
System 10 bestimmt in Punkt 54, ob es möglich ist, mit dem Server 16 unmittelbar zu kommunizieren. Falls eine Echtzeitkommunikation möglich ist, bestimmt der Server 16 in Punkt 56 die Benutzerzugriffsebene basierend auf stellenspezifischen Optionen und der Systembenutzer-Identifikationsinformation.
Das Servicelogistiksystem 10 zieht unterschiedliche Benutzerebenen in Bezug auf den Service PC 14 in Betracht. Die Liste des Hilfspersonals enthält Menschen von einem Mechaniker in einem Laden bis zu einem Komponentenherstellungsexperten, der im Feld fortgeschrittene Komponentenservicemaßnahmen durchführt. Die Nutzerberechtigungsstufe wird pro Komponente und durch die Facility vergeben. Wenn unterschiedliche Nutzerebenen implementiert sind, sind die für den Benutzer verfügbaren Menüs und Optionen unterschiedlich.
Ein Basisbenutzer hat Zugriff auf begrenzte Funktionen, um eine einfache Diagnostik und Produktreparatur zu ermöglichen. Ein derartiger Benutzer ist in der Lage, eine Servicemaßnahme einzuleiten, Fehlercodes abzurufen und zu löschen, Auswahlisolationsverfahren vorzunehmen, Daten zu überwachen und aufzuzeichnen, Serviceaktivitätsberichte zu empfangen und Hilfefunktionen für die Bereiche zu nutzen, für deren Nutzung er eine Erlaubnis hat.
Ein Zwischenstufennutzer ist mit der Komponente, die gewartet wird, mehr vertraut und nutzt gewöhnlich weitergehende Diagnosemerkmale, um Servicemaßnahmen an einer Komponenten durchzuführen. Deshalb hat ein Zwischenstufennutzer sämtliche Funktionen, die für einen Basisnutzer verfügbar sind, gemeinsam mit einer verfeinerten Symptomdiagnose und dergleichen. Darüber hinaus ist ein Zwischenstufennutzer in der weiteren lage, eine Komponenten zu aktualisieren, einschließlich eine Programmspeicheraktualisierung, Kalibrierung, berufliche Änderungen und Merkmalsaktualisierungen vorzunehmen.
Ein Nutzer einer fortgeschrittenen Stufe ist ein Experte für die Komponente, die gewartet wird, und hierzu zählt gewöhnlich das Hilfspersonal des Herstellers. Ein fortschrittlicher Nutzer enthält all die vorhandenen Funktionen, wie sie für den Produktservice verfügbar sind, zuzüglich der Möglichkeit, beträchtliche Konfigurationsänderungen der Komponente vorzunehmen.
Wie in Punkt 58 veranschaulicht, wird als nächstes die Information 50 in Echtzeit gemeinsam mit dem Server 16 benutzt, um die abgespeicherte Verfolgungs- und Identifikationsinformation, die die spezielle Komponente und das Fahrzeug betrifft, in der Komponentenverfolgungsdatenbank 44 zu aktualisieren. Falls keine Aufzeichnung in der Datenbank 44 erzeugt worden ist, wird eine Aufzeichnung erzeugt.
Ansonsten, wenn eine Echtzeitkommunikation in Punkt 54 nicht möglich ist, wird die Information 50 in der Warteschlange 40 gespeichert, wie in Punkt 60 veranschaulicht, um später hochgeladen zu werden, wenn die Verbindung wieder hergestellt ist. Anschließend wird in Punkt 62 die Stufe des Benutzerzugriffs basierend zum Teil auf der Information, die in der Serverdatenuntermenge 42 verfügbar ist, ermittelt. Ein vollständiger Zugriff auf die Menüoptionen 22 ist jedoch nicht möglich.
Nach der Übermittlung oder Abspeicherung der Information 50 und der Bestimmung der Nutzerzugriffsstufe sind in der Information 50 genug Daten enthalten, um eine Bestimmung zu ermöglichen, ob die dem Modul 12 zugeordnete Komponente eine ist, auf der eine Servicemaßnahme durchgeführt werden kann (d.h. ob sie durch den Hersteller gebaut worden ist), wie dies in Punkt 64 ermittelt wird. Das System 10 kehrt zu der Aufrufoperation in Punkt 66 zurück, falls eine Servicemaßnahme nicht möglich ist.
Falls eine Servicemaßnahme möglich ist, leitet das System 10 in Punkt 68 eine Aufzeichnung sämtlicher Serviceaktivitäten ein, die der Servicesitzung zugeordnet sind, um später einen Serviceaktivitätsbericht zu erzeugen. Ein Serviceaktivitätsbericht ist eine „Zusammenstellung" von Hauptaktionen, die während einer einzelnen Sitzung zu diagnostischen Zwecken vorgenommen werden. Er enthält eine Debug-Endindikation und enthält Schlüsseldaten, die in Bezug auf eine spezielle Komponente eines Fahrzeugs eingelesen oder eingegeben worden sind. Das ausgewählte Debuggingszenario, wie es nachfolgend beschrieben ist, die ausgeführten Schritte und die gemessenen Werte werden ebenfalls in dem Serviceaktivitätsbericht aufbewahrt. Der Be richt wird dem Benutzer jedes Mal angeboten, wenn das Programm einen „Ende"-Befehl empfängt, und zwar innerhalb der meisten Systemmenüs, wie dies bei dem Ende-Punkt 37 unter den Menüoptionen 22 veranschaulicht ist.
Bei der Beendigung oder beim Verlassen des Systems 10 wird der Aktivitätsbericht in einer Historiendatei auf dem Service-PC 14 gespeichert und optional vollständig oder teilweise in die Komponentenverfolgungsdatenbank 44 hochgeladen. Historiendateien werden auf dem Service-PC 14 für eine vorbestimmte Zeitdauer oder solange aufbewahrt, bis das Erreichen von Speicherplatzgrenzen erfasst wird. Falls die Historiendateien vorzeitig gelöscht werden sollen, sollen die ältesten Dateien zuerst gelöscht werden, und zwar gewöhnlich nachdem der letzte Systembenutzer benachrichtigt worden ist.
Das System 10 geht von dem Punkt 68 zu den Menüoptionen 22 über. Die erste verfügbare Auswahl, die Fahrzeug-/Komponentenaktivitätshistorie 24, ermöglicht einem qualifizierten Benutzer, die verfügbare Information über eine bestimmte Fahrzeugkomponente aus der Komponentenverfolgungsdatenbank 44 zu erhalten. Wie vorstehend erwähnt, umfasst eine derartige Information die Komponentenbetriebshistorie (z.B. Histogramme/Aufzeichnungen kritischer Betriebsparameter oder Konfigurationen sowie frühere Servicezusammenfassungen oder Serviceaktivitätsberichte) und eine Verfolgung der Produktinhaberschaft.
Die Diagnostik 26 ist in größerer Einzelheit mit Bezug auf 2 beschrieben. Wenn die Diagnostik 26 ausgewählt wird, wird ein Diagnoseoptionsmenü 80 dargeboten.
Die ersten drei Optionen betreffen sämtliche Komponentenfehlerinformationen (d.h. Fehlercodes), die durch das Komponentenmodul und/oder andere mit dem Modul 12 verbundenen Module bereits detektiert worden sind, während die Option 81 die Rückkehr des Systems 10 zu der Aufrufoperation (z.B. dem Menü 22) betrifft. Eine Fehlercodeanalyse (82) ermöglicht den Abruf und die Überprüfung von Fehlercodes. Eine Option 84 betrifft das Löschen aktiver Fehlercodes, während eine Option 86 das Löschen inaktiver Fehlercodes betrifft. Wenn die Codes gelöscht worden sind, wird die Anzeige aktualisiert.
Falls es nicht möglich ist, einen Code zu löschen, wird diese Information auch in dem Aktivitätsbericht an den Benutzer geliefert. Falls der Code nicht ein Produkt betrifft, das in dem Server 16 oder der Serverdatenuntermenge 42 enthalten ist, wird der Aktivitätsbericht nicht aufbewahrt, sondern die Fehlercodes werden gelöscht und die Ergebnisse angezeigt.
Aktive Fehlercodes sind Codes, die Probleme repräsentieren, die noch erkannt sind, während inaktive Fehlercodes Probleme repräsentieren, die aus einem oder anderem Grund nicht länger erkannt werden.
Nach der Auswahl der Option 82 kann der Benutzer wählen, in Punkt 88 Komponenten- oder Fahrzeugfehlercodeinformationen zu sichten. Dann wird sowohl die aktive als auch die inaktive Fehlerinformation angezeigt. Falls eine Komponenteninformation angefordert wird, werden lediglich Komponentenfehlercodes angezeigt. Falls eine Fahrzeuginformation angefordert wird, werden lediglich Fahrzeugfehlercodes angezeigt. Jeder Fehlercode kennzeichnet, welche Fahrzeug komponente zu dem Code geführt hat.
Die Codeliste wird mit zunächst den aktiven Codes angezeigt, denen die inaktiven Codes folgen. Für sowohl die aktiven als auch die inaktiven Codes werden die neuesten Codes zuerst aufgelistet. Die für jeden Code angezeigte Information ist:

MID (Modulidentifikation)
PID/SID (Parameteridentifikationszahl oder Untersystemidentifikationszahl)
FMI w/Beschreibung der FMI (Fehlermodeidentifikation)
Indexcodenummer (Indexnummer, die MID, PID/SID und FMI verknüpft)
Fehlername
Zeitstempel (PID 254, falls durch das Produkt geliefert)
Häufigkeit des Auftretens
Beschreibung des Fehlers
aktiver oder inaktiver Status.

Wenn die Codes geprüft werden, kann der Benutzer einen speziellen Fehlercode, der gewöhnlich in einer Indexcodenummer eingebunden ist, die die oben angegebene zusätzliche Information aufweist, auswählen, damit eine weitere Diagnose folgen kann. Die Verwendung einer Indexcodenummer, in der der Fehlercode enthalten ist, ist im Vergleich zu dem reinen Fehlercode selbst manchmal vorteilhaft, um mögliche Diagnoseszenarios zu verfeinern, die für eine bestimmte Komponente oder ein bestimmtes Fahrzeug verfügbar sind.
In einem Entscheidungspunkt 90 wird der Code mit der Diagnoseinformation verglichen, die entweder von dem Server 16 oder der Serverdatenuntermenge 42 verfügbar ist. Falls die den Fehlercode betreffende Information nicht verfügbar ist, kehrt das System 10 zu dem Diagnoseoptionsmenü 80 zurück, nachdem es eine Fehlermeldung ausgibt. In einer bevorzugten Ausführungsform der Erfindung kann wenigstens ein Teil des Serviceaktivitätsberichtes zu dem Server 16 übermittelt und mit einem Flag versehen werden, um durch einen Expertennutzer betrachtet zu werden, der bestimmen kann, ob Modifikationen in der Form weiterer Verbesserungen des Problemleitfadens/Servicemanuals oder der Isolationsprozeduren vorgenommen werden müssen, um sich dem Fehler zu widmen, um eine weitere Diagnose bereitzustellen. Somit werden der Problemleitfaden/das Servicemanual und die Isolationsprozeduren mit der Zeit verbessert und verfeinert. Wie nachstehend beschrieben, ist eine direkte Kommunikation mit einem Benutzer auch nach der Durchsicht des Serviceaktivitätsberichtes über die misslungene diagnostische Problembeseitigung möglich.
Falls ein Code, für die eine Diagnose verfügbar ist, ausgewählt wird, werden anschließend verschiedene zusätzliche Menüoptionen in Form von Debuggingszenarios dargeboten, zu denen der Problemleitfaden/das Servicemanual 92, die Isolationsprozedur 94, weitere Debugginsszenarios 96, die Abspeicherung einer Auflistung erforderlicher Teile 98 und eine Rückkehr zu den Diagnoseoptionen 100 zählen. Die Debuggingszenarios werden basierend nicht nur auf dem Fehlercode, sondern auch basierend auf der in der Komponentendatenbank 44 abgespeicherten Komponenteninformation, einschließlich der historischen Information, angepasst. Somit kann ein spezieller Satz von Debuggingszenarios bereitgestellt werden, um den Diagnoseprozess zu rationalisieren.
Falls der Problembeseitigungsleitfaden/das Servicemanual 92 ausgewählt wird, führt das System 10 den Benutzer zu allen Teilen des verfügbaren, elektronisch abgespeicherten Materials, die den Fehlercode betreffen. Gewöhnlich wird der Benutzer jedoch unmittelbar zu der Isolationsprozedur 94 übergehen, falls ein Fehlercode ausgewählt worden ist, weil die Isolationsprozedur dazu eingerichtet ist, den Fehlercode zu beheben, indem an der Fahrzeugkomponente eine Servicemaßnahme in der erforderlichen Weise durchgeführt wird. Die Prozedur beginnt mit einer Anforderung oder Anforderungen nach geeigneten Datenlinkinformationen zwischen dem Service-PC 14 und dem Modul 12 über die Datenverbindung 18, und es folgt die Isolierung oder Eingrenzung, um eine Komponente oder ein Komponentensystem zu reparieren oder zu ersetzen.
Der Isolationsprozess ermöglicht dem Benutzer, Messwerte einzugeben, wie sie für die Isolationsprozedur erforderlich sind. Wenn die Werte eingegeben werden, wird der als nächstes erforderliche Schritt der Isolationsprozedur oder die erforderliche Reparatur für den Benutzer automatisch angezeigt. Wie durch die Linie 102 veranschaulicht, kann die Ausführung einer Isolationsprozedur sowohl die Datenüberwachungs-/-sammlungsoption 104 als auch die Produkttestoption 106 aus dem Diagnoseoptionsmenü 80 erfordern, wie dies nachstehend näher beschrieben ist. Wenn die Isolationsprozedur beendet ist, hat der Benutzer die Wahl, eine durch die Isolationsprozedur erzeugte Auflistung sämtlicher Teile, die erforderlich sind, um eine Reparatur zu Ende zu führen, für eine spätere Bestellung abzuspeichern, wie dies in Punkt 98 veranschaulicht ist. Anschließend kann der Benutzer über die Menüoption 100 zu dem Diagnoseoptionsmenü zurückkehren.
Erfahrenere Benutzer, beispielsweise ein vorstehend beschriebener Zwischenstufennutzer, können wählen, eine Überprüfung von Fehlercodes zu umgehen und unmittelbar zu der Diagnoseoption überzugehen, die direkt der Symptomanalyse 110 zugeordnet ist. Eine Auswahl der Symptomanalyse 110 liefert eine Dialogbox, die einem Benutzer ermöglicht, in Punkt 112 aus einer Liste vordefinierter Symptome für die momentan gewartete Fahrzeugkomponente auszuwählen. Gewöhnlich sind spezielle Symptome auf dem Server 16 in einer komprimierten Form gespeichert. Sie werden zu Beginn einer Problembeseitigungssitzung zu dem Service-PC 14 heruntergeladen, wenn das Diagnoseoptionsmenü 80 ausgewählt wird und nachdem eine spezielle Fahrzeugkomponenteninformation geliefert worden ist, wie dies oben beschrieben ist. Somit ist eine Liste verfügbarer Symptome aus einer Auflistung sämtlicher möglicher Symptome basierend auf der bereitgestellten oder bereits in der Komponentendatenbank 44 abgespeicherten Komponenteninformation bestimmt. Alternativ kann wenigstens eine Untermenge der speziellen Symptome als Teil der Serverdatenuntermenge 42 abgespeichert sein.
Wenn ein Symptom identifiziert ist, ermittelt das System 10, ob eine Diagnose von dem Server 16 oder von der Serverdatenuntermenge 42 verfügbar ist, wie dies vorstehend mit Bezug auf die Fehlercodes beschrieben ist. Falls eine Diagnose für das identifizierte Symptom verfügbar ist, können anschließend der Problembeseitigungsleitfaden/das Servicemanual 92, die Isolationsprozedur 94, weitere Debuggingszenarios 96 und die Abspeicherung einer Auflistung erforderlicher Teile 98 verwendet werden, wie dies mit Bezug auf die speziellen Fehlercodes beschrieben ist. Im Falle des Problembeseitigungsleitfadens/Servicemanuals 92 wird der Benutzer zu Abschnitten des Leitfadens gelenkt, die unmittelbar das identifizierte Symptom betreffen. Falls eine Diagnose verfügbar ist, sind die vorstehend mit Bezug auf die Fehlercodes beschriebenen Ereignisse auch für die Liste gewählter Symptome verfügbar, und der Benutzer ist dann in der Lage, zu dem Diagnoseoptionsmenü 80 zurückzukehren.
Eine weitere Option, die in dem Menü 80 verfügbar ist, ist die Datenüberwachungs-/-sammlungsoption 104. Eine Auswahl der Option 104 ermöglicht einem Benutzer, alle von dem Modul 12 verfügbaren Parameter in Echtzeit über die Datenverbindung 18 zu dem Service-PC 14 zu sichten. Es sind mehrere Monitoring- und Sammlungsoptionen verfügbar, wie dies in dem Menü 114 veranschaulicht ist. Zu den Optionen zählen das Bildschirmmonitoring 116, das Drucken aus der Datei 118, eine Dateiübertragung auf den Server 120 und eine Rückkehr zu der Aufrufoperation 121. Wenn Datenüberwachung/-sammlung 104 unmittelbar aus dem Optionsmenü 80 aufgerufen wird, kehrt das System 10 somit zu dem Menü zurück. Falls Datenüberwachung/-sammlung 104 aus der Isolationsprozedur 94 aufgerufen wird, kehrt das Programm hingegen zu der Prozedur zurück und fährt mit dem nächsten Schritt fort.
Wie oben erwähnt, wird die Datenüberwachungs-/-sammlungsoption 104 häufig als Teil einer Isolationsprozedur 94, wie sie oben beschrieben ist, als Reaktion auf die Identifizierung eines speziellen Fehlercodes oder Symptoms benutzt. Deshalb ist die Möglichkeit, eine Datendatei auf den Server 16 zu übertragen, wie durch die Option 120 veranschaulicht, oder die Möglichkeit, die Datendatei auf einem Drucker auszudrucken, wie in Punkt 118 veranschaulicht, sehr wichtig. Durch die Verwendung dieser beiden Optionen ist es für einen Expertennutzer möglich, die Daten an einer entfernten Stelle anzusehen. Eine derartige Vorgehensweise bietet eine zusätzliche Diagnoseunterstützung für einen Benutzer, der dem Service-PC 14 zugeordnet ist, insbesondere wenn ein bestimmter Fehlercode oder ein bestimmtes Symptom nicht von dem Server 16 verfügbar ist.
Wenn ein Benutzer das Bildschirm-Monitoring 116 wählt, muss der Benutzer in einem Entscheidungspunkt 122 entscheiden, ob er eine bereits existierende Datendatei ansehen 124 und anschließend zu den Optionen 114 zurückkehren will oder ob er ein Echtzeit-Datenmonitoring vornehmen will. Falls die Entscheidung lautet, eine spezielle Komponente zu überwachen, muss der Benutzer in Punkt 126 Parameteridentifikationen und Meldungsidentifikationen laden oder auswählen. Gewöhnlich liegen bereits eine oder mehrere vorbestimmte Konfigurationslisten 128 vor, die ausgewählt oder modifiziert und als eine neue Liste abgespeichert werden können. Alternativ ist es möglich, die Parameteridentifikationen und Meldungsidentifikationen, die angezeigt werden sollen, vollständig neu auszuwählen und sie anschließend als eine neue Konfigurationsliste 128 abzuspeichern. Konfigurationslisten können entweder von dem Service-PC 14 oder dem Server 16 abgerufen oder darin gespeichert werden, und zwar abhängig von der Benutzerstufe und den an einer bestimmten Servicestelle spezifizierten Optionen.
Insbesondere wird in Punkt 126 eine Liste aller definierten J1587-Parameteridentifikationen und Meldungsidentifikationen in eine Auswahlliste eingegeben. Die Anzeige enthält vorzugsweise wenigstens sieben angezeigte Parameter. Die Parameter werden aus der Auswahllisteninformation ausgewählt. Die Parameter werden gewöhnlich in natürlichen Einheiten dargestellt, wobei die Einheiten und der Wert angezeigt werden. Die Einheit wird in der durch die Parameteridentifikation festgelegten Auflösung angezeigt. In dem Fall, dass lediglich Daten angefordert werden, wird die Anforderungsrate automatisch angepasst. Der Benutzer kann in eine leere Anzeige eingeben oder eine angezeigte Meldung mit einer anderen MID/PID überschreiben.
Nachdem die geeigneten Parameteridentifikationen und Meldungsidentifikationen festgelegt worden sind, kann ein Benutzer in Punkt 130 die Datensammlungslänge festlegen. Sie wird auf der Basis entweder der Zeit oder spezieller vorausgewählter Ereignisse (z.B. Schaltereignisse in dem Fall einer Getriebekomponente) festgelegt. Die Entscheidung, die Überwachungssitzung in einer Datei abzuspeichern, wird in Punkt 132 getroffen. Jede in Punkt 134 abgespeicherte Datendatei wird vorzugsweise anfänglich lediglich auf dem Service-PC 14 gespeichert. Das Monitoring findet schließlich in Punkt 136 statt. Wie durch die Pausenoption 138 veranschaulicht, ist es möglich, das Echtzeitmonitoring anzuhalten. Falls das Monitoring angehalten werden soll, soll das Monitoring 136 nur bei einer Erkennung einer Triggerung eines Datenereignisses wieder anlaufen. Um das aktive Monitoring zu triggern, muss der Benutzer bestimmte Triggerbedingungen bestimmen. Gewöhnlich kann der Benutzer aus einer Parameterliste, einer Kennzeichenliste und Operationsanforderungsschranken in Bezug auf die Triggerparameter auswählen. Das Triggern umfasst Parameterbedingungen oder logische Operationen der Parameter (z.B. Gang > 4 und Gang < 6 sowie Interrupt aus; Schaltungen weg vom Leerlauf, Luftdruck < 60), eine einfache Tasteneingabe durch den Benutzer oder sogar eine Zeitspanne.
Wenn schließlich das Monitoring in Punkt 140 beendet ist, kehrt das System 10 zu dem Menü 114 zurück. Es kann eine neue Option ausgewählt werden, einschließlich der Option, eine Datendatei 134 auf den Server 16 zu übertragen, wie dies in Punkt 120 veranschaulicht und oben beschrieben ist.
Produkttests 106 werden gewöhnlich als Teil einer im Voraus gewählten Isolationsprozedur 94 durchgeführt, wie dies durch die Linie 102 veranschaulicht ist. Unter gewissen Umständen kann jedoch ein Produkttest erwünscht sein, ohne eine vollständige Überprüfung von Symptomen oder Fehlercodes vornehmen zu müssen, insbesondere wenn eine Getriebemodifikation bestätigt worden ist, wie weiter unten näher beschrieben. Wenn Produkttests 106 ausgewählt werden, wird dem Benutzer eine Liste für das momentane Produkt verfügbarer Tests präsentiert, wie dies in Punkt 150 veranschaulicht ist. Wenn die Produkttests Teil der Ausführung einer speziellen Isolationsprozedur 94 sind, wird vorzugsweise eine Untermenge verfügbarer Tests angezeigt, die sich auf diejenigen Tests beschränken, die unmittelbar der Prozedur zugeordnet sind.
Wenn ein Benutzer einen Test auswählt, wird der Test anschließend in Punkt 152 durchgeführt. Jede spezielle Information für diesen Test und jede Eingabe, die für den Test verwendet wird, wird dem Benutzer angezeigt. Ferner werden die auszuführenden Tasks (Aufgaben) angezeigt, und der Benutzer wird aufgefordert, die Beendigung einer jeden Task zu bestätigen, bevor mit der nächsten fortgefahren wird. Beispiele für derartige Task-Benachrichtigungen umfassen, dass sichergestellt wird, dass der Motor abgeschaltet ist, dass sichergestellt wird, dass der Motor läuft, dass sichergestellt wird, dass das Getriebe in den Leerlauf geschaltet ist, und dergleichen. Wenn die Beendigung der erforderlichen Tasks bestätigt worden ist, wird die Eingabe, den ausgewählten Test ein- und auszuschalten oder den Test zu starten, aktiviert. Nachdem der Test beendet worden ist, wird die Kontrolle aus den oben beschriebenen Gründen zur Datenüberwachung/-sammlung 104 zurück zu der Aufrufoperation in Punkt 154 übergeben. Somit kann die Kontrolle entweder zu der Isolationsprozedur 94 oder unmittelbar zu dem Menü 80 zurückgegeben werden, wo sie über eine Rückkehr zu der Aufrufoperation 154 zurück zu den Menüoptionen 22 gemäß 1 zurückkehrt.
Wie in 1 veranschaulicht, wird eine Diagnostik 26 nicht sofort ausgeführt, wenn sie ausgewählt ist. Statt dessen bestimmt das System 10, wie in dem Entscheidungspunkt 156 veranschaulicht, ob das Modul 12 die neueste Programmspeicheraktualisierung aufweist, die durch eine Modulsoftware-Revisionsidentifizierung gekennzeichnet ist. Falls dies nicht der Fall ist, wird eine Empfehlung gegeben, eine Komponentenaktualisierung auszuführen 28, bevor mit der Diagnostik 26 fortgefahren wird. Wenn die neueste Version des Modulprogrammspeichers installiert ist, fährt die Diagnostik 26 auf die oben beschriebene Weise fort.
Was passiert, wenn eine Komponentenaktualisierung 28 aus den Menüoptionen 22 ausgewählt wird, ist in größerer Einzelheit mit Bezug auf 3 beschrieben. Es sind unterschiedliche Komponentenaktualisierungsoptionen 170 verfügbar, wozu Programmspeicheraktualisierungen 172, Kalibrierungen 214, berufliche Änderungen 216 und Merkmalsaktualisierungen 218 gehören. Die Rückkehr zu der Aufrufoperationsoption 179 ist ebenfalls Teil der Getriebeaktualisierungsoptionen 170. Wenn eine Komponentenaktualisierung 28 durch die Diagnostik 26 ausgewählt wird, wird gewöhnlich lediglich eine Untermenge der verfügbaren Optionen, bspw. die Programmspeicheraktualisierungen 172, zur Verfügung gestellt, um durch einen Benutzer ausgewählt zu werden.
Programmspeicheraktualisierungen 172 erleichtern das Programmieren von Fahrzeugmodulen, bspw. des Moduls 12, und ermöglichen einem Benutzer, die Applikationssoftware in einer ausgewählten Komponente gemäß der neuesten geeignete Änderung zu aktualisieren. Bei einer Auswahl fragt das System 10 zunächst in dem Entscheidungspunkt 174 ab, ob die gewünschten Parameter, die gewöhnlich in der Form einer Applikationssoftware vorliegen, zuvor auf dem Service-PC 14 abgespeichert worden sind, wie dies in Punkt 176 veranschaulicht ist. Es ist möglich, eine Anzahl derartiger Parameteraktualisierungen auf einmal herunterzuladen und sie anschließend auf den im Voraus identifizierten Modulen 12 zu installieren. Wenn bspw. die einer Programmspeicheraktualisierung 172 zugeordneten Parameter zuvor abgespeichert worden sind, können sie somit in Punkt 176 für den Download in das Modul 12 in Punkt 178 ausgewählt werden.
Wenn die erforderlichen Parameter noch nicht auf dem Service-PC 14 abgespeichert worden sind, geht das System 10 zum Punkt 180 über, in dem alle verfügbaren öffentlichen Parameter aus dem Server 16, falls dieser verfügbar ist, oder aus einer Untermenge von dem Service-PC 14 ausgewählt werden können. Anschließend wird in dem Entscheidungspunkt 182 ermittelt, ob irgendwelche privaten Parameter verfügbar sind. Falls dies der Fall ist, geht das System 10 zu Punkt 184 über, so dass beliebige verfügbare private Parameter aus der Konfigurationsdatenbank 46 ausgewählt werden können. Programmspeicheraktualisierungen 172 enthalten wenigs tens einige private Parameter. Deshalb wählt der Benutzer in Punkt 184 aus den zur Verfügung stehenden privaten Parametern, die von dem Server 16 verfügbar sind, aus, wenn der Server 16 verfügbar ist. Ansonsten, wenn die privaten Parameter nicht in einem geeigneten sicheren Format entweder in der Serverdatenuntermenge 42 oder auf dem CD-ROM 38 abgespeichert sind, sind sie nicht verfügbar. Anschließend bestimmt das System 10 in dem Entscheidungspunkt 186, ob von der Konfigurationsdatenbank 46 für die Programmspeicheraktualisierung 172 irgendwelche verkäuflichen Parameter verfügbar sind. Falls derartige Parameter verfügbar sind, können sie anschließend in Punkt 188 ausgewählt und in Punkt 190 bezahlt werden. In Punkt 192 werden alle Parameter durch den Server 16 für den Download zu dem Service-PC verschlüsselt, um lediglich auf dem im Voraus bestimmten Modul 12 verwendet zu werden. Die Verschlüsselung soll eine einheitliche modulbezogene Identifikation oder einheitliche modulbezogene Identifikationen als „Kennwerte" für die Verschlüsselungsberechnungen enthalten. Die Verschlüsselung hat den Zweck, zu verhindern, dass Benutzer den Download kopieren und diesen auf mehr als einem Modul einsetzen. Somit ist die Verschlüsselung von der oben beschriebenen sicherheitsbasierten Verschlüsselung und Fehlerprüfung zwischen dem Server 16 und dem Service-PC 14 unabhängig und für sich gesondert.
Eine Programmspeicheraktualisierung 172 wird durch den Server 16 basierend auf der speziellen Information über das Produkt angepasst, die durch die Getriebedatenbank 44 gemeinsam mit einer möglichen Eingabe von einem Benutzer geliefert wird. Die spezielle Modulnummer, Seriennummer und ein Applikationskennzeichen werden gewöhnlich verwendet, um die neueste Programmspeicheraktualisierung 172, die zur Verfügung steht, zu bestimmen.
Im Entscheidungspunkt 194 entscheidet der Benutzer, ob die ausgewählten Parameter als Aktualisierung auf dem Modul 123 installiert werden sollen. Falls dies der Fall ist, werden anschließend in Punkt 178 die Parameter zu dem Komponentenmodul 12 heruntergeladen. Beim Herunterladen sollte die bevorzugte Datenverbindung 18 für die verschlüsselten Parameter auf dem „Jtalk"-Format basieren, jedoch insofern erweitert sein, um die Verschlüsselung der Daten zu umfassen. Ansonsten werden die Parameter auf dem Service-PC 14 für eine spätere Installation abgespeichert, wie dies in Punkt 196 veranschaulicht ist.
Wie in 3 veranschaulicht, kann für den Fall, dass keine privaten Parameter ausgewählt werden sollen, der gesamte Verschlüsselungsprozess umgangen werden, wobei das System 10 unmittelbar zu dem Entscheidungspunkt 194 übergeht.
Um eine Parameteraktualisierung des Moduls 12 zu ermöglichen, muss der Service-PC 14 eine verschlüsselte Meldung zu dem bezeichneten Modul senden, um den Download zu ermöglichen. Die Aktivität erfordert normalerweise, dass das Modul in einem nichtflüchtigen Bereich des Speichers läuft und es zulässt, dass sein Parameter- oder Programmspeicher überschrieben wird. Dieses „Zulassen des Schreibens" soll zeitlich begrenzt sein und jede Sekunde ein Neuschreiben erfordern. Ansonsten geht das Modul zurück in einen gesicherten Modus über.
Nach dem Download zu dem Modul 12 bestimmt das System 10 in einem Entscheidungspunkt 198, ob die heruntergeladene Aktualisierung verschlüsselt ist. Da die Programmspeicheraktualisierung 172 verschlüsselt ist, werden die Parameter durch das Modul 12 entschlüsselt, wie dies in Punkt 200 veranschaulicht ist. Nach der Entschlüsselung bestätigt das Modul 12 den Empfang der neuen Parameter in Punkt 202. Falls keine Entschlüsselung erforderlich ist, bestätigt das Modul 12 unmittelbar den Empfang der neuen Parameter in Punkt 202.
Das Modul 12 installiert anschließend die Parameter in Punkt 204. Die Parameterinstallation wird in Punkt 206 bestätigt. In Abhängigkeit von den installierten neuen Parametern kann das System 10 eine Diagnostik 26 anstoßen, um die Parameterinstallation zu bestätigen, oder ansonsten beliebige erforderliche Kalibrierungen oder Einstellungen zurücksetzen. Alternativ können fehlerhafte oder erfolgreiche Änderungen unter Verwendung einer Kombination aus Audioalarmen und visuellen Anzeigen entweder auf dem Modul 12 oder von dem Service-PC 14 aus angezeigt werden.
Wenn die Installation bestätigt ist, bestätigen das Modul 12 und der Service-PC 14 in Punkt 208 eine erfolgreiche Übertragung der Aktualisierung zusammen mit dem Server 16. Wenn die Parameter zuvor auf dem Service-PC 14 abgespeichert worden sind, werden sie anschließend gelöscht. Schließlich kehrt das System 10 zu der Aufrufoperation zurück, wie dies in Punkt 210 veranschaulicht ist.
Ein wiederprogrammierbarer nichtflüchtiger Speicher des Moduls 12 erleichtert den Download des Programmspeichers. Der umgekehrte Vorgang, also der Upload der ECU mit einer von einer weiteren ECU hochgeladenen Software wird durch den Service-PC nicht zugelassen. Der Schutz verhin dert das Kopieren von Code von einem Modul zu einem anderen.
Unter gewissen Umständen muss ein neues Modul 12 als Teil einer Diagnoseprozedur 26 installiert werden. Neue Module 12 werden gewöhnlich mit einem standardgemäßen Basiscode im voraus geladen, der gewöhnlich für einen ordnungsgemäßen Betrieb der Komponente sofort aktualisiert werden muss. Unter den meisten Umständen reicht der Basiscode lediglich aus, um eine Programmspeicheraktualisierung 172 zuzulassen. Es ist eine beträchtliche Aktualisierung erforderlich, die das Modul 12 in einem wesentlichen Maße programmiert.
Das Optionsmenü 170 zur Getriebeaktualisierung enthält weitere Auswahlmöglichkeiten, wie bspw. eine Kalibrierung 214, berufsspezifische Änderungen 216 und Merkmalsaktualisierungen 218. Die Prozedur für die Aktualisierung der Parameter, die diesen Auswahlmöglichkeiten zugeordnet sind, ist im Grunde genommen mit derjenigen gleich, die für die Programmspeicheraktualisierungen 172 vorgenommen werden. Wie oben erwähnt, ist es jedoch möglich, dass einige der Parameteraktualisierungen keine privaten Parameter enthalten, wie dies in größerer Einzelheit nachstehend beschreiben ist. Unter derartigen Umständen kann der Benutzer die gewünschten nicht privaten oder öffentlichen Parameter aus dem Server 16 oder eine Untermenge von diesen unmittelbar aus der Serverdatenuntermenge 42 des Service-PCs 14 auswählen. Wenn die Parameter ausgewählt sind, werden sie zu dem Modul 12 heruntergeladen, ohne die oben beschriebene Verschlüsselung zu benötigen.
Die Kalibrierung 214, berufsspezifische Änderungen 216 und Merkmalsaktualisierungen 218 stehen in enger Beziehung miteinander. Alle drei bieten Möglichkeiten zur Aktualisierung eines Moduls 12 entsprechend bestimmten Vorzügen.
Die Kalibrierung 214 betrifft spezielle Auswahlmöglichkeiten hinsichtlich des Leistungsverhaltens, die für ein installiertes Produkt verfügbar sein können, wie dies durch das Modulkennzeichen und Applikationskennzeichen des Moduls 12 bestimmt ist. Sie ist stark modulspezifisch. Mit Bezug auf ein Getriebe kann bspw. eine verfügbare Kalibrierungsänderung Drehmomenteinstellungen enthalten. Es ist möglich, einen Gesamtdrehmomentgrenzwert wie auch einen Drehmomentgrenzwert für jeden Gang festzulegen. In ähnlicher Weise ist es auch möglich, die Anzahl von Gängen, die durch das Getriebe verwendet werden, zu ändern.
„Optimierungskalbrationen" ermöglichen dem Benutzer, das Verhalten eines Produktes entsprechend den Vorzügen des Fahrzeugnutzers innerhalb eines gegebenen Richtliniensatzes zu optimieren. Beispiele für Optimierungskalibrationen in Bezug auf ein Getriebe enthalten den Anfahrgang, die Drehzahl zum Schalten oder den maximalen Reifendruck. Diese Optimierungskalibrationen werden als öffentliche Kalibrationen angesehen.
Berufsspezifische oder berufliche Änderungen 216 ermöglichen es, die Hardware für ein einfaches Getriebe auf eine umfassendere Weise für spezielle Arbeitsumgebungen, wie bspw. Wagenpark, Verhalten und Konstruktion, zu modifizieren. Beispielsweise kann das gleiche Getriebe in einem Mülllastwagen wie auch in einem für Fernverkehr bestimmten Fahrzeug eingebaut sein. Die berufsspezifischen Parameter des Getriebes können in dem Modul 12 in Abhängigkeit von der Arbeitsumgebung ohne Weiteres aktualisiert werden und lassen sich verändern, falls sich die Arbeitsumgebung des Getriebes ändert.
Schließlich ermöglichen zukünftige Änderungen 218 einem Benutzer, fahrzeugspezifische Funktionen zu und abzuschalten. Zu Beispielen zählen Zapfwellenantrieb (Power Take Off), schnelles Wechseln in die Leerlaufstellung (Quick to Neutral) oder Leerlaufsperre (Neutral Lock). Diese Modifikationen werden als öffentliche Parameter angesehen.
Wie oben erwähnt, weist das System 10 die Fähigkeit auf, eine Liste aller Teile zu speichern, die während einer Diagnoseroutine 26 identifiziert worden sind. Unter der Menüoption 30 der Menüoptionen 22, wie in 1 veranschaulicht, können die Teile als Teil eines Teilebeschaffungsprozesses bestellt und die Produkte dem Benutzer in Rechnung gestellt werden. Insbesondere kann ein Benutzer die Teileverfügbarkeit, die Preise und den Bestellungsstatus ermitteln sowie Teile ordern. Eine Bestellungsinformation enthält den Käufer, den Ort, eine Blankoeinkaufsbestellungsreferenz und eine Berechtigungsnummer. Allen aufgegebenen Bestellungen wird eine Verfolgungsnummer zugewiesen. Wenn ein Benutzer den Status einer Bestellung anfordert, liefert das System 10 eine Anzahl von Antworten, einschließlich: wartet auf Bearbeitung, Bestellung aufgegeben und Bestellung abgesandt.
Die elektronische Literaturbibliothek 32 ist ebenfalls eine unter den Hauptmenüoptionen 22 verfügbare Option. Es ist eine Anzahl von Quellen verfügbar, wenn die Bibliothek 32 ausgewählt wird. Diese Quellen enthalten Komponenten informationen, Prozedurinformationen, Teilebeschreibungen, Applikationsrichtlinien und illustrierte Teilemanuals. Weitere Quellen können Serviceberichte, Aktualisierungsinformationen in Bezug auf das System 10 und beliebige Betriebsprozeduränderungen enthalten. Um die Quellen, die komponentenspezifisch sind, durchzusehen, kann die gewünschte Komponente aus den verfügbaren von Hand ausgewählt werden. Alternativ wird in dem Fall, dass eine geeignete Komponenteninformation von dem Modul 12 abgerufen worden ist, die gelieferte Information die ausgewählte Komponente betreffen.
Die Komponenteninformation enthält Informationen über eine ausgewählte Komponente, einschließlich verkaufsspezifischer Informationen und trainingsspezifischer Informationen. Häufig enthält die Information im Gegensatz zu lediglich schriftlichen Materialien auch eine Kombination von Audio- und Videopräsentationen. Die Prozedurinformation stellt für den Benutzer einen Index der verfügbaren Problembeseitigungsrichtlinien/Servicemanuals oder Isolationsprozeduren. Schließlich liefert die Teileinformation, wenn sie aus der geöffneten Bildschirmanzeige ausgewählt wird, an den Benutzer einen Index des Teilemanuals. Wie oben erwähnt, wird die Information in Industriestandardformaten zur Verfügung gestellt und ist vorzugsweise komprimiert, um einen Download zwischen dem Server 16 und dem Service-PC 14 zu erleichtern.
Geschäftliche Kommunikationen 36 ist eine weitere Option, die aus den Menüoptionen 23 heraus verfügbar ist. Geschäftliche Kommunikationen 36 umfassen elektronische Mail und spezielle Dateiübertragungsmöglichkeiten, um dem Benutzer eine weitere Unterstützung zu geben. Eine elektro nische Mail enthält spezielle Übertragungsanforderungen, Fragen und Problemsituationen. Außerdem verfolgt die geschäftliche Kommunikation 36 laufend Angelegenheiten, wie berechtigte Systemeinrichtung, ihre anerkannten Identifikationsnummern, administrativer Kontakt, Service-PC-Administrator, eingerichtete Nutzer und ihre Berechtigungsstufen.
Das System 10 enthält ferner einen Systemverifikationstest 230. Ein derartiger Test umfasst eine Softwareverifikation und eine Systemverifikation des Moduls 12, des Service-PCs 14, des Servers 16 und beider Datenverbindungen 18 und 20. Falls das System 10 nicht ordnungsgemäß arbeitet, werden Funktionen, wie ein Diagnostiktest 26 und eine Systemaktualisierung 28, angeboten. Eine Softwareverifikation enthält das Folgende:

1. eine geeignete Identifikationsinformation für alle Systemkomponenten;
3. Identifikation der Softwareversion, die getestet wird;
4. Identifikation und Beschreibung eines jeden Tests, der an dem Modul 12 durchgeführt wird.

Die gesammelte Information enthält die Identifikation und Beschreibung eines jeden Testfalls für jeden an dem Komponentenmodul durchgeführten Test, einschließlich der Ergebnisse jedes Testfalls gemeinsam mit Unregelmäßigkeiten, Widersprüchlichkeiten oder Fehlern, die während der Ausführung des Testfalls aufgetreten sind. Es werden auch Aufzeichnungen einer beliebigen Information gesammelt, die helfen können, die Ursache für die beobachteten Probleme einzugrenzen und zu korrigieren.
Die beschriebenen Ausführungsformen und Beispiele sind angegeben, um die vorliegende Erfindung zu veranschaulichen. Sie sollen jedoch nicht den Schutzumfang der vorliegenden Erfindung beschränken. Deshalb ist die vorliegende Erfindung lediglich durch die beigefügten Ansprüche beschränkt.

Claims

Servicelogistiksystem mit einem wiederprogrammierbaren fahrzeuggetragenen Modul (12), mit einem lokalen Servicecomputer (14) mit Servicemitteln (22, 64), die Diagnosemittel (26) oder Komponentendatenaktualisierungsmittel (28) bilden, mit einem zentralen Server (16), mit einer ersten Zweiwegedatenverbindung (18), die das Modul (12) mit dem Servicecomputer (14) verbindet, der Diagnosemittel und Aktualisierungsmittel bereithält, mit einer zweiten Datenverbindung (20), die den Servicecomputer (14) mit dem zentralen Server (16) verbindet und ein Client-Server-Interface (21) bildet, das den Echtzeitaustausch von Information zwischen dem Servicecomputer (14) und dem Server (16) gestattet.
Servicelogistiksystem nach Anspruch 1, dadurch gekennzeichnet, dass es dem Modul (12) zugeordnete Komponenteninformation (50) enthält, wobei der Servicecomputer (14) wenigstens einen Teil der Komponenteninformation über die erste Datenverbindung (18) und wenigstens eine Untergruppe der Komponenteninformation mittels der zweiten Datenverbindung (20) zu dem Server (16) überträgt.
Servicelogistiksystem nach Anspruch 2, bei dem der Server (16) eine Komponentendatenbank (44) enthält, wobei die Komponentendatenbank mit der Untergruppe der Komponenteninformation aktualisiert wird.
Servicelogistiksystem nach Anspruch 1, gekennzeichnet durch Mittel zur Bestimmung verschiedener Ebenen des Nutzerzugriffs (56) auf das System, wobei die Bedingungen des Zugriffs auf dem Server gespeichert sind.
Servicelogistiksystem nach Anspruch 1, bei dem das System Diagnosemittel (26) enthält, wobei zu dem Diagnosemittel (26) gehören: Mittel zum Abruf eines Fehlercodes (88) aus dem Komponentenmodul und aus isolierten Symptomen (112), eine Diagnosedatenbank (48) auf dem zentralen Server (16) und ein Debuggingszenario (90), wobei das Debuggingszenario durch einen Vergleich (82) des Fehlercodes (88) und/oder der Symptome (112) mit einem entsprechenden Fehlercode oder entsprechenden Symptomen der Diagnosedatenbank bestimmt ist.
Servicelogistiksystem nach Anspruch 5, bei dem der Fehlercode durch den Servicecomputer (14) über die erste Datenverbindung (18) von dem Modul abgerufen wird, wobei der Fehlercode durch die zweite Datenverbindung (20) von dem Servicecomputer auf den Server (16) übertragen wird.
Servicelogistiksystem nach Anspruch 5, weiter aufweisend: Komponenteninformation (50), wobei die Komponenteninformation zu dem Server (16) übertragen wird, eine Liste aller möglicher Symptome, die auf dem Server gespeichert ist, und verfügbare Symptome (112), wobei der Server (16) die Komponenteninformation (50) mit den möglichen Symptomen vergleicht, um die verfügbaren Symptome zu liefern, und wobei die Symptome aus den verfügbaren Symptomen ausgewählt sind.
Servicelogistiksystem nach Anspruch 5, bei dem das Debuggingszenario (90) ein Eingrenzungsverfahren (94) beinhaltet, wobei das Eingrenzungsverfahren dem Fehlercode und/oder den Symptomen zugeordnet ist.
Servicelogistiksystem nach Anspruch 8, bei dem das Eingrenzungsverfahren (90) eine Komponentenüberwachung (104) beinhaltet, wobei die Komponentenüberwachung Daten beinhaltet, die in Echtzeit aus den Komponenten abgerufen worden sind.
Servicelogistiksystem nach Anspruch 8, bei dem die Daten in dem Servicecomputer (14) selektiv gespeichert und selektiv auf den Server (16) übertragen werden.
Servicelogistiksystem nach Anspruch 1, zu dem außerdem eine Aufzeichnung (68) der Serviceaktivität gehört, wobei beim Service des Moduls (12) durch das System Schritte zur Aufzeichnungsverfolgung unternommen werden.
Servicelogistiksystem nach Anspruch 1, dadurch ge kennzeichnet, dass das System Aktualisierungsmittel (28) für das Komponentenmodul aufweist.
Servicelogistiksystem nach Anspruch 12, bei dem das Modulaktualisierungsmittel Parameter beinhaltet, wobei zu den Parametern wenigstens öffentliche Parameter (180) und/oder private Parameter (182) gehören, wobei die Parameter eine Untergruppe aller verfügbaren Parameter darstellen.
Servicelogistiksystem nach Anspruch 13, außerdem aufweisend: Komponenteninformation (50), wobei die Komponenteninformation zu dem Server (16) übertragen wird, und eine Liste aller möglicher auf dem Server gespeicherter Parameter, wobei der Server die Komponenteninformation mit den möglichen Parametern vergleicht, um eine Liste (180, 184) der verfügbaren Parameter zu erstellen, wobei die Parameter aus den verfügbaren Parametern ausgewählt sind.
Servicelogistiksystem nach Anspruch 14, bei dem die Parameter dazu verwendet werden, die Module (12) zu aktualisieren, wobei das Modul die Aktualisierung bestätigt und der Servicecomputer (14) aktualisierte Komponenteninformation an die Konfigurationsdatenbank des Servers überträgt.
Servicelogistiksystem nach Anspruch 14 mit verschlüsselten Parametern (142), wobei die verschlüsselten Parameter teilweise auf der Komponenteninformation beruhen, um eine Entschlüsselung (200) nur durch das Modul (12) unter Ausschluss aller anderen Module zu gestatten.
Servicelogistiksystem nach Anspruch 16, bei dem die Parameter nur dann verschlüsselt sind, wenn die Parameter wenigstens einen privaten Parameter (182) enthalten.
Servicelogistiksystem nach Anspruch 17, bei dem die Parameter außerdem einen Verkaufsparameter (188) enthalten, wobei der Verkaufsparameter ein privater Parameter ist, dem die Zahlung einer Gebühr (186) zugeordnet ist.
Servicelogistiksystem nach Anspruch 1 mit einer Komponentendatenbank (44), die in einem Server gespeichert ist, wobei die Komponentendatenbank mit wenigstens einer Untergruppe der Komponenteninformation (50) aktualisiert ist.
Servicelogistiksystem nach Anspruch 19, zu dem außerdem ein Mittel (68) zur Aufzeichnung der Serviceaktivität gehört, wobei das Aufzeichnungsmittel Schritte verfolgt, die durch das System bei der Pflege des Moduls (12) unternommen worden sind.
Servicelogistiksystem nach Anspruch 19, bei dem die Komponentendatenbank sowohl aktuelle als auch frühere Komponenteninformation enthält, wobei die aktuelle und die frühere Komponenteninformation (50) dazu verwendet wird, den Service des Moduls (12) anzupassen.
Servicelogistiksystem nach Anspruch 21, bei dem aktuelle und frühere Komponenteninformation ein angepasstes Debuggingszenario (90) oder ein angepasstes Listing von verfügbaren Parametern zum Download als Teil eines Komponentenupdates (28) bereitstellt.
Servicelogistiksystem nach Anspruch 19 beinhaltend: Fehlercodes (88), die der Komponenteninformation (50) zugeordnet sind, wobei wenigstens einer der Fehlercodes zu dem Server (16) transferiert wird, eine Diagnosedatenbank (48) auf dem Server (16), ein Debuggingszenario (90), wobei das Debuggingszenario durch einen Vergleich des Fehlercodes (88) mit einem entsprechenden Fehlercode in der Diagnosedatenbank bestimmt ist.
Servicelogistiksystem nach Anspruch 19, dadurch gekennzeichnet, dass es außerdem Symptomanalysemittel (110) aufweist, wobei eine Liste aller möglichen Symptome mit der Komponenteninformation verglichen wird, um eine Liste aller verfügbaren Symptome (112) zu erzeugen, wobei die Diagnosesymptome aus einer Liste aller verfügbaren Symptome manuell ausgewählt werden.
Servicelogistiksystem nach Anspruch 19 mit einem Mittel (104) zum Komponentenmonitoring, wobei zum Komponentenmonitoring Daten gehören, die von der Komponente durch das Modul in Echtzeit abgerufen und auf dem Servicecomputer (14) selektiv gespeichert und selektiv auf den Server (16) übertragen werden.
Servicelogistiksystem nach Anspruch 19, bei dem das System Komponentenmodulaktualisierungsmittel (28) aufweist, wobei die Modulaktualisierung Parameter umfasst, wobei diese Parameter öffentliche Parameter (180) und/oder private Para meter (182) enthalten, wobei die Parameter wenigstens eine Untergruppe aller verfügbaren Parameter repräsentieren, wobei die verfügbaren Parameter durch einen Vergleich der Komponenteninformation und eines Listings (180, 184) aller möglichen Parameter erzeugt werden, wobei die Parameter zur Aktualisierung des Moduls (117) verwendet werden und wobei das Modul Mittel zur Bestätigung (206) der Aktualisierung aufweist.
Servicelogistiksystem nach Anspruch 26, bei dem zu den Parametern verschlüsselte Parameter (192) gehören, wobei die verschlüsselten Parameter teilweise auf der Komponenteninformation beruhen, so dass sie nur durch das Modul (12) entschlüsselt werden können, das die Information erzeugt hat.
Servicelogistiksystem nach Anspruch 1 mit einer Komponentendatenbank (44), die auf dem Server gespeichert ist, wobei die Komponentendatenbank mit einer Untergruppe der Komponenteninformation aktualisiert ist, und mit Diagnosemitteln (26), wobei zu den Diagnosemitteln (26) Fehlercodes (88), die der Komponenteninformation zugeordnet sind, wobei wenigstens einer der Fehlercodes auf den Server transferiert wird, eine Diagnosedatenbank (48) auf dem Server, ein Debuggingszenario (90), wobei das Debuggingszenario durch einen Vergleich des Fehlercodes mit einem entspre chenden Fehlercode in der Diagnosedatenbank erzeugt wird, und Symptomanalysemittel (110) gehören, wobei eine Liste aller möglichen Symptome mit der Komponenteninformation verglichen wird, um eine Liste aller verfügbaren Symptome zu erzeugen, wobei die Diagnosesymptome manuell aus einer Liste aller verfügbaren Symptome ausgewählt werden.
Servicelogistiksystem nach Anspruch 28, wobei die Diagnose Komponentenmonitoringmittel (104) beinhaltet, wobei das Komponentenmonitoring Daten beinhaltet, die in Echtzeit von der Komponente abgerufen werden.
Servicelogistiksystem nach Anspruch 28, wobei das System Komponentenmodulaktualisierungsmittel (28) enthält, wobei die Modulaktualisierung Parameter beinhaltet, wobei die Parameter öffentliche Parameter (180) und/oder private Parameter (182) beinhalten, wobei die Parameter wenigstens eine Untergruppe aller verfügbaren Parameter repräsentieren, wobei die verfügbaren Parameter durch einen Vergleich der Komponenteninformation und eines Listings (182, 184) aller möglichen Parameter erzeugt werden, wobei die Parameter zur Aktualisierung der Module verwendet werden, wobei die Module die Aktualisierung bestätigen.
Servicelogistiksystem nach Anspruch 30, bei dem die Parameter verschlüsselte Parameter (192) beinhalten, wobei die verschlüsselten Parameter teilweise auf der Komponenteninformation beruhen, so dass sie nur durch dasjenige Modul entschlüsselt (200) werden können, das die Komponenteninformation erzeugt hat.
Servicelogistiksystem nach Anspruch 31, bei dem außerdem ein Aufzeichnungsmittel (68) für die Serviceaktivität vorgesehen ist, wobei durch das System (10) bei dem Service des Moduls Aufzeichnungsschritte unternommen werden.
Servicelogistiksystem nach Anspruch 31, bei dem Mittel zur Bestimmung verschiedener Niveaus des Nutzerzugriffs (56) auf das System vorgesehen sind, wobei die Niveaus Optionen entsprechen, die für das Diagnosemittel (26) und das Komponentenmodulaktualisierungsmittel (28) verfügbar sind.
Servicelogistiksystem nach Anspruch 28, bei dem die Komponentendatenbank (44) sowohl aktuelle als auch ältere Komponenteninformation beinhaltet, wobei die aktuelle und die ältere Komponenteninformation dazu verwendet wird, den Service des Moduls (12) anzupassen, wozu die Schaffung eines angepassten Debuggingszenarios (90) oder einer angepassten Liste verfügbarer Parameter zum Download als Teil eines Komponentenupdates gehört.