[go: up one dir, main page]

DE102006032217A1 - Verfahren zum Betreiben eines LIN-Busses - Google Patents

Verfahren zum Betreiben eines LIN-Busses Download PDF

Info

Publication number
DE102006032217A1
DE102006032217A1 DE102006032217A DE102006032217A DE102006032217A1 DE 102006032217 A1 DE102006032217 A1 DE 102006032217A1 DE 102006032217 A DE102006032217 A DE 102006032217A DE 102006032217 A DE102006032217 A DE 102006032217A DE 102006032217 A1 DE102006032217 A1 DE 102006032217A1
Authority
DE
Germany
Prior art keywords
lin
protocol
service
frame
diagnostic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102006032217A
Other languages
English (en)
Inventor
Ingo Mauel
Ralf Machauer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102006032217A priority Critical patent/DE102006032217A1/de
Priority to US12/227,816 priority patent/US20090307400A1/en
Priority to PCT/EP2007/056687 priority patent/WO2008006737A1/de
Priority to EP07765778A priority patent/EP2044736A1/de
Priority to CNA2007800260859A priority patent/CN101491016A/zh
Publication of DE102006032217A1 publication Critical patent/DE102006032217A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40234—Local Interconnect Network LIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)

Abstract

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.

Description

  • 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.
  • Figure 00110001
  • Figure 00120001
    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 (tRtoutM) 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 (tRtoutM) 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

Claims (15)

  1. 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.
  2. Verfahren nach Anspruch 1, bei dem ein mit dem Kommunikationsprotokoll verbundener Dienst auf einen Rahmen des LIN-Protokolls abgebildet wird.
  3. Verfahren nach Anspruch 2, bei dem mindestens ein Datum des Rahmens in Abhängigkeit des Dienstes belegt wird.
  4. Verfahren nach Anspruch 3, bei dem mindestens ein Datum des Diagnoseframes in Abhängigkeit des Dienstes belegt wird.
  5. Verfahren nach einem der voranstehenden Ansprüche, bei dem mindestens ein Teilnehmer des LIN-Busses über das Kommunikationsprotokoll programmiert wird.
  6. Verfahren nach einem der voranstehenden Ansprüche, bei dem während des Sonderbetriebs eine Diagnose durchgeführt wird, wobei das alternative Kommunikationsprotokoll auf einem Diagnoserahmen des LIN-Protokolls abgebildet wird.
  7. Verfahren nach einem der voranstehenden Ansprüche, bei dem ein UDS-Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein UDS-Dienst auf dem Rahmen abgebildet wird.
  8. Verfahren nach einem der Ansprüche 1 bis 6, bei dem ein proprietäres Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein proprietärer Dienst auf dem Rahmen abgebildet wird.
  9. Verfahren nach einem der Ansprüche 1 bis 6, bei dem ein KWP2000-Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein KWP2000-Dienst auf dem Rahmen abgebildet wird.
  10. Verfahren nach einem der voranstehenden Ansprüche, bei dem Parameter des alternativen Kommunikationsprotokolls dienstabhängig belegt werden.
  11. Anordnung, die einen LIN-Bus mit mehreren Teilnehmern aufweist und deren Spezifikationen in einem Normalbetrieb durch ein LIN-Protokoll beschrieben sind, und die zur Durchführung eines Sonderbetriebs dazu ausgebildet ist, ein alternatives Kommunikationsprotokoll durch das LIN-Protokoll zu tunneln.
  12. Anordnung nach Anspruch 11, bei der ein erster Teilnehmer als Master (102) und mindestens ein zweiter Teilnehmer als Slave (104) ausgebildet ist.
  13. Anordnung nach Anspruch 12, bei dem zur Durchführung einer Kommunikation vorgesehen ist, dass der Master (102) an den Slave (104) Anfragen (114, 118, 122, 128, 134) übermittelt und der Slave (104) and den Master (102) Antworten (130, 136) übermittelt.
  14. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 10 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Anordnung nach einem der Ansprüche 11 bis 13, ausgeführt wird.
  15. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 10 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einem Steuergerät in einer Einrichtung nach einem der Ansprüche 11 bis 13, ausgeführt wird.
DE102006032217A 2006-07-12 2006-07-12 Verfahren zum Betreiben eines LIN-Busses Withdrawn DE102006032217A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102006032217A DE102006032217A1 (de) 2006-07-12 2006-07-12 Verfahren zum Betreiben eines LIN-Busses
US12/227,816 US20090307400A1 (en) 2006-07-12 2007-07-03 Method for Operating a Lin Bus
PCT/EP2007/056687 WO2008006737A1 (de) 2006-07-12 2007-07-03 Verfahren zum betreiben eines lin-busses
EP07765778A EP2044736A1 (de) 2006-07-12 2007-07-03 Verfahren zum betreiben eines lin-busses
CNA2007800260859A CN101491016A (zh) 2006-07-12 2007-07-03 用于运行lin总线的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102006032217A DE102006032217A1 (de) 2006-07-12 2006-07-12 Verfahren zum Betreiben eines LIN-Busses

Publications (1)

Publication Number Publication Date
DE102006032217A1 true DE102006032217A1 (de) 2008-01-24

Family

ID=38443345

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102006032217A Withdrawn DE102006032217A1 (de) 2006-07-12 2006-07-12 Verfahren zum Betreiben eines LIN-Busses

Country Status (5)

Country Link
US (1) US20090307400A1 (de)
EP (1) EP2044736A1 (de)
CN (1) CN101491016A (de)
DE (1) DE102006032217A1 (de)
WO (1) WO2008006737A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011079688A1 (de) * 2010-08-03 2012-04-05 Continental Teves Ag & Co. Ohg Kommunikationsverfahren mit Echo
EP2654245A2 (de) 2012-04-18 2013-10-23 Magna Car Top Systems GmbH Steuereinrichtung mit Signalzusammenfassung
EP2161638B2 (de) † 2008-09-08 2014-03-05 Siemens Aktiengesellschaft Automatisierungssystem, Gerät zur Verwendung in einem Automatisierungssystem und Verfahren zum Betreiben eines Automatisierungssystems
DE102013002647B3 (de) * 2013-02-15 2014-05-22 Audi Ag Kraftwagen mit einem Fahrzeugkommunikationsbus und Verfahren zum Erzeugen von Busnachrichten
DE102013002648B3 (de) * 2013-02-15 2014-05-22 Audi Ag Master-Busgerät für einen Fahrzeugkommunikationsbus eines Kraftwagens
DE102011054785B4 (de) 2010-10-28 2022-04-28 Denso Corporation Elektronische Vorrichtung

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012080379A (ja) * 2010-10-04 2012-04-19 Renesas Electronics Corp 半導体データ処理装置及びデータ処理システム
US8924025B2 (en) * 2011-04-28 2014-12-30 GM Global Technology Operations LLC Heating, ventilating, and air conditioning module for a vehicle
CN103607258B (zh) * 2013-11-18 2018-07-06 深圳市道通科技股份有限公司 汽车电脑诊断设备中主从设备的通信方法、装置及系统
DE102014116909B4 (de) * 2014-11-19 2016-07-28 Infineon Technologies Ag Empfänger, Sender, Verfahren zum Wiedergewinnen eines zusätzlichen Datenwerts aus einem Signal und Verfahren zum Übertragen eines Datenwerts und eines zusätzlichen Datenwerts in einem Signal
DE102015204924B4 (de) * 2015-03-18 2022-05-25 Röchling Automotive SE & Co. KG LIN-Netzwerk
US10230592B2 (en) * 2016-03-02 2019-03-12 Oracle International Corporation Compound service performance metric framework
FR3076161B1 (fr) * 2017-12-21 2019-11-15 Psa Automobiles Sa Dispositif de supervision de defauts d’organe(s) esclave(s) pour un organe maitre d’un reseau multiplexe.
KR102707737B1 (ko) * 2019-06-03 2024-09-23 현대자동차주식회사 제어기 진단 장치 및 그 방법
CN111736873B (zh) * 2020-06-22 2023-02-24 中国第一汽车股份有限公司 电子控制单元的程序更新方法、装置、设备和存储介质
DE102020124549A1 (de) * 2020-09-21 2022-03-24 Bayerische Motoren Werke Aktiengesellschaft System zur datenübertragung in einem kraftfahrzeug, kraftfahrzeug und verfahren
US12195016B2 (en) * 2021-06-22 2025-01-14 Hyundai Motor Company Apparatus for extracting driving data of autonomous driving vehicle, and system and method for the same
CN115718470A (zh) * 2021-08-24 2023-02-28 上汽通用汽车有限公司 用于远程诊断测试的系统、方法以及存储介质
CN115766889B (zh) * 2022-09-28 2024-06-21 重庆赛力斯凤凰智创科技有限公司 一种数据帧结构和数据通信方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10124800A1 (de) * 2001-05-21 2002-12-12 Siemens Ag Prozessautomatisierungssystem und Prozessgerät für ein Prozessautomatisierungssystem
DE10147445A1 (de) * 2001-09-26 2003-04-17 Bosch Gmbh Robert Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE10156159A1 (de) * 2001-11-15 2003-05-28 Siemens Ag Verfahren zum Einsetzen eines höherwertigen Protokolls auf einem beschränkten Bussystem
DE10311395A1 (de) * 2003-03-13 2004-09-23 Robert Bosch Gmbh Kommunikationsvorrichtung mit asynchroner Datenübertragung über eine symmetrische serielle Schnittstelle
EP1530137A1 (de) * 2003-11-10 2005-05-11 Robert Bosch Gmbh Simulationssystem und Computerimplementiertes Verfahren zur Simulation und Verifikation von Kontrollsystemen
EP1735672A1 (de) * 2004-04-01 2006-12-27 Delphi Technologies, Inc. Verfahren und protokoll zur diagnose beliebig komplexer netzwerke von einrichtungen
DE102004020393A1 (de) * 2004-04-23 2005-11-10 Endress + Hauser Gmbh + Co. Kg Funkmodul für Feldgeräte der Automatisierungstechnik
DE102006009098A1 (de) * 2006-02-28 2007-08-30 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
US20070260900A1 (en) * 2006-05-03 2007-11-08 Renesas Technology America, Inc. High-performance microprocessor with lower-performance microcontroller in a vehicle network
DE102006058184B4 (de) * 2006-11-29 2008-10-16 Atmel Germany Gmbh Integrierter Treiberschaltkreis für einen LIN-Bus

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2161638B2 (de) † 2008-09-08 2014-03-05 Siemens Aktiengesellschaft Automatisierungssystem, Gerät zur Verwendung in einem Automatisierungssystem und Verfahren zum Betreiben eines Automatisierungssystems
DE102011079688A1 (de) * 2010-08-03 2012-04-05 Continental Teves Ag & Co. Ohg Kommunikationsverfahren mit Echo
DE102011054785B4 (de) 2010-10-28 2022-04-28 Denso Corporation Elektronische Vorrichtung
EP2654245A2 (de) 2012-04-18 2013-10-23 Magna Car Top Systems GmbH Steuereinrichtung mit Signalzusammenfassung
DE102012206390A1 (de) 2012-04-18 2013-10-24 Magna Car Top Systems Gmbh Steuereinrichtung mit Signalzusammenfassung
DE102013002647B3 (de) * 2013-02-15 2014-05-22 Audi Ag Kraftwagen mit einem Fahrzeugkommunikationsbus und Verfahren zum Erzeugen von Busnachrichten
DE102013002648B3 (de) * 2013-02-15 2014-05-22 Audi Ag Master-Busgerät für einen Fahrzeugkommunikationsbus eines Kraftwagens
WO2014124731A1 (de) 2013-02-15 2014-08-21 Audi Ag Master-busgerät für einen fahrzeugkommunikationsbus eines kraftwagens
WO2014124732A1 (de) 2013-02-15 2014-08-21 Audi Ag Kraftwagen mit einem fahrzeugkommunikationsbus und verfahren zum erzeugen von busnachrichten
US9485327B2 (en) 2013-02-15 2016-11-01 Audi Ag Motor vehicle having a vehicle communication bus and method for generating bus messages
US9715471B2 (en) 2013-02-15 2017-07-25 Audi Ag Master bus device for a vehicle communication bus of a motor vehicle

Also Published As

Publication number Publication date
EP2044736A1 (de) 2009-04-08
CN101491016A (zh) 2009-07-22
WO2008006737A1 (de) 2008-01-17
US20090307400A1 (en) 2009-12-10

Similar Documents

Publication Publication Date Title
EP2044736A1 (de) Verfahren zum betreiben eines lin-busses
DE102010016283B4 (de) Verfahren zur Übertragung von Daten über einen CANopen-Bus sowie Verwendung des Verfahrens zum Konfigurieren und/oder Parametrieren von Feldgeräten über den CANopen-Bus
WO2003027629A1 (de) Verfahren zur durchführung einer ferndiagnose bei einem kraftfahrzeug, fahrzeugdiagnosemodul und servicecenter
EP2705430A1 (de) System zur diagnose einer komponente in einem fahrzeug
DE102012102187B3 (de) Steuerungsvorrichtung zum Steuern von sicherheitskritischen Prozessen in einer automatisierten Anlage und Verfahren zur Parametrierung der Steuerungsvorrichtung
EP3080950B1 (de) Verfahren und system zur deterministischen autokonfiguration eines gerätes
EP3759871B1 (de) Master-slave bussystem und verfahren zum betrieb eines bussystems
EP2957075B1 (de) Master-busgerät für einen fahrzeugkommunikationsbus eines kraftwagens
DE102007062763A1 (de) Verteiltes Diagnosesystem mit einem einzelnen Diagnose-Protokollserver und mehreren Datenquellen-Modulen für Verbrennungsmotoren
EP3948448B1 (de) Verfahren, softwareklemme und klemmensystem zur änderung einer steuerungssoftware eines automatisierungssystems
DE102008030162C5 (de) Verfahren zum Prüfen der Funktionsfähigkeit einer eingebetteten Komponente in einem eingebetteten System
DE102009027168B4 (de) Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge
WO2005002145A1 (de) Anordnung und verfahren zur verwaltung eines speichers
DE102010063528B4 (de) Verfahren zum Verbinden von Busleitungen zu Bussen und Vorrichtung zur Ausführung des Verfahrens
WO2011018422A1 (de) Vorrichtung zum zugriff auf elektronische fahrzeugkomponenten
DE102009044936A1 (de) Verfahren zum Austauschen von Daten
DE102016225755A1 (de) Verfahren zum Betreiben einer Datenverarbeitungsanlage, Datenverarbeitungsanlage
EP4094407A1 (de) Sende-/empfangseinrichtung und kommunikationssteuereinrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
WO2021148351A1 (de) Sende-/empfangseinrichtung und kommunikationssteuereinrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
DE102020211168B3 (de) Verfahren und Vorrichtung zum Zustandsrücksetzen von Komponenten eines Fahrzeugs
DE102016008587B4 (de) Zugriff auf ein über einen Datenbus eines Kraftfahrzeugs übermittelbares Steuersignal
DE102020214129A1 (de) Verfahren und System zum Kommunizieren über einen Kommunikationsbus
DE102020214515A1 (de) Verfahren zum Speichern eines digitalen Schlüssels in einem Steuergerät
DE102020216071A1 (de) Verfahren zum Betreiben einer Vorrichtung, ein Steuergerät eines Kraftfahrzeugs, und Vorrichtung

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee