DE10243319B4 - Sichere Datenübertragung - Google Patents

Sichere Datenübertragung Download PDF

Info

Publication number
DE10243319B4
DE10243319B4 DE2002143319 DE10243319A DE10243319B4 DE 10243319 B4 DE10243319 B4 DE 10243319B4 DE 2002143319 DE2002143319 DE 2002143319 DE 10243319 A DE10243319 A DE 10243319A DE 10243319 B4 DE10243319 B4 DE 10243319B4
Authority
DE
Germany
Prior art keywords
data
controller
check code
block check
data bus
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.)
Expired - Fee Related
Application number
DE2002143319
Other languages
English (en)
Other versions
DE10243319A1 (de
Inventor
Johannes Dipl.-Phys. Hesselbarth
Peter Dipl.-Ing. Hiemer (FH)
Werner Mayer
Martin Dipl.-Ing. Rahm (FH)
Mario Dipl.-Ing. Tannert
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.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
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 DaimlerChrysler AG filed Critical DaimlerChrysler AG
Priority to DE2002143319 priority Critical patent/DE10243319B4/de
Publication of DE10243319A1 publication Critical patent/DE10243319A1/de
Application granted granted Critical
Publication of DE10243319B4 publication Critical patent/DE10243319B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related 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/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • 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
    • 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/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • 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/40215—Controller Area Network CAN
    • 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/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

Verfahren
– zur Datenübertragung in einem Datenbus (1) eines Verkehrsmittels, wobei
– Steuergeräte (2) über einen Datenbus (1) verbunden sind,
– Daten über den Datenbus (1) entsprechend eines Datenbus-Protokolls ausgetauscht werden,
– Nutzdaten und korrespondierende Nachrichtenidentifikations- oder Adressierungsdaten von einem Mikro-Controller (3) eines Steuergeräts (2) zur Versendung bereitgestellt werden,
– die Daten gemäß dem Datenbus-Protokoll von einem Kommunikations-Controller (4) unter Verwendung eines Blockprüfungscodes bearbeitet kodiert werden und
– mittels einer Sende-/Empfangseinheit (5) des Steuergeräts (2) über den Datenbus (1) versendet werden,
dadurch gekennzeichnet, dass
– zusätzlich zum Blockprüfungscode des Kommunikations-Controllers (4) ein Blockprüfungscode mittels einer Blockprüfung über die Daten, bestehend aus Nutzdaten und korrespondierende Nachrichtenidentifikations- bzw. Adressierungsdaten von dem Mikro-Controller (3) des sendenden Steuergeräts (2) ermittelt wird und
– der zusätzliche Blockprüfungscode vom Mikro-Controller des empfangenden Steuergeräts überprüft wird.

Description

  • Die Erfindung betrifft ein Verfahren zur Datenübertragung im Datenbus eines Verkehrsmittels.
  • Bei der Datenübertragung zwischen Steuergeräten in einem Verkehrsmittel über einen Datenbus können Daten auf ihrem Weg zum Empfänger verfälscht bzw. verändert werden. Dies führt zu einem Fehler in dem empfangenden Steuergerät, sofern von dem empfangenden Steuergerät nicht erkannt wird, dass es verfälschte Daten empfangen hat.
  • Der Datenaustausch zwischen Steuergeräten auf dem Datenbus wird über ein Kommunikationsprotokoll, wie CAN(Controller Area Network), MOST (Media Oriented Systems Transport), TTP (Time Triggered Protocol), Ethernet, geregelt, welches beispielsweise die maximale Länge der zu versendenden Nutzdaten bzw. des Datenpakets, die Adressierung, das Format, die Sendeart usw. festlegt. Die Nutzdaten entsprechen den zu versendenden Daten des Mikro-Controllers eines Steuergeräts ohne die zur Versendung ebenfalls notwendigen Adressierungs- und Protokolldaten.
  • Die vom Steuergerät zu versendenden bzw. zu empfangenden Nutzdaten werden vom Mikro-Controller zum Kommunikations-Controller des Steuergeräts und dann zur eigentlichen Sende-/Empfangseinheit bzw. von der Sende-/Empfangseinheit zum Kommunikations-Controller und dann zum Mikro-Controller des Steuergeräts übertragen.
  • Mittels des im Kommunikations-Controllers implementierten Kommunikationsprotokolls erfolgt über die Sende-/Empfangseinheiten das Versenden und Empfangen von Daten in Form von Datenpakten bzw. Botschaften. Hierbei werden die zu versendenden Nutzdaten eines Steuergeräts mit Adressierungsdaten wie beispielsweise Botschaftsbezeichner oder Steuergerät-Adresse und mit Zusatzinformationen, wie beispielsweise Länge des Datenstrings, Start und Ende der Botschaft, o.a. in einen definierten Botschaftsrahmen gesetzt und als Datenpaket in dem Botschaftsrahmen versendet, welches vom Empfänger wieder aufgelöst werden muss. Der Kommunikations-Controller sorgt hierbei für die kommunikationsprotokollkonforme Erzeugung, Auflösung und Überprüfung des Bitstroms von und zum Mikro-Controller sowie von und zur Sende-/Empfangseinheit.
  • Das Kommunikationsprotokoll ist unabhängig vom Transportmedium des Datenbusses, also beispielsweise Glasfaserkabel, drahtlose Datenübertragung oder direkte Verdrahtung. Die Umsetzung auf das Transportmedium erfolgt über entsprechend ausgewählte Sende-/Empfangseinheiten, welche direkt am Datenbus angeschlossen sind, wie beispielsweise CAN-(Controller Area Network)-Bustreiber oder FOT (Fibre Optical Transceiver).
  • In aktuell ausgeführten Steuergeräten sind Mikro-Controller und Kommunikations-Controller aus Bauplatzgründen auf einem Chip als getrennte Einheiten zusammengeführt.
  • Der "Cyclic Redundancy Check", auch zyklische Blockprüfung genannt, stellt ein Standardverfahren zur Fehlererkennung in Kommunikationsnetzwerken dar. In der DE 101 05 626 A1 sowie in den darin zitierten Verweisen werden beispielhaft Verfahren zur Berechnung eines Blockprüfungscodes wie beispielsweise Polynomdivision sowie Anwendungen der zyklischen Blockprüfung offenbart.
  • Das Verfahren der zyklischen Blockprüfung besteht für den sendenden Teilnehmer im Erstellen eines Blockprüfungscodes über die zu versendenden Daten und dem Hinzufügen des Blockprüfungscodes an die zu versendenden Daten. Hierbei werden der Blockprüfungscode sowie die Daten mittels derer der Blockprüfungscode erstellt wurde jeweils an einer bestimmten Stelle im Botschaftsrahmen der Botschaft eingestellt, so dass diese beiden Teile vom Empfänger entsprechend erkannt werden können. Der empfangende Teilnehmer trennt aufgrund der Byte-Position den gesendeten Blockprüfungscode von den gesendeten Daten, über die der Blockprüfungscode erstellt wurde. Der empfangende Teilnehmer erstellt selbst einen Blockprüfungscode und vergleicht diesen mit dem Empfangenen. Bei Nicht-Übereinstimmung liegt ein Fehler vor. Vorraussetzung an dem Verfahren ist, dass aufgrund der Bit- bzw. Byte-Position in der Botschaft erkannt werden kann, welcher Teil dem gesendeten Blockprüfungscode bzw. welcher Teil den Daten entspricht, über die der gesendete Blockprüfungscode ermittelt wurde.
  • Die zyklische Blockprüfung wird beispielsweise im CAN-Bus über das entsprechende CAN-Kommunikations-Protokoll eingesetzt. Der CAN-Bus verbindet gleichberechtigte Stationen, wie beispielsweise Steuergeräte, über einen seriellen Bus. Das CRN-Protokoll ist in der ISO 11898 international genormt. Entsprechende Kommunikations-Controller bzw. Bustreiberchips, in dem speziellen Fall auch CAN-Controller genannt, sowie Sende-/Empfangseinheiten, sogenannte CAN-Transceiver, sind von mehreren Herstellern erhältlich.
  • Im CAN-Protokoll werden die Daten in Form von Botschaften mit fest definierten Botschaftsrahmen übertragen. Um Fehler in der Kommunikation zu detektieren, ist im CAN-Protokoll die zyklische Blockprüfung auf Botschaftsebene implementiert. Die zyklische Blockprüfung im CAN-Protokoll sichert die Information des Botschaftsrahmens, indem sendeseitig der CAN-Botschaft redundante Prüfbits hinzugefügt werden. Die Prüfbits entsprechen dem Blockprüfungscode und werden beispielsweise aus einer Polynomdivision über die Bestandteile der CAN-Botschaft gebildet. Empfangsseitig werden diese Prüfbits aus den empfangenen Bits neu berechnet und mit den empfangenen Prüfbits verglichen. Bei Nichtübereinstimmung liegt ein Fehler in der Übertragung der Botschaft von CAN-Controller zu CAN-Controller vor.
  • Die zyklische Blockprüfung im Botschaftsrahmen überprüft die korrekte Versendung der gesamten CAN-Botschaft. Ob der Inhalt der CAN-Botschaft korrekt ist wird nicht überprüft.
  • Damit werden Fehler des Kommunikations-Controllers oder des Mikro-Controllers eines Steuergeräts oder Fehler in der Kommunikation zwischen Mikro-Controller und Kommunikations-Controllers eines Steuergeräts über die zyklische Blockprüfung im Kommunikations-Controller nicht detektiert.
  • Ein Fallszenario für einen derartigen Fehler sieht folgendermaßen aus: Der Mikro-Controller eines Steuergeräts sendet seine Nutzdaten an seinen Kommunikations-Controller zur Versendung weiter. Ein Fehler in der Übermittlung vom Mikro-Controller zum Kommunikations-Controller oder ein defekter Kommunikations-Controller des Steuergeräts verändert die Nutzdaten beim Zusammenstellen der Botschaft, also noch vor der zyklischen Blockprüfung. Die zyklische Blockprüfung wird korrekt mit den veränderten Nutzdaten erstellt und der Botschaft beigefügt. Der Kommunikations-Controller des empfangenden Steuergeräts wird keinen Fehler detektieren, da die zyklische Blockprüfung keine fehlerhaften Daten feststellen kann. Der Mikro-Controller des empfangenden Steuergeräts erhält inkorrekte Nutzdaten, was zu einer Fehlfunktion des empfangenden Steuergeräts führt.
  • Um Fehler in der Übertragung vom Mikro-Controller zum Kommunikations-Controller des Steuergeräts bzw. Fehler im Kommunikations-Controller oder im Mikro-Controller zu detektieren werden heute zyklische Blockprüfungen ebenfalls auf Mikro-Controller-Ebene, also zusätzlich zur zyklischen Blockprüfung auf Kommunikationsprotokoll-Ebene, eingesetzt.
  • Hierzu werden die zu versendenden Nutzdaten von dem Mikro-Controller des sendenden Steuergeräts durch eine zyklische Blockprüfung abgesichert, wobei der Blockprüfungscode zusätzlicher Bestandteil der zu versendenden Nutzdaten wird. Der Mikro-Controller des empfangenden Steuergeräts bildet ebenfalls den zyklische Blockprüfungscode und vergleicht diesen Wert mit dem empfangenen Wert. Ist der selbst gebildete zyklische Blockprüfungscode identisch mit dem Empfangenen, dann war die Übertragung vom Mikro-Controller des sendenden Steuergeräts zum Kommunikations-Controller des sendenden Steuergeräts sowie die Übertragung vom Kommunikations-Controller des empfagenden Steuergeräts zum Mikro-Controller des empfangenden Steuergeräts fehlerfrei. Dass die Übertragung von Kommunikations-Controller zu Kommunikations-Controller fehlerfrei erfolgte, wurde aufgrund der zyklischen Blockprüfung auf Kommunikations-Controller-Ebene ermittelt.
  • Weiter ist beispielsweise aus der DE 101 52 235 A1 ein Verfahren zum Erkennen von Fehlern bei Datenübertragung innerhalb eines CAN-Controllers bekannt. Die Überprüfung mittels eines erzeugten Prüfbits kann nur in der bidirektionalen Datenübertragung zwischen Mikroprozessor und CAN-Controller desselben Steuergeräts erfolgen.
  • Bei dieser Vorgehensweise werden einige Fehler nicht erkannt. Beispielsweise kann es vorkommen, dass die zu versendenden Nutzdaten und die zyklische Blockprüfung seitens des Mikro- Controllers korrekt erstellt und zusammen mit den Adressierungsdaten wie Adresse oder Botschaftsbezeichner zum Senden an den Kommunikations-Controller übergeben wurde. Durch einen Fehler im Kommunikations-Controller werden die Daten im Botschaftsrahmen jedoch inkorrekt zusammengestellt.
  • Im Falle des CAN-Protokolls weist eine CAN-Botschaft im Standard-Format ein "Arbitration Field" (Botschaftskennzeichnungs-Feld) auf. Dieses Feld enthält die Botschaftskennzeichnung bzw. Identifier (ID) zur Kennzeichnung des Botschaftsinhalts. Nun kann beispielswiese verursacht durch einen Bitkipper-Fehler des CAN-Controllers bezogen auf den Identifier die CAN-Botschaft mit einem falschen Identifier versendet werden. Der inkorrekte Identifier kann nicht mittels der zyklischen Blockprüfung des CAN-Controllers ermittelt werden, da der Identfier ja korrekt im CAN-Protokoll übertragen wurde. Der inkorrekte Identfier kann ebenfalls nicht mittels der zyklischen Blockprüfung des Mikro-Controllers ermittelt werden, da diese Prüfung sich auf die versendeten Nutzdaten bezieht. Beide Überprüfungen ergeben also keinen Fehler, so dass die versendeten Nutzdaten der CAN-Botschaft vom empfangenden Steuergerät eingesetzt werden, obwohl die Nutzdaten nicht dem Identifier entsprechen, der vom sendenden Steuergerät vergeben wurde. Dies kann unvorhersehbare Fehlfunktionen im empfangenden Steuergerät auslösen.
  • So können CAN-Botschaften mit falsch gesetzten Identifiern für das unvorgesehene Öffnen der Hecklappe eines Kraftffahrzeugs, falsche Anzeigen und Warnhinweise für den Fahrer usw. verantwortlich sein.
  • Ein ähnliches Problem tritt auf, wenn mehrere CAN-Busse über Gateways zu einem Netzwerk zusammengeschalten sind. Innerhalb des Netzwerks kann es vorkommen, dass ein Identifier mehrfach über die CAN-Busse vergeben ist. Damit steht ein Identifier beispielsweise in einem CAN-Bus für Kilometerstandsdaten, während derselbe Identifier in einem weiteren CAN-Bus Daten des Geschwindigkeitssensors bezeichnet. Sind CAN-Busse, welche dieselben Identifier einsetzen, durch einen Kurzschluß-Fehler miteinander verbunden, kann vom Empfänger nicht erkannt werden, von welchem CAN-Bus eine CAN-Botschaft stammt. Der Empfänger weiss nicht welche Daten einer CAN-Botschaft mit diesem Identifier enthalten sind. Eine Vergabe derselben Identifier auf CAN-Bussen in einem Netzwerk würde also im Falle eines Kurzschlusses zu einem unvorhersehbaren Verhalten führen.
  • Es ist nun die Aufgabe der vorliegenden Erfindung die Fehlererkennung im eingangs beschriebenen Verfahren zu optimieren, um eine sichere Datenübertragung zu gewährleiseten.
  • Diese Aufgabe wird erfindungsgemäß durch die Merkmale des Anspruchs 1 gelöst. Danach wird von dem Mikro-Controller über die Daten, bestehend aus Nutzdaten und korrespondierende Nachrichtenidentifikations- bzw. Adressierungsdaten, ein zusätzlicher Blockprüfungscode mittels einer Blockprüfung ermittelt. Der Blockprüfungscode wird als Bestandteil der Daten an den Kommunikations-Controller übertragen. Der zusätzliche Blockprüfungscode wird vom Mikro-Controller des empfangenden Steuergeräts überprüft.
  • Da die zusätzliche Blockprüfung über die zu versendenden Daten zusammen mit den Adressierungsdaten erfolgt, können Fehler in der Kommunikation zwischen Mikro-Controller und Kommunikations-Controller sowie Fehler im Kommunikations-Controller ermittelt werden. Das empfangende Steuergerät kann den Fehler selbst detektieren. Beispielsweise können mit dem erfindungsgemäßen Verfahren Bitkipper-Fehler im Kommunikations-Controller einfach festgestellt werden.
  • Ein weiterer Vorteil des erfindungsgemäßen Verfahrens ist, dass der zusätzliche Blockprüfungscode Bestandteil der zu versendenden Daten ist, welche an den Kommunikations-Controller übertragen werden. Damit muss zur Anwendung des Verfahrens keine Änderung am Kommunikations-Protokoll und damit am Kommunikations-Controller ausgeführt werden.
  • Da die Nachrichtenidentifikations- bzw. Adressierungsdaten in die Blockprüfung auf Mikro-Controller-Ebene eingebunden sind, kann das empfangende Steuergerät den Absender verifizieren. Damit ist die Information des Datenbus-Protokolls gesichert im Mikro-Controller des empfangenden Steuergeräts angekommen.
  • Die Nachrichtenidentifikationsdatum ist beispielsweise im CAN-Protokoll der Identifier einer Botschaft. Wenn hingegen die Kommunikation in einem Datenbus-Protokoll über die Adressierung des Empfängers ausgeführt wird, ist das Adressierungsdatum beispielsweise im Ethernet-Protokoll eine Netzwerkadresse.
  • Die Erweiterung der in die Blockprüfung eingebunden Adressierungsdaten ist insbesondere im CAN-Protokoll ein Vorteil, da vom Empfänger gesichert festgestellt werden kann von welchem Steuergerät und von welchem Datenbussegment bzw. Netzsegment die Botschaft gesendet wurde.
  • Das erfindungsgemäße Verfahren erlaubt auch Fehler im Mikro-Controller zu detektieren. Beispielsweise kann es im CAN-Protokoll vorkommen, dass der Mikro-Controller in seiner Fehlfunktion falsche Botschaften, wie Botschaften mit definierten Nutzdaten aber undefinierten Identifiern, versendet. Da der Blockprüfungscode, insbesondere bei zyklischer Blockprüfung, vom Mikro-Controller des sendenden Steuergeräts nicht erstellt werden kann, wird der Fehler erkannt.
  • Die Anpassung der Blockprüfungscode-Länge bzw. der zyklischen Blockprüfung an die Restfehlerwahrscheinlichkeit hat den Vorteil, dass auch bei längeren Datenpaketen die Verifizierung durch die zyklische Blockprüfung noch gewährleistet ist.
  • Es gibt nun verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die untergeordneten Ansprüche und andererseits auf die nachfolgende Erläuterung einer Ausführungsform zu verweisen. Es sollen auch die vorteilhaften Ausgestaltungen einbezogen sein, die sich aus einer beliebigen Kombination der Unteransprüche ergeben.
  • Die Figur zeigt in schematischer Darstellung eine Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens.
  • In der Figur ist ein Steuergerät 2 abgebildet, welches einen Mikro-Controller 3 zur Ausführung der Steuergerätefunktion, einen Kommunikations-Controller 4 zur Umsetzung des Kommunikations-Protokolls und eine Sende-/Empfangseinheit 5 zur Anbindung an einen Datenbus 1 aufweist.
  • Der Datenbus 1 ist als CAN-Bus in einem Fahrzeug ausgebildet. Der Datenbus 1 verbindet mehrere Steuergeräte 2 untereinander. Der CAN-Bus 1 ist als serieller Bus ausgebildet, wobei die Busleitung selbst eine symmetrische oder unsymmetrische Zweidrahtleitung ist, die je nach Anforderung geschirmt oder ungeschirmt ausgelegt wird.
  • Das Steuergerät 2 verfügt über einen Mikro-Controller 3 zur Umsetzung der Steuergerätefunktionen. Hierzu weist der Mikro-Controller 3 einen Prozessor und entsprechenden Speicher auf. Sensoren und Aktoren werden ebenfalls als Steuergeräte 2 verstanden. Das Steuergerät 2 ist hier als sogenanntes ESP-(Elektronisches Stabilitäts Programm)-Steuergerät 2 ausgebil det, welches die Fahrstabilität des Fahrzeugs überwacht und bei Bedarf über Signale an die Motorsteuerung, die Bremsanlage etc. steuert.
  • Der Kommunikations-Controller 4 ist als CAN-Controller 4 ausgebildet, auf dem das oben aufgeführte CAN-Protokoll zur protokollkonformen Erzeugung, Auflösung und Überprüfung des Bitstroms von und zum Mikro-Controller 3 sowie von und zur Sende-/Empfangseinheit 5 hardewaremäßig umgesetzt ist.
  • Im CAN-Protokoll werden die Daten in Form von Botschaften mit fest definierten Botschaftsrahmen übertragen. Der CAN-Botschaftsrahmen zur Übertragung von Nachrichten auf dem Bus 1 besteht aus sieben Kennfeldern, welche folgendermaßen aufgebaut sind: Die CAN-Botschaft im Standard-Format beginnt mit dem Startbit "Start of Frame" (Start der Botschaft), dem sich das "Arbitration Field" (Botschaftskennzeichnungs-Feld) anschließt; dieses Feld enthält den Identifier (ID) zur Kennzeichnung des Botschaftsinhalt. Das "Control Field" (Kontrollfeld) enthält die Anzahl der im "Data Field" (Datenfeld) enthaltenen Datenbytes. Dem "Data Field", welches eine Länge von 0 bis 8 Byte aufweisen kann und die zu übertragenden Nutzdaten enthält, folgt das "CRC Field" (Cyclic Redundancy Check-Feld), welches als Rahmensicherung zur Erkennung von Bitfehlern dient. Das "ACK Field" (Empfangsbestätigungs-Feld) enthält ein Bestätigungssignal aller Empfänger, welche die Botschaft fehlerfrei empfangen haben. Mit dem "End of Frame" (Ende der Botschaft) wird das Ende der Botschaft gekennzeichnet.
  • Die Sende-/Empfangseinheit 5 stellt die elektrische Verbindung zwischen Steuergerät 2 und Datenbusleitungen her. Diese elektrische Verbindung erfolgt über Steckkontakte.
  • Die Sende-/Empfangseinheit 5 ist als CAN-Bustreiber 5, auch CAN-Transceiver 5 genannt, ausgebildet und setzt den Logikpegel des CAN-Controllers 4 in einen Busspannungspegel im Gegentaktsignal um. Bei der gewählten differentiellen Zweidrahtübertragung wird aus der Spannungspegeldifferenz auf den Datenbusleitungen das Nutzsignal bestimmt. Hierzu können die Spannungspegel des Signals symmetrisch oder asymmetrisch um einen bestimmten Spannungswert geführt werden.
  • In dem erfindungsgemäßen Verfahren zur sicheren Datenübertragung in Datenbussen 1 eines Verkehrsmittels werden Steuergeräte 2 über einen Datenbus 1 verbunden, Daten werden über den Datenbus 1 mittels eines Datenbus-Protokolls ausgetauscht, Nutzdaten und korrespondierende Adressierungsdaten werden von einem Mikro-Controller 3 eines Steuergeräts 2 zur Versendung bereitgestellt, wobei die Nutzdaten die zu versendenden Daten des Mikro-Controllers 3 ohne Adressierungs- und Protokolldaten darstellen. Diese Daten werden an einen Kommunikations-Controller 4 des Steuergeräts 2 übertragen, wobei die Daten gemäß dem Datenbus-Protokoll vom Kommunikations-Controller 4 bearbeitet werden und mittels einer Sende-/Empfangseinheit 5 des Steuergeräts 2 über den Datenbus 2 versendet werden.
  • Weiter wird von dem Mikro-Controller 3 über die Daten, bestehend aus Nutzdaten und korrespondierende Adressierungsdaten, ein Blockprüfungscode mittels einer zyklische Blockprüfung ermittelt. Der Blockprüfungscode wird als Bestandteil der Daten an den Kommunikations-Controller 4 übertragen und der Blockprüfungscode wird vom Mikro-Controller des empfangenden Steuergeräts überprüft.
  • Das erfindungsgemäße Verfahren ist als Software im Mikro-Controller 3 des Steuergeräts 2 implementiert und führt folgende Schritte aus.
  • Der Mikro-Controller 3 des ESP-Steuergeräts 2 erzeugt Nutzdaten. Die Nutzdaten sind beispielsweise die Anforderung des ESP-Steuergeräts 2 an das Motor-Steuergerät das Motormoment zu erhöhen. Diese Nutzdaten werden in einen Datenstring mit der Länge von sieben Byte bereitgestellt. In der Software des Mikro-Controllers 3 ist hinterlegt mit welchem Identifier diese Botschaft über den CAN-Bus 1 übertragen wird, damit diese als eine solche Anforderung von weiteren Steuergeräten erkannt werden kann. Die Datenlänge des Identifiers beträgt im Standard-Format elf Bits und im erweiterten Format neunundzwanzig Bits. Der Identifier bildet damit die Adressierungsdaten.
  • Die Mikro-Controller-Software führt eine zyklische Blockprüfung über die sieben Bytes Nutzdaten und den ein bis zwei Bytes des Identifiers aus. Die zyklische Blockprüfung wird mittels einer SAE(Society of Automotive Engineers)-Standard, den SAEJ1850 Standard ermittelt. Hierbei wird das Divisionspolynom x8 + x4 + x3 + x2 + 1 eingesetzt. Der resultierende Blockprüfungscode hat eine Länge von acht Bit.
  • Das Datenpaket, welches vom Mikro-Controller 3 zum CAN-Controller 4 übermittelt wird, besteht damit aus den ein bis zwei Byte für den Identifier und dem acht Byte "Data Field", wobei sieben Byte den Nutzdaten und ein Byte dem Blockprüfungscode entsprechen.
  • Dieses Datenpaket wird mittels des gewählten CAN-Protokolls über den CAN-Controller 4 gemäß oben beschriebenen Verfahrens aufbereitet und an die weiteren Steuergeräte übermittelt bzw. aufgrund der Adressierung über den Identifier auf den CAN-Bus 1 gelegt.
  • Der CAN-Controller des empfangenden Steuergeräts übergibt das "Data Field" der Länge acht Byte sowie weitere vom CAN- Protokoll zur Verfügung gestellte Informationen, insbesondere den Identifier, an den Mikro-Controller des empfangenden Steuergeräts weiter.
  • Der Mikro-Controller des empfangenden Steuergeräts separiert aus dem "Data Field" aufgrund der Byte-Position die sieben Byte Nutzdaten und den vom sendenden Steuergerät ermittelten Blockprüfungscode ab. Der Mikro-Controller ermittelt mit derselben zyklischen Blockprüfung, der auch vom sendenden Mikro-Controller 3 eingesetzt wurde, den Blockprüfungscode über die sieben Byte Nutzdaten und den ein bis zwei Bytes des Identifiers. Bei Übereinstimmung liegt kein Fehler vor. Die Nutzdaten sind nicht nur korrekt übermittelt, sondern sie besitzen auch noch den korrekten Absender bzw. Identifier.
  • Ist der vom empfangenden Steuergerät gebildete Blockprüfungscode identisch mit dem Empfangenen, dann war die Übertragung vom Mikro-Controller 3 des sendenden Steuergeräts zum CAN-Controller des sendenden Steuergeräts 2 sowie die Übertragung vom CAN-Controller des empfagenden Steuergeräts zum Mikro-Controller des empfangenden Steuergeräts fehlerfrei. Dass die Übertragung von CAN-Controller 4 zu CAN-Controller fehlerfrei erfolgt, wird über das "CRC-Field" des Botschaftsrahmens mittels des CAN-Protokolls, also über die gesamte Botschaft, überprüft.
  • Das erfindungsgemäße Verfahren kann noch erweitert werden, indem eine Steuergeräte-Identifikation sowie eine Datenbus-Identifikation zur zyklischen Blockprüfung auf Mikro-Controller-Ebene hinzugezogen wird. Hierbei werden also die Adressierungsdaten um Steuergeräte- und/oder Datenbus-Identifikation erweitert. Diese Zusatzinformationen stehen auch dem empfangenden Steuergerät bei der Überprüfung zur Verfügung.
  • Hierzu ist im erfindungsgemäßen Verfahren der Mikro-Controller-Software eine Kommunikationsmatrix bekannt gemacht worden, in der abgelegt ist, welche Steuergeräte-Identifikation welche Identifier versenden darf. Damit wird sichergestellt, dass der Absender der Daten mit einem bestimmten Identifier dem in der Kommunikationsmatrix hinterlegten Absender entspricht. Dies hat den Vorteil, dass das empfagende Steuergerät sobald Identifier mehrfach vergeben sind oder Identifier falsch gesetzt sind, die Daten selbsttätig prüfen kann. Die Kommunikationsmatrix ist in der Mikro-Controller-Software jedes Datenbusteilnehmers nicht veränderbar im Programm abgelegt.
  • Sind mehrere Datenbusse über ein Gateway miteinander verbunden, liegt ein Netzwerk vor, welches aus mehreren Netzsegment besteht. In diesem Fall ist die Kommunikationsmatrix für jeden Datenbus bzw. jedes Datenbussegment individuell erstellt und mit einer Datenbus-Identifikation für den entsprechenden Datenbus bzw. das entsprechende Datenbussegment versehen. Die Datenbusse bzw. Datenbussegmente sind physikalisch über ein Gateway getrennt und werden unabhängig voneinander betrieben. Eine Kommunikationsmatrix in einem Netzwerk, wobei das Netzwerk aus mehreren Netzsegmenten besteht, verfügt damit über eine Netzsegment-Identifikation.
  • Die Adressierungsdaten welche zur zyklischen Blockprüfung einbezogen werden, müssen an das jeweilige Protokoll angepasst sein. Bei Ethernet-Protokollen wäre dies beispielsweise die Ethernet-Adresse des sendenden und/oder des empfangenden Teilnehmers.
  • Die zyklische Blockprüfung muss an die Länge der zu versendenden Datenblöcke anpasst werden. Die Größe des Blockprüfungscodes ist abhängig von der Anwendung der maximal zulässigen Restfehlerwahrscheinlichkeit, welche ensteht sobald die zu prüfende Datenlänge die Länge des Blockprüfungscodes überschreitet. Die Restfehlerwahrscheinlichkeit eines acht Bit Blockprüfungscodes ist Null solange die Blocklänge kleiner gleich acht Bit ist. Bei größeren Datenlängen würde man beispielsweise einen 32-Bit Blockprüfungscode einsetzen.
  • Nicht dargestellte weiteren Anwendungen des erfindungsgemäßen Verfahrens schließen Kommunikationsverfahren in Netzwerken ein, bei denen weitere Transportmedien zum Einsatz kommen. Damit ist das Verfahren auch anwendbar auf Protokolle wie MOST, FlexRay, TTP, USB, Ethernet usw. Für das Bussystem bzw. für das Busprotokoll unerheblich, mit welchem Medium das Protokoll übertragen wird, da die Umsetzung der Logiksignale des Kommunikations-Controllers 4 auf das Busmedium 1 über die entsprechend angepassten Sende-/Empfangseinheit 5 erfolgt.
  • Das erfindungsgemäße Verfahren kann unabhängig davon eingesetzt werden, ob der Mikro-Controller 3 und der Kommunikations-Controller 4 als Einheiten auf einem Baustein, beispielsweise einem Chip, oder verschiedenen in beliebiger Art verbundenen Bausteinen ausgeführt ist. Ebenso kann das erfindungsgemäße Verfahren eingesetzt werden, wenn der Kommunikations-Controller 4 nicht als Hardware-Logikschaltung ausgebildet ist, sondern zur Erfüllung seiner Funktionen einen Prozessor und entsprechenden Speicher aufweist.
  • Der Blockprüfungscode muss nicht über eine zyklische Blockprüfung ermittelt werden. Vielmehr kann der Blockprüfungscode von Daten beispielsweise mittels einer Prüfsumme über die Daten bestimmt werden. Für ein Datenfeld der Länge sieben Byte kann eine einfache 8-Bit Prüfsumme eingesetzt werden, in der die sieben Byte Daten addiert werden und nur die niederwertigsten acht Bit betrachtet werden.
    • 1
    Datenbus
    2
    Steuergerät
    3
    Mikro-Controller
    4
    Kommunikations-Controller
    5
    Sende-/Empfangseinheit

Claims (6)

  1. Verfahren – zur Datenübertragung in einem Datenbus (1) eines Verkehrsmittels, wobei – Steuergeräte (2) über einen Datenbus (1) verbunden sind, – Daten über den Datenbus (1) entsprechend eines Datenbus-Protokolls ausgetauscht werden, – Nutzdaten und korrespondierende Nachrichtenidentifikations- oder Adressierungsdaten von einem Mikro-Controller (3) eines Steuergeräts (2) zur Versendung bereitgestellt werden, – die Daten gemäß dem Datenbus-Protokoll von einem Kommunikations-Controller (4) unter Verwendung eines Blockprüfungscodes bearbeitet kodiert werden und – mittels einer Sende-/Empfangseinheit (5) des Steuergeräts (2) über den Datenbus (1) versendet werden, dadurch gekennzeichnet, dass – zusätzlich zum Blockprüfungscode des Kommunikations-Controllers (4) ein Blockprüfungscode mittels einer Blockprüfung über die Daten, bestehend aus Nutzdaten und korrespondierende Nachrichtenidentifikations- bzw. Adressierungsdaten von dem Mikro-Controller (3) des sendenden Steuergeräts (2) ermittelt wird und – der zusätzliche Blockprüfungscode vom Mikro-Controller des empfangenden Steuergeräts überprüft wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass – die Nutzdaten in einem Datenfeld bestimmter Länge vom Mikro-Controller (3) bereitgestellt werden und – der zusätzliche Blockprüfungscode Bestandteil dieses Datenfeldes ist.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass – der zusätzliche Blockprüfungscode eine Datenlänge von acht Bit aufweist und – der Blockprüfungscode im achten Byte des Datenfeldes der Nutzdaten positioniert ist.
  4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Berechnung des zusätzlichen Blockprüfungscodes und der Blockprüfungscode an die Datenlänge der Nutzdaten in Abhängigkeit der Restfehlerwahrscheinlichkeit angepasst wird.
  5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Nachrichtenidentifikations- bzw. Adressierungsdaten – an das Datenbus-Protokoll angepasst werden, – Steuergeräte-Identifikation und/oder – Datenbus-Identifikation aufweisen.
  6. Verfahren nach Anspruch 1 bis 5, dadurch gekennzeichnet, dass eine Kommunikationsmatrix erstellt und in dem Mikro-Controller (3) des am Datenbus angebundenen Steuergeräts zur Verfügung gestellt wird, welche die Adressierungsdaten der am Datenbus (1) angebundenen Steuergeräte (2) aufweist.
DE2002143319 2002-09-18 2002-09-18 Sichere Datenübertragung Expired - Fee Related DE10243319B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2002143319 DE10243319B4 (de) 2002-09-18 2002-09-18 Sichere Datenübertragung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2002143319 DE10243319B4 (de) 2002-09-18 2002-09-18 Sichere Datenübertragung

Publications (2)

Publication Number Publication Date
DE10243319A1 DE10243319A1 (de) 2004-04-01
DE10243319B4 true DE10243319B4 (de) 2004-08-12

Family

ID=31969203

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002143319 Expired - Fee Related DE10243319B4 (de) 2002-09-18 2002-09-18 Sichere Datenübertragung

Country Status (1)

Country Link
DE (1) DE10243319B4 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006014453A1 (de) * 2006-03-29 2007-10-04 Volkswagen Ag Eingebettetes System und Verfahren zum Betreiben eines eingebetteten Systems mit verbesserter Kennzeichnung von fehlerhaften ausgetauschten Signalen
DE102007056318A1 (de) * 2007-04-12 2008-10-16 Deere & Company, Moline Kommunikationssystem eines Fahrzeugs und Verfahren zum Betreiben eines Kommunikationssystems
DE102008000810B4 (de) 2008-03-26 2018-06-21 Robert Bosch Gmbh Steuergerät und Verfahren zur Ansteuerung von Personenschutzmitteln für ein Fahrzeug
DE102021200411A1 (de) 2021-01-18 2022-07-21 Robert Bosch Gesellschaft mit beschränkter Haftung Bussystem mit Fehlererkennungsfunktion

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69121051T2 (de) * 1990-10-30 1997-02-06 Renault Adressenerkennungsvorrichtung für elektronischen Datenverarbeitungsmodul
DE19739808A1 (de) * 1997-09-10 1999-03-11 Siemens Ag Verfahren und Vorrichtung zur Steuerung der Datenübertragung zwischen zwei in einem Kraftfahrzeug vorhandenen Modulen
EP1002699A2 (de) * 1998-11-18 2000-05-24 Fuji Jukogyo Kabushiki Kaisha Überwachungsvorrichtung für ein Kraftfahrzeugsteuerungssystem
EP1006024A2 (de) * 1998-11-30 2000-06-07 DaimlerChrysler Corporation Kommunikationssystem
DE10006206A1 (de) * 2000-02-11 2001-08-30 Daimler Chrysler Ag Elektronisches Steuersystem
DE10105626A1 (de) * 2000-03-07 2001-09-27 Ibm Berechnung von M CRC-Bits zu einem zeitpunktfür Daten mit einer Bitlänge, die kein Vielfaches von M beträgt
DE10146161A1 (de) * 2000-09-19 2002-04-04 Mitsubishi Motors Corp Fehlerdiagnosevorrichtung und Fehlerdiagnoseverfahren für elektronisches Fahrzeugsteuerungssystem
DE10152235A1 (de) * 2001-10-20 2003-04-30 Bosch Gmbh Robert Verfahren zum Erkennen von Fehlern bei der Datenübertragung innerhalb eines CAN-Controllers und ein CAN-Controller zur Durchführung dieses Verfahrens

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69121051T2 (de) * 1990-10-30 1997-02-06 Renault Adressenerkennungsvorrichtung für elektronischen Datenverarbeitungsmodul
DE19739808A1 (de) * 1997-09-10 1999-03-11 Siemens Ag Verfahren und Vorrichtung zur Steuerung der Datenübertragung zwischen zwei in einem Kraftfahrzeug vorhandenen Modulen
EP1002699A2 (de) * 1998-11-18 2000-05-24 Fuji Jukogyo Kabushiki Kaisha Überwachungsvorrichtung für ein Kraftfahrzeugsteuerungssystem
EP1006024A2 (de) * 1998-11-30 2000-06-07 DaimlerChrysler Corporation Kommunikationssystem
DE10006206A1 (de) * 2000-02-11 2001-08-30 Daimler Chrysler Ag Elektronisches Steuersystem
DE10105626A1 (de) * 2000-03-07 2001-09-27 Ibm Berechnung von M CRC-Bits zu einem zeitpunktfür Daten mit einer Bitlänge, die kein Vielfaches von M beträgt
DE10146161A1 (de) * 2000-09-19 2002-04-04 Mitsubishi Motors Corp Fehlerdiagnosevorrichtung und Fehlerdiagnoseverfahren für elektronisches Fahrzeugsteuerungssystem
DE10152235A1 (de) * 2001-10-20 2003-04-30 Bosch Gmbh Robert Verfahren zum Erkennen von Fehlern bei der Datenübertragung innerhalb eines CAN-Controllers und ein CAN-Controller zur Durchführung dieses Verfahrens

Also Published As

Publication number Publication date
DE10243319A1 (de) 2004-04-01

Similar Documents

Publication Publication Date Title
DE69433882T2 (de) Vorrichtung zur Übertragung von Daten
DE102017211860B3 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
EP2160857B1 (de) Prüfverfahren und elektronische schaltung zur sicheren seriellen übertragung von daten
DE102012101747B4 (de) Zuverlässige datenübertragung mit verringerter bit-fehlerrate
EP3977682B1 (de) Fehlererkennung-testeinrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zum testen von mechanismen zur fehlererkennung bei einer kommunikation in einem seriellen bussystem
EP3189629A1 (de) Verfahren zur seriellen übertragung eines rahmens über ein bussystem von einem sender zu mindestens einem empfänger und teilnehmerstation für ein bussystem
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102007016917A1 (de) Verfahren sowie System zur sicheren Übertragung von zyklischen zu übertragenden Prozessdaten
EP3977683B1 (de) Einrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
WO2020126756A1 (de) Einrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
EP1548986B1 (de) Bussystem für ein Flugzeug
EP3725041B1 (de) Verfahren zur bereitstellung von informationen für die lokalisierung von fehlern in einem kommunikationsnetzwerk eines gerätes, entsprechend ausgelegte busteilnehmerstation sowie fahrzeug
DE10243319B4 (de) Sichere Datenübertragung
DE102010028485B4 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102012110712B4 (de) Verfahren und System zur Funktionsprüfung einer Fehlererkennungseinheit einer CAN-Bus-Controllereinheit
DE102016216700B4 (de) Verfahren zum Identifizieren einer defekten Fahrzeugkomponente in einem Kraftfahrzeug sowie Kraftfahrzeug mit über ein Kommunikationsnetzwerk gekoppelten Fahrzeugkomponenten
DE102021127310B4 (de) System und Verfahren zur Datenübertragung
DE102005059021B4 (de) Eingebettetes System und Verfahren zum Betreiben eines eingebetteten Systems mit verbesserter Kennzeichnung von fehlerhaften ausgetauschten Signalen
DE102020212452B3 (de) Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
DE10252109B4 (de) Verfahren zur Parametrierung
EP3987697B1 (de) Verfahren zum betreiben eines kommunikationsnetzwerks, kommunikationsnetzwerk und teilnehmer für ein kommunikationsnetzwerk
EP1515237B1 (de) Schnittstelle für ein UART-basiertes Bussystem
EP1523119B1 (de) Verfahren und eine Vorrichtung zur fehlerabgesicherten Übertragung von Nutzdaten
DE102013204891A1 (de) Verfahren zur Rekonstruktion von Messdaten
DE102006014453A1 (de) Eingebettetes System und Verfahren zum Betreiben eines eingebetteten Systems mit verbesserter Kennzeichnung von fehlerhaften ausgetauschten Signalen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE

8327 Change in the person/name/address of the patent owner

Owner name: DAIMLER AG, 70327 STUTTGART, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee