Anleitung STATUS STEUERN UDS

BMW Group
SGBD-Generator
Verwendung der UDS-Jobs

STATUS / STEUERN
im SGBD-Generator
Version: 1.25
Stand: 06.02.2012
Status: freigegeben
Autor: Stephan Keitel, Firma ESG
Ablage: Anleitung_STATUS_STEUERN_UDS_V1.25.doc
Umfang: 33
Historie
Version Stand Autoren Änderung
0.10 10.01.2006 T. Müller Ersterstellung
0.20 16.01.2006 T. Müller Ergänzungen/ Änderungen
0.21 13.02.2006 T. Müller Ergänzungen/ Änderungen
0.22 31.03.2006 T. Müller Überarbeitung: Tabellen
0.30 20.04.2006 T. Müller “BITFIELD“ für Bitauswertungen hinzu
0.40 29.05.2006 T. Müller Service $31 und $2F hinzu
0.41 01.06.2006 T. Müller Definierte Datentypen
0.52 12.08.2006 T. Müller Erweiterung Service $31
0.53 13.11.2006 T. Müller Überarbeitung
0.54 04.12.2006 T. Müller Tipps für EDIABAS Toolset hinzugefügt
0.56 23.03.2007 T. Müller Erweiterungen
0.57 03.05.2007 T. Müller Kapitel „Kombinieren von Services“ hinzu
1.00 10.06.2007 T. Müller Allgemeine Überarbeitung
1.10 05.09.2007 T. Müller STATUS_BLOCK_LESEN ergänzt
1.11 18.12.2007 A. Reuß Allgemeine Überarbeitung
1.12 19.05.2008 A. Reuß Überarbeiten Definition Resultnamen
1.13 25.07.2008 A. Reuß Allgemeine Überarbeitung, Fehlerkorrektur
Verwendung der UDS STATUS / STEUERN Jobs im SGBD-Generator Seite 2 von 33
1.14 01.08.2008 A. Reuß Tipps zu EDIABAS Toolset hinzu

1.15 29.08.2008 A. Reuß Bugfix STATUS_BLOCK_LESEN
1.16 30.09.2008 A. Reuß Bilder überarbeitet
1.17 23.10.2008 A. Reuß Definition Resultnamen(Sonderf. Einheit string hinzu)
1.18 02.03.2009 A. Schandl Beispiel 2F überarbeitet
1.19 14.05.2009 A. Schandl Überarbeitung
1.20 18.05.2010 S. Keitel Aktualisierung der Einleitung und Kontaktdaten,
Umstrukturierung der Kapitelgliederung,
Erweiterung der SG_Funktionen Beschreibung,
Anpassung der Datentypen,
Beispiel für gemischte Ergebnisse mit Bitfield,
Abkürzungsverzeichnis.
1.21 13.01.2011 M.Saller Überarbeitung
1.22 04.10.2011 S. Keitel Entfernung Titelblatt Hinweis und Umbenennung des
Titels, nach Rücksprache mit Gerd Huber (TI-538),
Ergänzung Kapitel Verwendung von Umwelttexten
1.23 05.10.2011 S. Keitel Überarbeitung Kapitel 3.5 (Service 2C) und Überar-
beitung Kapitel 2.4 und 2.4.3
1.24 07.12.2011 S.Keitel Überarbeitung Kapitel 2.4, Neue Unterkapitel 2.4.2
1.25 06.02.2012 G. Huber Kleine Korrekturen (insbesondere Titel und Kapitel 6)
Stephan Keitel, Firma ESG 06.02.2012

Anleitung_STATUS_STEUERN_UDS_V1.25.doc freigegeben
Inhaltsverzeichnis
Abkürzungsverzeichnis ......................................................................................................................... 4
1 Einleitung ....................................................................................................................................... 5
2 Tabelle ”SG_Funktionen” für Standardjobs ............................................................................... 6

2.1 Standardjobs ............................................................................................................................... 6
2.2 Tabelle ”SG_Funktionen” ............................................................................................................ 7
2.3 Definierte Datentypen für die SG_Funktionen Tabelle ................................................................ 8
2.4 Definition Resultnamen für die SG_Funktionen Tabelle ............................................................. 9
2.4.1 Regeln für die Resultnamen ............................................................................................. 9
2.4.2 Regeln für die Entwickler-Resultnamen .......................................................................... 10
2.4.3 Beispiel einer Ergebnistabelle mit möglichen Ergebnistypen. ........................................ 11
3 Beschreibung der Standardjobs ................................................................................................ 12
3.1 JOB: STATUS_LESEN ($22- ReadDataByIdentifier) ................................................................ 12
3.1.1 Auslesen von einem Data-Identifier (DID) aus dem Steuergerät.................................... 12
3.1.1.1 Beispiel 1: Auslesen des Saugdruckwertes ................................................................................. 12
3.1.1.2 Beispiel 2: Auslesen von mehreren Data-Identifier (DID) aus dem Steuergerät .......................... 13
3.1.1.3 Beispiel 3: Auslesen des Saugdruckwertes und der Lufttemperatur ........................................... 13
3.1.2 Sonderfall: Mehrere Results pro Funktionsaufruf ........................................................... 14
3.1.2.1 Beispiel 1: Auslesen von Lichtstatus aus einem Lichtsteuergerätes ........................................... 14
3.1.2.2 Beispiel 2: Auslesen von Lichtstatus mit Hilfe des Datentyps “BITFIELD“ .................................. 15
3.1.2.3 Beispiel 3: Ergebnistabelle mit gemischten Ergebnistypen und BITFIELD.................................. 16
3.2 JOB: STEUERN ($2E- WriteDataByIdentifier) .......................................................................... 18
3.2.1 Beispiel 1: Vorgeben einer Drehzahl............................................................................... 19
3.2.2 Sonderfall: Mehrere Argumente pro Funktionsaufruf übergeben ................................... 20
3.2.2.1 Beispiel 2: Übergeben von mehreren Argumenten pro Funktionsaufruf ...................................... 20
3.3 JOB: STEUERN_ROUTINE ($31- RoutineControl) .................................................................. 22
3.3.1 Beispiel 1: Starten (oder stoppen) der Routine ............................................................... 22
3.3.2 Beispiel 2: Abrufen von Results mit dem Service $31 .................................................... 23
3.4 JOB: STEUERN_IO ($2F- InputOutputControlByIdentifier) ...................................................... 24
3.4.1 Beispiel 1: Vorgeben einer Drehzahl............................................................................... 24
3.5 JOB: STATUS_BLOCK_LESEN ($2C- DynamicallyDefineData-Identifier) ............................... 26
3.5.1 Beispiel 1: Erzeugen von 2 Data-Identifier ...................................................................... 26
3.5.2 Beispiel 2: Auslesen von 2 Data-Identifier ...................................................................... 27
4 Kombinieren von Services.......................................................................................................... 28
5 Hinweise zum Toolset32 (Tool32.exe) ....................................................................................... 29

5.1 Tipp1: Laden der Tabelle SG_Funktionen................................................................................ 29
5.2 Tipp2: Parameter aus einer Tabelle übernehmen .................................................................... 30
5.3 Tipp3: Navigieren zwischen (Sub)-Tabellen ............................................................................. 31
6 Verwendung von Umwelttexten ................................................................................................. 32
7 Ansprechpartner und Links ........................................................................................................ 33

7.1.1 Hotline EDIABAS und SGBD-Generator: ........................................................................ 33
7.1.2 Hotline ZEDIS: ................................................................................................................ 33
7.1.3 Links (BMW-Intranet): ..................................................................................................... 33

Abkürzungsverzeichnis
ARG / Argument Argumente die an das Steuergerät geschickt werden
B2S BEST/2 Quelldatei bzw. Source
BEST Beschreibungssprache für Steuergeräte
BMW-fast BMW "fast access for service and testing"
DID Data-Identifier
DS2 Diagnose System 2
DTC Der Diagnostic Trouble Code ist eine im Automobilbau verwendete hexade-
zimale Kennziffer zur Identifikation von Fehlfunktionen, die während des Be-
triebs eines Automobils auftreten können.
EDIABAS Das Elektronik Diagnose-Basis-System ermöglicht den Zugriff auf
DiagnoseInformationen am Fahrzeug.
iMAN Informationsmanager
ISO14229 Kommunikationsprotokoll Standard ISO14229
KompCheck Kompatibilitätscheck
KWP2000 Keywordprotokoll 2000 Kommunikationsprotokoll
LH Lastenheft
RES / Result Ergebnisse die vom Steuergerät geliefert werden
SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung
SG Steuergerät
SG_Funktionen Standardtabelle „SG_Funktionen“
SGBD Die Steuergerätebeschreibungsdatei enthält über unterschiedliche
Applikationen (z.B. Toolset) aufrufbare Jobs, die in der SGBD zu
Diagnosetelegrammen aufbereitet werden.
Die Steuergeräteantworten werden in lesbare Results aufbereitet
Toolset EDIABAS Toolset Applikation, die mithilfe einer SGBD und frei zu
setzenden Parametern die Diagnostic Services einer SGBD über EDIABAS
ausführt. Erhältlich über GIS-BMW Standard Tools Entwicklung.
UDS Unified Diagnostic Services Kommunikationsprotokoll
XML Extensible Markup Language
ZEDIS Zentrales Diagnosesystem

1 Einleitung
Im Rahmen des Feed-forward-Prozesses Diagnose wurden zur L6 erstmalig Diagnosejobs,
die sich aufgrund ihrer Funktion in allen zukünftigen Baureihen befinden, in Form von Diag-
noseaufträgen standardisiert vorgegeben.
Alle Diagnoseumfänge, die für die Produktion und den Service benötigt werden und durch
die Standardjobs beschrieben sind, werden mittels ZEDIS in der Datenbank definiert. Die-
se steuergerätespezifischen Umfänge werden für jedes Steuergerät zusammengestellt
und anschließend aus ZEDIS in einem XML-Austauschformat exportiert und schließlich in
den SGBD-Generator importiert. Nach dem Import der Daten in den SGBD-Generator sind
die Umfänge in der Tabelle “SG_Funktionen“ sichtbar und können von dem Anwender noch
ergänzt werden.
Abbildung 1: Formular “SG Funktionen“ im SGBD-Generator
Die in der Tabelle definierten Umfänge werden von fünf speziellen Standardjobs genutzt.
Gelbe Felder sind für den User nicht editierbar.
Zusätzlich zu den Diagnoseaufträgen können in der Diagnosedatenbank noch Fehlerorte
und Fehlertexte (DTC’s) eingepflegt und zugeordnet werden. Diese Umfänge werden zu-
sätzlich zu den Diagnoseaufträgen beim Import der Daten in den SGBD-Generator in die
Standardtabelle “FOrtTexte“ importiert.
In diesem Dokument wird beschrieben, wie diese fünf Standardjobs aufgerufen und steu-
ergerätespezifische Anpassungen in der Tabelle SG_Funktionen durchgeführt werden.

2 Tabelle ”SG_Funktionen” für Standardjobs
2.1 Standardjobs
Es stehen folgende fünf Standardjobs zur Verfügung, die von der Tabelle SG_Funktionen
genutzt werden:
a. JOB: STATUS_LESEN (siehe Kapitel 3.1)

Service: $22 (ReadDataByIdentifier)
Datei: UDS_22_STATUS_LESEN.b2s
b. JOB: STEUERN (siehe Kapitel 3.2)

Service: $2E (WriteDataByIdentifier)
Datei: UDS_2E_STEUERN.b2s
c. JOB: STEUERN_ROUTINE (siehe Kapitel 3.3)

Service: $31 (RoutineControl)
Datei: UDS_31_STEUERN_ROUTINE.b2s
d. JOB: STEUERN_IO (siehe Kapitel 3.4)

Service: $2F (InputOutputControlByIdentifier)
Datei: UDS_2F_STEUERN_IO.b2s
e. JOB: STATUS_BLOCK_LESEN (siehe Kapitel 3.5)

Service: $2C (DynamicallyDefineData-Identifier)
Datei: UDS_2C_STATUS_BLOCK_LESEN.b2s
Die Beschreibung der Jobs und der Standardtabelle „SG_Funktionen“ befindet sich in den
folgenden Kapiteln. Die genaue Definition der einzelnen Diagnose-Services befindet sich in
der ISO 14229.
Die oben aufgeführten Jobs benutzen die Tabelle „SG_Funktionen“.

2.2 Tabelle ”SG_Funktionen”

Die oben aufgelisteten Jobs benötigen zur Laufzeit die Standardtabelle „SG_Funktionen“,
die sich nach dem Import der Diagnosedaten in den SGBD-Generator in der Gruppe „SG_
Funktionen“ (siehe: Abbildung 1: Formular “SG Funktionen“ im SGBD-Generator) befin-
det. Die Tabelle “SG_Funktionen“ besteht sowohl in der SGBD als auch im SGBD-
Generator aus folgenden Spalten:
Spaltendefinition:
• ARG Bezeichner als String. Es darf kein Bezeichner doppelt vorkommen.

• ID Daten- oder Routine-Identifier (DID oder RID) als 2 Byte Wert.
• RESULTNAME Name des Ergebnisses. (siehe Kapitel 2.4 „Definition Resultnamen“)
• INFO Ausführliche Information zur ID bzw. zu dem Diagnoseauftrag.
• EINHEIT Keine Einheit "-" oder erlaubte Einheit (siehe Kapitel 2.4 „Definition
Resultnamen“)
• LABEL SG-interner Variablenname.
• L/H Byte-Order low/high (erlaubte Werte: "h", "l", "-")
"High" und "-" => in SG-Antwort: zuerst High-Byte, dann Low-Byte
"Low" => in SG-Antwort: zuerst Low-Byte, dann High-Byte
Diese Spalte wird nur bei Datentypen benötigt, die aus mindestens
2 Byte bestehen und andernfalls mit "-" befüllt.
• DATENTYP Erlaubter Datentyp (Siehe Kapitel 2.3 "Definierte Datentypen" )
• NAME Tabellenname für diskrete Werte (EINHEIT = "0-n") bzw. Tabellenname
für BITFIELD Tabelle (EINHEIT = "BIT")
• MUL Analoger Wert = Analoger Wert * MUL. Bei "-" keine Operation.
• DIV Analoger Wert = Analoger Wert / DIV. Bei "-" keine Operation.
Bei 0 Division by Zero Fehler.
• ADD Analoger Wert = Analoger Wert + ADD. Bei "-" keine Operation.
Die Umrechnung für Analoge Werte:
• SG_ADR Optional: Wird von den derzeitigen Jobs nicht benutzt.

• SERVICE Angabe des Diagnoseservices, der beim Aufruf verwendet werden
muss.
• ARG_TABELLE Angabe der Subtabelle in der die Argumente definiert werden, die für
den Diagnoseaufruf benötigt werden.
• RES_TABELLE Angabe der Subtabelle in der die Results definiert werden, die der Diag-
noseaufruf als Ergebnisse liefert.
Hinweis: Die Spalte SG_ADR wird zurzeit von den Standardjobs nicht ausgewertet!

2.3 Definierte Datentypen für die SG_Funktionen Tabelle

Der in der SG_Funktionen Tabelle angezeigte Datentyp wird vom Standardjob (siehe 2)
interpretiert. Der in EDIABAS angezeigt Wert ist davon unabhängig immer „real“ oder
„string“.
Datentyp Länge Wertebereich

char 1 Byte signed (default): -128 bis+127
unsigned: 0 bis +255
int 2 Byte signed (default): -32768 bis +32767
long 4 Byte signed (default): -2147483648 bis +2147483647
Intel float* 4 Byte Intel float (default), Little Endian
Motorola float* 4 Byte Motorola float, Big Endian

einfache Genauigkeit
Intel double 8 Byte Intel double (default), Little Endian
Motorola double 8 Byte Motorola double, Big Endian

