Im Folgenden werden Informationen aufgelistet, wie sie in heute vorliegenden Dokumenten "System-Entwicklungsdokumentation (Diagnose)" gefunden werden.
Generell gilt:
 
Für alle Informationen können auch Randbedingungen formuliert sein.
 
Es kann Bezug genommen werden auf Variablen bzw. Kenngrößen im Steuergerät. Dieser Bezug kann dazu führen, daß Informationen (z.B. aus MSRSW.DTD Dateien) übernommen werden. Diese Bezüge können auch als Auswahlkriterien für die zu übernehmenden Datenlexikon-Informationen dienen.
 
Es ist zu unterscheiden zwischen Anweisung und Information. Anweisung sagt, was getan werden muß. Die Information begründet die Anweisung und gibt damit Hinweise zur Realisierung. So kann z.B. die Anweisung lauten: "setze dieses Bit auf 0". Die Information kennzeichnet dieses Bit als "reserviert für Weiterentwicklung". Der SG-Entwickler würde durch die Information veranlaßt, die "0" als Festwert abzulegen und nicht im Programmcode als Literalkonstante einzuführen.
 
Der Zusammenhang zwischen den Informationen der Diagnose-Services und der Implementierung im Steuergerät ist herzustellen.
Im einzelnen handelt es sich um folgende Informationen:
 
Ä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.
 
Diagnosedienste die der Mechaniker verwendet, um Fehler am Gesamtsystem Diagnose im weiteren Sinne (Offboard Fehleranalyse)
 
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.