Beschreibung

Titel

Verfahren zum Betreiben eines LIN-Busses

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 Intercon- nect 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übertra- gungsrate 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 LI N -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 LI N- 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 U DS- Protokolls durch das LIN- Protokoll wird ein U DS- 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 Steu- ergerä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.

- A -

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 Konfi- gurationsspezifikation 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 ein jeweiliges 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.

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:

Tabelle 2: Rahmentypen für Anfragen des Masters und Antworten des Slaves

Diagnoserahmen umfassen typischerweise 8 Datenbytes. Eine mögliche Struktur mög- licher Diagnoserahmen ist in der nachfolgenden Tabelle 3 dargestellt.

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.

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 Information) steht für Protokollkontrollinformation. Die Protokollkontrollinformation umfasst Informationen über den Rahmentyp und die Trans- portschichtflusskontrollinformation.

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 = Oxff) umfassen. In einem ersten Beispiel ergeben sich nachfolgende Werte:

Anzahl der Datenbytes in der Botschaft = 700 Byte (0x2bc) Länge = 0x2bd, Anzahl der Datenbytes in der Botschaft plus 1

LEN = Oxbd, acht niedrigstwertige Bits der Länge

PCI = 0x12, 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 (0x2bc)

Länge = 0x2bd, Anzahl der Datenbytes in der Botschaft plus 1

LEN = Oxbd, acht niedrigstwertige Bits der Länge

PCI = 0x12, 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. Ta- belle 6 zeigt den Zusammenhang zwischen SID und der Knotenadresse (NAD).

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 Antwort- dienstidentifikator und bestimmt Inhalte der Antwort. Der RSID für eine positive Antwort ist typischerweise SID + 0x40.

Die Interpretation von Datenbytes, die durch die Variablen Dl bis D6 für jeweils ein entsprechendes Datum 1 bis Datum 6 beschrieben sind, hängt von dem Dienstidentifi- kator oder dem Antwortdienstidentifikator ab. Falls ein Rahmen eines Protokolls nicht vollständig gefüllt wird, werden die ungenutzten Bytes mit Einsen (Oxff) 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.

Tabelle 7: Kommunikationsfehler

Abhängig von der Knotenart, also einer konkreten Ausbildung des LI N -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.

Tabelle 8: Reaktion auf Fehler im Slave-Knoten

Tabelle 9 zeigt Beispiele zu einer Fehlerbehandlung, die in dem Master- Knoten implementiert sind.

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 über-

tragung, Neustart der Anfrage- oder Antwortsequenz oder durch einen vollständiger Abbruch der Kommunikation.

In einer möglichen Ausgestaltung kann ein Diagnosedienst gemäß UDS (Unified Di- agnostic 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 LI N -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" (sub-function) und "SupPosRsp" (suppress positive response message, Unter- drü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 ge- wü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 0x40 zu bilden. Eine negative Antwort wird für den RSID 0x7F 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 Bitl BitO

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: 0x83, Beispiel für eine Knotenadresse,

PCI: 0x02, SID und ein Datenbyte, für einen Einzelrahmen

SID: 0x10, Diagnosesitzungskontrolldienst

Datuml: 0x02, durch UDS spezifizierte Programmierungssitzung

Tabelle 12: Diagnosesitzungskontrolle

Beispiel vier: Datenübertragung zum LIN-Slave.

NAD: 0x83, Beispiel für Knotenadresse

PCI: 0x10, erster Rahmen mit mehr als 6 Datenbytes

LEN: 0x09, SID und 8 Datenbytes sind zu übertragen

SID: 0x36, übertragungsdaten

Datuml: 0x01, Blocksequenzzähler (Unterparameter für SID 0x63 nach UDS)

Datum2-Datum4: zu übertragende Datenbytes

NAD: 0x83, Beispiel für Knotenadresse PCI: 0x21, Fortsetzungsrahmen (CF), zweiter Datenrahmen Datum 1-Datum4: zu übertragende Datenbytes Datum5-Datum6: nicht besetzt, auf OxFF gesetzt

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.

"Checksumme" D2 = "Checksumme"

"Blocktester Warten" (Antwort ldentifikator OxFE Antwort ohne Anfrage)

Response ("Blocktitel") RSID = 0xFE

Tabelle 14: Abbildung vom proprietären Rahmen zum LI N- Rahmen

Tabelle 15 zeigt eine übersicht einiger Diagnosedienste innerhalb des LI N -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.

I mit Parameterübergabe" | | fisch besondere Befehle definiert werden.

Tabelle 15: übersicht LIN-Diagnosedienste

Die Abbildung der Dienste auf den LI N- Rahmen kann nach einem der nachfolgenden Beispiele erfolgen.

Beispiel fünf: Beginn der Diagnosesitzung.

NAD: 0x83, Beispiel für Knotenadresse PCI: 0x04, SID, 3 Datenbytes und Checksumme, Einzelrahmen SID: 0x10, 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: es, Checksumme

Für den Start der Diagnosesitzung gilt Tabelle 16.

Tabellelδ: Start Diagnosesitzung

Beispiel sechs: Programmierung von 6 Bytes des Flash ROMs zur Adresse 0x0123.

Erster Rahmen (FF):

NAD: 0x83, Beispiel für Knotenadresse PCI: 0x10, erster Rahmen, mehr als 8 Datenbytes

LEN: OxOa, SID, 2 Adressenbytes, 6 Datenbytes und Checksumme sind zu übertragen

SID: 0x4b, "Program Flash ROM 16Bit Adressraum"

Datum 1: 0x01 MSB der Adresse, im proprietären Protokoll spezifiziert

Datum 2: 0x23 LSB der Adresse, im proprietären Protokoll spezifiziert Datum 3, Datum4: Datenbyte 1 und Datenbyte 2

Fortsetzungsrahmen (CF):

NAD: 0x83, Beispiel für Knotenadresse

PCI: 0x21, Fortsetzungsrahmen, zweiter Datenrahmen

D1-D4: zu übertragende Datenbytes (Byte 3 - Byte 6)

D5: es, Checksumme

D6: nicht benutzt, auf OxFF gesetzt

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äu- ternden 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

Figur 1 zeigt in schematischer Darstellung ein Diagramm zu einer Ausführungsform eines Ablaufs einer Kommunikation in einem LIN-Netzwerk.

Figur 2 zeigt in schematischer Darstellung ein Diagramm zur einem Ablauf eines Beginns einer Diagnosesitzung.

Figur 3 zeigt in schematischer Darstellung ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung.

Figur 4 zeigt in schematischer Darstellung ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung.

Ausführungsformen der Erfindung

In dem Diagramm aus Figur 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 = 0x3d gesendet hat. Bei einer Diagnose eines Fahrzeugs, wobei eine Fahrzeugtesteinrichtung als Diagnose- Masterl02 vorgesehen ist, werden zeitliche Anforderungen, die durch ein Diagnose- Protokoll 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 = 0x3d 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 _RtO ut _M ) in dem LIN-Netzwerk 106 implementiert werden. Der Master 102 sendet "0x3d", worauf der Slave 104 jedoch nicht antwortet, der Master 102 wiederholt die Botschaft mit "0x3d" 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 (traoutivi) 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.

Tabelle 18: übersicht Zeitparameter

Um die Software einfach und übersichtlich zu halten, ist es möglich, die Rücksetzzeit 120 t _R tout _M durch Zählen der 0x3d 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 (T _R ^ _M ) in der Regel von ei- nem Zustand des LIN-Netzwerks 106 abhängig.

Figur 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 Figur 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 Figur 2 dargestellten Schritte teilweise weggelassen werden. In diesem Fall genügt für UDS der durch das Diagramm aus Figur 3 und für den proprietären Dienst der durch das Diagramm aus Figur 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.

Figur 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 In- halts 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 Kästen 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 Figur 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.

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 0x27 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 0x21 0x47.

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

0x02 der Unterfunktion gemäß UDS spezifiziert die "sendKey" Funktion des Dienstes 0x27 zum Senden des Schlüssels. Falls der Schlüssel, beispielsweise 0x47 0x11, passt, wird ein Programmierungszugang gewährt.

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 0x01 - 0x03, übermittelt. Eine übertragung des Fingerprints 308 zeigt exemplarisch Tabelle 22.

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.

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 (0x31) der Routine wird in dem Slave eine Prozedur mit einer Routine mit ID = xxxx gestartet, wobei gemäß UDS eine Unterfunktion 0x01 = 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.

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 0x31 zu dieser Löschroutine aufgerufen und mit der Unterfunktion 0x01 = 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.

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.

Tabelle 26: Runterladen der Schreibroutine

Die übertragenen Bytes werden mit den in Tabelle 27 gelisteten Befehlssequenzen auf Richtigkeit überprüft.

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 (0x40) Datenbytes an der Adresse xxyy angefordert. Nach einer positiven Antwort werden die Daten mit aufeinanderfolgenden Rahmen in den Datentransferdienst (0x36) übertragen. Dieser Datentransferdienst beginnt mit einer Anfrage nach 66 Datenbytes (0x42; 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 (0x37) zur Anforderung des übertragungsendes (Re- questTransferExit) abgeschlossen werden.

Tabelle 28: Runterladen des ersten Speicherblocks

Mit nachfolgender Tabelle 29 ist dargestellt, wie ein zweiter Speicherblock herunterge- laden 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.

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 0x01 = 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.

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 (OxOl) angefordert. Es können jedoch auch andere Beschreibungen des Parameters gemäß UDS vorgesehen sein.

Tabelle 31: Rücksetzen der ECU

Figur 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 vorge- sehen. 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 Kästen in der vorliegende Ausführungsform optional durchgeführt werden können.

Die Diagnosedatenrahmen des LIN sind somit in Figur 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.

Tabelle 32: Start 404 der Programmierung der Diagnosesitzung

Danach wird der Flash- ROM-Zugang 406 bereitgestellt (wie in Tabelle 33 dargestellt).

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

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.

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 0x01234 übertragen.

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 "BuIk- Erase Flash ROM 16 Bit Adressraum", eine zugehörige Unter- funktion 0x00 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ösch prozesses wird eine positive Antwort gesendet. Die Zeit zur Löschung 414 wird durch ein Flash-Werkzeug berücksichtigt.

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.

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 (0x44; 64 Daten, 1 SID, 2 Adressenbytes (0x0123) und 1 Checksummenbyte). Zuletzt werden alle Rahmen der übertragenen Daten versendet, eine positive Antwort wird empfangen.

Tabelle 39: Runterladen des ersten Speicherblocks

Nachfolgende Tabelle 40 beginnt mit dem Herunterladen eines zweiten Speicherblock (Adresse 0x123+40). Dies erfolgt ebenfalls wie in Tabelle 39 dargestellt. Bevor das Herunterladen des zweiten Speicherblocks begonnen wird, ist ein Intervall einzuführen, da der Flash-Vorgang einige Zeit beansprucht.

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 bean- sprucht eine gewisse Zeit, weshalb bis zum Eintreffen einer positiven oder negativen Antwort ein Intervall zu berücksichtigen ist.

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 (OxOl) angefordert.

Tabelle 42: Rücksetzen der ECU