DE102016214279A1 - Verfahren und Vorrichtung zum Betreiben eines Bussystems - Google Patents

Verfahren und Vorrichtung zum Betreiben eines Bussystems Download PDF

Info

Publication number
DE102016214279A1
DE102016214279A1 DE102016214279.8A DE102016214279A DE102016214279A1 DE 102016214279 A1 DE102016214279 A1 DE 102016214279A1 DE 102016214279 A DE102016214279 A DE 102016214279A DE 102016214279 A1 DE102016214279 A1 DE 102016214279A1
Authority
DE
Germany
Prior art keywords
sending
messages
subscriber
bus system
query
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.)
Pending
Application number
DE102016214279.8A
Other languages
English (en)
Inventor
Joachim Steinmetz
Antonio La Marca
Liem Dang
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 DE102016214279.8A priority Critical patent/DE102016214279A1/de
Priority to US15/661,144 priority patent/US10185682B2/en
Publication of DE102016214279A1 publication Critical patent/DE102016214279A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/325—Power saving in peripheral device
    • G06F1/3253—Power saving in bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3287—Power saving characterised by the action undertaken by switching off individual functional units in the computer system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Verfahren zum Betreiben eines Bussystems (10) insbesondere eines Kraftfahrzeugs, bei dem Nachrichten des Bussystems (10) empfangen werden und abhängig von diesen Nachrichten darauf erkannt wird, ob ein diese Nachrichten absendender Teilnehmer (4) des Bussystems (10) ein sich anmeldender Teilnehmer (4) des Bussystems (10) ist.

