Diagnose

MSR-Dokumentation

Diagnose
Strukturelle Grundlagen
[ msrdia[minus ]-sp]
Version: 1.6


1. Einführung

Diagnose
1. Einführung

Die Arbeitsgruppe spezifiziert eine msrdia.dtd um die im Zusammenhang mit DiagnosejobDiagnose zu handhabenden Informationen zu analysieren und zu strukturieren. Ob diese DTD dauerhaft besteht und wie ihre Beziehung zu den anderen MSR bzw ASAP DTDs gestaltet wird, ist noch offen.


1.1. Vorhandene Diagnose-Dokumente

Die Diagnose-Information umfaßt folgende, heute in der Regel als eigenständige Papiere verteilte Dokumente.
System-Entwicklungsdokumentation (Diagnose) Das ist die Dokumentation zur Entwicklung von Steuergeräten und Systemen mit Schwerpunkt Diagnose, z.B. Dokumentation der Diagnose-Eigenschaften eines Steuergerätes bzw. eines Systems.

Diese System-Entwicklungsdokumentation existiert für jedes diagnosefähige System im Fahrzeug ggf. separat [image] . Ein solches System kann auch eine einzelne Komponente sein [image] .
Zielgruppe dieser Dokumentation ist der Steuergeräte bzw. der System-Entwickler.
Dieser Bereich wird in msrdia.dtd abgedeckt.
Diagnose im engeren Sinne (Onboard Fehlererkennung)Diagnose im engeren Sinne (Eigendiagnose) wird nicht in System-Entwicklungsdokumentation (Diagnose) beschrieben. Diese wird im Pflichtenheft für die SG-Software dargestellt.
Datenversorgung für den Diagnosetester Diese Daten werden vom Diagnosetester gelesen und verarbeitet. Es ist also die Bereitstellung der Daten für die Durchführung der Testerkommunikation.

Diese Datei stellt damit auch eine Beschreibung der Diagnosemöglichkeiten des Steuergerätes dar.
Diese Datenversorgung wird abgedeckt durch die asap-diagnose.dtd. Die Informationen müssen in die Entwicklungsdokumentation übernommen werden können. Andererseits sind Szenarien denkbar, bei der aus der System-Entwicklungsdokumentation Daten zu übernehmen sind (vgl. 1.2.3. Zusammenwirken ASAP2D und MSRDIA).
Produktions-Entwicklungsdokumentation (Diagnose) Das ist die Dokumentation zur Entwicklung von Fertigungseinrichtungen in der Produktion (z.B. Bandende). Dabei sind Informationen aus der Entwicklungsdokumentation enthalten, diese werden ergänzt [image] um produktionsspezifische Belange (wie Vorschläge für Prüfabläufe) usw.

Diese Produktions-Entwicklungsdokumentation kann für verschiedene Systeme, Produktionsschritte, Fertigungswerke separat existieren.
Die Dokumentation kann ggf. nach Hard- Software getrennt werden.
Zielgruppe dieser Dokumentation ist der Entwickler von Produktionseinrichtungen.
Dieser Bereich wird in msrdia.dtd in der Weise abgedeckt, daß alle Informationen beinhaltet sind, die zwischen Produktion (Fahrzeug, und auch Steuergeräte) und Steuergeräte-entwicklung ausgetauscht bzw. verabredet werden.
Tester-Entwicklungsdokumentation (Diagnose) Das ist die Dokumentation zur Entwicklung von Testsystemen für die Kundendienstwerkstätten. Dabei sind Informationen aus der Entwicklungsdokumentation enthalten, diese werden aber ergänzt [image] um Belange der Werkstätten bzw. des Testerherstellers.

Diese Tester-Entwicklungsdokumentation existiert übergreifend für Fahrzeugbaureihen, bzw. jedes System ggf. separat.
Die Dokumentation kann ggf. nach Hard- Software getrennt werden.
Zielgruppe dieser Dokumentation ist der Testerhersteller.
Dieser Bereich wird in msrdia.dtd in der Weise abgedeckt, daß alle Informationen beinhaltet sind, die zwischen Testerhersteller und Steuergeräte-entwicklung ausgetauscht bzw. verabredet werden.
Reparaturleitfaden für Kundendienstwerkstatt Das ist die Dokumentation, die in der Service-Werkstatt verwendet wird, um Diagnose im weiteren Sinne (Offboard Fehleranalyse)Diagnose im weitere Sinne auszuführen. Hier fließen Informationen aus der Entwicklungsdokumentation ein wie Fehlerbaum-Analyse, Schaltpläne, Systembeschreibungen, Codes, Umrechnungen usw.