doppelte Genauigkeit
string dynamisch 0-255 Zeichen
Hex0: String Enderkennung
string[n] **) max. 255 Byte 1 ≤ n ≤ 255
n = Anzahl der Bytes
data[n] **) max. 255 Byte 1 ≤ n ≤ 255
n = Anzahl der Bytes
BITFIELD - Sonderfall: SG_Funktionen Datentyp für Bitfield
Ergebnisse
*) Es dürfen nur Datentypen benutzt werden, die auch vom Steuergerät unterstützt wer-
den. In der Regel können nur wenige Steuergeräte Float-Zahlen verarbeiten.
**) Beim Datentyp „string“ kann optional die Stringlänge angegeben werden. Falls keine
Stringlänge angegeben wurde, wird als Endezeichen „0x00“ erwartet.
Der Datentyp „data“ erfordert zwingend eine Längenangabe.

2.4 Definition Resultnamen für die SG_Funktionen Tabelle

Jeder Ergebnisname beginnt mit "STAT_". Es gibt vier verschiedene Ergebnistypen (Se-
mantiken). Der Ergebnistyp wird durch die Einheit festgelegt.
2.4.1 Regeln für die Resultnamen

Result-Typ RESULTNAME EINHEIT DATENTYP
Dummy Result DUMMY_... DATA data[n]
1 ≤ n ≤ 255
Analoges Result STAT_..._WERT char, int, usw.
TEXT Ergebnisse STAT_..._TEXT TEXT string[n]
1 ≤ n ≤ 255
DATA Ergebnisse STAT_..._DATA DATA data[n]
1 ≤ n ≤ 255
Digitale Ergebnisse STAT_... 0/1 char, int, usw.
(außer _DATA, _TEXT,
_WERT)
Diskrete Ergebnisse STAT_.. 0-n char, int, usw.
_WERT)
Hex Ergebnisse STAT_..._WERT HEX char, int, usw.
Bit-Field Ergebnis …. BIT BITFIELD
_WERT)
• Analoge Ergebnisse (EINHEIT alles außer = "0/1", "0-n", „DATA“ und „TEXT“)
enden mit _WERT und sind vom Datentyp char, int, long, float, double, string oder
data.
Die Results _EINH und _INFO werden automatisch erzeugt.
Sonderfälle:
o EINHEIT = "TEXT": Beim Datentyp string wird zusätzlich das Result _TEXT
erzeugt.
Im Result _TEXT wird das Ergebnis in Textform ausgegeben.
o EINHEIT = "DATA": Beim Datentyp data wird zusätzlich das Result _DATA
erzeugt.
Im Result _DATA wird das Ergebnis in hexadezimaler Darstellung ausgege-
ben (Bsp.: _DATA= 05 07 06 1A FF …).
Das Result _WERT ist in diesen beiden Fällen leer und wird mit “0“ befüllt
(_WERT=0).
• Digitale Ergebnisse (EINHEIT = "0/1") dürfen nicht mit _WERT enden und sind
vom Datentyp char, int oder long wobei nur "0" oder "1" erlaubt sind.
Das Result _INFO wird automatisch erzeugt.
• Diskrete Ergebnisse (EINHEIT = "0-n") dürfen nicht mit _WERT enden und sind
vom Datentyp char, int oder long. Dem Ergebnisnamen wird die umgerechnete De-
zimalzahl des Antworttelegramms zugeordnet.
Die Results _EINH, _TEXT und _INFO werden automatisch erzeugt.
• HEX Ergebnisse (EINHEIT = "HEX") enden mit _WERT und sind vom Datentyp
char, int oder long.
Die Results _EINH und _INFO werden automatisch erzeugt.
• Bit-Field Ergebnisse (EINHEIT = „BIT“) vom Datentyp „BITFIELD“.

Für diese Semantik „Bitfield“ ist dann nur die Einheit „Bit“ erlaubt und die Datenty-
pen „unsigned char“, „unsigned int“ und „unsigned long“.
o Aktuell ist nur das gesamt Ergebnis von einem Job als Bitfield definierbar
Sonderfall (neu):
o Verschachtelung von Ergebnissen eines Diagnoseauftrags mit mehreren Semantiken
z.B. Analog, Bitfield und Diskret.
Weitere Informationen zur Ergebnisdefinition siehe Lastenheft Diagnose Teil 5

"Richtlinien für Steuergerätebeschreibungsdateien" (SAP: 10000786).
2.4.2 Regeln für die Entwickler-Resultnamen
Result-Typ RESULTNAME EINHEIT DATENTYP

Analoges Result _STAT_..._WERT char, int, usw.
TEXT Ergebnisse _STAT_..._TEXT TEXT string[n]
1 ≤ n ≤ 255
DATA Ergebnisse _STAT_..._DATA DATA data[n]
1 ≤ n ≤ 255
Digitale Ergebnisse _STAT_... 0/1 char, int, usw.
_WERT)
Diskrete Ergebnisse _STAT_... 0-n char, int, usw.
_WERT)
Hex Ergebnisse _STAT_..._WERT HEX char, int, usw.
Bit-Field Ergebnis _.... BIT BITFIELD
_WERT)
• Entwicklerresults mit „_“…

Bisher wurden Entwicklerresults von der Überprüfung ausgeschlossen, dies gilt nun nicht
mehr, da der Standardjob auch Entwicklerjobs überprüft. Entwickler Results unterscheiden
sich durch "normale" Result nur dadurch, dass ein "_" dem Namen vorangestellt ist. Ansons-
ten gelten die gleichen Regeln wie bei einem "normalen" Ergebnis. Insbesondere muss hier
fast immer ein "_STAT_" vorangestellt werden.

2.4.3 Beispiel einer Ergebnistabelle mit möglichen Ergebnistypen.
Ergebnistabelle:
RESULTNAME EINHEIT L/H DATENTYP MASKE NAME MUL DIV ADD INFO
STAT_SPANNUNG_WERT V - CHAR - - - - - Spannung in Volt

- Spannungsversorgung:
STAT_VERSORGUNG_EIN 0/1 - INT - - - -
1=EIN; 0=AUS
Radposition; Zuord-
STAT_RAD 0-n - CHAR - TAB_RAD - - -
nung gemäß TAB_RAD
STAT_ANTWORT_WERT HEX - INT - - - - - Antworttelegramm
Tabelle „TAB_RAD“:
WERT TEXT
0x01 Rad vorne links
0x02 Rad vorne rechts
0x03 Rad hinten links
0x04 Rad hinten rechts
0xFF nicht definiert
Der Aufruf des Diagnoseauftrags führt zu folgenden Results:
STAT_SPANNUNG_WERT (Semantik Analog):

STAT_SPANNUNG_EINH =V
STAT_SPANNUNG_INFO = Spannung in Volt
STAT_SPANNUNG_WERT = 8.000000E+000
STAT_VERSORGUNG_EIN (Semantik Digital):

STAT_VERSORGUNG_EIN =1
STAT_VERSORGUNG_EIN_INFO = Spannungsversorgung: 1=EIN; 0=AUS;
STAT_RAD_NR (Semantik Diskret):

STAT_RAD =2
STAT_RAD_EINH = 0-n
STAT_RAD_INFO = Radposition; Zuordnung gemäß TAB_RAD
STAT_RAD_TEXT = Rad hinten links
STAT_ANTWORT_WERT (Semantik HEX):

STAT_ANTWORT_EINH = hex
STAT_ANTWORT_INFO = Antworttelegramm
STAT_ANTWORT_WERT = AFFE

3 Beschreibung der Standardjobs
3.1 JOB: STATUS_LESEN ($22- ReadDataByIdentifier)

