-
Die
Erfindung betrifft ein Verfahren zum Betreiben eines LIN-Busses,
eine Anordnung, die einen LIN-Bus aufweist, ein Computerprogramm
und ein Computerprogrammprodukt.
-
Stand der Technik
-
Bei
einem LIN-Bus bzw. einem LIN-Netzwerk handelt es sich um einen sogenannten
Feldbus, der in die elektronischen Komponenten, wie bspw. Aktoren
und Sensoren vorwiegend im Kraftfahrzeugbau eingebunden ist. Die
Abkürzung
LIN (Local Interconnect Network) steht für lokales Zwischenverbindungsnetzwerk. Über LIN-Busse
sind elektronische Komponenten miteinander verbunden, die vorwiegend
in Einrichtungen, die nicht unmittelbar der Fortbewegung des Kraftfahrzeugs
dienen und bspw. in Sitzen oder Türen aufgenommen sind. Es ist
vorgesehen, dass eine Komponente und somit ein Teilnehmer als übergeordneter
LIN-Master ausgebildet
ist. Die weiteren Komponenten bzw. Teilnehmer sind als LIN-Slaves
vorgesehen. Üblicherweise überträgt ein LIN-Slave über den
LIN-Bus nur dann Daten, wenn dieser von dem LIN-Master durch eine
Anfrage dazu aufgefordert wurde.
-
LIN-Busse
sind weniger komplex ausgebildet als CAN(Controller Area Network)-Busse.
Da sie eine geringere Bandbreite aufweisen, ist jedoch eine geringere
Datenübertragungsrate
als bei CAN-Bussen möglich.
Zu beachten ist aber, dass LIN-Busse kostengünstiger als LAN-Busse sind.
-
Offenbarung der Erfindung
-
Die
Erfindung betrifft ein Verfahren zum Betreiben eines LIN-Busses,
dessen Spezifikationen in einem Normalbetrieb durch einen LIN-Bus
beschrieben sind, bei dem zur Durchführung eines Sonderbetriebs
ein alternatives Kommunikationsprotokoll durch das LIN-Protokoll
getunnelt wird.
-
Durch
ein derartiges Tunneln des Kommunikationsprotokolls durch das LIN-Protokoll
werden funktionelle Eigenschaften des LIN-Busses oder mindestens
eines Teilnehmers des LIN-Busses modifiziert. Somit ist es möglich, dass
der mindestens eine Teilnehmer während
des Sonderbetriebs technische Funktionen durchführt und/oder auf technische
Wechselwirkungen reagiert, die sich von Funktionen und Wechselwirkungen
des Normalbetriebs unterscheiden.
-
Zur
Durchführung
des Verfahrens ist in Ausgestaltung vorgesehen, dass ein mit dem
Kommunikationsprotokoll verbundener Dienst auf einen Rahmen bzw.
Frame des LIN-Protokolls
abgebildet wird. Somit wird ein LIN-Rahmen dazu benutzt, um ein
anderes Kommunikationsprotokoll darin zu übertragen. Dazu wird mindestens
ein Datum des Rahmens in Abhängigkeit
des Dienstes belegt. Parameter des alternativen Kommunikationsprotokolls
sind des weiteren dienstabhängig
zu belegen.
-
Während des
Sonderbetriebs kann mindestens ein Teilnehmer des LIN-Busses über das
Kommunikationsprotokoll programmiert werden. Alternativ oder begleitend
kann während
des Sonderbetriebs auch eine Diagnose durchgeführt werden, wobei das alternative
Kommunikationsprotokoll auf einem als Diagnoserahmen ausgebildeten
Rahmen des LIN-Protokolls
abgebildet wird.
-
Es
ist möglich,
unterschiedliche alternative Kommunikationsprotokolle durch das
LIN-Protokoll zu
tunneln und dabei entsprechende Dienste auf dem Rahmen des LIN-Protokolls
abzubilden. Beim Durchtunneln eines UDS-Protokolls durch das LIN-Protokoll
wird ein UDS-Dienst
auf dem Rahmen abgebildet. Beim Durchtunneln eines proprietären, eigenen
Protokolls durch das LIN-Protokoll wird ein proprietärer Dienst
auf dem Rahmen abgebildet. Beim Durchtunneln eines KWP2000-Protokolls
durch das LIN-Protokoll wird ein KWP2000-Dienst auf dem Rahmen abgebildet.
-
Die
Erfindung betrifft außerdem
eine Anordnung, die einen LIN-Bus mit mehreren Teilnehmern aufweist.
Spezifikationen des LIN-Busses sind in einem Normalbetrieb durch
ein LIN-Protokoll beschrieben. Zur Durchführung eines Sonderbetriebs
ist die Anordnung dazu ausgebildet, ein alternatives Kommunikationsprotokoll
durch das LIN-Protokoll zu tunneln.
-
In
der Anordnung ist ein erster Teilnehmer typischerweise als Master
und mindestens ein zweiter Teilnehmer als Slave ausgebildet. In
diesem Fall ist zur Durchführung
einer Kommunikation und einem damit verbundenen Datenaustausch vorgesehen,
dass der Master an den Slave Anfragen übermittelt und der Slave and den
Master Antworten übermittelt.
-
Die
Anordnung oder zumindest ein Teilnehmer der Anordnung ist zur Durchführung sämtlicher
Schritte des erfindungsgemäßen Verfahrens
ausgebildet.
-
Das
erfindungsgemäße Computerprogramm
mit Programmcodemitteln ist zum Durchführen aller Schritte eines erfindungsgemäßen Verfahrens
ausgebildet, wenn das Computerprogramm auf einem Computer oder einer
entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Anordnung,
ausgeführt
wird.
-
Die
Erfindung betrifft zudem ein Computerprogrammprodukt mit Programmcodemitteln,
die auf einem computerlesbaren Datenträger gespeichert sind, um alle
Schritte eines erfindungsgemäßen Verfahrens
durchzuführen,
wenn das Computerprogramm auf einem Computer oder einer entsprechenden
Recheneinheit, insbesondere einem Steuergerät in einer erfindungsgemäßen Anordnung,
ausgeführt
wird.
-
Mit
der vorliegenden Erfindung ist es möglich, Diagnoseframes bzw.
Diagnoserahmen des LIN-Protokolls
dazu zu nutzen, andere Kommunikations- und insbesondere Diagnoseprotokolle
darin zu übertragen.
In Ausgestaltung erfolgt dies durch das UDS-Protokoll sowie das
proprietäre
Protokoll. Die vorliegende Erfindung erweitert die Anwendung von
Diagnoseprotokollen, wie bspw. Unified Diagnostic Services (UDS),
proprietäre Dienste
oder KWP2000, für
das LIN-Bussystem, insbesondere für eine Revision 2.0 als auch
für ältere Revisionen,
so dass ein Tunneln dieser Diagnoseprotokolle durch das LIN-Busprotokoll
möglich
ist.
-
Mit
der Erfindung kann somit ein Verfahren zur Implementierung eines
Diagnosemechanismus für
einen LIN-Knoten, in der Regel ein Slave, durchgeführt werden.
Das Verfahren baut insbesondere auf einem Konzept für die LIN-Diagnose
und eine Konfigurationsspezifikation nach Revision 2.0 auf. Dadurch
werden alternative Vorgehensweisen zur Sammlung von Diagnosedaten
implementiert. Das Konzept berücksichtigt
in Ausgestaltung eine benutzerdefinierte Diagnose "User Defined Diagnostic" und eine Diagnosetransportschicht "Diagnostic Transport
Layer". Das Diagnosekonzept
ist als Erweiterung bzw. Zusatz zu einem Standardkommunikationsprotokoll
und somit dem LIN-Protokoll des LIN-Busses zu verstehen.
-
Als
Anforderungen für
dieses Protokoll ist vorgesehen, dass eine elektronische Kontrolleinheit
(ECU) ein Diagnosekonzept benutzt, das mindestens eines der Kommunikationsprotokolle
LIN 1.2, LIN 1.3, LIN 2.0, SAE J2602 (veröffentlicht im August 2004)
implementiert.
-
Eine
Datenübertragungsrate
im Kommunikationsprotokoll wird durch einjeweiliges Projekt definiert. Falls
dieses Projekt eine Nutzung unterschiedlicher Datenübertragungsraten
für normale
Anwendungen und einen Diagnosebetrieb erfordert, ist eine Nutzung
eines Mechanismus zur Änderung
der Datenübertragungsraten
möglich.
-
Diagnosebotschaften
werden üblicherweise
innerhalb des LIN-Befehlsrahmens, der für Anfragen des Masters und
Antworten des Slaves als Teilnehmer des LIN-Busses reserviert ist, übertragen,
Beispiele hierfür sind
in Tabelle 1 dargestellt.
Identifikator
(Hex) | Beschreibung |
0×3c | Anfragerahmen
des Masters |
0×3d | Antwortrahmen
des Slaves |
Tabelle
1: Diagnoseidentifikator
-
Für eine Zusammenfassung
von Diagnosedaten sind sowohl für
die Anfragen des Masters als auch für Antworten des Slaves die
in der nachfolgenden Tabelle 2 beispielhaft dargestellten Rahmentypen
vorgesehen:
Typ | Beschreibung |
Einzelrahmen
(Single Frame, SF) | Der
SF wird benutzt, falls die übertragene
Diagnosebotschaft in einen einzigen LIN-Diagnoserahmen passt. |
Erster
Rahmen (First Frame, FF) | Der
FF wird benutzt, falls die übertragene
Diagnosebotschaft länger
als ein einziger LIN-Rahmen ist. Dabei weist der erste LIN-Rahmen
der Diagnosebotschaft die Struktur des SF auf. |
Fortsetzungsrahmen | CF
wird benutzt, falls die übertragene
Diagnosebotschaft länger |
(Continuation
Frame, CF) | als
ein LIN-Rahmen ist. Sämtliche
LIN-Rahmen mit Ausnahme des FF weisen die Struktur des TF auf. |
Tabelle
2: Rahmentypen für
Anfragen des Masters und Antworten des Slaves
-
Diagnoserahmen
umfassen typischerweise 8 Datenbytes. Eine mögliche Struktur möglicher
Diagnoserahmen ist in der nachfolgenden Tabelle 3 dargestellt.
Sender | Typ | ID | Datenbytes |
Byte
1 | Byte
2 | Byte
3 | Byte
4 | Byte
5 | Byte
6 | Byte
7 | Byte
8 |
Master | SF | 0×3c | NAD | PCI | SID | D1 | D2 | D3 | D4 | D5 |
Master | FF | 0×3c | NAD | PCI | LEN | SID | D1 | D2 | D3 | D4 |
Master | CF | 0×3c | NAD | PCI | D1 | D2 | D3 | D4 | D5 | D6 |
Slave | SF | 0×3d | NAD | PCI | RSID | D1 | D2 | D3 | D4 | D5 |
Slave | FF | 0×3d | NAD | PCI | LEN | RSID | D1 | D2 | D3 | D4 |
Slave | CF | 0×3d | NAD | PCI | D1 | D2 | D3 | D4 | D5 | D6 |
Tabelle 3: Struktur von Diagnoserahmen
-
Dabei
steht die Abkürzung
NAD (Note Address) für
Knotenadresse. Dies ist in der Diagnose- und Konfigurationsspezifikation des
LIN nach Version 2.0 erstmals spezifiziert worden. NAD bezeichnet
die Adresse des Slave-Knotens, der über die Anfrage adressiert
wird. NAD kann ebenfalls zur Anzeige einer Quelle einer Anfrage
benutzt werden. Die nachfolgende Tabelle 4 zeigt ein Beispiel einer
Nutzung der Knotenadresse (NAD) bei bestimmten Systemkonfigurationen.
Kommunikationsprotokoll | Topologie
der Anordnung | Knotenadresse
(NAD) |
LIN 1.2 LIN 1.3 | Punkt
zu Punkt (Fertigung, Entwicklung) | Eine
Knotenadresse für
den Slavenknoten liegt in einem Bereich von 0×80 bis 0×ff. |
LIN-Netzwerk
(Serie) | Die
Knotenadresse wird von einem Nutzer oder Anwender in einem Bereich
von 0×80
bis 0×ff
definiert. Falls keine Diagnose erforderlich ist und der Anwender
des Netzwerks keine Information über die
Knotenadresse benötigt,
wird eine einheitliche Knotenadresse für jeden Slave-Knoten in einem Bereich
von 0×80
bis 0×ff
definiert. |
LIN 2.0 | Punkt
zu Punkt (Fertigung, Entwicklung) | Die
vom dem Anwender definierte Knotenadresse liegt im Bereich von 0×01 bis
0×7e.
Es ist ebenfalls möglich,
für den
Slave-Knoten eine festgelegte Knotenadresse in einem Bereich von
0×80bis 0×ff zu definieren. |
LIN-Netzwerk
(Serie) | Die
Knotenadresse wird von dem Anwender definiert. Falls keine Diagnose
erforderlich ist und der Anwender des Netzwerks keine Information über die
Knotenadresse benötigt,
wird von dem Projekt eine einheitliche Knotenadresse für jeden
Sklave-Knoten in einem Bereich von 0×80 bis 0×ff definiert. |
SAE J2602 | Punkt
zu Punkt (Fertigung, Entwicklung) | Hierbei
kann die von dem Anwender definierte Methode der Kontenkonfiguration
benutzt werden, die Knotenadresse befindet sich in einem Bereich
von 0×01
bis 0×7e.
Es ist ebenfalls möglich,
für den
Slave-Knoten eine festgelegte Knotenadresse in einem Bereich von
0×80 bis
0×ff zu
definieren. |
LIN-Netzwerk
(Serie) | Hierbei
kann die von dem Anwender definierte Methode der Kontenkonfiguration
benutzt werden, die Knotenadresse befindet sich in einem Bereich
von 0×01
bis 0×7e. |
Tabelle
4: Übersicht
zur Definition von NAD
-
Eine
Struktur des in Tabelle 3 eingeführten
PCI-Bytes ist in Tabelle 5 dargestellt. Die Abkürzung PCI (Protocol Control
Inforamtion) steht für
Protokollkontrollinformation. Die Protokollkontrollinformation umfasst Informationen über den
Rahmentyp und die Transportschichtflußkontrollinformation.
Typ | PCI Byte |
Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0 |
SF | 0 | 0 | 0 | 0 | Länge Anzahl der
benutzten Datenbytes in dem Rahmen plus 1 für SID oder RSID (Maximalwert
= 6 – >5 Datenbytes plus SID oder
RSID; Minimalwert = 1 – >0 Datenbytes plus SID
oder RSID). |
FF | 0 | 0 | 0 | 1 | Länge/256 Dies
ist die Länge
einer Gesamtzahl übermittelter Datenbytes
der Botschaft plus 1 für
SID oder RSID. Die vier höchstwertigen
Bits der Länge
der Botschaft werden in die vier niedrigstwertigen Bits des PCI-Bytes übertragen. |
CF | 0 | 0 | 1 | 0 | Rahmenzähler Zähler für CF-Rahmen. Der
erste CF-Rahmen ist mit 1 numeriert, der zweite mit 2, usw. Falls die
Botschaft mehr als 15 CF-Rahmen aufweist, wird eine Zählung des
Rahmenzählers
wieder mit 0, 1, 2, ... fortgesetzt. |
Tabelle
5: Struktur des PCI-Bytes
-
Falls
die Botschaft nicht in einen einzigen Rahmen passen sollte, werden
die vier höchstwertigen
Bits der Länge
der Botschaft in die vier niedrigstwertigen Bits des PCI-Bytes übertragen.
Die acht niedrigstwertigen Bits der Länge der Botschaft werden zu
dem in Tabelle 3 eingeführten
LEN-Byte übertragen.
Die Botschaft kann maximal 4095 Bytes (Länge = 0×ff) umfassen. In einem ersten
Beispiel ergeben sich nachfolgende Werte:
Anzahl der Datenbytes
in der Botschaft = 700 Byte (0×2bc)
Länge = 0×2bd, Anzahl
der Datenbytes in der Botschaft plus 1
LEN = 0×bd, acht
niedrigstwertige Bits der Länge
PCI
= 0×12,
vier niedrigstwertige Bits des PCI umfassen vier höchstwertige
Bits der Länge,
die vier höchstwertigen
Bits des PCI umfassen die Rahmentypanzeige
-
In
einem zweiten Beispiel ergeben sich folgende Werte:
Anzahl
der Datenbytes in der Botschaft = 700 Byte (0×2bc)
Länge = 0×2bd, Anzahl
der Datenbytes in der Botschaft plus 1
LEN = 0×bd, acht
niedrigstwertige Bits der Länge
PCI
= 0×12,
vier niedrigstwertige Bits des PCI umfassen vier höchstwertige
Bits der Länge,
die vier höchstwertigen
Bits des PCI umfassen die Rahmentypanzeige
-
Die
Abkürzung
SID (Service Identifier) in Tabelle 3 steht für Dienstidentifikator und bestimmt
die Anfrage, die durch die Slave-Knotenadresse durchgeführt werden
soll. Tabelle 6 zeigt den Zusammenhang zwischen SID und der Knotenadresse
(NAD).
NAD | SID | Kommentar |
0×01-0×7e | gleichbleibend
für ISO
15765-3 oder ISO 14229-1 | Nur
für elektronische
Kontrolleinheiten (ECU) die LIN2.0 oder SAE J2602 benutzen: Es ist
nicht möglich,
den Dienstidentifikator in einem Bereich von 0×b0 bis 0×b7 für die Diagnose zu benutzen,
da diese Identitäten
für die
Knotenkonfiguration im LIN Standard benutzt werden. |
0×80-0×ff | projektspezifisch | Es
wird durch den Anwender entschieden, welche Art von Dienst benutzt
wird, z.B. UDS, proprietäre
Dienste, ISO usw. |
Tabelle
6: Korrelation zwischen SID und NAD
-
Die
erforderliche Definition des Dienstes bzw. Diagnosedienstes wird
in der Regel durch das Projekt oder den Anwender bestimmt. Einige
Anwender benutzen ISO-Dienste oder beispielsweise proprietäre Dienste.
Es ist auch möglich,
dass der Anwender eigene zu dem LIN-Protokoll alternative Kommunikationsprotokolle und
dabei bestimmte Diagnosedienste definiert. Demnach muss durch den
Anwender entschieden werden, welche Art von Diagnosediensten benutzt
werden.
-
Die
Abkürzung
RSID (Response Service Identifier) aus Tabelle 3 steht für Antwortdienstidentifikator und
bestimmt Inhalte der Antwort. Der RSID für eine positive Antwort ist
typischerweise SID + 0×40.
-
Die
Interpretation von Datenbytes, die durch die Variablen D1 bis D6
für jeweils
ein entsprechendes Datum 1 bis Datum 6 beschrieben sind, hängt von
dem Dienstidentifikator oder dem Antwortdienstidentifikator ab.
Falls ein Rahmen eines Protokolls nicht vollständig gefüllt wird, werden die ungenutzten
Bytes mit Einsen (0×ff)
gefüllt.
-
Der
Ablauf der Kommunikation hängt
von einer Anzahl von Erfordernissen ab. In Produktionsserien definiert
bspw. der Anwender den Ablauf der Diagnosekommunikation in seinem
System. In der Fertigung bzw. in der Fabrik wird der Ablauf für jedes
spezifische Produkt optimiert, um die Dauer von Fertigungsschritten
zu reduzieren. Demnach wird der Ablauf insbesondere durch die Art
des Projekts definiert.
-
Tabelle
7 gibt eine Übersicht
für Fehler,
die bei einer Kommunikation auftreten können.
Fehler | Beschreibung |
Negative
Antwort | Der
Master erhält
von dem LIN-Slave eine negative Antwort. |
Inkonsistenter
Inhalt des Rahmens | Der
Inhalt der Anfrage oder der Antwort ist inkonsistent. Dies bedeutet
beispielsweise, dass die empfangene Botschaft projektabhängig einen
nicht definierten PCI oder einen nicht definierte SID oder RSID
aufweist. Dieser Fehler kann zudem dafür benutzt werden, wenn die
empfangenen benutzerdefinierten Datenbytes (D1...Dx) nicht die erwarteten Werte
aufweisen. |
Fehler
in der Sequenz | Der
Rahmenzähler
einer Sequenz eines Fortsetzungsrahmens ist inkonsistent, z. B.
Rahmenzähler =
1..2..5..6. |
Auszeit
bei der Übertragung | Die
Zeit zwischen Versendung einer Anfrage und einer positiven Antwort
des Slaves ist überschritten
(tRtoutM > TRtoutM). |
Kommunikationsfehler | Kommunikationsfehler
im LIN-Protokoll, z.B. unterbrochene Kommunikation, gescheiterter
Transfer. |
Tabelle
7: Kommunikationsfehler
-
Abhängig von
der Knotenart, also einer konkreten Ausbildung des LIN-Masters oder
des LIN-Slaves, müssen unterschiedliche
Fehlermechanismen implementiert werden. Eine Übersicht einer Fehlerbehandlung, wie
sie in den Slave-Knoten implementiert werden kann, ist in Tabelle
8 dargestellt.
Slave-Knoten |
Fehler | Reaktion |
Inkonsistenter
Inhalt des Rahmens | Abbruch
des Empfangs, weitere CS-Rahmen desselben Empfängers werden ignoriert. Verwerfen
der Daten der Übertragung.
Senden einer negativen Antwort. |
Fehler
in der Sequenz | Abbruch
des Empfangs, weitere CS-Rahmen desselben Empfängers werden ignoriert. Verwerfen
der Daten der Übertragung.
Senden einer negativen Antwort. |
Kommunikationsfehler | Dieselbe
Reaktion wie bei einem normalen Kommunikationsbetrieb, ist durch
den Anwender definiert. |
Tabelle
8: Reaktion auf Fehler im Slave-Knoten
-
Tabelle
9 zeigt Beispiele zu einer Fehlerbehandlung, die in dem Master-Knoten
implementiert sind.
Master-Knoten |
Fehler | Reaktion |
Negative
Antwort | Reaktion
wird durch den Anwender definiert. |
Inkonsistenter
Inhalt des Rahmens | Abbruch
des Empfangs, Verwerfen der Daten der Übertragung. Senden einer negativen
Antwort. |
Fehler
in der Sequenz | Abbruch
des Empfangs, Verwerfen der Daten der Übertragung. Senden einer negativen
Antwort. |
Auszeit
bei der Übertragung | Abbruch
der Übertragung,
Verwerfen der Daten der Übertragung.
Senden einer negativen Antwort. |
Kommunikationsfehler | Dieselbe
Reaktion wie bei einem normalen Kommunikationsbetrieb, ist durch
den Anwender definiert. |
Tabelle
9: Reaktion auf Fehler im Master-Knoten
-
Jedes
Projekt definiert die Verhaltensweise des Systems nach Auftauchen
eines Fehlers und wie ein Übertragungsstrom
gestoppt wird, z.B. durch Wiederholung der Übertragung, Neustart der Anfrage-
oder Antwortsequenz oder durch einen vollständiger Abbruch der Kommunikation.
-
In
einer möglichen
Ausgestaltung kann ein Diagnosedienst gemäß UDS (Unified Diagnostic Services, vereinheitlichter
Diagnosedienst) für
Straßenfahrzeuge
nach ISO14229-1.2 aus dem Jahr 2003 für LIN-Busse und somit LIN-Protokolle
angewandt werden. Hierzu zeigt nachfolgende Tabelle 10 eine Übersicht
für Diagnosedienste
innerhalb des LIN-Kontextes. Es sind jedoch auch andere Dienste
anwendbar. Beispiele zu dieser Ausgestaltung sind in den Tabellen
10 bis 13 dargestellt.
-
Tabelle
10 umfasst den Namen des Dienstes und den zugehörigen Dienstidentifikator (Service
Identifier, SID), der hier als Hexadezimalwert dargestellt ist.
Des weiteren ist eine kurze Beschreibung für jeden Diagnosedienst angegeben.
Die Spalten "Unterfunktionen" (subfunction) und "SupPosRsp" (suppress positive response
message, Unterdrückung
einer positiven Antwort) definieren, ob für den jeweiligen Diagnosedienst Unterfunktionen
existieren und ob jeweils positive Antworten unterdrückt werden
können.
Hierbei sind Unterfunktionen von Unterparametern (subparameters)
zu unterscheiden. Durch Unterparameter können gewünschte Dienste oder Funktionen
(z.B. Speichergröße, Speicheradresse,
usw.) konkretisiert werden, wohingegen Unterfunktionen gewünschte Dienste
unter einem bestimmten Ablaufschema aufrufen, bspw. ein weiches
Zurücksetzen
oder ein hartes bzw. abruptes Zurücksetzen. Das höchstwertige
Bit (bit 7) eines Parameters der Unterfunktion bzw. eines Dienstparameterbytes
wird zur Unterdrückung
einer positiven Antwort für
den jeweiligen Dienst benutzt (Tabelle 11). In der Regel ist der
RSID (response service identifier), was für Antwortdienstidentifikator
steht, für
positive Antworten durch Summation des Antwort-SID mit dem konstanten
Hexadezimalwert 0×40
zu bilden. Eine negative Antwort wird für den RSID 0×7F benutzt.
In diesem Fall ist das zweite Byte der SID, der einen Fehler verursacht
hat. Durch ein drittes von dem SID abhängiges Byte wird der Fehler
genauer beschrieben.
-
-
Tabelle
10: Übersicht
zu LIN-Diagnosediensten
-
Tabelle
11 zeigt einen üblichen
Aufbau des Dienstparameterbytes
Dienstparameterbyte
(SPB) |
Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0 |
SupPosRsp | Diagonsesitzungstyp |
Tabelle
11: Diagnoseidentifikator
-
Gemäß dieser
Ausgestaltung werden die erwähnten
Dienste des nach UDS vorgesehenen Kommunikationsprotokolls auf die
LIN-Rahmen bzw. LIN-frames abgebildet. Eine derartige Abbildung
auf die LIN-Rahmen erfolgt gemäß der nachfolgend
beschriebenen Beispiele.
-
Drittes Beispiel: Start der Standardeinstellung
einer Diagnosesitzung.
-
- NAD: 0×83,
Beispiel für
eine Knotenadresse,
- PCI: 0×02,
SID und ein Datenbyte, für
einen Einzelrahmen
- SID: 0×10,
Diagnosesitzungskontrolldienst
- Datum1: 0×02,
durch UDS spezifizierte Programmierungssitzung
-
Dienst | LIN
ID | LIN
Datenrahmen |
Diagnosesitzungskontrolle | 3C | 83
02 10 02 FF FF FF FF |
Tabelle
12: Diagnosesitzungskontrolle
-
Beispiel vier: Datenübertragung zum LIN-Slave.
-
- NAD: 0×83,
Beispiel für
Knotenadresse
- PCI: 0×10,
erster Rahmen mit mehr als 6 Datenbytes
- LEN: 0×09,
SID und 8 Datenbytes sind zu übertragen
- SID: 0×36, Übertragungsdaten
- Datum1: 0×01,
Blocksequenzzähler
(Unterparameter für
SID 0×63
nach UDS)
- Datum2-Datum4: zu übertragende
Datenbytes
- NAD: 0×83,
Beispiel für
Knotenadresse
- PCI: 0×21,
Fortsetzungsrahmen (CF), zweiter Datenrahmen
- Datum1–Datum4:
zu übertragende
Datenbytes
- Datum5-Datum6: nicht besetzt, auf 0×FF gesetzt
-
Dienst | LIN
ID | LIN
Datenrahmen |
Übertragungsdaten
FF | 3C | 83
10 09 36 01 01 02 03 |
Übertragungsdaten
CF | 3C | 83
21 04 05 06 07 FF FF |
Tabelle
13: Übertragungsdaten
-
In
einer weiteren Ausgestaltung kann ein proprietärer Dienst in den LIN-Diagnoserahmen
abgebildet werden. Details zu dieser Ausgestaltung sind in den Tabellen
14 bis 17 dargestellt.
proprietärer Rahmen | LIN
Rahmen |
| NAD
= 0×80
.. 0×ff |
"Anforderungsblock" |
"Blocklänge" | Länge = "Blocklänge" – 2 (siehe Tabelle 5) |
"Blocktitel" | SID |
"Nutzinformation" | Datenbytes |
"Cheksummenbyte" | Letztes
Datum der Diagnosesitzung. (Bem.: nicht das letzte Byte des LIN-Rahmens
wg. Füllbytes.) |
Dienstanfrage
mit Slave-Antwort (Anfrage Identifikator 0×22 .. 0×60) |
Request
("Blocktitel") | SID |
Response
("Blocktitel") | RSID
= Antwort ("Blocktitel") – 0×40 (Bem.:
Antwort ist Anfrage + 0×80) |
"Blockbestätigung" (Antwort Identifikator
0×01) |
"Blocklänge" | PCI
= 02 |
"Blocktitel" | RSID
= SID + 0×40
RSID = 0×50
(Start der Diagnosesitzung) RSID = 0×60 (Ende der Diagnosesitzung) RSID
= 0×61
(DUT device under test) Einrichtung im Test vorhanden |
"Checksumme" | D1
= "Checksumme" |
"keine Blockbestätigung" (Antwort Identifikator
0×02) |
"Blocklänge" | PCI
= 03 |
"Blocktitel" | RSID
= "Blocktitel NACK" |
"Fehlercode" | D1
= "Fehlercode" |
"Checksumme" | D2
= "Checksumme" |
"Blocktester Warten" (Antwort Identifikator
0×FE Antwort
ohne Anfrage) |
Response
("Blocktitel") | RSID
= 0×FE |
Tabelle
14: Abbildung vom proprietären
Rahmen zum LIN-Rahmen
-
Tabelle
15 zeigt eine Übersicht
einiger Diagnosedienste innerhalb des LIN-Kontextes. Tabelle 15
umfasst die Namen der Dienste und die zugehörigen Dienstidentifikatoren
SID ("Blocktitel"), die hier als Hexadezimalwerte
dargestellt sind. Des weiteren ist eine kurze Beschreibung zu jedem
Diagnoseservice angegeben.
| SID
(Hex) | Dienstname |
Start
Diagnostic Session (Beginn Diagnosesitzung) | 10 | Freigabe
der Diagnosesitzung |
End
Diagnostic Session (Ende Diagnosesitzung) | 20 | Master
fordert Beendigung der Datenübertragung |
Read
DUT Statusinformation Long (Lese "Einrichtung im Test" Statusinformation Lang) | 22 | Master
fordert die Information über
den Zustand des Slaves, des Projekts, der Software oder der Hardware
an. |
Read
Snapshot 2 Byte 16 bit address (Lese Speicherauszug 2 Byte 16 Bit
Adresse) | 31 | Master
verlangt das Lesen des aktuellen Werts des bereitgestellten Speicherabschnitts. |
Internal
EEPROM Access | 36 | Slave
soll den Zugang zu dem EEPROM zur |
Enable
(EEPROM Zugang möglich) | | Programmierung
freigeben. |
Flash
ROM Access enable (Flash ROM Zugang möglich) | 38 | Slave
soll den Zugang zu dem Flash ROM zur Programmierung freigeben. |
Hardware
Access enable (Hardwarezugang möglich) | 3a | Slave
soll den Zugang zu der ECU-Hardware freigeben. |
Program
Flash ROM 16 bit Area (Programmiere Flash ROM 16 Bit Bereich) | 4b | Datenübertragung
zum LIN-Slave zur Flash-Programmierung. |
RAM
Access enable (RAM-Zugang möglich) | 50 | Freigabe
des Zugangs zum RAM |
Start
routine 16 bit address area (Beginn Routine 16 Bit Adressbereich) | 53 | Ausführung des
Codes an einer definierten Adresse. |
"Transparenter Datenblock
mit Parameterübergabe" | 60 | Mit
dieser Identifikation (ID) können
projektspezifisch besondere Befehle definiert werden. |
Tabelle
15: Übersicht
LIN-Diagnosedienste
-
Die
Abbildung der Dienste auf den LIN-Rahmen kann nach einem der nachfolgenden
Beispiele erfolgen.
-
Beispiel fünf Beginn der Diagnosesitzung.
-
- NAD: 0×83,
Beispiel für
Knotenadresse
- PCI: 0×04,
SID, 3 Datenbytes und Checksumme, Einzelrahmen
- SID: 0×10,
Beginn der Diagnosesitzung
- Datum 1: xx, ECU Id Byte 1, im proprietären Protokoll spezifiziert
- Datum 2: xx, ECU Id Byte 2, im proprietären Protokoll spezifiziert
- Datum 3: cs, Checksumme
-
Für den Start
der Diagnosesitzung gilt Tabelle 16.
Dienst | LIN
ID | LIN
Datenrahmen |
Diagnosesitzungskontrolle | 3C | 83
04 10 xx xx cs FF FF |
Tabelle
16: Start Diagnosesitzung
-
Beispiel sechs: Programmierung von 6 Bytes
des Flash ROMs zur Adresse 0×0123.
-
Erster Rahmen (FF):
-
- NAD: 0×83,
Beispiel für
Knotenadresse
- PCI: 0×10,
erster Rahmen, mehr als 8 Datenbytes
- LEN: 0×0a,
SID, 2 Adressenbytes, 6 Datenbytes und Checksumme sind zu übertragen
- SID: 0×4b, "Program Flash ROM
16Bit Adreßraum"
- Datum 1: 0×01
MSB der Adresse, im proprietären
Protokoll spezifiziert
- Datum 2: 0×23
LSB der Adresse, im proprietären
Protokoll spezifiziert
- Datum 3, Datum4: Datenbyte 1 und Datenbyte 2
-
Fortsetzungsrahmen (CF):
-
- NAD: 0×83,
Beispiel für
Knotenadresse
- PCI: 0×21,
Fortsetzungsrahmen, zweiter Datenrahmen
- D1-D4: zu übertragende
Datenbytes (Byte 3-Byte 6)
- D5: cs, Checksumme
- D6: nicht benutzt, auf 0×FF
gesetzt
-
Dienst | LIN
ID | LIN
Datenrahmen |
Übertragungsdaten
FF | 3C | 83
10 0a 4b 01 23 01 02 |
Übertragungsdaten
CF | 3C | 83
21 03 04 05 06 cs FF |
Tabelle
17: Datenübertragung
-
Eine
mögliche
Anwendung der Erfindung bietet sich bei der Entwicklungsphase von
LIN-Komponenten und
somit von Teilnehmern von LIN-Netzwerken bzw. Bussen, wobei derartige
LIN-Komponenten insbesondere als elektronische Steuereinheiten (ECU)
ausgebildet sind. Somit ist ein Flashen bzw. eine Softwareänderung
von LIN-Komponenten am Bandende und innerhalb des LIN-Busses möglich. Außerdem ergibt
sich die Möglichkeit,
Diagnoseabfragen in dem LIN-Bus vornehmen zu können. LIN-Komponenten und somit
auch -Busse sind am ehesten in der sog. Body-Domäne also im Fahrzeugaufbau verbreitet
und werden für
Klappenstellmotoren von Lüftungsanlagen,
Motoren zur Sitzverstellung oder für die Türelektronik eingesetzt.
-
Weitere
Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der
Beschreibung und der beiliegenden Zeichnung.
-
Es
versteht sich, dass die vorstehend genannten und die nachstehend
noch zu erläuternden
Merkmale nicht nur in der jeweils angegebenen Kombination, sondern
auch in anderen Kombinationen oder in Alleinstellung verwendbar
sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Die
Erfindung ist anhand von Ausführungsbeispielen
in der Zeichnung schematisch dargestellt und wird im folgenden unter
Bezugnahme auf die Zeichnung ausführlich beschrieben.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
in schematischer Darstellung ein Diagramm zu einer Ausführungsform
eines Ablaufs einer Kommunikation in einem LIN-Netzwerk.
-
2 zeigt
in schematischer Darstellung ein Diagramm zur einem Ablauf eines
Beginns einer Diagnosesitzung.
-
3 zeigt
in schematischer Darstellung ein Diagramm zu einem Ablauf einer
ersten Ausführungsform
einer Diagnosesitzung.
-
4 zeigt
in schematischer Darstellung ein Diagramm zu einem Ablauf einer
ersten Ausführungsform
einer Diagnosesitzung.
-
Ausführungsformen der Erfindung
-
In
dem Diagramm aus 1 sind schematisch ein Master 102 und
ein Slave 104 eines LIN-Netzwerks 106 dargestellt,
die miteinander kommunizieren. Innerhalb des als LIN-Netzwerk 106 ausgebildeten
Systems ist der Master 102 für die Zeiteinteilung 108 verantwortlich,
da der Slave 104 lediglich eine Antwort senden kann, nachdem
der Master 102 einen Header 110 eines Rahmens
mit ID = 0×3d
gesendet hat. Bei einer Diagnose eines Fahrzeugs, wobei eine Fahrzeugtesteinrichtung
als Diagnose-Master 102 vorgesehen ist, werden zeitliche
Anforderungen, die durch ein Diagnoseprotokoll des Nutzers festgelegt
sind, von dem Master 102 beschlossen. Dies bedeutet in
vorliegender Ausführungsform,
dass der Master zyklisch 102 Botschaften an den Slave 102 schickt,
um somit anzuzeigen, dass sich das Untersystem im Testmodus befindet.
-
Die
Diagnosekommunikation in dem LIN-Netzwerk
106 wird durch
zwei Kommunikationsarten verwirklicht, nämlich von Anfragen (Requests)
des Masters
102 und Antworten (Responses) des Slaves
104.
Während
eines ersten Zeitabschnitt
112 und somit in einem ersten
Fall sendet der Master
102 eine erste Anfrage
114 an
den Slave
104, wobei keine besonderen zeitlichen Parameter
erforderlich sind. In einem zweiten Fall während eines zweiten Zeitabschnitts
116,
bei dem von dem Slave
104 erwartet wird, eine Antwort an
den Master
102 zu senden, ist vorgesehen, dass der Master
eine zweite Anfrage
118 mit dem Header
110 mit
ID = 0×3d
versendet, der Slave
104 jedoch nicht antwortet. Um eine
Beobachtung des Systems und somit des LIN-Netzwerks
106 zu
gewährleisten,
muss nach Versenden der zweiten Anfrage
118 eine Auszeit
120 bzw. ein
Timeout (t
RtoutM) in dem LIN-Netzwerk
106 implementiert
werden. Der Master
102 sendet "0×3d", worauf der Slave
104 jedoch
nicht antwortet, der Master
102 wiederholt die Botschaft
mit "0×3d" bis die Auszeit
abgelaufen ist. Eine Übersicht
zu Zeiteinstellungen ist in nachfolgender Tabelle 18 vorgegeben.
Eine dritte, ebenfalls unbeantwortete Anfrage
122 wird
während
eines dritten Zeitabschnitts
124 versendet. Während eines
vierten Zeitabschnitts
126 sendet der Master
102 eine
vierte Anfrage
128, auf die der Slave
104 mit
einer ersten Antwort
130 reagiert, worauf die Auszeit
120 (t
RtoutM) beendet wird. Während eines fünften Zeitabschnitts
132 übermittelt
der Master
102 eine fünfte
Anfrage
134, auf die von dem Slave
104 mit einer
zweiten Antwort
136 geantwortet wird.
Knoten | Zähler | Anfangsbedingung | Rücksetzbedingung | Maximalwert |
Master | tRtoutM | Antwort
auf den 0×3d
Rahmen, wie von dem Master empfangen | Antwort
des vom Master empfangenen 0×3d
Rahmens | TRtoutM projektspezifisch |
Tabelle
18: Übersicht
Zeitparameter
-
Um
die Software einfach und übersichtlich
zu halten, ist es möglich,
die Rücksetzzeit 120 tRtoutM durch Zählen der 0×3d Rahmen ohne Antworten des
Slaves 104 zu erfassen. Bei einer Beobachtung während des Beginns
einer Kommunikation kann es erforderlich sein, längere Rücksetzzeiten 120 als
bei normalen Arten der Kommunikation zu verwenden. Demnach ist der Maximalwert
für eine
Hauptzeit (TRtoutM) in der Regel von einem
Zustand des LIN-Netzwerks 106 abhängig.
-
2 zeigt
in schematischer Darstellung ein Diagramm zum Ablauf des Beginns
einer Diagnosesitzung 202 für eine ECU Programmierung eines
einzelnen Slaves in einem LIN-Netzwerk.
Dabei ist diese Diagnosesitzung 202 in eine Standarddiagnosesitzung 204,
eine erweiterte Diagnosesitzung 206 und eine Programmierung 208 der
Diagnosesitzung 202 unterteilt.
-
Die
Diagnosesitzung 202 für
die Flash-Reprogrammierung 210 beginnt mit dem Lesen 212 einer
Identifikation des Slaves, in einem zweiten Schritt folgt eine Überprüfung 214 eines
Zustands der Reprogrammierung 210.
-
Zu
Beginn der erweiterten Diagnosesitzung 206 wird in einem
dritten Schritt ein erster Wechsel 216 des Diagnosesitzungstyps
vollzogen. Optional erfolgt in einem vierten Schritt eine Unterdrückung 218 von
Fehlereinträgen.
Zum Abschluss der erweiterten Diagnosesitzung 206 erfolgt
ein zweiter Wechsel 220 des Diagnosesitzungstyps.
-
Der
hier angegebene Fluss der Botschaften zwischen Master und Slave
basiert auf der Übertragung einer
Löschroutine
und einer Schreibroutine für
den Speicher, hier einem Flash-Speicher
sowie auf zwei Datenblöcken.
Falls eine Verriegelung der Software erforderlich ist, werden die
Lösch-
und Schreibroutinen des Flash-Speichers aus Sicherheitsgründen nicht
vollständig
auf der elektronischen Kontrolleinheit (ECU) abgelegt. Während einer
Durchführung
der Programmsequenz werden fehlende Teile dieser Routinen an den
Slave übertragen.
Es ist vorgesehen, dass zwei Speicherblöcke mit einer Länge von
64 Bytes zu dem Slave übertragen
werden und in den Flash-Speicher programmiert werden. Die einzelnen
in 2 dargestellten Schritte werden als Einleitung
zur Flash-Programmierung in dem LIN-Netzwerk benutzt.
-
Die
Kommunikation in dem LIN-Netzwerk erfolgt während des Normalbetriebs mit
dem LIN-Protokoll. Zur
Realisierung von Sonderbetrieben, wie der Diagnosesitzung, werden
in vorliegender Ausführungsform
alternative Kommunikationsprotokolle durch das LIN-Protokoll getunnelt.
Dabei erfolgt ein Umschalten des LIN-Protokolls zu einem derartigen
alternativen Kommunikationsprotokoll bei dem ersten Wechsel 216,
ein Rückschaltung
von dem alternativen Kommunikationsprotokoll zu dem LIN-Protokoll
erfolgt bei dem zweiten Wechsel 220, so dass die erweiterte
Diagnosesitzung 206 für
das LIN-Netzwerk mit dem alternativen Kommunikationsprotokoll erfolgt.
-
Zur
Realisierung der Diagnosesitzung 202 mit dem anderen Diagnoseprotokoll
kommen als Dienste UDS, KWP2000 oder propprietäre Dienste in Frage. Bei Nutzung
des UDS-Dienstes wird die Programmierung der Diagnosesitzung 202 lediglich
in den sog. "bootloader" eingegeben. Falls
eine Verbindung zwischen gleichwertigen Teilnehmern und somit eine
Punkt-zu-Punkt Verbindung vorliegt, können die in 2 dargestellten
Schritte teilweise weggelassen werden. In diesem Fall genügt für UDS der
durch das Diagramm aus 3 und für den proprietären Dienst
der durch das Diagramm aus 4 dargestellte,
verbleibende Programmierungsprozess.
-
Der
Vorgang zur Flash-Programmierung wird durch Senden einer Sequenz
eines Diagnoseantrags zu dem Slave kontrolliert. Daraufhin übermittelt
der Slave eine positive oder negative Antwort. Im Falle einer negativen
Antwort ist eine Fehlerbehandlung erforderlich, wobei eine derartige
Fehlerbehandlung projektspezifisch ist.
-
3 zeigt
ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung
für den
Fall, dass ein als UDS vorgesehenes Kommunikationsprotokoll bei
einer Programmierung einer elektronischen Steuereinheit in einem
LIN-Netzwerk durch ein LIN-Protokoll getunnelt wird. Dabei wird
eine Reprogrammierung eines Slaves, der als die elektronische Steuereinheit
(ECU) ausgebildet ist, innerhalb des LIN-Netzwerks vorgenommen.
-
Dabei
sind für
eine Programmierung 302 der Diagnosesitzung mehrere Schritte
vorgesehen. Mit einem ersten Schritt erfolgt ein Start 304 der
Programmierungssitzung, in einem zweiten Schritt wird UDS-spezifisch
ein Sicherheitszugang 306 gewährt und in einem dritten Schritt
ein Fingerprint 308 übermittelt.
Danach erfolgt in einem vierten Schritt ein Austausch 310 einer
Löschroutine,
worauf in einem fünften
Schritt eine Löschung 312 eines
Speichers, hier eines Flash-Speichers, durchgeführt wird. Die Schritte vier
und fünf
können bedarfsweise
wiederholt werden. Danach wird in einem sechsten Schritt ein Austausch 314 einer
Schreibroutine vorgenommen, worauf in einem siebten Schritt ein
Schreiben 316 des Speichers erfolgt, auch der sechste und
der siebte Schritt können
erforderlichenfalls wiederholt werden. Eine Bestätigung 318 des Inhalts
des Speichers wird im achten Schritt durchgeführt. Im neunten Schritt wird
die Programmierung der Diagnosesitzung durch ein Zurücksetzen 320 beendet.
Es sei darauf hingewiesen, dass die Schritte zwei, vier, fünf, sechs und
acht in den innerhalb des Diagramms gestrichelt umrandeten Kasten
in der vorliegende Ausführungsform optional
durchzuführen
sind. Details zu den Schritten ergeben sich aus den nachfolgenden
Tabellen.
-
Die
Diagnosedatenrahmen des LIN sind somit in
3 dargestellt.
Dieses Ausführungsbeispiel
basiert auf einer Flash-Programmierung von zwei Datenblöcken mit
einer Länge
von 64 Bytes in den Slave. Da in dem ECU keine Routine zum Löschen oder
Schreiben des Flash-Speichers vorgesehen ist, werden derartige Routinen
nach deren Übertragung
zu dem ECU im RAM ausgeführt.
Außerdem
sind in diesem Beispiel keine Zeitangaben, wie bspw. für ein Warten
auf eine Antwort, vorgesehen, da diese von der benutzten Hardware
abhängen.
Es ist lediglich eine Reihenfolge der Sequenzen der Botschaft beschrieben.
Zunächst
wird eine Diagnoseprogrammierungsitzung, wie in Tabelle 19 gezeigt,
gestartet.
Dienst | LIN
ID | LIN
Datenrahmen |
Diagnosesitzungsprotokoll
(Programmierungssitzung) | 3C | 83
02 10 02 FF FF FF FF |
Antwort
SF | 3D | 83
02 50 02 FF FF FF FF |
Tabelle
19: Start 304 der Diagnoseprogrammierungssitzung
-
Danach
wird der Sicherheitszugang
306 eingesetzt, falls die ECU
einen Verriegelungsmechanismus benutzt. In nachfolgender Tabelle
20 ist dargestellt, wie eine Testeinrichtung von der als LIN-Slave
ausgebildeten Komponente mit SID 0×27 einen Seed anfordert. Das
nächste
Byte steht für
einen Parameter einer Unterfunktion, die gemäß UDS den Seed anfordert. Die
Antwort umfasst einen beliebig gewählten Keim, beispielsweise
0×21 0×47.
Dienst | LIN
ID | LIN
Datenrahmen |
Sicherheitszugang
(readSeed) SF | 3C | 83
02 27 01 FF FF FF FF |
Antwort
SF | 3D | 83
04 67 01 21 74 FF FF |
Tabelle
20: Sicherheitszugang 306, Lesen des Seeds (readSeed)
-
Der
Sicherheitszugang
306 wird, wie in Tabelle 21 dargestellt,
durch Übermittlung
eines errechneten Schlüssels,
der auf dem empfangenen Seed basiert, fortgesetzt. Ein Wert 0×02 der
Unterfunktion gemäß UDS spezifiziert
die "sendKey" Funktion des Dienstes
0×27 zum
Senden des Schlüssels.
Falls der Schlüssel,
beispielsweise 0×47
0×11,
passt, wird ein Programmierungszugang gewährt.
Dienst | LIN
ID | LIN
Datenrahmen |
Sicherheitszugang
(sendKey) SF | 3C | 83
04 27 02 47 11 FF FF |
Antwort
SF | 3D | 83
02 67 02 FF FF FF FF |
Tabelle
21: Sicherheitszugang 306, Senden des Schlüssels (sendkey)
-
Da
nun ein Zugang zu dem Slave möglich
ist, wird ein Software-Fingerprint
308 und somit ein Fingerabdruck
der Software zur Speicherung in den Slave übertragen. Dabei können die
xx und yy Bytes gemäß der Identität des gewünschten
Fingerprints
308 besetzt werden. Danach werden die Daten
des Fingerprints
308 gemäß UDS, beispielsweise 0×01-0×03, übermittelt.
Eine Übertragung
des Fingerprints
308 zeigt exemplarisch Tabelle 22.
Dienst | LIN
ID | LIN
Datenrahmen |
WriteDataByIdentifier
SF (Lesen Daten durch Identifikator) | 3C | 83
06 2E xx yy 01 02 03 |
Antwort
SF | 3D | 83
03 6E xx yy FF FF FF |
Tabelle
22: Übermittlung
des Fingerprints 308
-
Da
in diesem Beispiel der Slave eine Softwareverriegelung benutzt,
ist in dem Flash-Speicher keine Löschroutine abgelegt. Stattdessen
wird ein Programmierungscode zum Löschen des Flash-Speichers,
wie in Tabelle 23 gezeigt, unmittelbar vor einer Durchführung der
Löschoperation
zumindest teilweise übertragen.
Dienst | LIN
ID | LIN
Datenrahmen |
RequestDownload
SF (Anforderung Runterladen) | 3C | 83
06 34 00 12 xx yy 0F |
Antwort
SF | 3D | 83
04 74 20 00 FF FF FF |
TransferData
FF (Datenübertragung
FF) | 3C | 83
10 11 36 01 01 02 03 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
21 04 05 06 07 08 09 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
22 0A 0B 0C 0D 0E 0F |
Antwort
SF | 3D | 83
02 76 01 FF FF FF FF |
RequestTransferExit
SF (Anforderung Übertragungsende) | 3C | 83
1 37 FF FF FF FF FF |
Antwort
SF | 3D | 83
01 77 FF FF FF FF FF |
Tabelle
23: Runterladen der Löschroutine
-
Nach
einer kompletten Übertragung
der Löschprozedur
kann der Programmcode, wie in Tabelle 24 dargestellt, überprüft werden.
Mit der Kontrollsequenz (0×31)
der Routine wird in dem Slave eine Prozedur mit einer Routine mit
ID = xxxx gestartet, wobei gemäß UDS eine
Unterfunktion 0×01
= start festgelegt ist. Da zur Berechnung der Routine ein gewisser
Zeitraum erforderlich ist, ist die Antwort verzögert. Ein derartiges Verhalten
kann jedoch durch ein Testwerkzeug und somit eine Fahrzeugtesteinrichtung
berücksichtigt
werden. In einer positiven Antwort wird als Ergebnis der Routine
yyyy mitgegeben.
Dienst | LIN
ID | LIN
Datenrahmen |
RoutineControl
SF (Routinekontrolle SF) | 3C | 83
04 31 01 xx xx FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
04 71 01 yy yy FF FF |
Tabelle
24: Überprüfung Löschroutine
-
In
Tabelle 25 ist gezeigt, wie der Flash-Speicher unter Verwendung
der kurz zuvor übermittelten
Löschroutine
gelöscht
wird. Die Löschroutine
wird durch die Kontrollsequenz 0×31 zu dieser Löschroutine
aufgerufen und mit der Unterfunktion 0×01 = start gemäß UDS begonnen.
Eine Identität
(ID) der Löschroutine
ist als xxyy kodiert. Da die Löschung
312 einen
gewissen Zeitraum beansprucht, sind einige der RX-Diagnosebotschaften des
Slaves gegebenenfalls leer. Nach Abschluss des Löschvorgangs wird eine positive
Antwort gesendet. Die zur Löschung
312 beanspruchte
Zeit wird durch ein Flash-Werkzeug berücksichtigt.
Dienst | LIN
ID | LIN
Datenrahmen |
RoutineControl
SF (Routinekontrolle) | 3C | 83
04 31 01 xx yy FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
04 71 01 xx yy FF FF |
Tabelle
25: Speicherlöschung
-
Bedingt
durch die Verriegelung der Software ist im vorliegenden Beispiel
keine Schreibroutine zu dem nichtflüchtigen Speicher vorgesehen.
Nachfolgende Tabelle 26 zeigt eine Botschaftssequenz, mit der die Schreibroutine
für den
Slave heruntergeladen wird.
Dienst | LIN
ID | LIN
Datenrahmen |
RequestDownload
SF (Anforderung Runterladen) | 3C | 83
06 34 00 12 XX YY 0F |
Antwort
SF | 3D | 83
04 74 20 00 FF FF FF |
TransferData
FF (Datenübertragung
FF) | 3C | 83
10 11 36 01 01 02 03 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
21 04 05 06 07 08 09 |
TransferData
DF (Datenübertragung
DF) | 3C | 83
22 0A 0B 0C 0D 0E 0F |
Antwort
SF | 3D | 83
02 76 01 FF FF FF FF |
RequestTransferExit
SF (Anforderung Übertragungsende) | 3C | 83
01 37 FF FF FF FF FF |
Antwort
SF | 3D | 83
01 77 FF FF FF FF FF |
Tabelle
26: Runterladen der Schreibroutine
-
Die übertragenen
Bytes werden mit den in Tabelle 27 gelisteten Befehlssequenzen auf
Richtigkeit überprüft.
Dienst | LIN
ID | LIN
Datenrahmen |
RoutineControl
SF (Routinekontrolle SF) | 3C | 83
04 31 01 xx yy FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
04 71 01 xx yy FF FF |
Tabelle
27: Überprüfung der
Schreibroutine
-
Nun
wird der aktuell vorliegende erste Speicherblock übertragen,
was in Tabelle 28 dargestellt ist. Hierbei wird in einem ersten
Schritt ein Herunterladen von 64 (0×40) Datenbytes an der Adresse
xxyy angefordert. Nach einer positiven Antwort werden die Daten
mit aufeinanderfolgenden Rahmen in den Datentransferdienst (0×36) übertragen.
Dieser Datentransferdienst beginnt mit einer Anfrage nach 66 Datenbytes
(0×42;
64 Daten, 1 SID und 1 Blocksequenznummernbyte). Zuletzt werden alle
Rahmen der übertragenen
Daten versendet, eine positive Antwort wird empfangen. Demnach kann
die Übertragung
mit einer Sequenz (0×37)
zur Anforderung des Übertragungsendes
(RequestTransferExit) abgeschlossen werden.
Dienst | LIN
ID | LIN
Datenrahmen |
RequestDownload
SF (Anforderung Runterladen SF) | 3C | 83
06 34 00 12 xx yy 40 |
Antwort
SF | 3D | 83
04 74 20 00 FF FF FF |
TransferData
FF (Datenübertragung
FF) | 3C | 83
10 42 36 01 01 02 03 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
21 04 05 06 07 08 09 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
22 0A 0B 0C 0D 0E 0F |
: | : | : |
TransferData
CF (Datenübertragung
CF) | 3C | 83
2A 3A 3B 3C 3D 3E 3F |
TransferData
CF (Datenübertragung
CF) | 3C | 83
2B 40 FF FF FF FF FF |
Antwort
SF | 3D | 83
02 76 01 FF FF FF FF |
RequestTransferExit
SF (Anforderung Übertragungsende) | 3C | 83
01 37 FF FF FF FF FF |
Antwort
SF | 3D | 83
01 77 FF FF FF FF FF |
Tabelle
28: Runterladen des ersten Speicherblocks
-
Mit
nachfolgender Tabelle 29 ist dargestellt, wie ein zweiter Speicherblock
heruntergeladen wird. Dies erfolgt nach demselben Schema wie das
mit Tabelle 28 dargestellte Herunterladen. Ein derartiger Flash-Vorgang
beansprucht einen gewissen Zeitraum, weshalb als Pause ein Intervall
vorzusehen ist, bevor ein Herunterladen des zweiten Datenblocks
begonnen werden kann.
Dienst | LIN
ID | LIN
Datenrahmen |
RequestDownload
SF | 3C | 83
06 34 00 12 xx yy 40 |
(Anforderung
Runterladen SF) | | |
Antwort
SF | 3D | 83
04 74 20 00 FF FF FF |
TransferData
FF (Datenübertragung
FF) | 3C | 83
10 42 36 01 01 02 03 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
21 04 05 06 07 08 09 |
TransferData
CF (Datenübertragung
CF) | 3C | 83
22 0A 0B 0C 0D 0B 0F |
: | : | : |
TransferData
CF (Datenübertragung
CF) | 3C | 83
2A 3A 3B 3C 3D 3E 3F |
TransferData
CF (Datenübertragung
CF) | 3C | 83
2B 40 FF FF FF FF FF |
Antwort
SF | 3D | 83
02 76 01 FF FF FF FF |
RequestTransferExit
SF (Anforderung Übertragungsende) | 3C | 83
01 37 FF FF FF FF FF |
Antwort
SF | 3D | 83
01 77 FF FF FF FF FF |
Tabelle
29: Runterladen des zweiten Speicherblocks
-
Nach
einer für
den Flash-Vorgang vorgesehenen Wartezeit kann die Diagnosesitzung
fortgesetzt werden. Für
sämtliche übertragenen
und in dem nichtflüchtigen
Speicher gespeicherten Daten kann eine Überprüfung aktiviert werden. Nachfolgende
Tabelle 26 zeigt eine hierfür
geeignete Diagnosesequenz. Gemäß UDS wird
eine Prüfroutine
mit der ID xxyy und der Unterfunktion 0×01 = start begonnen. Ein derartiger
Vorgang zur Überprüfung beansprucht
einen gewissen Zeitraum, weshalb bis zum Eintreffen einer positiven
oder negativen Antwort ein Intervall zu berücksichtigen ist.
Dienst | LIN
ID | LIN
Datenrahmen |
RoutineControl
SF (Routinekontrolle SF) | 3C | 83
04 31 01 xx yy FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
04 71 01 xx yy FF FF |
Tabelle
30: Überprüfung der
Speicherblöcke
-
Einen
letzten Schritt zum Rücksetzen
der ECU zeigt Tabelle 31. Im vorliegenden Beispiel wird ein derartiger
Dienst zum Rücksetzen
mit einem Parameter für
ein hartes bzw. abruptes Rücksetzen
(0×01)
angefordert. Es können
jedoch auch andere Beschreibungen des Parameters gemäß UDS vorgesehen
sein.
Dienst | LIN
ID | LIN
Datenrahmen |
ECUReset
SF (Rücksetzen
der ECU) | 3C | 83
02 11 01 FF FF FF FF |
Antwort
SF | 3D | 83
02 51 01 FF FF FF FF |
Tabelle
31: Rücksetzen
der ECU
-
4 zeigt
ein Diagramm zu einem Ablauf einer zweiten Ausführungsform einer Diagnosesitzung
für den
Fall, dass ein proprietäres
Kommunikationsprotokoll bei einer Programmierung eines elektronischen
Steuereinheit in einem LIN-Netzwerk durch das LIN-Protokoll getunnelt
wird. Dabei wird eine Reprogrammierung eines Slaves, der als die
elektronische Steuereinheit (ECU) ausgebildet ist, innerhalb des
LIN-Netzwerks vorgenommen.
-
Dabei
sind für
eine Programmierung 402 der Diagnosesitzung mehrere Schritte
vorgesehen. Mit einem ersten Schritt erfolgt der Start 404 der
Programmierungssitzung. In einem zweiten Schritt wird ein Flash-ROM-Zugang 406 und
in einem dritten Schritt ein RAM-Zugang 408 bereitgestellt.
In einem vierten Schritt wird ein Fingerprint 410 übermittelt.
Danach erfolgt in einem fünften
Schritt der Austausch 412 einer Löschroutine, worauf in einem
sechsten Schritt die Löschung 414 eines
Speichers durchgeführt
wird. Die Schritte fünf
und sechs können
bedarfsweise wiederholt werden. Danach wird in einem siebten Schritt
der Austausch 416 einer Schreibroutine vorgenommen, worauf
in einem achten Schritt das Schreiben 418 des Speichers
erfolgt, auch der siebte und der achte Schritt können erforderlichenfalls wiederholt
werden. Eine Bestätigung 420 eines
Inhalts des Speichers wird im neunten Schritt durchgeführt. Im
zehnten Schritt wird die Programmierung der Diagnosesitzung durch
ein Zurücksetzen 422 beendet.
Es sei darauf hingewiesen, dass die Schritte zwei, drei, fünf, sechs,
sieben und neun in den gestrichelt umrandeten Kasten in der vorliegende
Ausführungsform
optional durchgeführt
werden können.
-
Die
Diagnosedatenrahmen des LIN sind somit in
4 detailliert
dargestellt. Dieses Ausführungsbeispiel
basiert auf einer Flash-Programmierung von zwei Datenblöcken mit
einer Länge
von 64 Bytes in den Slave. Da in dem ECU keine Routine zum Löschen oder
Schreiben des Flash-Speichers vorgesehen ist, werden derartige Routinen
nach deren Übertragung
zu dem ECU im RAM ausgeführt.
Außerdem
sind in diesem Beispiel keine Zeitangaben wie beispielsweise für ein Warten
auf eine Antwort, vorgesehen, da diese von der benutzten Hardware
abhängen.
Es ist lediglich eine Reihenfolge der Sequenzen der Botschaft beschrieben.
Zunächst
wird eine Diagnoseprogrammierungsitzung, wie in Tabelle 32 gezeigt,
gestartet.
Dienst | LIN
ID | LIN
Datenrahmen |
Start
Diagnostic Session SF | 3C | 83
04 10 xx xx cs FF FF |
Antwort
SF | 3D | 83
02 50 02 FF FF FF FF |
Tabelle
32: Start 404 der Programmierung der Diagnosesitzung
-
Danach
wird der Flash-ROM-Zugang
406 bereitgestellt (wie in Tabelle
33 dargestellt).
Dienst | LIN
ID | LIN
Datenrahmen |
Zugang
zum Flash ROM ermöglichen | 3C | 83
02 38 3b FF FF FF FF |
Antwort
SF | 3D | 83
02 78 bb FF FF FF FF |
Tabelle
33: Bereitstellung des Flash-ROM-Zugangs 406
-
Die
Löschroutine
und die Schreibroutine für
den Flash Speicher werden in den RAM geladen, wobei der RAM-Zugang
408 ermöglicht wird
Dienst | LIN
ID | LIN
Datenrahmen |
RAM
Zugang ermöglichen | 3C | 83
02 39 3a FF FF FF FF |
Antwort
SF | 3D | 83
02 79 ba FF FF FF FF |
Tabelle
34: Bereitstellung des RAM-Zugangs 408
-
Da
nun der Flash-ROM-Zugang
406 bereitgestellt ist, kann der
Fingerprint
410 der Software nach Tabelle 35 zu dem Slave übertragen
werden. Dabei werden die xx und yy Bytes gemäß der Identität des gewünschten
Fingerprints
410 besetzt. Danach werden die Daten des Fingerprints
410,
beispielsweise yy, übermittelt.
Dienst | LIN
ID | LIN
Datenrahmen |
"Transparenter Datenblock
mit Parameterübergabe" | 3C | 83
04 60 xx yy cs FF FF |
Antwort
SF | 3D | 83
03 A0 xx cs FF FF FF |
Tabelle
35: Übertragung
des Fingerprints 410
-
Da
der Slave in diesem Beispiel eine Softwareverriegelung verwendet,
liegt im Flash-Speicher keine Routine zum Löschen vor. Stattdessen wird
ein Programmcode zum Löschen
des Flash-Speichers,
wie Tabelle 36 zeigt, unmittelbar vor einer Löschoperation zumindest teilweise
in die RAM-Adresse 0×01234 übertragen.
Dienst | LIN
ID | LIN
Datenrahmen |
Write
RAM 16 Bit FF | 3C | 83
10 13 50 01 23 01 02 |
Write
RAM 16 Bit CF | 3C | 83
21 03 04 05 06 07 08 |
Write
RAM 16 Bit CF | 3C | 83
22 09 0a 0b 0c 0d 0e |
Write
RAM 16 Bit CF | 3C | 83
23 0f cs FF FF FF FF |
Antwort
SF | 3D | 83
03 90 01 cs FF FF FF |
Tabelle
36: Runterladen der Löschroutine
-
In
nachfolgender Tabelle 38 ist dargestellt, wie der Flash-Speicher
mit der zuvor übertragenen
Löschroutine
gelöscht
wird. Der Dienst für
die entsprechende Routine besitzt die Bezeichnung "Bulk-Erase Flash ROM
16 Bit Adressraum",
eine zugehörige
Unterfunktion 0×00
zu dem proprietären
Protokoll bedeutet, dass der komplette Flash-Speicher gelöscht wird.
Da die Löschung
einige Zeit beansprucht, können
einzelnen RX-Diagnosebotschaften des Slaves leer sein. Um anzuzeigen,
dass der LIN-Slave dennoch wartet, sollte eine Antwort, die besagt,
dass der Tester wartet, in spezifischen Zeitintervallen übersendet
werden. Nach Beendigung des Löschprozesses
wird eine positive Antwort gesendet. Die Zeit zur Löschung
414 wird
durch ein Flash-Werkzeug berücksichtigt.
Dienst | LIN
ID | LIN
Datenrahmen |
Bulk-Erase
(Hauptlöschung) Flash
ROM 16bit Adreßraum | 3C | 83
03 4d 00 cs FF FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF (Tester wartet) | 3D | 83
02 fe fd FF FF FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
03 8d 01 cs FF FF FF |
Tabelle
37: Löschung
414 des Speichers
-
Bedingt
durch die Verriegelung der Software ist im vorliegenden Beispiel
keine Routine zum Schreiben des nichtflüchtigen Speichers vorgesehen.
Nachfolgende Tabelle 38 zeigt eine Botschaftssequenz, mit der eine
Schreibroutine für
den Slave heruntergeladen wird.
Dienst | LIN
ID | LIN
Datenrahmen |
Write
RAM 16bit FF | 3C | 83
10 13 50 02 34 01 02 |
Write
RAM 16bit CF | 3C | 83
21 03 04 05 06 07 08 |
Write
RAM 16bit CF | 3C | 83
22 09 0a 0b 0c 0d 0e |
Write
RAM 16bit CF | 3C | 83
23 0f cs FF FF FF FF |
Antwort
SF | 3D | 83
03 90 01 cs FF FF FF |
Tabelle
38: Schreibroutine Runterladen
-
Nun
wird der erste, aktuell vorliegende Speicherblock übertragen,
was in Tabelle 39 dargestellt ist. Der Dienst "Program Flash ROM 16bit" startet mit einer
Anfrage nach 68 Datenbytes (0×44;
64 Daten, 1 SID, 2 Adressenbytes (0×0123) und 1 Checksummenbyte).
Zuletzt werden alle Rahmen der übertragenen
Daten versendet, eine positive Antwort wird empfangen.
Dienst | LIN
ID | LIN
Datenrahmen |
Program
Flash ROM 16bit FF | 3C | 83
10 44 4b 01 23 01 02 |
Program
Flash ROM 16bit CF | 3C | 83
21 03 04 05 06 07 08 |
Program
Flash ROM 16bit CF | 3C | 83
22 09 0A 0B 0C 0D 0E |
: | : | : |
Program
Flash ROM 16bit CF | 3C | 83
2A 39 3A 3B 3C 3D 3E |
Program
Flash ROM 16bit CF | 3C | 83
2B 3f 40 cs FF FF FF |
Antwort
SF | 3D | 83
03 8b 01 cs FF FF FF |
Tabelle
39: Runterladen des ersten Speicherblocks
-
Nachfolgende
Tabelle 40 beginnt mit dem Herunterladen eines zweiten Speicherblock
(Adresse 0×123 +
40). Dies erfolgt ebenfalls wie in Tabelle 39 dargestellt. Bevor
das Herunterladen des zweiten Speicherblocks begonnen wird, ist
ein Intervall einzufahren, da der Flash-Vorgang einige Zeit beansprucht.
Dienst | LIN
ID | LIN
Datenrahmen |
Program
Flash ROM 16bit FF | 3C | 83
10 44 4b 01 63 01 02 |
Program
Flash ROM 16bit CF | 3C | 83
21 03 04 05 06 07 08 |
Program
Flash ROM 16bit CF | 3C | 83
22 09 0A 0B 0C 0D 0E |
: | : | : |
Program
Flash ROM 16bit CF | 3C | 83
2A 39 3A 3B 3C 3D 3E |
Program
Flash ROM 16bit CF | 3C | 83
2B 3f 40 cs FF FF FF |
Antwort
SF | 3D | 83
03 8b 01 cs FF FF FF |
Tabelle
40: Runterladen des zweiten Speicherblocks
-
Nach
dem für
den Flash-Vorgang vorgesehenen Intervall kann die Diagnosesitzung
fortgesetzt werden. Für
sämtliche übertragenen
und in dem nichtflüchtigen
Speicher gespeicherten Daten kann eine Überprüfung aktiviert werden. Nachfolgende
Tabelle 41 zeigt eine hierfür
geeignete Diagnosesequenz. Bei dem proprietären Protokoll wird eine Prüfroutine
mit der ID xyyx begonnen. Ein derartiger Vorgang zur Überprüfung beansprucht
eine gewisse Zeit, weshalb bis zum Eintreffen einer positiven oder
negativen Antwort ein Intervall zu berücksichtigen ist.
Dienst | LIN
ID | LIN
Datenrahmen |
"Transparenter Datenblock
mit Parameterübergabe" | 3C | 83
04 60 xy yx cs FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
02 fe fd FF FF FF FF |
Antwort
SF | 3D | Keine
Antwort |
Antwort
SF | 3D | 83
03 A0 xx cs FF FF FF |
Tabelle
41: Überprüfen des
Speicherblocks
-
Der
letzte Schritt des Rücksetzens
der ECU ist in Tabelle 42 dargestellt. Der Dienst "Transparenter Datenblock
mit Parameterübergabe" wird mit einem harten
Rücksetzen
(zz) der Parameter (0×01)
angefordert.
Dienst | LIN
ID | LIN
Datenrahmen |
"Transparenter Datenblock
mit Parameterübergabe" | 3C | 83
04 06 xx zz cs FF FF |
Antwort
SF | 3D | 83
03 A0 yy cs FF FF FF |
Tabelle
42: Rücksetzen
der ECU