Zielgruppe dieser Dokumentation ist die Kundendienstwerkstatt. Sie wird vom Fahrzeughersteller erstellt.
Dieser Bereich wird durch die J2008.DTD behandelt.
Dieser Bereich wird in msrdia.dtd aus der Sicht des System-Entwicklers abgedeckt.
Der Schwerpunkt der msrdia.dtd ist die Systementwicklungsdokumentation (Diagnose). Die DTD muß alles enthalten, was zwischen Entwicklung, Produktion und Kundendienstorganisation ausgetauscht wird. Die Pflege liegt bei der System-Entwicklung. Die msrdia.dtd kann auch verwendet werden, um Rückflüsse an die Entwicklung zu geben. Diese Rückflüsse sollten in separaten Instanzen erfolgen, um definierte Verantwortlichkeiten sicherzustellen.

Diese Ergänzung wird verantwortlich vom Entwickler eingetragen.
Diese Ergänzung wird verantwortlich vom Entwickler eingetragen.
vgl. Kompenentenstruktur in MSRSYS.DTD
Es ist zu prüfen, wie aus einzelnen Dokumenten ein Gesamtdokument für das übergeordnete System automatisch zusammengestellt werden kann.


1.2. Mögliche Einsatzszenarien füdie MSRDIA DTD bzw. ASAP2D.DTD

1.2. Mögliche Einsatzszenarien für die MSRDIA DTD bzw. ASAP2D.DTD

Inhalt dieses Kapitels:
  • 1.2.1. Lebenszyklus
  • 1.2.2. Details zu den Phasen Systemlastenheft bis Kalibrierung
  • 1.2.3. Zusammenwirken ASAP2D und MSRDIA


1.2.1. Lebenszyklus

Folgendes Lebenszyklusszenario wird betrachtet:
Lebenszyklusszenario
Phase
Beschreibung
Diagnose-Info
Systemkonzept Fahrzeug
Es wird das Gesamtkonzept des Fahrzeuges festgelegt, inklusive der Entwicklungsprozesse
Grundsätzliche Diagnose-Themen (Protokoll, verwendete Normen, verwendete Prozesse, zu kommunizierende Informationen)
Vernetzung
Umfänge der MSRNET.DTD
Gegenseitige Referenzierung von Elementen:
  • Vorgabe eindeutiger Identifier
  • Datalink-Layer ist ein CAN-Netzwerk
Systemlastenheft Fahrzeug mit Komponentenstruktur
Umfänge der MSRSYS.DTD mit Komponenten, Signalen, Eigendiagnose, Fehlersituationen usw.
Diagnose-Lastenheft ergänzt als eigenständiges Dokument das Systemlastenheft.
Es fallen formale Diagnoseinformationen an. Bedatung einer Diagnose-Instanz kann beginnen (Service-IDs, Protokolle, Geräteadressen, Fehlercodes)
Software-Funktionen
Funktionsumfang der SG-Software mit Diagnose im engeren Sinne (Onboard Fehlererkennung)Diagnose im engeren Sinne (Fehleridentifikation, Testerkommunikation, Fehlermanagement)
Es fallen formale Diagnoseinformationen an. Bedatung einer Diagnose-Instanz kann beginnen (Service-IDs, Protokolle, Geräteadressen, Fehlercodes)
Kalibrierung/Applikation
Ergänzung der der SG-Software um Fahrzeugspezifische Anpassungen.
Es entstehen z.B. Schwellen für Diagnose-Funktionen.
Es entstehen Steuergeräte Speicherinhalte, die in das Steuergerät transportiert werden. Dafür werden die Testerkommunikationseinrichtungen verwendet.
Produktionsvorbereitung
Es werden Diagnoseabläufe (Diangose-Jobs) festgelegt.
Steuergeräte Speicherinhalte, werden in das Steuergerät transportiert. Dafür werden die Testerkommunikationseinrichtungen verwendet.
Werkstatt - Kundendienst
Es werden Diagnoseabläufe (Diagnose-Jobs) festgelegt.
Steuergeräte-Speicherinhalte, die in das Steuergerät transportiert werden. Dafür werden die Testerkommunikationseinrichtungen verwendet.


1.2.2. Details zu den Phasen Systemlastenheft bis Kalibrierung