Der ReadDataByIdentifier-Service erlaubt dem Tester Daten, die über einen Data-Identifier
definiert sind, gezielt von einem Steuergerät abzufragen. Eine Abfrage kann einen oder
mehrere Data-Identifier beinhalten. Wenn das Steuergerät einen ReadDataByIdentifier vom
Tester erhält, soll es die dazu gehörigen Daten, die durch den Data-Identifier definiert sind,
in einem positiven Response zum Tester senden. Zum Beispiel kann durch senden eines
bestimmten Data-Identifier (DID) der Spannungswert des Bordnetzes abgerufen werden.
Weitere Informationen entnehmen Sie den Lastenheften oder der ISO/DIS 14229.
3.1.1 Auslesen von einem Data-Identifier (DID) aus dem Steuergerät
Um den Standardjob “STATUS_LESEN“ aufzurufen, müssen zwei Argumente übergeben

werden:
Argument 1: “ARGUMENT_SPALTE“
• Hier wird der Name der Spalte eingetragen, aus der das 2. Argument benutzt wer-
den soll. Aus der Tabelle “SG_Funktionen“ können die Spalten “ARG“, “ID“ oder
“LABEL“ ausgewählt werden.
Argument 2: “STATUS“
• Hier wird der Wert, aus der im 1. Argument gewählten Spalte, eingetragen werden.
Z.B “DID“ = 0xD001
3.1.1.1 Beispiel 1: Auslesen des Saugdruckwertes
Der Saugdruck soll aus einem Motorsteuergerät ausgelesen werden. Dazu sind drei ver-
schiedene Jobaufrufe möglich.
a: Dem Job wird ein Argument aus der Spalte “ARG“ übergeben
apiJob("<SGBD-Name>","STATUS_LESEN","ARG;IPSAU","")
b: Dem Job wird ein Argument aus der Spalte “ID“ übergeben
apiJob("<SGBD-Name>"," STATUS_LESEN ","ID; 0xD002","")
c: Dem Job wird ein Argument aus der Spalte “LABEL“ übergeben
apiJob("<SGBD-Name>"," STATUS_LESEN ","LABEL; MAP_MES","")
Auszug aus der Tabelle “SG_Funktionen”
Tabelle „SG_Funktionen“:
ARG ID RESULTNAME INFO EINHEIT LABEL L/H
IPSAU 0xD002 STAT_SAUGROHRDRUCK_WERT Saugrohrdruck hPa MAP_MES -
DATENTYP NAME MUL DIV ADD SG_ADR SERVICE ARG_TABELLE RES_TABELLE
unsigned int - 0,82 1 1 0x12 22 - -

Der Job kann wie folgt aufgerufen werden. Wenn das Steuergerät richtig antwortet, dann
werden die Results automatisch erzeugt. (Siehe Beispiel )
ApiJob ("<SGBD-Name>"," STATUS_LESEN ","ID; 0xD002","")
STAT_ SAUGROHRDRUCK _EINH = hPa

STAT_ SAUGROHRDRUCK _INFO = Saugrohrdruck
STAT_ SAUGROHRDRUCK _WERT = 9.000000E+000
3.1.1.2 Beispiel 2: Auslesen von mehreren Data-Identifier (DID) aus dem Steuergerät
Mit dem Job “STATUS_LESEN“ ist es auch möglich mehrere Data-Identifier und somit
mehrere Ergebnisse mit einem Jobaufruf aufzurufen. Die Anzahl der DID’s die durch einen
Jobaufruf abgefragt werden können, sind bei den Steuergeräten unterschiedlich. Die ma-
ximale Anzahl der DIDs die aufgerufen werden können, legt jeder Entwickler für sein Steu-
ergerät im Feld “Konstanten“ im SGBD-Generator fest.
Defaulteinstellung: unsigned char MAX_ARGUMENT_STATUS_LESEN = 5;
3.1.1.3 Beispiel 3: Auslesen des Saugdruckwertes und der Lufttemperatur
ApiJob ("<SGBD-Name>"," STATUS_LESEN ","ID; 0xD002; 0xD003","")

STAT_ LUFTTEMPERATUR _EINH = °C

STAT_ LUFTTEMPERATUR _INFO = Luft-Temperatur
STAT_ LUFTTEMPERATUR _WERT = 25.000000E+000
Auszug aus der Tabelle “SG_Funktionen”
ITANS 0xD003 STAT_LUFTTEMPERATUR_WERT Luft-Temperatur °C TIA -
unsigned int - 0,82 1 1 0x12 22 - -
unsigned char - 0,75 1 1 0x12 22 - -
Die obige Umrechnung z.B. für STAT_LUFTTEMPERATUR_WERT bedeutet, dass ein

Wert vom Steuergerät zurückgeliefert wird, welches vom Standardjob als unsigned char
interpretiert und als real in EDIABAS ausgeben wird also:
32 (°C) x 0,75
========== + 1 = 25 (°C - Luft-Temperatur) => Ausgabe in EDIABAS 25.000000E+000
1

3.1.2 Sonderfall: Mehrere Results pro Funktionsaufruf
Der Service $22 erlaubt dem Tester mehrere Ergebnisse mit einem Data-Identifier abzu-
rufen. Das bedeutet, dass ein DID zum Steuergerät geschickt wird und das Steuergerät
mehrere Ergebnissätze zurückgeben kann.
Die einzelnen Results, die vom Steuergerät geliefert werden, müssen in einer Subtabelle
definiert sein. Der Name der Subtabelle wird in der Spalte “RES_TABELLE“ in der Tabelle
“SG_Funktionen“ eingetragen. Die Reihenfolge der Results darf nicht vertauscht werden.
3.1.2.1 Beispiel 1: Auslesen von Lichtstatus aus einem Lichtsteuergerätes

Der Aufruf soll mehrere Status von Glühlampen des Lichtmoduls liefern.
Der Jobaufruf sieht wie folgt aus:
ApiJob ("<SGBD-Name>"," STATUS_LESEN ","ID; 0xD020","")
STAT_ FL_LINKS_EIN =1
STAT_ FL_LINKS_EIN_INFO = Fernlicht links 1=EIN, 0=AUS
STAT_ FL_RECHTS_EIN =0
STAT_ FL_RECHTS_EIN_INFO = Fernlicht rechts 1=EIN, 0=AUS
STAT_ AL_LINKS_EIN =0
STAT_ AL_LINKS_EIN_INFO = Abblendlicht links 1=EIN, 0=AUS
STAT_ AL_RECHTS_EIN =1
STAT_ AL_RECHTS_EIN_INFO = Abblendlicht rechts 1=EIN, 0=AUS
Auszug aus der Tabelle “SG_Funktionen”:
Auslesen des Abblend- und

FL_AL_LICHT 0xD020 - - - -
des Fernlichtes
RES_TABELLE
DATENTYP NAME MUL DIV ADD SG_ADR SERVICE ARG_TABELLE
- - - - - - 22 - RES_0xD020
Tabelle „RES_0xD020“:
Fernlicht links:
STAT_FL_LINKS_EIN 0/1 - INT - - - - -
1=EIN; 0=AUS
Fernlicht rechts:
STAT_FL_RECHTS_EIN 0/1 - INT - - - - -
1=EIN; 0=AUS
Abblendlicht links:
STAT_AL_LINKS_EIN 0/1 - INT - - - - -
1=EIN; 0=AUS
Abblendlicht
STAT_AL_RECHTS_EIN 0/1 - INT - - - - - rechts:
1=EIN; 0=AUS
In diesem Beispiel wird für jedes Result der Datentyp “INT“ benutzt. Wenn viele Status von
einem Steuergerät abgerufen werden sollen, können die Anzahl der Datenbytes verringert
werden, wenn der Datentyp “BITFIELD“ benutzt wird (siehe 3.1.2.2 ).

3.1.2.2 Beispiel 2: Auslesen von Lichtstatus mit Hilfe des Datentyps “BITFIELD“
Durch die Verwendung des Datentyps “BITFIELD“ in der Spalte “DATENTYP“ in der Ta-
belle SG_Funktionen können mehrere Status in einem Byte (oder mehreren Bytes) ausge-
wertet werden. Die Maske zum Ausmaskieren wird in der Subtabelle in der Spalte “Maske“
angegeben. Bei diskreten (0-n) und digitalen (0/1) Ergebnissen sind 1, 2 oder 4 Byte er-
laubt. Ist ein Diagnoseauftrag als Bitfield deklariert, werden alle darin enthaltenen Argu-
mente/Results als Bitfield behandelt. Darüber hinaus dürfen keine weiteren Argumen-
te/Results angelegt werden.
Auslesen des Abblend-