Description

  • Die Erfindung betrifft ein Verfahren zum Betreiben eines Bussystems, ein Computerprogramm und eine Steuer und-/oder Regeleinrichtung zur Durchführung des Verfahrens sowie ein maschinenlesbares Speichermedium, auf dem das Computerprogramm gespeichert ist.
  • Stand der Technik
  • In der DE 10 2009 026 995 A1 ist ein Verfahren zum Betreiben eines Bussystems, insbesondere eines CAN-Busses, beschrieben. An das Bussystem sind mehrere Stationen anschließbar. Eine übertragene Nachricht weist einen Identifier auf, wobei ein bestimmter Identifier (z.B. IDENT2) immer nur von einer einzigen Station verwendet werden darf. Jede der Stationen vergleicht den Identifier einer übertragenen Nachricht mit den von ihr selbst verwendeten Identifiern (z.B. IDENT2). Bei einer Übereinstimmung wird eine Fehlermeldung erzeugt wird.
  • Vorteile der Erfindung
  • Durch die Vernetzung des IoT (Internet-of-Things) halten immer mehr internetbasierte Dienstleistungen Einzug in Kraftfahrzeuge. Häufig sind die genutzten Dienstleistungen auf die Sammlung von kraftfahrzeuginternen Daten des Fahrers angewiesen.
  • Dazu gibt es sogenannte OBD-Dongles, die an eine OBD-Schnittstelle des Fahrzeugs angeschlossen und mittels drahtloser Kommunikation (z.B. Bluetooth, WiFi) z.B. durch ein Smartphone indirekt oder direkt an die Cloud angebunden werden können und permanent fahrerspezifische Daten wie z.B. Geschwindigkeit, Drehzahl, GPS-Koordinaten etc. zur weiteren Verarbeitung in eine Cloud verschicken.
  • Zur zyklischen Abfrage der Daten können standardisierte Diagnose-Services, wie z.B. OBD-Services oder Kraftfahrzeughersteller-spezifische Diagnose-Services (UDS) genutzt werden.
  • Die Nutzung solcher Dienstleistungen birgt die Gefahr, dass entsprechende Daten ungewollt oder unwissentlich abgefragt werden, da vom Fahrer selbst kaum verifiziert werden kann welche Daten und in welchem Zyklus diese Daten abgegriffen werden.
  • Das Verfahren mit den Merkmalen des unabhängigen Anspruch 1 hat den Vorteil, dass irreguläre Datenabfragen im Netzwerk – und somit eine aktive Datenerfassungseinheit – erkannt und dessen Ausführung bzw. Abfragen gezielt automatisiert blockiert bzw. gestört werden können.
  • Ein Vorteil der Erfindung ist daher die Erhöhung des Datenschutzes gegenüber Abfragen in das Netzwerk durch direkte oder indirekte angeschlossene Datenerfassungseinheiten. Das Verfahren kann an einer beliebigen Stelle in einem Netzwerk z.B. als integrierter Bestandteil eines oder mehreren Steuergeräte, eines Gateways oder auch in Connectivity-Einheiten, welche z.B. via OBD-Stecker nachträglich an das Kraftfahrzeugnetzwerk angebunden werden können (Connectivity Control Unit – CCU), angewandt werden.
  • Aus datenschutzrechtlicher Sicht kann mit der Erfindung ein Verfahren eingeführt werden, welches es ermöglicht, ungewollte Datenabfragen zu erkennen und die Datenerfassung zu blockieren bzw. zu stören. Damit wird bei der Nutzung internetbasierter Dienstleistungen dem Recht auf informationelle Selbstbestimmung Rechnung getragen.
  • Offenbarung der Erfindung
  • In einem ersten Aspekt ist daher ein Verfahren zum Betreiben eines Bussystems insbesondere eines Kraftfahrzeugs vorgesehen, bei dem Nachrichten (der Term „Nachrichten“ wird im Folgenden synonym mit „Botschaften“ verwendet), insbesondere eine Mehrzahl von Nachrichten, des Bussystems, also Nachrichten, die über das Bussystem verschickt werden, d.h. von einem Teilnehmer des Bussystems über Verbindungen des Bussystems an mindestens einen anderen Teilnehmer des Bussystems übermittelt und von dem anderen Teilnehmer empfangen werden und abhängig von diesen Nachrichten, also insbesondere abhängig von den Inhalten dieser Nachrichten, darauf erkannt wird, ob ein diese Nachrichten absendender Teilnehmer des Bussystems ein sich anmeldender Teilnehmer des Bussystems ist.
  • Dabei kann insbesondere abhängig von diesen Nachrichten auch darauf erkannt werden, ob der absendende Teilnehmer ein neuer Teilnehmer des Bussystems ist. Ein neuer Teilnehmer kann insbesondere ein Teilnehmer sein, der vor dem Start des Verfahrens nicht als Teilnehmer identifiziert war. Es kann auch ein Teilnehmer sein, der vor einem letztmaligen Start eines Motors des Kraftfahrzeugs nicht als Teilnehmer identifiziert war.
  • Die Erkennung kann insbesondere mittels einer Überwachung aller oder nur eines Teils der Botschaften im Bussystem erfolgen. Insbesondere können solche Botschaften überwacht werden (d.h. die Erkennung erfolgt (insbesondere nur) abhängig von solchen Botschaften), die einem solchen Diagnose-Service entsprechen, der zur Abfrage von Datenwerten (z.B. historische Fahrtdaten, Fehlerspeichereinträge auslesen, aktuelle Werte wie z.B. Geschwindigkeit, Drehzahl etc.) dient. Ein solches Verfahren ist besonders effizient und einfach.
  • Ferner ist es u.U. möglich, dass mit einer einzelnen Botschaft oder einer einzelnen Sequenz (zyklisch auftauchende) irreguläre Datenabfrage nicht zuverlässig genug erkannt werden können. Daher ist es möglich, die Botschaften in einem Zwischenspeicher, ggf. inkl. Metainformationen, zu puffern. Somit ist es verbessert möglich, zyklisch auftauchenden Sequenzen bei der Prüfung von irregulären Datenabfragesequenzen oder einer Datenerfassungseinheit zu erkennen. Andere im Netzwerk als relevante Parameter definierte Botschaften können ebenfalls in diesem Pufferspeicher für die Erkennung gespeichert werden. Der Puffer kann wieder geleert werden, z.B. durch eine Implementierung als FIFO-Speicher oder über eine Überwachung von Zeitstempeln der Botschaften.
  • Somit kann geprüft werden, ob ein bestimmtes, sich regelmäßig wiederholendes Muster entsprechender Datenabfrage-Botschaften festgestellt werden kann.
  • Die Erkennung einer Datenerfassungseinheit als sich neu anmeldender und/oder neuer Teilnehmer des Bussystems basiert auf der Idee, die Initialisierungsphase dieses Teilnehmers, z.B. eines OBD-Dongles oder einer mittels eines OBD-Dongles angebunden Software (z.B. auf dem Smartphone) zu erkennen. Werden während der Initialisierungsphase, z.B. bei Start der Software oder beim Aktivieren des Klemme-15-Signals im Kraftfahrzeug (d.h. bei Anschalten der Zündung), bestimmte Parameter wie z.B. „VIN“, „PID-Supported“ zur Verifizierung und Kraftfahrzeugerkennung in einer für den Teilnehmer charakteristischen Abfolge im Netzwerk des Bussystems abgefragt. Diese spezifische Initialisierungssequenz des Teilnehmers kann mittels Überwachung des Bussystems als „Signatur“-Sequenz erkannt werden.
  • In einem weiteren Aspekt kann vorgesehen sein, dass abhängig vom Ergebnis des Erkennens Maßnahmen eingeleitet werden, um den absendenden Teilnehmer zu deaktivieren. Ein solches Vorgehen ist (gegenüber anderen Möglichkeiten wie beispielsweise einem Unterdrücken einer spezifischen Anfrage des absendenden Teilnehmers) besonders sicher, da auch zukünftige potenzielle Anfragen besonders zuverlässig unterbunden werden können.
  • Die Maßnahmen können insbesondere umfassen, eine Stromversorgung des absenden Teilnehmers zu deaktivieren. Insbesondere kann vorgesehen sein, eine Stromversorgung der OBD-Schnittstelle des Bussystems zu deaktivieren. Ein solches Verfahren ist eine besonders einfache sichere Variante, den absendenden Teilnehmer zu deaktivieren.
  • Alternativ oder zusätzlich können die Maßnahmen umfassen, Selbstaschaltnachrichten, insbesondere über das Bussystem an den absenden Teilnehmer zu schicken, die den absendenden Teilnehmer dazu veranlassen, sich zumindest teilweise zu deaktivieren, sich also beispielsweise abzuschalten oder in einen inaktiven oder reduziert aktiven Zustand überzugehen. Dieses Vorgehen ist besonders einfach, da es auf bereits vorhandene Funktionalitäten zurückgreift.
  • Beispielsweise kann vorgesehen sein, den absendenden Teilnehmer dazu zu veranlassen, in einen Stand-by-Modus zu gehen. Ist der absendende Teilnehmer ein Dongle, kann beispielsweise vorgesehen sein, ihn über seine WiFi- oder Bluetooth-Schnittstelle zu veranlassen, sich abzuschalten.
  • Insbesondere kann hier vorgesehen sein, dass die Selbstabschaltnachrichten Nachrichten umfassen, welche dem absendenden Teilnehmer die Information übermitteln, dass das Kraftfahrzeug einen vorgebbaren Zustand einnimmt. Der vorgebbare Zustand kann insbesondere umfassen, dass das Kraftfahrzeug steht und/oder dass eine Brennkraftmaschine des Kraftfahrzeugs ausgeschaltet ist und/oder dass ein Start-Stopp-Betriebsmodus aktiv ist und/oder dass die Brennkraftmaschine im Leerlauf betrieben wird. Dies nutzt aus, dass bei Datenerfassungseinheiten teilweise das Energiemanagement bzw. die Zustandserkennung des implementierten Automaten darauf ausgelegt ist, dass sich diese selbst ausschalten oder in einen entsprechenden inaktiven Zustand versetzen, falls innerhalb einer entsprechenden Zeitspanne bestimmte Abfragedaten, wie z.B. Drehzahl und Geschwindigkeit, suggerieren, dass das Kraftfahrzeug steht und/oder aus ist. Dies kann daher als Abwehrmaßnahme genutzt werden, indem Antworten mit gezielten Daten für die abgefragten Werte verschickt werden, die eine stehende und/oder ausgeschaltete Brennkraftmaschine suggerieren.
  • Es ist ferner möglich, festzustellen, ob die Abwehrmaßnahme erfolgreich war. Dazu kann geprüft werden, ob die zuvor erkannte Datenabfragesequenz weiterhin verschickt bzw. im Bussystem erkannt wird. Ist dies der Fall, kann die Erkennungseinheit nach einer gewissen Zeitspanne bzw. nach einigen erfolglos durchgeführten Abwehrzyklen weitere Abwehrmaßnahmen durchführen.
  • Alternativ oder zusätzlich ist es auch möglich, dass die Selbstabschaltnachrichten Nachrichten umfassen, welche dem absendenden Teilnehmer die Information übermitteln, dass eine Abfrage bestimmter Datenangaben von Teilnehmern des Bussystems nicht unterstützt wird. Dies kann insbesondere geschehen, wenn die empfangene Nachricht eine Abfrage enthält, ob die Abfrage dieser Datenangaben unterstützt wird. Falls diese Abfrage über die OBD-Schnittstelle erfolgt, kann dies beispielsweise dadurch geschehen, indem falsche „PID-Supported“-Werte, insbesondere während der Initialisierungsphase des Teilnehmers versendet werden. Es ist auch möglich, dass dem Teilnehmer mitgeteilt wird, dass bestimmte Werte wie z.B. Drehzahl, Geschwindigkeit, etc. nicht unterstützt werden. Hier liegt die Erkenntnis zugrunde, dass je nach Implementierung des absendenden Teilnehmers diese Daten dann nicht weiter abgefragt werden. Dieses Verfahren neutralisiert die Gefährdung durch den absendenden Teilnehmer besonders wirkungsvoll, ohne anderweitig die Funktionsweise des absendenden Teilnehmers zu beeinträchtigen.
  • Alternativ oder zusätzlich ist es im Falle, dass der absendende Teilnehmer einen Wert mittels UDS übermittelt hat, möglich, eine negative-Response Nachricht mit einem entsprechenden Response-Code an den absendenden Teilnehmer zu schicken. So lässt sich dem Teilnehmer der Eindruck vortäuschen, dass die Abfrage nicht unterstützt wird oder seine Abfrage fehlerhaft war, was dazu führen kann, dass der absendende Teilnehmer seine Abfrageaktivitäten einstellt.
  • Alternativ oder zusätzlich kann neben der Erkennung des absendenden Teilnehmers als sich anmeldendem Teilnehmer überprüft werden, ob der absendende Teilnehmer eine Datenabfrage durchgeführt hat, wobei dann, wenn diese Datenabfrage erkannt wurde, eine korrekte Antwort auf die Datenabfrage unterbunden wird. Dieses Verfahren ist besonders zielgerichtet und verhindert eine weitere Beeinträchtigung des Systems.
  • Dies kann beispielsweise dadurch besonders effektiv geschehen, dass das Unterbinden umfasst, eine tatsächliche Antwort des erkannten Adressaten zu unterbinden, d.h. zu verhindern, dass der erkannte Adressat eine Antwort an den absendenden Teilnehmer übermittelt.
  • Dies ist insbesondere dann möglich wenn das beschriebene Verfahren von dem Teilnehmer (nachfolgend „Zielteilnehmer“), insbesondere dem Steuergerät (nachfolgend „Zielsteuergerät“), durchgeführt wird welches ohne das Unterbinden eine Antwort auf die Datenabfrage liefern würde. Wird das beschriebene Verfahren auf einem zentralen Steuergerät (einem sogenannten Gateway) durchgeführt, ist es auch möglich die Antworten des Zielteilnehmers zu blockieren. Dieses Vorgehen ist besonders einfach.
  • Es ist ferner möglich, dass das Unterbinden die Maßnahme umfasst, mindestens eine Nachricht an den absendenden Teilnehmer zu übermitteln. Dieses Unterbinden kann insbesondere auch abhängig davon durchgeführt werden, wie hoch eine Frequenz ist, mit der diese Datenabfrage durchgeführt wird. Ein solches Verfahren kann besonders zuverlässig wiederkehrende Abfragen unterbinden.
  • Die übermittelte Nachricht kann insbesondere abhängig von einem erkannten Adressaten der Datenabfrage gewählt werden.
  • Wird eine entsprechende irreguläre Abfragesequenz und/oder eine neue Abfrageeinheit erkannt, lassen sich -Services geschehen, dessen sich der anfragende Teilnehmer zu seiner auf Basis der empfangenen Botschaften mittels der Netzwerk-ID(s) die betroffen Zielsteuergeräte erkennen. Damit lässt sich der Abwehrmechanismus gezielt auslösen.
  • Dies kann dadurch geschehen, dass ein Inhalt der übermittelten Nachricht so ausgestaltet ist, als sei sie eine Antwort des erkannten Adressaten auf die Datenabfrage, insbesondere die übermittelte Nachricht eine unkorrekte Antwort auf die Datenabfrage umfasst.
  • Im Falle einer erkannten irregulären Datenabfrage kann vorgesehen sein, mittels der Response-Adressierung des betroffenen Zielsteuergeräts eine gültige Antwortnachricht mit nicht plausiblen, falschen Werten für die abgefragten Daten zu übermitteln. Dies kann z.B. eine falsche Fahrzeuggeschwindigkeit etc. sein. Dies kann unter Verwendung der Diagnoseanfrage bedient, z.B. OBD oder ein Kraftfahrzeugersteller-spezifischer Diagnose-Service, z.B. mittels UDS. Zudem kann auf Basis der erkannten Abfragefrequenz bzw. des erkannten Abfragezyklus ermittelt werden, wann der Abwehrmechanismus jeweils ausgelöst werden muss. Alternativ oder zusätzlich besteht unter anderem darin die nicht plausiblen Daten in einer höheren Frequenz als die bekannte Abfragesequenz zu verschicken, um die plausiblen Antworten des betroffenen Zielsteuergeräts zu unterdrücken. Dies ist eine besonders wirksame Unterdrückungsmaßnahme.
  • Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beiliegende Zeichnung näher erläutert. In der Zeichnung zeigen:
  • 1 schematisch ein Netzwerk, in dem das erfindungsgemäße Verfahren zum Einsatz kommen kann;
  • 2 einen Ablaufplan des Verfahrens gemäß eines Aspekts der Erfindung.
  • 1 zeigt beispielhaft ein Netzwerk mit einem Bussystem 10, beispielsweise in einem Kraftfahrzeug, über das Teilnehmer 1, 2, 4 kommunizieren. Teilnehmer 1 kann ein Steuergerät sein, oder beispielsweise auch ein Sensor. Teilnehmer 2 ist ein Steuergerät, auf dem im Ausführungsbeispiel die Erfindung implementiert ist. Teilnehmer 4 ist ein OBD-Dongle, der über die OBD-Schnittstelle 3 an das Bussystem 10 angebunden ist.
  • Nach dem Anschließen an die OBD-Schnittstelle 3 sendet der OBD-Dongle Anfragen an einige oder alle der Teilnehmer 1, 2 des Datenbusses, um sich zu initialisieren und zu erfragen, welche Datenabfragen möglich sind. Teilnehmer 2 empfängt diese Abfragen, und kann somit identifizieren, dass Teilnehmer 4 ein neuer Teilnehmer im Bussystem 10 ist. In einem typischen Szenario versucht Teilnehmer 4, durch Datenabfragen an Teilnehmer 1 Daten abzufragen, z.B. über den Zustand des Kraftfahrzeugs. Im Normalfall würde Teilnehmer 1 Teilnehmer 4 Antworten auf diese Abfragen zuschicken. Teilnehmer 2 empfängt ebenfalls die Nachrichten, die an Teilnehmer 1 adressiert sind, und kann auf Basis dieser Nachrichten wie beschrieben Gegenmaßnahmen treffen.
  • 2 zeigt den Ablauf eines Verfahrens, das in dem in 1 illustrierten Ausführungsbeispiel auf Teilnehmer 2 ablaufen kann. Das Verfahren beginnt mit Schritt 1000.
  • Im nachfolgenden Schritt 1010 empfängt Teilnehmer 2 Nachrichten, die über das Bussystem 10 verschickt werden, und speichert diese beispielsweise je absendendem Teilnehmer in einem FIFO-Buffer, um Sequenzen von Nachrichten zu analysieren.
  • Im nachfolgenden Schritt 1020, indem überprüft wird, ob sich aus den empfangenen Nachrichten ergibt, dass ein neuer Teilnehmer im Bussystem 10 angemeldet ist. Im Beispiel von 1 sendet Teilnehmer 4 beispielsweise unmittelbar nach dem Anschließen an die OBD-Schnittstelle 3 eine für seine Initialisierung charakteristische Sequenz von Nachrichten, die von Teilnehmer 2 empfangen werden, sodass Teilnehmer 2 identifiziert werden kann. Ist dies der Fall („j“), folgt Schritt 1050, andernfalls („n“) folgt Schritt 1030, in dem optional die gespeicherten Nachrichten inklusive Metainformationen in einem weiteren Zwischenspeicher abgelegt werden. Nach Schritt 1030 verzweigt das Programm zurück zu Schritt 1010.
  • In Schritt 1050 wird überprüft, ob unter den empfangenen Nachrichten unerwünschte Datenabfragen sind. Dies kann beispielsweise durch eine Analyse des Inhalts der Nachrichten geschehen, indem z.B. extrahiert wird, welche Daten abgefragt werden. Ob diese Abfrage unerwünscht ist, oder nicht, kann beispielsweise durch Vergleich dieser abgefragten Daten (oder Sequenz dieser abgefragten Daten) mit Einträgen einer vorgebbaren Liste erfolgen. Im Ausführungsbeispiel sind in der Liste solche Einträge hinterlegt, deren Abfrage unerwünscht ist. Wird erkannt, dass die abgefragten Daten als Einträge in dieser Liste hinterlegt sind („j“), folgt Schritt 1090, andernfalls („n“) folgt Schritt 1060.
  • In Schritt 1060 erfolgt optional eine weitere Abfrage, ob diese abgefragten Daten in einer weiteren Liste vorhanden sind. Im Ausführungsbeispiel sind in der weiteren Liste als solche Einträge hinterlegt, deren Abfrage nicht unerwünscht ist. Wird erkannt, dass die abgefragten Daten als Einträge in dieser weiteren Liste hinterlegt sind („j“) folgt Schritt 1070, in dem optional diese Abfragen, ggf. inklusive Metainformationen, gespeichert werden, bevor das Programm zu Schritt 1010 zurückverzweigt. Andernfalls („n“) folgt Schritt 1090, oder zunächst optional Schritt 1080, in dem eine Abfrage an einen Nutzer, z.B. den Fahrer des Kraftfahrzeugs, ausgegeben wird, ob die vorliegende Datenabfrage genehmigt wird. Die Antwort des Nutzers wird empfangen und ausgewertet. Der Nutzer hat somit die Möglichkeit die Abfrage für die spezifische Sequenz oder für das abgefragte Datum allgemein dauerhaft oder temporär freizugeben bzw. zu sperren. Der Nutzer hat damit die Möglichkeit eine individuelle White- und Blacklist zu erstellen, welche er zur jeder Zeit wieder editieren kann. Wird die Abfrage genehmigt („j), wird zu Schritt 1010 zurückverzweigt, andernfalls („n“) folgt Schritt 1090.
  • In Schritt 1090 wird eine der aufgezählten Gegenmaßnahmen ausgeführt. Beispielsweise wird eine Stromversorgung des Teilnehmers 4, der über die OBD-Schnittstelle versorgt wird, abgeschaltet, oder Teilnehmer 2 verschickt wie beschrieben Abwehrnachrichten. Anschließend folgt Schritt 1100, in dem optional der Inhalt der Abfrage gespeichert wird.
  • Dieses Speichern in Schritt 1100 kann (ebenso wie das Speichern in Schritt 1030 oder 1070) in einem Speicher des Kraftfahrzeugs selbst erfolgen, also z.B. in einem Steuergerät oder einen integrierten Infotainment-System), oder außerhalb des Kraftfahrzeugs abgespeichert werden (z.B. im einem verbundenen Mobiltelefon, auf einem Server in der „Cloud“, o.ä.). Das Speichern kann jeweils mit Metainformationen, wie z.B. einem Zeitstempel erfolgen.
  • Es folgt Schritt 1100, in dem optional dem Nutzer über das Dashboard oder einem entsprechend angebunden Drittgerät (z.B. Smartphone) visualisiert werden kann, welche Daten im Bussystem 10 durch eine aktive Anfrage abgefragt wurden.
  • Es folgt Schritt 1110, in dem dem Nutzer optional angezeigt wird, dass eine Datenabfrage erkannt und unterbunden wurde. Damit verzweigt das Verfahren zurück zu Schritt 1010.
  • Es versteht sich für den Fachmann, dass das Verfahren in Hardware implementiert sein kann, oder in Software, oder in einer Mischform aus Hardware und Software.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102009026995 A1 [0002]

Claims (15)

  1. Verfahren zum Betreiben eines Bussystems (10) insbesondere eines Kraftfahrzeugs, bei dem Nachrichten des Bussystems (10) empfangen werden und abhängig von diesen Nachrichten darauf erkannt wird, ob ein diese Nachrichten absendender Teilnehmer (4) des Bussystems (10) ein sich anmeldender Teilnehmer (4) des Bussystems (10) ist.
  2. Verfahren nach Anspruch 1, wobei abhängig von diesen Nachrichten auch darauf erkannt wird, ob der absendende Teilnehmer (4) ein neuer Teilnehmer (4) des Bussystems (10) ist.
  3. Verfahren nach Anspruch 1 oder 2, wobei abhängig vom Ergebnis des Erkennens Maßnahmen eingeleitet werden, um den absendenden Teilnehmer (4) zu deaktivieren.
  4. Verfahren nach Anspruch 3, wobei die Maßnahmen umfassen, eine Stromversorgung des absenden Teilnehmers (4) zu deaktivieren.
  5. Verfahren nach Anspruch 3 oder 4, wobei die Maßnahmen umfassen, Selbstabschaltnachrichten an den absenden Teilnehmer (4) zu schicken, die den absendenden Teilnehmer (4) dazu veranlassen, sich zumindest teilweise zu deaktivieren.
  6. Verfahren nach Anspruch 5, wobei die Selbstabschaltnachrichten Nachrichten umfassen, welche dem absendenden Teilnehmer (4) die Information übermitteln, dass das Kraftfahrzeug einen vorgebbaren Zustand einnimmt.
  7. Verfahren nach einen der Anspruch 5 oder 6, wobei die Selbstabschaltnachrichten Nachrichten umfassen, welche dem absendenden Teilnehmer (4) die Information übermitteln, dass eine Abfrage bestimmter Datenangaben von Teilnehmern des Bussystems nicht unterstützt wird und/oder dass die Abfrage des absenden Teilnehmers (4) ungültig ist.
  8. Verfahren nach einem der vorherigen Ansprüche, wobei zusätzlich darauf erkannt wird, ob der absendende Teilnehmer (4) eine Datenabfrage durchgeführt hat, wobei dann, wenn diese Datenabfrage erkannt wurde, eine korrekte Antwort auf die Datenabfrage unterbunden wird.
  9. Verfahren nach Anspruch 8, wobei das Unterbinden umfasst, mindestens eine Nachricht an den absendenden Teilnehmer (4) zu übermitteln.
  10. Verfahren nach Anspruch 9, wobei ein Inhalt der übermittelten Nachricht so ausgestaltet ist, als sei sie eine Antwort des erkannten Adressaten (1) auf die Datenabfrage.
  11. Verfahren nach Anspruch 10, wobei die übermittelte Nachricht eine unkorrekte Antwort auf die Datenabfrage umfasst.
  12. Verfahren nach einem der Ansprüche 8 bis 11, wobei das Unterbinden umfasst, eine tatsächliche Antwort des erkannten Adressaten (1) zu unterbinden.
  13. Computerprogramm, welches eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
  14. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 13 gespeichert ist.
  15. Steuer- und/oder Regeleinrichtung (2), die eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