Im folgenden wird ein beispielhaftes Szenario skizziert (Systemneuentwicklung auch beim Systemlieferant), welches sich in den Phasen Systemlastenheft bis Kalibrierung bewegt. Das Diagnose-Lastenheft wird dabei mehrfach zwischen den beteiligten Stellen ausgetauscht und um Informationen ergänzt. Für andere Szenarien (wie Folgeprojekte) gelten ähnliche Aussagen.
  • Der Fahrzeughersteller erstellt ein Diagnose-Lastenheft , in dem beschrieben ist, welche Informationen über die Diagnose-einrichtungen zu kommunizieren sind. Im Wesentlichen sind das Tabellen, von Services die zunächst nur eine grobe Beschreibung der geforderten Information enthalten. Es sind aber bereits alle Spalten für die vollständige Information angelegt, auch wenn einige davon leer bleiben. Der Fahrzeughersteller trägt die Information ein, die er weiß (z.b. nur die Spalte "Beschreibung").
  • Das Diagnose-Lastenheft geht an den System-Zulieferer. Dort wird die Steuergerätesoftware entwickelt (System-Design). Dabei werden entsprechend der Anforderungen aus dem Diagnose-Lastenheft Variablen, Kenngrößen usw. angelegt. Diese stehen dann auch als <msrsw> Datei zur Verfügung. Diese korrespondiert mit dem Diagnose-Lastenheft z.B. über die vorgesehene Spalte für den <short-name> der Steuergeräte-Variablen bzw. Parameter.
  • Nach dem die Spalte [image] für den <short-name> ausgefüllt ist, können weitere Detailinformationen (z.B. Quantisierung, Maßeinheiten, Wortgrößen) aus z.B. einer MSRSW-Datei automatisch hinzugefügt werden.
    Damit entsteht ein Dokument für den Fahrzeughersteller, das die Umsetzung des System-Zulieferers detailliert beschreibt. Dabei wird auch eine Korrespondenztabelle von Anforderung und Vorschlag generiert, welche alle vorgenommenen Änderungen bzw. Ergänzungen enthält. Das Dokument geht zurück zum Fahrzeug-Hersteller.
  • Der Fahrzeug-Hersteller prüft das Ergebnis und kann Änderungswünsche eintragen. Dies geschieht z.B. dadurch, daß er den Eintrag in der Spalte für den <short-name> löscht oder ändert [image] .
  • Das Dokument wird auch an weitere betroffene Stellen (z.B. Testerhersteller) gegeben und auch dort überprüft. Sie können als gleichberechtigter Partner das Dokument so ändern wie oben beschrieben.
  • Die vorherigen Schritte können wiederholt werden, bis das System vollständig festgelegt ist.
  • Das Diagnose-Lastenheft kann im folgenden weiter ausgewertet werden, z.b. durch
    • Erzeugung mehrerer Sprachvarianten
    • Erzeugung von Rohlingen für Testerkonfiguration oder Header-files für das Steuergerät
    • Erzeugung von Prüflisten

Dazu muß er inzwischen vom Zulieferer die Liste der verfügbaren Informationen bekommen haben, z.B. als MSRSW-Datei.
Es ist anzustreben, daß zwischen allen beteiligten Partnern die short-names vereinbart werden. Allerdings bleibt es möglich, jeweils eine eigene Spalte für den Kurzname des Herstellers bzw. des Zulieferers vorzusehen. Die Automatismen für die Dokumentpflege werden allerdings komplizierter.


1.2.3. Zusammenwirken ASAP2D und MSRDIA

Diagnose gehört zur Entwicklungs- bzw. Systemdokumentation. Der Schwerpunkt der beiden DTDs ist.
ASAP2D DTD | Diese Instanz ist ein Ergebnis der Entwicklung, welches die Kommunikation mit dem Tester behandelt und zur Testerkonfiguration eingesetzt wird. Die Ordnungskriterien in der DTD orientieren sich an der technischen Vollständigkeit der Testerinformationen. Sie sind daher sehr detailliert und datenbezogen.
MSRDIA DTD | Diese Instanz ist ein sowohl entwickungsbegleitende Dokumentation als auch ein Ergebnis der Entwicklung, welches die Diagnoseaspekte dokumentiert, Anforderungen beschreibt und sich in ihrer Struktur am menschlichen Leser orientiert. Informationen aus anderen DTDs sind zuweilen verdichtet (z.B. in Form von Übersichtstabellen).
Einsatzmöglichkeiten während der Entwicklung sind:
  • Informale bzw. semiformale Beschreibung der Diagnoseaspekte, in einer am Entwickler orientierten Ordnung und Zusammenstellung in der MSRDIA DTD.
  • Im Laufe des Prozesses können einige der semiformalen Informationen durch formale Informationen aus MSRSSW DTD,MSRSYS DTD, MSRNET DTD,ASAP2D DTD ergänzt, ersetzt bzw. detailliert werden (z.B. die grob beschriebenen Antworten von ReadDataByLocalIdentifierwerden durch die Labels der MSRSW-Instanz ergänzt).
  • Diese semiformalen Informationen können beispielsweise auch verwendet werden, um vorgefüllte Instanzen von ASAP2D DTD (wie z.B. SG-spezifische Anteile) zu erzeugen.
Einsatzmöglichkeiten am Ende der Entwicklung sind:
  • Man könnte z.B. in <part-type-spec>ein Element <diagnosis> anbringen, welches formale Verweise auf eine ASAP-Diagnose-Instanz bzw. informelle Diagnosebeschreibungen erlaubt.
  • Damit könnte man Dokumente erzeugen, die in sich geschlossen Informationen aus beiden Welten enthält.
  • Die gesamte Dokumentation kann in sich plausibilitätsgeprüft werden.
  • Der Anwender möchte z.B. beim Lesen in einem Hypertextsystem zwischen MSR und ASAP-Diagnose über gemeinsame Referenzbrowser zugreifen können.


1.2.3.1. Entwurf der MSRDIA DTD

