| | Änderungsverwaltung <admin-data>
|
| | Einführung, "Allgemein" <introduction> mit Prosatext und auch Verweisen auf andere Dokumente, z.B. Normen.
|
| | Systemkurzbeschreibung des System (ca. 1 Seite) inklusive Diagnose-Aspekte. Diese kann als Extrakt aus msrsys dtdübernommen werden.
|
| | Systemidentifikation ( <global-system-identification>) als allgemeine Beschreibung, wie das Steuergerät oder das System zu identifizieren ist. Dies kann z.B. auch die Beschreibung von Aufklebern sein oder besonderen konstruktiven Merkmalen sein, die eine Vorabidentifizierung des Gerätes durch einen Menschen ermöglicht. Erst wenn diese Vorabidentifizierung erfolgt ist, kann ein Tester angeschlossen werden, um eine elektronische Identifizierung durchzuführen. Diese Identifikation greift nur, wenn eine einzelne Komponente behandelt werden soll.
|
| | Grobe Beschreibung der diagnoserelevanten Fahrzeugarchitektur in <dia-architecture>. Hierin können Blockschaltbilder, Steckerbelegungen usw. angegeben werden. Die Information ist vergleichbar mit <architecture> einer MSRSYS dtdund kann ggf. auch aus einer solchen Instanz gewonnen werden.
|
| | Aufgabenspezifische Labor-Aufbauten <dia-lab-setting-spec>als Beschreibung der Vorbedingung für die Durchführung von Diagnose-Aufgaben. Beispiele hier für sind Anschlußbeschaltung (mindestens aufzuschaltende Signale und deren Werte), Restbussimulation.
|
| | Aufbau von Informationsspeichern ( <information-memory-spec>) wie Fehlerspeichedr usw.
|
| | Unterstützte Geräte im Fahrzeug, z.B. Kontroll-Lampe, Kombi-Instrument ( <dia-devices>).
Diese Geräte werden auch hinsichtlich der diagnoserelevanten Art der Nutzung beschrieben. Dabei kann schon grundsätzlich zwischen verschiedenen Klassen von Diagnosegeräten unterschieden werden ( <dia-device-class>). Beispiel für solche Klassen sind " Blinklampe", " KP2000".
| | Beschreibung der diagnoserelevanten Pins, z.B: pin-Nummer, Belastung der Diagnose-Leitung usw. <communication-ports>
|
| | Informationen zum Protokoll ( <dia-protcol>) (man könnte auch sagen: DataLink-Layer?). Hier werden unterschiedliche Möglichkeiten beschrieben, um Daten auszutauschen (z.B. Analogwert oder KWP2000)
| | Timing-Verhalten als Konkretisierung der in der Norm angegebenen Spielräume <dia-protocol-timing>
|
| | Kommunikationsaufbau <dia-communication-setup>(z.B. Adressierungsart, Übertragungsraten Headeraufbau usw.).
|
| | Kommunikationsabbau <dia-communication-shutdown>
|
| | Weitere Informationen zur Kommunikation:
| | management Verfahren <dia-communication-management>Tester present...
|
| | Fehlerbehandlung <dia-communication-error-handling>
|
| | generelle Struktur von Services <dia-dia-service-layout>
|
| | protokollweit vordefinierte Responses <dia-response-codes>
|
|
| | <dia-protocol-services> beschreiben Services, die zur Verwaltung der Kommunikation verwendet werden (z.B. Verändern von Kommunikationsparameter. Services die für mehrere Protokolle gelten werden in <DIA-APP-SERVICE-SPEC> beschrieben.
|
|
|
| | Eine flexible Kapitelstruktur, die es erlaubt, <chapter> und Service-beschreibungen beliebig zu mischen, um eine angemessene Strukturierung der Dienstebeschreibung zu gewährleisten. Die Strukturierung kann über ein <..class> Element erfolgen. Eine solche Strukturierung ist z.B.
| |
| | Steuergeräte- und Fahrzeugidentifikationsdaten
|
| | Ausgabe von Fehlerspeicherinhalten
Allgemeine Anforderung an den Fehlerspeicher (z.B. Batteriepufferung usw.)
|
| | Löschung von gespeicherten Informationen
|
| | Auslesen von Betriebsdaten
|
| | Auslesen von Festwerten (z.B. Schwellwerte) im Steuergerät
|
| | Beschreibung und Start von Download-Routinen im SG.
|
| | Aktivierung von Stellelementen im passiven Zustand
|
| | Beeinflussung von Stellelementen im aktiven Zustand
|
| | Steuergeräte-Programmierung bzw. Codierung
|
| | Start von steuergerätespezifischen Routinen (z.B. Kalibriervorgang auslösen)
|
|
| | obd-services beschreiben durch Gesetzgebung normierte Services. Diese haben eine spezielle Kommunikationsstruktur und standardisierte Inhalte.
|
|
| | Diagnosespezifische Bedingungen <dia-conditions>beschreiben Bedingungen (z.B. Betriebszustände, Temperaturen, Drehzahlen) des Systems, die erfüllt sein müssen, daß mit dem Gerät überhaupt kommunziert bzw. Diagnose durchgeführt werden kann bzw. der Service zur Verfügung steht.
Diese Bedingungen können ausführlich beschrieben oder aber unter Bezug ( <dia-condition-ref>) auf Bedingungen anderer <devices>definiert werden.
|
| | <dia-task> Wirkungsketten bzw. Aufgaben, die unter Verwendung von diagnose-services bzw. Eingriffen von außen (z.B. Klimaanlage einschalten) ablaufen. Hier können auch Prüfanleitungen untergebracht werden  .
|
| | Systemimmanente Informationsspeicher in dem im laufenden Betrieb anfallende Informationen aufgesammelt werden, die z.B. über Services ausgelesen werden kann ( <information-memories>)
|
| | Datenlexikon-Informationen <sw-data-dictionary>als Zusammenfassung von Informationen aus der msrsw.dtd.
|