FL_AL_SL_LICHT 0xD020 - BIT - -
und des Fernlichtes
NAME
DATENTYP MUL DIV ADD SG_ADR SERVICE ARG_TABELLE RES_TABELLE
BITFIELD RES_0xD020 - - - - 22 - -
Fernlicht links:
STAT_FL_LINKS_EIN 0/1 - INT 0x0001 - - - -
1=EIN; 0=AUS
Fernlicht rechts:
STAT_FL_RECHTS_EIN 0/1 - INT 0x0002 - - - -
1=EIN; 0=AUS
Schlusslicht:
STAT_SL 0-n - INT 0x0030 TAB_SL - - -
siehe Subtabelle
Abblendlicht rechts:
STAT_AL_RECHTS_EIN 0/1 - INT 0x0100 - - - -
1=EIN; 0=AUS
*1) *2)
*1): Erlaubte Einheiten sind “0/1“ und “0-n“

*2): Erlaubte Datentypen sind char, int und long. Innerhalb eines Bitfeldes müssen alle Da-
tentypen gleich sein.
TAB_SL: Subtabelle für diskrete Werte
Tabelle „TAB_SL“:
WERT TEXT
0x01 Schlusslicht links hinten

Schlusslicht rechts
0x02
hinten
0xFF nicht definiert

3.1.2.3 Beispiel 3: Ergebnistabelle mit gemischten Ergebnistypen und BITFIELD
Im Gegensatz zu Beispiel 2 kann auch statt einem kompletten Diagnoseauftrag als Bitfield
zu deklarieren, innerhalb eines Diagnoseauftrags einzelne Results als Bitfield behandelt
werden. Somit ist es möglich Teile vom Antworttelegram einzeln als Bitfield auszulesen.
TEST_BSP3 0xD040 - TEST GEMISCHTE ERG - - -
- - - - - - 22 - RES_0xD040
Ergebnistabelle „RES_0xD040“:
M D A
L/ MAS
RESULTNAME EINHEIT DATENTYP NAME U I D INFO
H KE
L V D
-
STAT_ANALOG_WERT °C - char - - - - Analoges Ergebnis
Spannungsversorgung:
STAT_BITFIELD_ERG BIT - BITFIELD - BF_BITFIELD1 - - -
1=EIN; 0=AUS
Bitfield: einzelnen Er-
unsigned
STAT_DISKRETE_WERTE 0-n - - TAB_DISKRETE_ - - - gebnisse stehen in der
char WERTE Tabelle BF_BITFIELD1
Tabelle „BF_BITFIELD1“:
RESULTNAME EINHEIT L/H DATENTYP NAME NAME MUL DIV ADD INFO
STAT_2A 0-n - unsigned int 0x00FF TEingangVideoSwitch - - - Test 2A
STAT_2B 0-n - unsigned int 0x0F00 - - - Test 2B
STAT_2C 0-n - unsigned int 0xF000 - - - Test 2C
Interpretation der Ergebnistabelle:

• STAT_ANALOG_WERT, Analoges Ergebnis mit Datentyp „char“ (1 Byte)
• STAT_BITFIELD_ERG, Bitfield Ergebnis (neu) mit Datentyp „unsigned int“ (2 Byte)
o STAT_2A, Diskretes Ergebnis mit Datentyp “unsigned int“, Maske 0x00FF
o STAT_2B, Diskretes Ergebnis mit Datentyp “unsigned int“, Maske 0x0F00
o STAT_2C, Diskretes Ergebnis mit Datentyp “unsigned int“, Maske 0xF000
• STAT_DISKRETE_ERG, Diskretes Ergebnis mit Datentyp „unsigned char“ (1 Byte)
In so einem Fall antwortet das SG mit einem Telegramm der Länge 4 Bytes (1+2+1). Die
genaue Beschreibung vom fachlichen Inhalt des Telegrams ist nun verschachtelt:
• STAT_ANALOG_WERT ist im 1. Byte
• STAT_BITFIELD_ERG von den 2. und 3. Bytes
o STAT_2A ist in den Bits 0 bis 7 (komplettes 2te Byte)
o STAT_2B ist in den Bits 8 bis 11 (Teil des 3ten Bytes)

o STAT_2C ist in den Bits 12 bis 15 (Teil des 3ten Bytes)
• STAT_DISKRETE_ERG ist im 4. Byte
Die von den Ergebnissen referenzierten Subtabellen:
Tabelle „BF_BITFIELD1“ beschreibt das Bitfield Ergebnis vom Datentyp „char“:

WERT TEXT
0x01 1. Wert
0x02 2. Wert
0x03 3. Wert
Tabelle „TEingangVideoSwitch“ beschreibt das diskrete Ergebnis vom Datentyp

„unsigned int“:
WERT TEXT
0x0001 1. Wert
0x0002 2. Wert
0x0003 3. Wert

3.2 JOB: STEUERN ($2E- WriteDataByIdentifier)

Der WriteDataByIdentifier-Service erlaubt dem Tester, den Speicher eines Steuergerätes
zu beschreiben, der durch einen Data-Identifier festgelegt wird.
Anwendungsfälle für diesen Service sind:
• Schreiben von Konfigurations-Informationen in das Steuergerät

• Setzen/ Rücksetzen von Werten
• Löschen von nichtflüchtigen Speicher
Zum Beispiel kann durch Senden eines bestimmten Data-Identifier (DID) eine Nummer ins
Steuergerät geschrieben werden.
Achtung:
Das Steuergerät kann den Zugriff auf verschiedene Data-Identifier einschränken oder ganz
untersagen (nur zum Lesen definierte Data-Identifier durch den Zulieferer oder Fahrzeug-
hersteller).
Um den Standardjob “STEUERN“ aufzurufen, müssen drei Argumente übergeben werden:
Z.B “DID“=0xD001
Argument 3: “WERT“
• Hier wird der Wert eingegeben, der an das Steuergerät zum Steuern übergeben
werden soll. Z.B “Nr“=1234567

3.2.1 Beispiel 1: Vorgeben einer Drehzahl

Die Leerlaufdrehzahl eines Motors soll dem Motorsteuergerät vorgegeben werden. Dazu
sind drei verschiedene Jobaufrufe möglich (siehe auch 3.1.1.1). Die Parameter werden an
das Steuergerät übergeben und bei erfolgreichem Aufruf wird “JOB_STATUS = OKAY“
zurück geliefert.
apiJob("<SGBD-Name>"," STEUERN ","ARG;MOT_DREHZAHL;2500","")
Steuern der Motordrehzahl.

MOT_DREHZAHL 0xD030 - - MDREH -
Eingabe in 1/min
ARG_TABELLE
DATENTYP NAME MUL DIV ADD SG_ADR SERVICE RES_TABELLE
- - - - - - 2E ARG_0xD030 -
Tabelle „ARG_0xD030“:
ARG EINHEIT L/H DATENTYP MASKE NAME MUL DIV ADD MIN MAX INFO
DREHZAHL 1/min - INT - - 1 1 0 - - Motordrehzahl in 1/min
Hinweis:
• Wenn ein Aufruf ein oder mehrere Argumente besitzt, dann befinden sich die Ar-
gumente in einer Subtabelle.
• Beim Service $2E muss mindestens ein Eintrag in der Argument Tabelle vorhanden
sein. Ein Aufruf ohne ein Argument ist nicht zulässig.

3.2.2 Sonderfall: Mehrere Argumente pro Funktionsaufruf übergeben

Der Service $2E erlaubt dem Tester mehrere Argumente mit einem Data-Identifier zu
übergeben. Das bedeutet, dass ein DID mit mehreren Argumenten zum Steuern versendet
werden kann.
Dieser Mechanismus funktioniert nur, wenn die Tabelle “SG_Funktionen“ richtig ausgefüllt
ist. Die einzelnen Argumente, die dem Steuergerät geliefert werden müssen, werden in
einer Subtabelle definiert. Der Name der Subtabelle wird in der Spalte “ARG_TABELLE“ in
der SG_Funktionen eingetragen. Es müssen immer alle Argumente übergeben werden.
Die Reihenfolge der Argumente darf nicht vertauscht werden.
3.2.2.1 Beispiel 2: Übergeben von mehreren Argumenten pro Funktionsaufruf

Die Außenspiegel eines Fahrzeuges sollen verfahren werden. Dazu benötigt das Steuerge-
rät folgende 3 Argumente.
Argument 1: “AUSWAHL_SPIEGEL“
• Mit dem Argument wird der Spiegel ausgewählt, der verfahren werden soll.
Mögliche Eingaben: “1“= Fahrerspiegel oder “0“= Beifahrerspiegel
Argument 2: “RICHTUNG_SPIEGEL“
• Mit dem Argument wird die Richtung festgelegt.
Mögliche Eingaben: “rechts“, “links“, “oben“ oder “unten“
Argument 3: “ANSTEUER_ZEIT“
• Mit dem Argument wird die Ansteuerzeit in ms festgelegt.
apiJob("<SGBD-Name>"," STEUERN ","ARG; SPIEGEL_VERFAHREN;1;RECHTS;1000","")
SPIEGEL_VERFAHREN 0xD040 - Verfahren der Außenspiegel - SP_VERFAHREN -
ARG_TABELLE
DATENTYP NAME MUL DIV ADD SG_ADR SERVICE RES_TABELLE
- - - - - - 2E 0xD040 -
1=Fahrerspiegel,
AUSWAHL_SPIEGEL 0/1 - INT - - - - - - -
0=Beifahrerspiegel
0x01=rechts, 0x02=links,
RICHTUNG_SPIEGEL 0-n - INT - TAB_SP_RI - - - - -
0x03=oben, 0x04= unten
ANSTEUER_ZEIT ms - INT - - - - - - - Ansteuerzeit in ms

Tabelle „TAB_SP_RI“:
WERT TEXT
0x01 rechts
0x02 links
0x03 oben
0x04 unten
Hinweis:
• Beim Aufruf von diskreten Argumenten kann der Eintrag aus der Spalte “TEXT“
oder der Eintrag aus der Spalte “WERT“ übergeben werden.
Beispielaufruf:
Tabelle „TAB_SP_RI“:
WERT TEXT
0x01 rechts
0x02 links
0x03 oben
0x04 unten
apiJob("<SGBD-Name>"," STEUERN ", apiJob("<SGBD-Name>"," STEUERN ",

"ARG; "ARG;
SPIEGEL_VERFAHREN;1;0x01; SPIEGEL_VERFAHREN;1;RECHTS;
1000","") 1000","")

3.3 JOB: STEUERN_ROUTINE ($31- RoutineControl)

Der Service $31 erlaubt dem Tester
- eine Routine zu starten [0x01: StartRoutine (STR)]

- eine Routine zu stoppen [0x02: StopRoutine (STPR)]
- Ergebnisse vom Steuergeräte abzufragen [0x03: RequestRoutineResults (RRR)]
Die einzelnen Argumente, die dem Steuergerät geliefert werden müssen, werden in einer
Subtabelle definiert. Der Name der Subtabelle wird in der Spalte “ARG_TABELLE“ in der
SG_Funktionen eingetragen.
Um den Standardjob “STEUERN_ROUTINE“ aufzurufen, müssen drei ggf. vier Argumente

übergeben werden.
Z.B “RID“=0xA001
Argument 3: “STEUERPARAMETER“
• RoutineControlOptionRecord. Mögliche Eingaben:
o STR: Routine starten
o STPR: Routine stoppen
o RRR: Ergebnisse vom Steuergerät abfragen
werden soll. Dieses Argument wird nur benötigt, wenn in der Subtabelle ein Parame-
ter definiert ist.
3.3.1 Beispiel 1: Starten (oder stoppen) der Routine
apiJob("<SGBD-Name>"," STEUERN_ROUTINE ","ARG; SENDER_SUCHLAUF;STR","")
SENDER_SUCHLAUF 0xA055 - Sender suchen - SENDER_SL -
- - - - - - 31 - -

3.3.2 Beispiel 2: Abrufen von Results mit dem Service $31
apiJob("<SGBD-Name>"," STEUERN_ROUTINE ","ARG;

SENDER_SUCHLAUF;RRR","")
STAT_SUCHLAUF_EIN = 1
STAT_BEST_AM_SENDER = SENDER_A
STAT_BEST_FM_WERT = 96,65
STAT_BEST_FM_WERT_EINH = kHz
STAT_BEST_AM_WERT = 88,50
STAT_BEST_AM_WERT_EINH = kHz
SENDER_SUCHLAUF 0xA055 - Sender suchen - SENDER_SL -
RES_TABELLE
DATENTYP NAME MUL DIV ADD SG_ADR SERVICE ARG_TABELLE
INT - - - - - 31 - RES_0xA055
Tabelle „RES_0xA055“:
DATEN-
RESULTNAME STR STPR RRR EINHEIT L/H MASKE NAME MUL DIV ADD INFO
TYP
0=Suchlauf aus,
STAT_SUCHLAUF_EIN - - + 0/1 - INT - - - - -
1=Suchlauf ein
Gibt den Namen
STAT_BEST_AM_SENDER - - + 0-n - STRING - - - - - des besten AM
Sender zurück
STAT_BEST_FM_WERT - + + kHz - INT - - 100 - Wert FM Sender
STAT_BEST_AM_WERT - + + kHz - INT - - - 100 - Wert AM Sender
Eine Besonderheit des Jobs “STEUERN_ROUTINE“ ist, dass für jeden Steuerparameter
(STR, STPR, RRR) einzelne Results definiert werden können. Somit können unterschiedli-
che Results für Start, Stop oder beim Abfragen von Results definiert werden. Die Definition
erfolgt in der jeweiligen Subtabelle. In dieser Tabelle befinden sich immer alle Results, die
zu einer ID gehören. Die Auswahl der einzelnen Results wird festgelegt, indem die Spalten
STR, STPR, RRR mit einem “-“ oder “+“ befüllt werden.
Dabei gilt:
“-“: Das Argument/Result wird beim Aufruf der ID mit dem jeweiligen Steuerparame-
ter nicht benutzt
“+“: Das Argument/Result wird beim Aufruf der ID mit dem jeweiligen Steuerparame-
ter benutzt

3.4 JOB: STEUERN_IO ($2F- InputOutputControlByIdentifier)

Der Service $2F wird benutzt, um über einem Data-Identifier einen Wert für ein Eingangs-
signal, eine interne Server-Funktion und/oder einen Ausgangswert zu setzen.
Wenn die Anfrage des Testers erfolgreich ausgeführt wurde, soll das Steuergerät eine po-
sitive Antwort senden.
Der Service erlaubt die Kontrolle über einen einzelnen Data-Identifier über den entspre-
chenden controlOptionRecord einer einzelnen Anfrage.
Die einzelnen Argumente, die dem Steuergerät geliefert werden müssen, werden in einer
Subtabelle definiert. Der Name der Subtabelle wird in der Spalte “ARG_TABELLE“ in der
SG_Funktionen eingetragen.
Um den Standardjob “STEUERN_IO“ aufzurufen, müssen vier Argumente übergeben wer-
den.
Z.B “DID“=0xD001
Argument 3: “STEUERPARAMETER“
• ControlOptionRecord. Mögliche Eingaben:
o RCTECU: ReturnControlToECU
o RTD: ResetToDefault
o FCS: FreezeCurrentState
o STA: ShortTermAdjustment
Hinweis: Wird kein Steuerparameter übergeben, wird ShortTermAdjustment (STA) be-

nutzt.
werden soll. Z.B. “Drehzahl“= 2300 1/min
3.4.1 Beispiel 1: Vorgeben einer Drehzahl

Dem Steuergerät soll eine Drehzahl von 2300 1/min vorgegeben werden. Als Rückgabe-
wert wird die IST-Drehzahl zurückgegeben.
apiJob("<SGBD-Name>"," STEUERN_IO","ARG;
DREHZAHL_VORGEBEN;STA;2300","")
STAT_IST_DREHZAHL_WERT = 2312
STAT_IST_DREHZAHL_EINH = 1/min
STAT_ FL_LINKS_INFO = Aktuelle Drehzahl in 1/min

Drehzahl kann i n1/min

DREHZAHL_VORGEBEN 0xD080 - - DREHZAHL_SOLL -
vorgegeben werden
INT - - - - - 2F ARG_0xD080 RES_0xD080
Motordrehzahl
DREHZAHL 1/min - INT - - 1 1 0 800 6000
Eingabe in 1/min
Aktuelle Drehzahl in
STAT_IST_DREHZAHL_WERT 1/min - INT - - - - -
1/ min

3.5 JOB: STATUS_BLOCK_LESEN ($2C- DynamicallyDefineData-

Identifier)
Der Service $2C erlaubt dem Tester in einem Steuergerät einen oder mehrere Data-
Identifier in einem Block zusammenzufassen. Beim Aufruf müssen die Data-Identifier an-
gegeben werden, die anschließend ausgelesen werden sollen. Zum Auslesen der angefor-
derten Identifier wird der Job “STATUS_BLOCK_LESEN“ benutzt. Die Data-Identifier, die
ausgelesen werden sollen, müssen in der Tabelle “SG_Funktionen“ definiert sein.
Der Service sollte nur benutzt werden, wenn eine zeitsynchrone Erfassung von Ergebnis-
sen benötigt wird. Die einfachere Lösung ist der Service $22 mit mehreren Ergebnissen
(siehe Kapitel 3.1.1.2)
Argument 1: “BLOCK_NR“
• Hier wird die Nummer des Blockes angegeben, der ausgelesen werden soll. Erlaub-
ter Bereich 0 – 255.
Argument 2: “NEU_DEFINIEREN“
• Wird “JA“ oder “YES“ eingegeben, dann wird der Block im SG gelöscht und neu ins
SG geschrieben. Wird “NEIN“ oder “NO“ eingegeben, dann wird der Block im SG
nicht gelöscht und nicht geschrieben.
Anschließend wird der Block gelesen.
Hinweis: Der erste Aufruf für einen Block erfolgt immer mit YES. Anschließend kann z.B.
eine zyklische Abfrage mit NO erfolgen, da ein löschen und neu anlegen jedes mal ineffi-
zient ist und der Aufruf mit YES wesentlich länger dauert als mit NO.
• Hier wird der Wert, aus der im 1. Argument gewählten Spalte, eingetragen für die
gewünschten Data-Identifier. z.B “DID“ = 0xD002 und 0xD003
3.5.1 Beispiel 1: Erzeugen von 2 Data-Identifier
apiJob("<SGBD-Name>"," STATUS_BLOCK_LESEN","1;YES;ID;
0xD002;0xD003","")
ITANS 0xD003 STAT_LUFTTEMPERATUR_WERT Luft-Temperatur °C TIA -
unsigned int - 0,82 1 1 - 22;2C - -
unsigned char - 0,75 1 1 - 22;2C - -

Bei diesem Aufruf werden die angeforderten Werte der Data-Identifier im Steuergerät be-
reitgestellt und können anschließend mit dem JOB “STATUS_BLOCK_LESEN“ ausgele-
sen werden.
3.5.2 Beispiel 2: Auslesen von 2 Data-Identifier
Wurde ein Block angelegt wie im Beispiel 1, so kann dieser Block erneut ausgelesen wer-
den.
Hinweis: Die Reihenfolge der angegeben DIDs darf nicht vertauscht werden. Da die Daten
sonst falsch interpretiert werden.
Der Aufruf sieht wie folgt aus:
ApiJob ("<SGBD-Name>"," STATUS_BLOCK_LESEN ","1; NO; ID; 0xD002; 0xD003","")

STAT_ LUFTTEMPERATUR _EINH = °C

STAT_ LUFTTEMPERATUR _INFO = Luft-Temperatur
STAT_ LUFTTEMPERATUR _WERT = 25.000000E+000
Folgender Aufruf wäre falsch, da der DID 0xD003 im Beispiel 1 nicht als erstes, sondern
als zweites Argument übergeben wurde:
ApiJob ("<SGBD-Name>"," STATUS_BLOCK_LESEN ","1; NO; ID; 0xD003; 0xD002","")

4 Kombinieren von Services

Folgende Kombinationen für die Verwendung von verschiedenen Services pro Data-
Identifier (DID) sind möglich.
a) $22 und $2E:

b) $22 und $2F: Diese Kombination ist nur möglich, wenn beim Aufrufen des Service
2F dieselben Results wie beim Service $22 zurückgegeben werden.

5 Hinweise zum Toolset32 (Tool32.exe)

Um die Bedienung von Tabellen im Toolset zu erleichtern wurden Erweiterungen
eingepflegt. Parameter in Tabellen können einfach ausgewählt werden und die Navigation
zwischen Tabellen und Subtabellen ist jetzt möglich.
5.1 Tipp1: Laden der Tabelle SG_Funktionen
Bei Auswahl einer der UDS-Standardjobs in der Jobauswahl wird in der Job-Info auf die Tabelle
SG_Funktionen verwiesen. Mit Doppelklick wird die Tabelle SG_Funktionen in der Tabelleninfo ange-
wählt.
1. Doppelklick

5.2 Tipp2: Parameter aus einer Tabelle übernehmen

Mit einem „Doppelklick“ kann ein Parameter aus der Tabelle in das Eingabefeld für Argu-
mente übernommen werden. Dabei wird automatisch die Spaltenbezeichnung ergänzt.
1. Doppelklick
2. Der Eintrag im
Eingabefeld wird
automatisch befüllt.
Diese Funktion ist für die Spalten “ARG“, “ID“ und “LABEL“ implementiert.

5.3 Tipp3: Navigieren zwischen (Sub)-Tabellen

Das Navigieren zwischen mehreren Tabellen wurde optimiert, so dass nun mit einem
„Doppelklick“ die Tabellen gewechselt werden können.
1. Doppelklick
2. Tabelle wird geöffnet
3. Das Navigieren ist mit

Hilfe der Pfeiltasten möglich.

6 Verwendung von Umwelttexten

Ähnlich der SG_Funktionen Tabelle werden die Tabellen FUmwelt- und IUmweltTexte
verwendet. Die genaue Verwendung ist im Lastenheft Diagnose Teil 5 (SAP: 10000786)
beschrieben.
Im nachfolgenden Beispiel ist eine FUmweltTexte Tabelle mit unterschiedlichen Elemen-

ten dargestellt. Die Tabelle kann weitere Tabellen referenzieren, in diesem Beispiel die Ta-
belle Tab_0x00AA und die Tabelle Gang.
table FUmweltTexte[9][] = {
{"UWNR" , "UWTEXT" , "UW_EINH" , "L/H" , "UWTYP" ,"NAME","MUL","DIV","ADD" },
{"0x0001", "@Batteriespannung@", "@Volt@" , "-" , "unsigned char", "-" , "25","255", "0"},
{"0x0002", "@Aussentemperatur@", "@Grad C@", "high", "signed int" , "-" , "1" , "1" , "0"},
{"0x0003", "@Motordrehzahl@" , "@1/min@" , "low" , "signed long" , "-" ,"1.97", "1", "7"},
{"0x0004", "@SHD-Position@" , "@mm@" , "-" , "Intel float" , "-" , "-" , "-" , "-"},
{"0x00AA", "SUB-Tabelle" , "0/1" , "-" , "0xFF" , "-" , "-" , "-" , "-"},
{"0x0005", "@Magnetventil@ 1" , "0/1" , "-" , "0x80" , "-" , "-" , "-" , "-"},
{"0x0006", "@Magnetventil@ 2" , "0/1" , "-" , "0x40" , "-" , "-" , "-" , "-"},
{"0x0007", "@Magnetventil@ 3" , "0/1" , "-" , "0x20" , "-" , "-" , "-" , "-"},
{"0x0009", "@Klappenposition@" , "@Grad@" , "-" , "signed char" , "-" ,"27","100","-50"},
{"0x000A", "@Taste XY@" , "0/1" , "-" , "0x01" , "-" , "-" , "-" , "-"},
{"0x0010", "@Waehlhebel@" , "0-n" , "-" , "0x07" ,"Gang", "-" , "-" , "-"},
{"0x0031", "@Schalter@ 1" , "0/1" , "high", "0x0001" , "-" , "-" , "-" , "-"},
{"0x0032", "@Schalter@ 2" , "0/1" , "high", "0x0002" , "-" , "-" , "-" , "-"},
{"0x0033", "@Schalter@ 3" , "0/1" , "high", "0x0004" , "-" , "-" , "-" , "-"},
{"0x0034", "@Stoerlampe@" , "0/1" , "high", "0x0010" , "-" , "-" , "-" , "-"},
{"0x0035", "@Bremse betaetigt@", "0/1" , "high", "0x0100" , "-" , "-" , "-" , "-"},
{"0x0040", "@Adresse@ XY" , "Hex" , "high", "unsigned int" , "-" , "-" , "-" , "-"},
{"0x0050", "@Audioquelle@" , "Text" , "high", "3" , "-" , "-" , "-" , "-"},
{"0xFFFF", "@ohne Bedeutung@" , "1" , "-" , "unsigned char", "-" , "1" , "1" , "0"},
{"0xXXYY", "@unbekannte UW@" , "1" , "-" , "unsigned char", "-" , "1" , "1" , "0"}
};
table Gang[2][] = {
{ "WERT", "UWTEXT" },
{ "0x01", "@Gang@: 1" },
{ "0x02", "@Gang@: 2" },
{ "0x03", "@Gang@: 3" },
{ "0x04", "@Gang@: 4" },
{ "0x05", "@Gang@: 5" },
{ "0x06", "@Gang@: R" },
{ "0xXY", "@Gang@: @unplausibel@" }
};
Die Tabelle Tab_0x00AA ist ein Beispiel für die Aufteilung eines Bytes in 3 digitale / 1 diskrete Um-
weltbedingungen. Eine solche Aufteilungstabelle darf nur Indizes für digitale (hier: 0x0005, 0x0006,
0x0007) oder diskrete Umweltbedingungen (hier: 0x0010) enthalten.
Die Spaltennamen beginnen nach UW_ANZ mit UW1_NR und gehen bis zur n-ten Umweltbedingung
(hier: UW4_NR). Die Anzahl der Umweltbedingungen (hier: 4) muss dabei in der 1. Spalte UW_ANZ
eingetragen werden. Ferner ist zu beachten, dass die Anzahl der Spalten der Tabelle bei der Tabellen-
definition angegeben werden muss (im Beispiel: TAB_0x00AA[5][]).
table Tab_0x00AA[5][] = {
{ "UW_ANZ", "UW1_NR", "UW2_NR", "UW3_NR", "UW4_NR" },
{ "4" , "0x0005", "0x0006", "0x0007", "0x0010" }
};

7 Ansprechpartner und Links
7.1.1 Hotline EDIABAS und SGBD-Generator:

Tel.: 089/382-68878
Abteilung: TI-538, 1.5/013.5-2
E-Mail: referenz@bmw.de
7.1.2 Hotline ZEDIS:

E-Mail: ee_servicedesk@bmw.de
Tel: +49-89-382-61664
7.1.3 Links (BMW-Intranet):

ZEDIS Homepage:
http:\\zedis.muc
Global-Information-Service (GIS):
https://gis.bmw.com


Anleitung STATUS STEUERN UDS

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Anleitung STATUS STEUERN UDS

Hochgeladen von

Copyright:

Verfügbare Formate

BMW Group

Verwendung der UDS-Jobs

1.14 01.08.2008 A. Reuß Tipps zu EDIABAS Toolset hinzu

Stephan Keitel, Firma ESG 06.02.2012

2 Tabelle ”SG_Funktionen” für Standardjobs ............................................................................... 6

5 Hinweise zum Toolset32 (Tool32.exe) ....................................................................................... 29

7 Ansprechpartner und Links ........................................................................................................ 33

Stephan Keitel, Firma ESG 06.02.2012

Stephan Keitel, Firma ESG 06.02.2012

Abbildung 1: Formular “SG Funktionen“ im SGBD-Generator

Stephan Keitel, Firma ESG 06.02.2012

2 Tabelle ”SG_Funktionen” für Standardjobs

a. JOB: STATUS_LESEN (siehe Kapitel 3.1)

b. JOB: STEUERN (siehe Kapitel 3.2)

c. JOB: STEUERN_ROUTINE (siehe Kapitel 3.3)

d. JOB: STEUERN_IO (siehe Kapitel 3.4)

e. JOB: STATUS_BLOCK_LESEN (siehe Kapitel 3.5)

Stephan Keitel, Firma ESG 06.02.2012

2.2 Tabelle ”SG_Funktionen”

• ARG Bezeichner als String. Es darf kein Bezeichner doppelt vorkommen.

Die Umrechnung für Analoge Werte:

• SG_ADR Optional: Wird von den derzeitigen Jobs nicht benutzt.

Stephan Keitel, Firma ESG 06.02.2012

2.3 Definierte Datentypen für die SG_Funktionen Tabelle

Datentyp Länge Wertebereich

Motorola float* 4 Byte Motorola float, Big Endian

Motorola double 8 Byte Motorola double, Big Endian

Stephan Keitel, Firma ESG 06.02.2012

2.4 Definition Resultnamen für die SG_Funktionen Tabelle

2.4.1 Regeln für die Resultnamen

• Bit-Field Ergebnisse (EINHEIT = „BIT“) vom Datentyp „BITFIELD“.

Stephan Keitel, Firma ESG 06.02.2012

Weitere Informationen zur Ergebnisdefinition siehe Lastenheft Diagnose Teil 5

2.4.2 Regeln für die Entwickler-Resultnamen

Result-Typ RESULTNAME EINHEIT DATENTYP

• Entwicklerresults mit „_“…

Stephan Keitel, Firma ESG 06.02.2012

2.4.3 Beispiel einer Ergebnistabelle mit möglichen Ergebnistypen.

STAT_SPANNUNG_WERT V - CHAR - - - - - Spannung in Volt

0x01 Rad vorne links

0x02 Rad vorne rechts

0x03 Rad hinten links

0x04 Rad hinten rechts

0xFF nicht definiert

Der Aufruf des Diagnoseauftrags führt zu folgenden Results:

STAT_SPANNUNG_WERT (Semantik Analog):

STAT_VERSORGUNG_EIN (Semantik Digital):

STAT_RAD_NR (Semantik Diskret):

STAT_ANTWORT_WERT (Semantik HEX):

Stephan Keitel, Firma ESG 06.02.2012

3 Beschreibung der Standardjobs

3.1 JOB: STATUS_LESEN ($22- ReadDataByIdentifier)

3.1.1 Auslesen von einem Data-Identifier (DID) aus dem Steuergerät

Um den Standardjob “STATUS_LESEN“ aufzurufen, müssen zwei Argumente übergeben

3.1.1.1 Beispiel 1: Auslesen des Saugdruckwertes

Auszug aus der Tabelle “SG_Funktionen”

ARG ID RESULTNAME INFO EINHEIT LABEL L/H

IPSAU 0xD002 STAT_SAUGROHRDRUCK_WERT Saugrohrdruck hPa MAP_MES -

DATENTYP NAME MUL DIV ADD SG_ADR SERVICE ARG_TABELLE RES_TABELLE

unsigned int - 0,82 1 1 0x12 22 - -

Stephan Keitel, Firma ESG 06.02.2012

ApiJob ("<SGBD-Name>"," STATUS_LESEN ","ID; 0xD002","")

STAT_ SAUGROHRDRUCK _EINH = hPa