Alle diese Szenarien bedingen einen geordneten Datenaustausch zwischen den Instanzen. Es kann kein verbindlicher Prozeß angegeben werden, wie die Entwicklung abläuft. Daher wird ein Konzept verfolgt, welches hinsichtlich des Datenaustausches flexibel ist, und anhand der Erfahrungen aus ersten Anwendungen verfeinert bzw. korrigiert werden kann.
Der Entwurf der MSRDIA DTD orientiert sich daher an den vorliegenden Diagnose-Lastenheften und versucht eine formale Verbindung zu Instanzen anderer DTDs zu etablieren.


1.3. Übernahme von Daten aus anderen Instanzen bzw. Datenbanken

Es tritt immer wieder der Fall auf, daß die zu erfassende Information als Extrakt aus Instanzen anderer DTDs (z.B. msrsys.dtd bzw. msrnet.dtd bzw. msrsw.dtd asap-diagnose.dtd) oder anderweitig vorhandene Datenbanken zu gewinnen ist, bzw. damit in Zusammenhang steht.
Für diesen Fall wird ein neuer Mechanismus (MSR Query) vorgeschlagen, der die Einbettung bzw. die Darstellung von Zusammenhängen in DTD-unabhängiger Weise ermöglicht. Dieser ist gekennzeichnet durch:
  • Die Parameter der Datenübernahme wie Semantik (Name), mögliche Argumente usw. werden angegeben.
  • Die Ergebnisse der Datenübernahme stehen in einer generischen, präsentationsorientierten Struktur welche die Darstellung der Information als Tabellen, Listen usw. erlaubt. Dies bedeutet, daß bei einer Datenübernahme nicht dir Originalstruktur, sondern eine präsentationsorientierte Darstellung übernommen wird.
  • Durch Verwendung der generischen Struktur ist die Datenübernahme allgemein anwendbar. Die Darstellung der Daten in Tabellen, Listen usw. kann zunächst interaktiv erfolgen, in dem die Struktur (ähnlich wie bei einer Textverarbeitung) manuell angelegt und auch ausgefüllt wird. Um das Ergebnis einer automatisierten Datenübernahme reproduzierbar zu halten, ist es sinnvoll auch ein Hinweis auf die Datenquelle (Dateiname, Dateiversion, etc.) mit einfließen zu lassen.
  • Gesteuert über die angegebene Semantik der Datenübernahme ist es nun möglich, in der manuell angelegten Struktur die Daten zu prüfen, zu korrigieren und auch zu erweitern. Voraussetzung hierfür ist ein spezifisches Verarbeitungsprogramm, welches die manuelle Struktur kennt (z.b. Anordnung der Spalten in einer Tabelle) und darauf arbeitet.
  • Dieses Verarbeitungsprogramm kann auf Basis von generischen SGML-Werkzeugen (z.B. MetaMorphosis, Balise, OmniMark, W3C-DOM) oder auch über die Programmierschnittstelle von SGML-Editoren ausgeführt realisiert werden.
  • Ein solches Verarbeitungsprogramm kann auch eingesetzt werden, um Daten zu überprüfen bzw. zu extrahieren. In frühen Phasen ist es auch möglich, die Ergebnisse manuell vorwegzudefinieren, um sie bei Verfügbarkeit der Datenquelle zu ersetzen bzw. zu überprüfen (vgl. 1.2.2. Details zu den Phasen Systemlastenheft bis Kalibrierung).
  • Dieser Mechanismus kann auch verwendet werden, um dokumentintern Übersichten zu erstellen (1.3.1. Generierung von Übersichten).
  • Wichtig ist, daß die Datenübernahme als Bestandteil der Dokumentenwartung verstanden wird, und nicht als Bestandteil der finalen Formatierung. Das bedeutet, daß nach Ausführung einer Übernahme wieder manuell in das Dokument eingegriffen werden kann. Verbindlich sind damit die Ergebnisse der Übernahme, wie sie im Dokuemnt (<result-p> usw.) enthalten sind.
    Das bedeutet auch, daß Dokumente nach Ausführung einer Übernahme ggf. erneut versioniert werden müssen.
  • In DTDs, welche <msr-query> unterstützen, sollte auch <msr-processing> enthalten sein. Dieses dient zur Aufnahme von Verarbeitungsprotokollen usw. Damit wird nachvollziehbar, was in dem Dokument automatisch manipuliert ist.


1.3.1. Generierung von Übersichten

Die Informationen, die z.B. aus anderen Instanzen übernommen werden, können beim Formatieren einer msrdia.dtd-Instanz in tabellarischer Darstellung zusammengefaßt werden. Beispiele hierfür sind:
  • Fehler mit (codes, arten, Umgebungsdaten)
  • Meßwerte mit den Labels aus der Software
  • Stellerlisten
  • Listen mit Umrechnungsformeln
Für die Erzeugung derartieger Übersichten kann ebenfalls <msr-query> verwendet werden.


1.3.2. Generierung verschiedener Dokumentansichten

Für die Generierung verschiedener Dokumentansichten gibt es folgende Möglichkeiten:
  • Ein Formatierer erzeugt die Dokument-Ansicht unter Verwendung der spezifischen Elemente in der DTD.
  • Es wird für jede Ansicht manuell ein neues Dokument angelegt [image] , welches über <msr-query> die geforderten Informationen einbezieht. Der Level der Datenübernahme kann dabei als Argument an <msr-query> mitgegeben werden, so daß zur Laufzeit eingestellt werden kann. Dadurch wird es möglich, den Detaillierungsgrad von Dokumenten zielgruppenspezifisch anzupassen.
  • Es ist möglich, in der DTD den Elementen Informationen anzuhängen, in welchen Dokumentansichten sie dargestellt werden sollen. Dies ist noch weiter zu untersuchen (todo).
  • Es gibt auch Fälle, bei denen eine Zusammenfassung nicht automatisch generiert werden kann, weil die Abstraktionsgrade der Informationen zu unterschiedlich sind.

Dieses fungiert dann sozusagen als "Steuerdokument"


2. Übersicht über Diagnose-Informationen

Diagnose
2. Übersicht über Diagnose-Informationen

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 [image] .
  • 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.

diagnose-task wird zuweilen auch als diagnose-job bezeichnet.


3. Detaillierte Struktur der Diagnose-Information in MSRDIA

Diagnose
3. Detaillierte Struktur der Diagnose-Information in MSRDIA

Im Folgenden wird eine detaillierte Struktur der Diagnose-Information beschrieben, wie sie über eine msrdia.dtd realisiert würde. Diese DTD dient lediglich zur präsentationsorientierten Strukturierung der Information. Daher ist z.B. eine automatische Bedatung eines Testers über die msrdia.dtd nicht vorgesehen.


3.1. Generelle Dokumenteninformation

Die generelle Dokumentinformation folgt den allgemeinen MSR-Prinzipien (vgl. MSR-Applikations-profil mit <short-name> <project-data>, <admin-data>, <introduction>.


3.2. Globale Systemidentifikation

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 wenn diese Vorabidentifzizierung erfolgt ist, kann ein Tester angeschlossen werden, um eine elektronische Identifizierung durchzuführen. Diese Identifikation greift nur, wenn eine einzelne Komponente behandelt werden soll.


3.3. Allgemeine Informationen zum Gerät/System

In <general-product-data-1> werden allgemeine Informationen zum System angegeben, um einen Überblick zu bekommen. Diese Informationen können als Extrakt aus <TT TYPE="Product">msrsys.dtd</TT> entnommen werden.


3.4. Laboraufbauten

Hier können aufgabenspezifische Labor-Aufbauten <dia-lab-settings> beschrieben werden. Diese spzifizieren Vorbedingung für die Durchführung von Diagnose-Aufgaben. Beispiele hier für sind Beschaltung der des Steuergerätes, mindestens aufzuschaltende Signale und deren Werte, Restbussimulation.


3.5. Informationsspeicher

In der vorliegenden DTD wird ein allgemein anwendbares Modell für übertragbare Informationsblöcke in <information-memory-spec> angegeben. Diese Informationen werden unabhängig vom Fehlerspeicher gesammelt und sind über Diagnosefunktionen abrufbar. Das Modell ist gekennzeichnet durch folgende Eigenschaften:
  • es können beliebig viele Informationsspeicher spezifiziert <information-memory>. Jeder dieser Speicher ist gekennzeichnet durch <long-name>, <short-name> und Klasse (<information-memory-class>). Information-memory-class sind u.a. Crash-Speicher, Alarm-Speicher.
  • Die Position und die Größe des Informationsblockes wird mit <information-memory-location> und mit <information-memory-size> angegeben.
  • Die Einträge in den Informationsblöcken (information-memory-entry) werden sequentiell definiert und durch <information-memory-entry-class> klassifiziert. Z.B. CAN, interne Ereignisse, Sensoren, Schalter, etc.
    Die Größe des Eintrages z.B. Word, Byte, Bit etc. wird durch <data-type> definiert.
    Das Element <data-pos> ist der Zugriffsindex auf den Datentyp des Entry, z.B. bei data-type = Byte kann <data-pos> als Bitinformation zwischen 0 und 7 liegen. Handelt es sich bei dem Informationsspeicher um einen homogenene Aufbau d.h. der <data-type> ist bei allen Einträgen identisch, kann <data-pos> wie oben beschrieben verwendet werden. Sollte ein inhomogener Aufbau existieren, so ist die <data-pos> als Bitinformation bezogen auf den gesamten Informationsspeicher anzugeben.


3.6. Fehlermanagement

Es gibt einen Service (readDiagnosticTroubleCode), der zum Auslesen von Fehlerinformationen (aus dem Fehlerspeicher) dient. Davon Bestandteil sind Fehlercodes und Fehlerarten. Die Pfadbeschreibung für Fehlercode und Fehlerart sollten sinnvollerweise aus den Funktionsbeschreibungen in msrsw.dtd extrahiert werden können. Dort muß ja beschrieben werden, wie Diagnose im engeren Sinne (Onboard Fehlererkennung)Fehler erkannt und verwaltet werden.
Diese Fehlercodes sind in der asap-diagnose.dtd zwar bedatet, und mit einem Satz beschrieben. Die dahinterliegenden Fehlerbäume (also die Bedingungen, unter denen diese Fehler diagnostiziert werden) sind dort jedoch nicht enthalten. Die Bedatung der msrsw.dtd mit Fehlercodes (applizierbare Festwerte) sollte eigentlich aus der asap-diagnose.dtd heraus erfolgen.
In der Struktur <fault-management-spec> können mehrere Fehlerpfade (<fault-path>)definiert werden. Ein Fehlerpfad ist eine Überwachungseinheit für z.B. ein Sensor mit Verkabelung oder ein Steller mit Verkabelung oder eine indirekte Überwachung von Komponenten z.B. KAT oder EEPROM.
Jedem Fehlerpfad wird ein Fehlercode zugeordnet z.B. P0100.


3.7. Variantenbeschreibung

In der msrdia Beschreibung müssen auch variantenspezifische Informationen festgehalten werden können. Es wurde beschlossen folgende Struktur in der DTD zu berücksichtigen: <general-project-data> <variant-spec>.
Dies hat folgende Vorteile gegenüber einer nichtsemantischen Modellierung:
  • Es kann mit xref auf einzelne Varianten referenziert werden.
  • Einheitliches Layout der Variantenbeschreibung über alle msr-dia Dokumente
  • Es bietet die Möglichkeit über einen separaten Prozess die Inhalte automatisch füllen zu lassen.
Innerhalb der detailierten Diagnosebeschreibungen werden keine semantischen Strukturen verwendet. Z.B. können verschiedene Varianten durch jeweils eigene Spalten in CALS-Tabellen behandelt werden.


4. Arbeitsgruppen-interne Informationen

Diagnose
4. Arbeitsgruppen-interne Informationen

Inhalt dieses Kapitels:
  • 4.1. Noch zu klärende Detailpunkte
  • 4.2. Geklärte Detailpunkte
  • 4.3. Fertigstellungskriterien für MSRDIA.DTD


4.1. Noch zu kläende Detailpunkte

4.1. Noch zu klärende Detailpunkte

  • Aus Gründen der Kapitelnummerierung muss überlegt werden ob die <DIA-PROTOCOL-SERVICE-SPEC> auf die Ebene von <DIA-APP-SERVICE-SPEC> zu legen.
  • Wird bei der Definition von Dia-Services ein Dia-Service-ref benötigt, um doppelte defginitionen zu vermeiden
  • Muß MSR-Query auch bei anderen Elementen ausserhalb von NCOI möglich sein, z.B. der Generierung von Dia-Services und anderen Listen.
  • Wie kann die Anwendung von <msr-query> (z.B. die verfügbaren Abfragen) zwischen den Partnern kommuniziert werden? (Hier geht es um einen ev. gemeinsamme Entwicklung der MSR-Query Programme, nicht um den Datenaustausch zwischen den MSR Partnern)
    11.6.1999: todo Nach einer Erfahrungsphase sollte hierzu eine weitere AG einberufen werden.
  • Wie kann die Übereinstimmung von Responses mit der Implementierung im Steuergerät sichergestellt werden. Gibt es z.B. in MSRSW Mittel, um Service-Aufbauten zu beschreiben.
    11.6.99 MSRSW bietet keine expliziten Mittel, um Services zu beschreiben. Es ist jedoch zu untersuchen, in wieweit die vorhanden <msr-query> genutzt werden können, um Service-Beschreibungen gegen Ergebnisse aus der SW-Entwicklung zu vergleichen.
  • Einbau der Diagnose-Anteile in <Function-description> und Spezifikation von Fehlerpfaden und Bedingungen. Soll <information-memory-spec> nicht komplett in MSRSW.DTD übernommen werden.
    Fehlerspeicher-Einträge als Objekte in der MSRSW.DTD anbringen ?
    11.6.99 Die Fehlerpfade wurden vorläufig modelliert und in eine eigene Struktur gebracht. Die Übernahme nach msrsw ist noch offen.
  • Sichtenkonzept
    11.6.99 hierzu wurden Aussagen gemacht (1.3.2. Generierung verschiedener Dokumentansichten). Weitere Arbeiten notwendig.
  • Normbezug mit dem Wunsch, die referenzierten Normen auch bei der Dokumentaufbereitung (Präsentation) einflechten zu können.
    11.6.99 Die Normen müssen als SGML erfaßt werden. Dann können sie mit <msr-query> übernommen werden. TODO der Fall mit <normative-name>, welcher nicht in <result-chapter> usw. enthalten ist, muß noch geklärt werden. Praxiserfahrung ist notwendig.
  • Anwendung der Ergebnisse auf "$2C" - wie können temporäre Datenpakete behandelt werden.
    11.6.1999 Da nun die Services nicht mehr semantisch modelliert sind, muß geprüft werden, ob man mit der NCOI-Beschreibung und <msr-query> das Problem behandeln kann.
  • <information-memory-spec> behandeln.


4.2. Gekläte Detailpunkte

4.2. Geklärte Detailpunkte

  • Formale Anteile in NCOI einbetten
    11.6.1999 Das kann nun mit <msr-query> behandelt werden.
  • Umgang mit Glossaren, Definitionen, Abkürzungen
    11.6.1999 Behandlung über <msr-query>.
  • Wo und wie wird das Servicelayout beschrieben.
    11.6.1999 Service-layout wird unter der Kommunikationsbeschreibung der Protokolle (<dia-com-spec>) im Element <dia-service-layout> beschrieben.
  • Wo werden die speziellen Anforderungen an ein Transportprotokoll beschrieben?
    11.6.1999 Diese werden unter <dia-protocol> beschrieben. Es ist Aufgabe des Experten, die am besten passende Stelle festzulegen (ggf. <add-spec> verwenden).
  • Es wird ein zentraler Pool von negativen Responses benötigt. Diese werden von verschieden Requests verwendet. Durch die Spiegelung der Identifikationoption und der Service-Id sind die positiven Requests immer unterschiedlich. Vorschlag:n-Pool unter <dia-service-layout> modellieren.
    Es ist noch zu klären in wie weit n-responses und p-responses sowohl bei <dia-srv-param> als auch bei <dia-service> vorhanden sein muß. Es scheint auf jeden Fall sinnvoll zu sein dies im <dia-srv-param> vorzusehen.
    11.6.1999: es werden keine spezifischen Elemente für Responses angelegt, da eine formale Beschreibung von Services und Service-Layout nicht erfolgt. Daher können Reponses in <chapter> beschrieben werden. Das ermöglichkt auch das Referenzieren. Erhöhte Anforderungen können über msr-Query behandelt werden.


4.3. Fertigstellungskriterien füMSRDIA.DTD

4.3. Fertigstellungskriterien für MSRDIA.DTD

  • DTD ist anhand von zwei existierenden Lastenheften (Detlef Staffe, Porsche, bzw. Holger Kollmeier, Daimler-Benz) erfolgreich verifiziert.
  • DTD enthält genügt den MSR-Richtlinien
  • <msr-query> ist verfiziert durch Beispiele, in denen die Abfrage und das erwartete Ergebnis spezifiziert ist. Beispielhafte Scripts wäre hilfreich.
  • Protokolldokumente nach [Keyword 2000 German Implementation;;;;] sind in msrdia.dtd darstellbar, insbesondere die verbalen Anteile.


5. Glossar

Diagnose
5. Glossar

Diagnose im engeren Sinne (Onboard Fehlererkennung)
Diagnose im engeren Sinne ist die Fähigkeit eines Steuergerätes oder eines Systems, Fehler an sich selbst, an Sensoren und Aktuatoren bis hin zum Gesamtsystem zu erkennen, auszuwerten und zu speichern. Diese werden der Kommunikationsschnittstelle (z.B. Testerkommunikation)Kommunikationsschnittstelle (z.B. zur Testerkommunikation) zur Verfügung gestellt.
Diagnose im weiteren Sinne (Offboard Fehleranalyse)
Diagnose im weiteren Sinne ist eine Tätigkeit, die unter Ausnutzung der über die Kommunikationsschnittstelle (z.B. Testerkommunikation)Kommunikationsschnittstellen bereitgestellten Informationen/Aktionen (vgl. Diagnoseservice) die Ursache von Fehlfunktionen von Komponenten und Systemen analysiert. Dabei können die bereitgestellten Informationen kombiniert und geeignete Schlüsse gezogen werden.
Diagnoseservice
Ein atomarer Dienst(kleinste Informationseinheit) eines Steuergerätes, den ein Testsystem anstoßen kann. Er ist z.B. gekennzeichnet durch einen Identifikator, Parameter und die möglichen Antworten.
Diagnosejob
Kombination von DiagnoseserviceDiagnoseservices zur Durchführung einer bestimmten Aufgabe am Gesamtsystem. Diese Kombination erfolgt im Testsystem.
Diagnose
Dies ist ein unscharfer Überbegriff, welcher für sich alleine nicht aussagefähig ist, und daher im vorliegenden Dokument für die Gesamtheit von Diagnose im engeren Sinne (Onboard Fehlererkennung), Diagnose im weiteren Sinne (Offboard Fehleranalyse), Kommunikationsschnittstelle (z.B. Testerkommunikation) verwendet.
Kommunikationsschnittstelle (z.B. Testerkommunikation)
Ist das Protokoll mit allen Parametern die benötigt werden, um die Kommunikation zwischen einem Testsystem und einem Steuergerät betreiben zu können. Sie umfaßt physical layer, datalink layer und application layer.
Diese Schnittstelle bezieht sich nicht nur auf traditionelle Verfahren (K-Leitung, CAN usw.) sondern auch auf die Anwendung von Meßtechnik (z.B. Prüflampe, Spannungsmeßgerät, Oszilloskop) zur Diagnose.
Varianten
Variantencodierung
ist die Eigenschaft eines Steuergerätes durch vorgesehene Eingriffe (z.B. Umprogrammierung einer Speicherzelle, Beschaltung eines Pins usw.) eine bestimmte Funktionsausprägung annehmen zu können. Es kann also eine der im Steuergerät enthaltenen Varianten ausgewählt werden.
In der MSRSYS.DTD wird <variant-coding> verwendet, um die Zuordnung von Varianten zu Variantenmerkmalskombinationen und deren Einfluß auf die Variantenauswahl (Sachnummernbildend oder Komponentenintern über äußere Einflüsse).


6. Elementbeschreibung

Diagnose
6. Elementbeschreibung

Inhalt dieses Kapitels:
  • 6.1. mnemonic
  • 6.2. data-pos
  • 6.3. data-length
  • 6.4. scaling-type


6.1. mnemonic

Description
 | Zusätzliche Bezeichnung des Diagnoseservices, z.b. bei ReadECUIdentification ist dies "REI".


6.2. data-pos

Description
Startposition des Parameters in der Nutzinformation. Einheiten in der Nutzinformation werden ab 1 gezählt. Bei "ReadECUIdentification" Serviceparameter "Identification Option" ist dies "2". "1" ist grundsätzlich die ID des Services. Ist <data-length> und <scaling-type> nicht angegeben, so gilt wird "<data-length>=1" und "<scaling-type>=Byte".


6.3. data-length

Description
 | Anzahl der Informationseinheiten der Nutzinformation. Die Informationseinheit wird durch ein separates Scaling festgelegt.


6.4. scaling-type

Scaling Basis Type für <data-length> z.B. Byte, Word.
Description


Technische Begriffe

Diagnose
Technische Begriffe

Produkte
ASAP-Diagnose
asap-diagnose.dtd, asap-diagnose.dtd, asap-diagnose.dtd
ASAP2D DTD
ASAP2D DTD
CAN
J2008.DTD
msrdia
MSRDIA DTD
MSRDIA DTD, MSRDIA DTD
msrdia.dtd, msrdia.dtd, msrdia.dtd, msrdia.dtd, msrdia.dtd
MSRNET DTD
MSRNET.DTD
MSRSSW DTD
MSRSW-Datei
msrsw.dtd, msrsw.dtd, msrsw.dtd
msrsys dtd
MSRSYS DTD
MSRSYS.DTD, MSRSYS.DTD
Programmcode
Blinklampe
EEPROM
KAT
KP2000
ReadDataByLocalIdentifier
readDiagnosticTroubleCode
SGML Elemente
..class
add-spec
admin-data, admin-data
architecture
chapter, chapter
communication-ports
data-length, data-length
data-pos
data-type
devices
DIA-APP-SERVICE-SPEC, DIA-APP-SERVICE-SPEC
dia-architecture
dia-com-spec
dia-communication-error-handling
dia-communication-management
dia-communication-setup
dia-communication-shutdown
dia-condition-ref
dia-conditions
dia-device-class
dia-devices
dia-dia-service-layout
dia-lab-setting-spec
dia-lab-settings
dia-protcol
dia-protocol
DIA-PROTOCOL-SERVICE-SPEC
dia-protocol-services
dia-protocol-timing
dia-response-codes
dia-service
dia-service-layout
dia-srv-param
dia-task
diagnosis
fault-management-spec
fault-path
Function-description
general-product-data-1
general-project-data
global-system-identification, global-system-identification
information-memories
information-memory
information-memory-class
information-memory-entry-class
information-memory-location
information-memory-size
information-memory-spec, information-memory-spec, information-memory-spec
introduction, introduction
long-name
msr-processing
msr-query, msr-query, msr-query, msr-query, msr-query, msr-query
msrsw
normative-name
part-type-spec
project-data
result-chapter
result-p
scaling-type
short-name, short-name, short-name
sw-data-dictionary
variant-coding
variant-spec
Sonstige
application layer
datalink layer
Diagnose-Lastenheft , Diagnose-Lastenheft
physical layer
System-Entwicklungsdokumentation (Diagnose)
Systemlastenheft
Status
System-Design
Werkzeuge
Testsystem


Untitled

Diese Ergänzung wird verantwortlich vom Entwickler eingetragen.


Untitled

Dazu muß er inzwischen vom Zulieferer die Liste der verfügbaren Informationen bekommen haben, z.B. als MSRSW-Datei.


Untitled

Dieses fungiert dann sozusagen als "Steuerdokument"


Untitled

diagnose-task wird zuweilen auch als diagnose-job bezeichnet.


Untitled

Es ist zu prüfen, wie aus einzelnen Dokumenten ein Gesamtdokument für das übergeordnete System automatisch zusammengestellt werden kann.


Untitled

Es ist anzustreben, daß zwischen allen beteiligten Partnern die short-names vereinbart werden. Allerdings bleibt es möglich, jeweils eine eigene Spalte für den Kurzname des Herstellers bzw. des Zulieferers vorzusehen. Die Automatismen für die Dokumentpflege werden allerdings komplizierter.