DE102016214279.8A 2016-08-02 2016-08-02 Verfahren und Vorrichtung zum Betreiben eines Bussystems Pending DE102016214279A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102016214279.8A DE102016214279A1 (de) 2016-08-02 2016-08-02 Verfahren und Vorrichtung zum Betreiben eines Bussystems
US15/661,144 US10185682B2 (en) 2016-08-02 2017-07-27 Method and device for operating a bus system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016214279.8A DE102016214279A1 (de) 2016-08-02 2016-08-02 Verfahren und Vorrichtung zum Betreiben eines Bussystems

Publications (1)

Publication Number Publication Date
DE102016214279A1 true DE102016214279A1 (de) 2018-02-08

Family

ID=60996178

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016214279.8A Pending DE102016214279A1 (de) 2016-08-02 2016-08-02 Verfahren und Vorrichtung zum Betreiben eines Bussystems

Country Status (2)

Country Link
US (1) US10185682B2 (de)
DE (1) DE102016214279A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10812257B2 (en) 2017-11-13 2020-10-20 Volkswagen Ag Systems and methods for a cryptographically guaranteed vehicle identity
US10650623B2 (en) * 2018-09-18 2020-05-12 Avinew, Inc. Detecting of automatic driving
JP7247905B2 (ja) * 2020-01-22 2023-03-29 トヨタ自動車株式会社 第１中継装置、第２中継装置、第１中継方法、第２中継方法、第１中継プログラム、第２中継プログラム、及び中継システム
CN112269368B (zh) * 2020-10-20 2021-07-13 东风汽车股份有限公司 一种自适应读取车辆识别码的方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009026995A1 (de) 2009-06-17 2011-03-31 Robert Bosch Gmbh Verfahren zum Betreiben eines Bussystems, insbesondere eines CAN-Busses

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19812163C2 (de) * 1998-03-19 2002-03-07 Siemens Ag Verfahren zur Identifizierung und Initialisierung von Geräten
US6801942B1 (en) * 2000-09-15 2004-10-05 Robert Bosch Gmbh Apparatus, method and system for remotely accessing and/or controlling can node arrangements, including vehicle electronic control units, during vehicle operation
US6871067B2 (en) * 2001-10-15 2005-03-22 Electronic Data Systems Corporation Method and system for communicating telematics messages
US20080219252A1 (en) * 2007-03-08 2008-09-11 Ya Narasimhaprasad Shared communication protocol for controller area network
WO2009054769A1 (en) * 2007-10-22 2009-04-30 Volvo Lastvagnar Ab System and method for changing the state of vehicle components
US9338035B2 (en) * 2011-03-07 2016-05-10 Microchip Technology Incorporated Microcontroller with can bus module and auto speed detect
DE102012208205A1 (de) * 2012-05-16 2013-11-21 Bayerische Motoren Werke Aktiengesellschaft Datenlogging bzw. Stimulation in Automotiven Ethernet Netzwerken unter Verwendung der Fahrzeug-Infrastruktur
US10369942B2 (en) * 2014-01-06 2019-08-06 Argus Cyber Security Ltd. Hosted watchman
US9705678B1 (en) * 2014-04-17 2017-07-11 Symantec Corporation Fast CAN message authentication for vehicular systems
US20160121823A1 (en) * 2014-10-31 2016-05-05 American Axle & Manufacturing, Inc. Controlling Automotive Vehicle Powertrain, Drivetrain Suspension Components and Accessories Using Portable Personal Electronic Telecommunication Devices
US11397801B2 (en) * 2015-09-25 2022-07-26 Argus Cyber Security Ltd. System and method for controlling access to an in-vehicle communication network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009026995A1 (de) 2009-06-17 2011-03-31 Robert Bosch Gmbh Verfahren zum Betreiben eines Bussystems, insbesondere eines CAN-Busses

Also Published As

Publication number Publication date
US20180039591A1 (en) 2018-02-08
US10185682B2 (en) 2019-01-22

Similar Documents

Publication Publication Date Title
DE102016214279A1 (de) Verfahren und Vorrichtung zum Betreiben eines Bussystems
DE102017208547A1 (de) Verfahren zum Schutz eines Netzwerkes vor einem Cyberangriff
DE102017109099A1 (de) Bereitstellen von modul-updates für ein fahrzeugsystem
DE102018102660A1 (de) Methode und vorrichtung zum erkennen einer batterieentladung
DE102015109057A1 (de) Sperren des Zugriffs auf vertrauliche Fahrzeugdiagnosedaten
DE102017200826A1 (de) Verfahren zum Betreiben einer Überwachungsvorrichtung eines Datennetzwerks eines Kraftfahrzeugs sowie Überwachungsvorrichtung, Steuergerät und Kraftfahrzeug
DE102019207423A1 (de) Verfahren und System zur Erfassung eingekoppelter Nachrichtenanomalien
WO2013064221A1 (de) System und verfahren zur bestimmung eines bevorzugten kommunikationskanals
DE102017209557A1 (de) Verfahren zum Schutz eines Fahrzeugnetzwerks gegen manipulierte Datenübertragung
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102018208118A1 (de) Verfahren und Vorrichtung zum Authentifizieren einer über einen Bus übertragenen Nachricht
DE102018219960A1 (de) Fahrzeug-zu-X-Kommunikationsanordnung und Verfahren zum Empfangen von Fahrzeug-zu-X-Nachrichten
DE102020214099A1 (de) Verfahren zur Erkennung eines unerlaubten physischen Zugriffs auf ein Bussystem
WO2015090659A1 (de) Vorrichtung und verfahren zur übertragung von daten
DE102021202075A1 (de) Verfahren zur Validierung von Nachrichten
DE102016200775A1 (de) Verfahren und Vorrichtung zum Schutz eines Fahrzeuges vor Cyberangriffen
DE102017209556A1 (de) Verfahren zum Schutz eines Fahrzeugnetzwerks gegen manipulierte Datenübertragung
DE102016204999A1 (de) Verfahren zur Überwachung der Sicherheit von Kommunikationsverbindungen eines Fahrzeugs
DE102017212249A1 (de) Verfahren und Vorrichtungen für Teilnehmer übergreifende Kommunikation
EP3641231A1 (de) Verfahren und vorrichtung zur überwachung einer datenkommunikation
DE102017208551A1 (de) Verfahren zum Schutz eines Netzwerkes vor einem Cyberangriff
DE112019005132T5 (de) Simultanes testen, ob mehrere über ein kommunikationsnetzwerk verbundene elektronische vorrichtungen ausnahmen korrekt behandeln
DE102016214910A1 (de) Mobilfunkvorrichtung für ein Kraftfahrzeug und Verfahren zum Betreiben der Mobilfunkvorrichtung
DE102017209806A1 (de) Verfahren und Vorrichtung zum Erkennen von Angriffen auf einen Feldbus
DE102013106586A1 (de) Verfahren zum Betreiben eines Kraftfahrzeugs

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000

R012 Request for examination validly filed