[go: up one dir, main page]

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

Verfahren und Vorrichtung zum Betreiben eines Bussystems Download PDF

Info

Publication number
DE102016212816A1
DE102016212816A1 DE102016212816.7A DE102016212816A DE102016212816A1 DE 102016212816 A1 DE102016212816 A1 DE 102016212816A1 DE 102016212816 A DE102016212816 A DE 102016212816A DE 102016212816 A1 DE102016212816 A1 DE 102016212816A1
Authority
DE
Germany
Prior art keywords
message
defensive
designated recipient
diagnostic
valid
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
DE102016212816.7A
Other languages
English (en)
Inventor
Benjamin Herrmann
Joachim Steinmetz
Antonio La Marca
Michael Beuten
Marco Neumann
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 DE102016212816.7A priority Critical patent/DE102016212816A1/de
Priority to US15/643,791 priority patent/US10554444B2/en
Priority to CN201710564863.5A priority patent/CN107623608A/zh
Publication of DE102016212816A1 publication Critical patent/DE102016212816A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/554Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/85Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/24Testing correct operation
    • H04L1/242Testing correct operation by comparing a transmitted test signal with a locally generated replica
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40032Details regarding a bus interface enhancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/143Termination or inactivation of sessions, e.g. event-controlled end of session

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
  • Traffic Control Systems (AREA)
  • Small-Scale Networks (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Abstract

Verfahren zum Betreiben eines Bussystems (10), bei dem eine Nachricht des Bussystems (10) empfangen und ihre Validität ermittelt wird, dadurch gekennzeichnet, dass dann, wenn ermittelt wurde, dass die Nachricht „nicht valide“ ist, eine Abwehrnachricht an einen designierten Empfänger (2) der Nachricht gesendet wird, wobei die Abwehrnachricht derart ausgebildet ist, dass der designierte Empfänger (2) durch die Abwehrnachricht angewiesen wird, Abwehrmaßnahmen gegen die Nachricht einzuleiten.

Description

  • Die Erfindung betrifft ein Verfahren zum Betreiben eines Bussystems, insbesondere in einem Kraftfahrzeug, 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.
  • Vorteil der Erfindung
  • Das Verfahren mit den Merkmalen des unabhängigen Anspruch 1 hat den Vorteil, dass besonders effektiv irreguläre Eingriffe in einem Netzwerk dieses Bussystems erkannt werden können, um sie bei Bedarf gezielt zu blockieren oder zu verhindern. Ein Vorteil der Erfindung ist daher die Erhöhung der Netzwerkintegrität gegenüber manipulativen Eingriffen in das Netzwerk.
  • Ein weiterer Vorteil ist, dass Sicherheitslücken aufgedeckt werden können, und somit die Möglichkeit eröffnet, diese mit einem Software-Update zu beheben.
  • Ein weiterer Vorteil der Erfindung ist, dass die Abwehr irregulären Eingriffe im Netzwerk mittels vorhandener Bordmittel erfolgt. Insbesondere kann sie mit Hilfe weiterer Funktionen im betroffenen Netzwerkteilnehmer erfolgen, die über das Netzwerk aktiviert werden.
  • Ein weiterer entscheidender Vorteil der Erfindung ist, dass bei einem Abwehrversuch die Funktionsweise des Netzwerks nicht beeinträchtigt wird, d.h. die am Netzwerk angeschlossenen Systeme und/oder Steuergeräte (der Begriff „Steuergerät“ wird hier und im Folgenden ohne Einschränkung als synonymer Kurzbegriff für „Steuer- und/oder Regeleinrichtung“ verwendet) werden in ihrer Funktion nicht beeinträchtigt, da durch die gezielte Nutzung bereits vorhandener Bordmittel zur Abwehr eines irregulären Eingriffs volle Kompatibilität gewährleistet ist.
  • Offenbarung der Erfindung
  • Eingriffe in ein Kraftfahrzeug können mittels genormeter oder properitärer Protokolle erfolgen, über welche die Netzwerkteilnehmer Daten und/oder Kommandos austauschen. Diese gernormten oder proprietären Protokolle können entweder zustandsbehaftet oder zustandslos sein.
  • Im Fall zustandsbehafteter Protokollen kann sich insbesondere die folgende Situation ergeben: Um Diagnosen an Kraftfahrzeugen zu vereinfachen, können Steuergeräte im Fahrzeug spezielle Diagnosefunktionen beinhalten. Diese Diagnosefunktionen können beispielsweise Eingriffe wie die Ansteuerung von Elektromotoren oder Ventilen im Fahrzeug ermöglichen. Sie können ferner erlauben, Zustände herzustellen, welche während des regulären Betriebs des Kraftfahrzeugs nicht erwünscht sind. Ferner können Diagnosefunktionen dazu eingesetzt werden, Daten aus Steuergeräte auszulesen, um Rückschlüsse auf die auf den Steuergeräten vorhandene Software oder auf einen Zustand des Kraftfahrzeugs zu erlauben.
  • Die Diagnosefunktionen selbst können beispielsweise über genormte Diagnoseprotokolle wie z.B. ISO14229 z.B. mit Hilfe eines Werkstatttesters im Steuergerät gestartet werden.
  • Im Falle kritischer Diagnosefunktionen sieht z.B. die Norm ISO14229 eine einfache Überwachung vor, welche sicherstellt, dass eine aktive Verbindung zwischen einem ausgewählten Steuergerät (dem „Zielsteuergerät“) und dem Werkstatttester besteht. Dazu wird zunächst eine „non-default“-Diagnosesession im Zielsteuergerät mittels einer dedizierten Netzwerkbotschaft an das Zielsteuergerät gestartet. Anschließend können die eigentlichen Diagnosefunktionen gestartet werden.
  • Beim Verlassen einer aktiven „non-default“-Diagnosesession kann vorgesehen sein, zuvor aktivierte Diagnosefunktionen generisch zu stoppen. Eine aktive Diagnosesession kann verlassen werden, wenn beispielsweise
    • – die Timeoutüberwachung der „non-default“-Diagnosesession wegen einer fehlenden „KeepAlive“-Botschaft, z.B. via dem in der ISO14229 beschriebenen Diagnoseservice TesterPresent, zuschlägt
    • – aktiv eine neue Session gestartet wird, z.B. via dem in der ISO14229 beschriebenen Diagnoseservice DiagnosticSessionControl
    • – oder wenn durch die Anfrage eines anderen Diagnoseprotokolls mit höherer Priorität ein Protokollwechsel im Steuergerät erfolgt
  • Neben den generischen Methoden, eine aktivierte Diagnosefunktion zu beenden, gibt es des Weiteren noch Möglichkeiten, diese gezielt zu deaktivieren. Beispielsweise hält die ISO14229 im Diagnoseservice InputOutputControlByIdentifier den InputOutputControlParameter „returnControlToEcu“ oder auch im Diagnoseservice RoutineControl die Subfunktion „StopRoutine“ vor. Diese Methode zur gezielten Deaktivierung bietet sich insbesondere an, wenn ein irregulärer Diagnoseeingriff möglich ist, ohne zunächst eine „Non-Default“-Diagnosesession zu starten und/oder wenn eine Diagnosekommunikation umgesetzt wurde, die sich nicht strikt an die in der ISO14229 beschriebenen Methoden hält.
  • Die dargestellten Diagnosefunktionen sind als Service zur Fehlerdiagnose mit Werkstatttestern unter kontrollierten Bedingungen in der Werkstatt oder der Produktion vorgesehen. Durch die zunehmende Vernetzung und Connectivity im Fahrzeug ist mit geeigneten Gegenmaßnahmen zu verhindern, dass Diagnosefunktionen missbraucht werden, etwa um den Fahrbetrieb gezielt zu stören.
  • Sowohl für den oben angesprochenen Fall zustandsbehafteter wie auch für den oben angesprochenen Fall zustandsloser Protokolle wird daher ein Verfahren zum Betreiben eines Bussystems vorgeschlagen, bei dem eine Nachricht des Bussystems empfangen und ihre Validität ermittelt wird (d.h. beispielsweise bei einer zweistufigen Bewertung der Validität, ob die Nachricht valide ist oder nicht). In dem Fall, dass ermittelt wurde, dass die Nachricht „nicht valide“ ist, ist vorgesehen, eine Abwehrnachricht an einen designierten Empfänger der Nachricht zu senden. Der designierte Empfänger kann insbesondere ein Teilnehmer des Bussystems sein. Es ist vorgesehen, dass die Abwehrnachricht derart ausgebildet ist, dass der designierte Empfänger durch die Abwehrnachricht angewiesen wird, Abwehrmaßnahmen gegen die Nachricht einzuleiten. Das Verfahren ist hierbei nicht auf einen einzigen designierten Empfänger eingeschränkt. Denkbar ist auch, es für eine Mehrzahl designierter Empfänger durchzuführen.
  • Da zur Abwehr also Abwehrmaßnahmen ausgenutzt werden, die bereits im Empfänger vorhanden sind (sogenannte Bordmittel), wird ein System durch dieses Verfahren besonders einfach „plug-and-play“-fähig.
  • Die Ermittlung der Validität kann beispielsweise dadurch erfolgen, dass die Netzwerkkommunikation überwacht und mit Ausgabewerten eines oder mehrerer Sensoren (der Begriff „Sensor“ kann hier so weit gefasst verstanden werden, dass er auch eine zugeordnete Auswerteeinheit in einem Steuergerät mit umfasst) verknüpft wird. Wird nun beispielsweise von einem Sensor ein Hinweis empfangen, dass eine Anomalie vorliegt (beispielsweise, weil in der Nachricht einen abnormalen Sprung des innerhalb des Netzwerks übertragenen Wunschmoments einer Bremse festgestellt wird und/oder weil eine irreguläre Diagnoseanfrage erkannt wird, weil vorbestimmbare Bedingungen für die Zulässigkeit der Diagnoseanfrage nicht vorliegen, weil z.B. ein Stellgliedtest angefordert wird, während sich das Fahrzeug bewegt,) wird darauf entschieden, dass die Nachricht nicht valide ist.
  • Die folgenden Ausführungsformen sind insbesondere für den oben angesprochenen Fall zustandsbehafteter Protokolle vorteilhaft.
  • Insbesondere kann die Abwehrnachricht dann ausgebildet sein den designierten Empfänger dazu zu veranlassen, eine aktive, also aktuell laufende, „non-default“-Diagnosesession zu deaktivieren und/oder eine weitere „non-default“-Diagnosesession zu starten.
  • In einer besonders effektiven Weiterbildung kann die Abwehrnachricht ausgebildet sein, den designierten Empfänger dazu zu veranlassen, einen Protokollwechsel von einem der „non-default“-Diagnosesession zugeordneten Diagnoseprotokoll hin zu einem anderen Diagnoseprotokoll durchzuführen. Vorteilhafterweise sind den Diagnoseprotokollen hierbei Prioritäten zugewiesen, und dem anderen Diagnoseprotokoll ist eine höhere Priorität zugewiesen als dem Diagnoseprotokoll, das der „non-default“-Diagnosesession zugeordnet ist.
  • In einer weiteren besonders einfachen Weiterbildung kann die Abwehrnachricht ausgebildet sein, den designierten Empfänger dazu zu veranlassen, die Nachricht zu deaktivieren. Dies kann beispielsweise in dem in der ISO14229 definierten Diagnoseservice „InputOutputControlByIdentifier“ durch den dort vorgehaltenen InputOutputControlParameter „returnControlToEcu“ geschehen, oder in dem ebenfalls in der ISO14229 definierten Diagnoseservice „RoutineControl“ durch die Subfunktion „StopRoutine“.
  • In weiteren Aspekten kann die Verwendung zustandsbehafteter Protokolle, wie beispielsweise die in Kraftfahrzeugen eingesetzten Protokolle CCP (CAN Calibration Protocol) und XCP (Universal Calibration Protocol), welche zum Messen, Stimulieren und Verstellen verwendet werden, vorgesehen sein.
  • Z.B. kann in einer besonders einfachen Weiterbildung die Abwehrnachricht ausgebildet sein, den designierten Empfänger dazu zu veranlassen, die als „nicht valide“ erkannte Nachricht (beispielsweise einen Stimuli-Eingriff wie z.B. einen eingeleiteten Messeingriff) zu deaktivieren, indem die Abwehrnachricht so ausgebildet ist, dass sie ein Kommando zum Stoppen einer von der erkannten Nachricht ausgelösten Reaktion, beispielsweise des Stimuli-Eingriffs, überträgt, beispielsweise das Kommando START-STOP-DATA-TRANSMISSION das sowohl im CCP als auch im XCP Standard definiert ist. Es kann dann bei Verwendung von XCP mittels der gleichen Abwehrnachricht, beispielsweise des START-STOP-DATA-TRANSMISSION-Kommandos, der designierte Empfänger dazu veranlasst werden, den eingeleiteten nicht validen Stimuli-Eingriff zu deaktivieren.
  • Ist die von der als „nicht valide“ erkannten Nachricht ausgeöste Reaktion ein Verstellzugriff so kann die Abwehrnachricht beispielsweise so ausgestaltet sein, dass sie ein Kommando zum Umschalten des Datensatzes auf die Referenzseite des Speichers repräsentiert, beispielsweise das Kommando SET-CALIBRATION-PAGE das sowohl im CCP als auch im XCP Standard definiert ist.
  • In einer weiteren besonders einfachen Aspekt kann die Nachricht so ausgebildet sein, dass sie das Schließen einer existierende Verbindung im designierten Empfänger durch Versenden einer Abwehrnachricht auslöst. Dies kann beispielsweise mittels des DISCONNECT-Kommandos erfolgen, dass sowohl im CCP als auch im XCP Standard definiert ist. Da sich mittels dieser Weiterbildung unabhängig von dem Anwendungsgebiet der als „nicht valide“ erkannten Nachricht die im designierten Empfänger ausgeführten Eingriffe abwehren lassen, ist diese Weiterbildung der Abwehrmaßnahme eine sehr generische und daher einfache Methode.
  • Für den oben angesprochenen Fall zustandsloser Protokolle sind insbesondere die folgenden Weiterbildungen vorteilhaft. Z.B. können dann in einer besonders einfachen Weiterbildung Abwehrmechanismen des designierten Empfängers ausgenutzt werden, indem die Abwehrnachricht ausgebildet ist, vom designierten Empfänger als nicht valide Nachricht identifiziert zu werden. D.h. durch die (gezielte) Injektion von fehlerbehafteten Botschaften, für welche Überwachungsmechanismen im designierten Empfänger vorhanden sind, werden die dafür vorgesehenen Ersatzreaktionen provoziert.
  • Die Abwehrnachricht kann hierzu mit einem falschen Data-Length-Code („DLC“) und/oder einem falschen Cyclic-Redundancy-Check-(„CRC“)Code und/oder einem falschen Botschaftszähler (auch als „Alive Counter“ bekannt) und/oder einem unplausiblen Signalwert und/oder einem falschen Signal-Qualifier ausgestattet sein, um somit unmittelbar eine Fehlererkennung auszulösen.
  • Der Signal-Qualifier kann ein separates Signal mit z.B. 1–2 Bit Länge sein. Dieses Signal kann vom Sender verwendet werden, um den Empfänger über die Ungültigkeit der gesendeten Information (z.B. aufgrund eines als defekt erkannten Sensors) zu informieren.
  • Die Abwehrnachricht kann alternativ oder zusätzlich eine gleiche Kennung wie die empfangene Nachricht aufweisen, um somit in dem Fall, dass die empfangene Nachricht zyklisch versendet wird, eine falsche Zykluszeit/Sendeperiode zu erzeugen.
  • Die Abwehrnachricht kann alternativ oder zusätzlich eine Priorität erhalten, die höher ist als die Priorität der empfangenen Nachricht. Dies kann beispielsweise auf einer mehrstufigen diskreten Skala ein Zahlenwert sein, der die Priorität um eine oder mehrere Stufen gegenüber dem empfangenen Nachricht vorrangig macht. Empfängt der designierte Empfänger nun Nachricht und Abwehrnachricht, kann somit sichergestellt werden, dass der designierte Empfänger die Abwehrnachricht vor der Nachricht bearbeitet. Das Verfahren wird somit besonders sicher.
  • Die Abwehrnachricht kann zusätzlich einen Ersatzwert für ein Signal enthalten, das mit der Nachricht an den designierten Empfänger übermittelt werden sollte. Beispielsweise ist es möglich, dass der Ersatzwert so gewählt ist, dass das Kraftfahrzeug in einen sicheren Zustand überführt wird.
  • Unabhängig davon, ob der oben angesprochene Fall zustandsbehafteter oder zustandsloser Protokolle vorliegt, sind die folgenden Weiterbildungen besonders vorteilhaft:
  • In einem weiteren Aspekt kann z.B. vorgesehen sein, dass neben der Abwehrnachricht zusätzlich eine weitere Abwehrnachricht gesendet wird. Die weitere Abwehrnachricht kann die gleiche Nachricht sein, wie die Abwehrnachricht. Sie kann aber auch von der Abwehrnachricht unterschiedlich sein, und beispielsweise nach einer der oben aufgezählten Varianten ausgebildet sein. Auf diese Weise wird das Verfahren besonders effektiv.
  • In einer besonders sicheren Weiterbildung kann vorgesehen sein, dass weitere Abwehrnachrichten so lange gesendet werden, bis festgestellt wird, dass der designierte Empfänger eine Abwehrmaßnahme eingeleitet hat.
  • In einem weiteren Aspekt kann vorgesehen sein, dass die empfangene Nachricht gespeichert wird, wenn sie als „valide“, also bei einer zweistufigen Validitätsskala nicht als „nicht valide“, eingestuft wurde.
  • Ferner kann vorgesehen sein, dass abhängig von empfangenen gespeicherten Nachrichten entschieden wird, ob die Nachricht als „valide“ eingestuft wird. Ein solches Verfahren ist auf besonders einfache Weise lernfähig.
  • Durch die Einhaltung der Kompatibilität und Nutzung bereits vorhandener Bordmittel zur Abwehr ist das beschriebene Verfahren ebenso jederzeit auf sämtlichen Recheneinheiten nachrüstbar, die einen Zugang zum Kraftfahrzeugnetzwerk haben, z.B. Steuergeräte und Gateways im Fahrzeug oder auch in Connectivity-Einheiten oder nachgeschalteten Recheneinheiten, z.B. „Cloud“. Das Verfahren kann also an einer beliebigen Stelle in einem Netzwerk eines Kraftfahrzeugs eingesetzt werden, z.B. als integrierter Bestandteil eines oder mehrerer Steuergeräte, eines Gateways oder auch in Connectivity-Einheiten, welche z.B. via OBD-Stecker an das Netzwerk nachträglich angebunden werden können. Des Weiteren sind keine weiteren Bausteine oder Veränderungen in der Architektur des Kraftfahrzeugs notwendig, d.h. der Einsatz des Verfahrens ist besonders einfach.
  • 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;
  • 3 einen Ablaufplan des Verfahrens gemäß eines weiteren Aspekts der Erfindung.
  • 1 zeigt ein beispielhaft ein Netzwerk mit einem Bussystem 10, über das Teilnehmer 1, 2, 3, 4 kommunizieren. Bei den Teilnehmern 1, 2, 4 kann es sich jeweils beispielsweise um Steuergeräte handeln, oder beispielsweise auch um Sensoren. Teilnehmer 3 ist ein Steuergerät, auf dem im Ausführungsbeispiel die Erfindung implementiert ist.
  • Über das Bussystem 10 tauschen die Teilnehmer 1, 2, 3, 4 Nachrichten aus, die jeweils mit einer Kennung („ID“) versehen sind. Die Wörter „Botschaft“ und „Nachricht“ werden synonym verwendet. Das Versenden einer Botschaft ist in 1 mit „TX“ und der zugehörigen Kennung der versendeten Botschaft gekennzeichnet, das Empfangen einer Botschaft mit „RX“ und der zugehörigen Kennung der empfangenen Botschaft. In 1 versendet Teilnehmer 1 eine Botschaft mit der Kennung „123“. Diese Botschaft wird von Teilnehmer 2 empfangen. Teilnehmer 3 versendet eine Botschaft mit der Kennung „789“. Dieser Botschaft wird von Teilnehmern 2 und 3 empfangen.
  • Teilnehmer 3 empfängt im Ausführungsbeispiel alle im Netzwerk 10 definierten Botschaften. Ein Angreifer 5, der ebenfalls Teilnehmer im Netzwerk 10 ist, sendet ebenfalls eine Botschaft mit der Kennung „123“. Teilnehmer 2 empfängt auch diese Botschaft, erkennt sie aber nicht als Angriff, da beispielsweise der CRC-Code der Botschaft mit der Kennung „123“ korrekt nachgebildet wurde. Teilnehmer 2 verwendet den manipulierten Botschaftsinhalt daher weiter in der Verarbeitung seines Programmcodes. Teilnehmer 3 erkennt jedoch (beispielsweise durch eine Plausibilitätsprüfung des Dateninhalts der Botschaft „123“), dass Botschaft „123“ nicht valide ist, und kann Abwehrmaßnahmen einleiten.
  • 2 zeigt den Ablauf des Verfahrens, das in dem in 1 illustrierten Ausführungsbeispiel auf Teilnehmer 3 abläuft. Beispielsweise verfügt Teilnehmer 3 über ein maschinenlesbares Speichermedium, auf dem ein Computerprogramm gespeichert ist, das die Schritte dieses Verfahrens ausführt, wenn es auf Teilnehmer 3 ausgeführt wir, d.h. dass das Computerprogramm ausgebildet ist, dieses Verfahren auszuführen.
  • Das Verfahren beginnt in Schritt 1000, in dem sich beispielsweise der Teilnehmer 3 im Netzwerk 10 anmeldet oder eine IDS-Anwendung aktiviert. Es folgt Schritt 1010, in dem Teilnehmer 3 die Kommunikation im Netzwerk 10 überwacht und die über das Netzwerk versendeten Nachrichten empfängt. Diese Nachrichten können beispielsweise in einer Queue gepuffert werden. Die nachfolgenden Schritte werden vorteilhafterweise für jede der Nachrichten einzeln durchgeführt.
  • Die Verarbeitung einer empfangenen Nachricht beginnt im nachfolgenden Schritt 1020. In diesem Schritt wird überprüft, ob die empfangene Nachricht von einem bekannten Typ ist. Beispielsweise kann dies durch Nachschauen in einer Datenbank erfolgen, in denen Nachrichten nach charakteristischen Eigenschaften (beispielsweise den Reaktionen, die sie in ihrem designierten Empfänger auslösen) suchbar hinterlegt sind. Wird die empfangene Nachricht in einer solchen Datenbank gefunden, gilt ihr Typ als bekannt, andernfalls als unbekannt. Ist dies nicht der Fall (Ausgang „n“), d.h. ist die empfangene Nachricht nicht von bekanntem Typ, folgt Schritt 1030, in dem optional eine interne oder externe Warnung erfolgen kann, dass eine unbekannte Nachricht empfangen wurde, und es wird zu Schritt 1010 zurückverzweigt.
  • Ist die Nachricht hingegen bekannt (Ausgang „j“), folgt Schritt 1040, in dem überprüft, ob die Botschaft „valide“ oder „nicht valide“ ist. Ist die Botschaft „nicht valide“ wird auf Angriff erkannt (Ausgang „j“), und es folgt Schritt 1050, andernfalls (Ausgang „n“) wird zu Schritt 1010 zurückverzweigt.
  • In Schritt 1050 bringt Teilnehmer 3 weitere Daten ins Netzwerk 10 ein, bei deren Charakteristik eingebaute Überwachungsmechanismen im designierten Empfänger der nicht-validen Nachricht anschlagen und dort vordefinierte Ersatzmaßnahmen eingeleitet werden. Hierzu sendet Teilnehmer 3 eine Abwehrnachricht an den designierten Empfänger der als Angriff identifizierten nicht-validen Nachricht. Diese Abwehrnachricht kann beispielsweise die gleiche Kennung haben wie die nicht-valide Nachricht. Sie kann auch eine alternative Kennung haben, sofern die Botschaft mit dieser alternativen Kennung im designierten Empfänger eine Ersatzreaktion auslöst, die das angegriffene System abdeckt, d.h. die die Wirkung der nicht-validen Nachricht neutralisiert oder die Kritikalität der Folgen reduziert.
  • Optional wird in Schritt 1050 die als „nicht valide“ erkannte Botschaft aufgezeichnet wird und in einem Speicher im Kraftfahrzeug und/oder außerhalb des Kraftfahrzeugs abgelegt wird. Alternativ oder zusätzlich kann die Tatsache, dass die Botschaft als „nicht valide“ erkannt wurde, dem Fahrer des Kraftfahrzeugs oder z.B. dem Hersteller gemeldet wird. Dies kann beispielsweise über eine Meldung im Dashboard und/oder über ein Infotainmentsystem und/oder über eine Mitteilung an angebundene Dienste außerhalb des Kraftfahrzeugs erfolgen.
  • Beispielsweise injiziert Teilnehmer 3 in dem o.g. detektierten abnormalen Sprung des Bremsenwunschmoments eine Nachricht auf der gleichen Kennung „123“ mit falschem CRC-Code(den der Angreifer in seiner Attacke korrekt nachgebildet hatte) ins Netzwerk 10. Die CRC Prüfung schlägt nun im designierten Empfänger (hier: Teilnehmer 2) fehl und die entsprechenden Ersatzreaktionen werden angestoßen.
  • Alternativ oder zusätzlich kann das folgende Verfahren vorgesehen sein. Zunächst wird optional auf Basis der empfangenen Nachricht überprüft (z.B. auf Basis einer in dieser Nachricht enthaltenen Kennung), wer der designierte Empfänger ist bzw. welcher Teilnehmer 1, 2, 4 von der als „nicht valide“ erkannten Nachricht betroffen ist. Damit ist es möglich, den Abwehrmechanismus gezielt für die betroffenen Teilnehmer 1, 2, 4 auszulösen.
  • Damit endet dieser Durchlauf des Verfahrens und es wird zurückverzweigt zu Schritt 1010.
  • Es kann vorgesehen sein, dass Teilnehmer 3 solange „korrumpierte“ Daten injiziert, bis eine Ersatzreaktion sicher ausgelöst wurde bzw. solange, bis Teilnehmer 3 keine Manipulationen mehr detektiert.
  • 3 zeigt den Ablauf des Verfahrens gemäß eines weiteren Aspekts der Erfindung, das wie das in 2 illustrierte Verfahren in dem in 1 illustrierten Ausführungsbeispiel in Teilnehmer 3 implementiert ist.
  • Das Verfahren beginnt in Schritt 2000, in dem sich beispielsweise der Teilnehmer 3 im Netzwerk 10 anmeldet oder eine IDS-Anwendung aktiviert. Es folgt Schritt 2010, in dem Teilnehmer 3 die Kommunikation im Netzwerk 10 überwacht und die über das Netzwerk versendeten Nachrichten empfängt. Diese Nachrichten können beispielsweise in einer Queue gepuffert werden. Die nachfolgenden Schritte werden vorteilhafterweise für jede der Nachrichten einzeln durchgeführt.
  • Die Verarbeitung einer empfangenen Nachricht beginnt im nachfolgenden Schritt 2020. In diesem (optionalen) Schritt 2020 wird zunächst überprüft, ob die empfangene Nachricht relevant ist. Hierzu kann beispielsweise überprüft werden, ob die empfangene Nachricht eine Nachricht ist, die geeignet ist in einem oder mehreren der designierten Empfänger eine Diagnosefunktion zu aktivieren (in diesem Fall wird die empfangene Nachricht auch „Diagnosebotschaft“ genannt). Ist dies nicht der Fall (Ausgang „n“) folgt Schritt 2030.
  • Im (optionalen) Schritt 2030 wird die empfangene Nachricht (z.B. inklusive Metainformationen) in einem Zwischenspeicher gepuffert, und kann somit optional in Schritt 2020 Prüfung von irregulären Eingriffen verwendet werden, um auch Sequenzen von Nachrichten zu erkennen, die nicht einzeln, aber als Sequenz nicht valide sind. Andere vordefinierte Parameter, die im Netzwerk 10 als relevant definierte Nachrichten identifiziert sind, 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 eine Überwachung von Zeitstempeln. Anschließend wird zurückverzweigt zu Schritt 2010.
  • Wird in Schritt 2020 hingegen erkannt, dass die empfangene Nachricht nicht valide ist (Ausgang „j“) folgt Schritt 2040. Dies kann beispielsweise wie in Schritt 1020 erfolgen, oder alternativ oder zusätzlich dadurch, dass erkannt wurde, dass eine „non default“-Diagnosesession aktiviert ist und zusätzlich in der empfangenen Nachricht eine als kritisch eingestufte Diagnosefunktion aktiviert wird. Dies kann optional weiterhin auf bestimmte Betriebsbereiche des Kraftfahrzeugs eingeschränkt werden, beispielsweise, dass als weitere Bedingung überprüft wird, ob das Kraftfahrzeug zusätzlich fährt. Ist dies der Fall (Ausgang „j“) folgt die Aktivierung von Gegenmaßnahmen in Schritt 2050, andern falls (Ausgang „n“) wird zurückverzweigt zu Schritt 2010.
  • In Schritt 2050 kann die Gegenmaßnahme wie in Schritt 1050 beschrieben erfolgen. Alternativ oder zusätzlich kann das folgende Verfahren vorgesehen sein. Zunächst wird optional auf Basis der empfangenen Nachricht überprüft (z.B. auf Basis einer in dieser Nachricht enthaltenen Kennung), wer der designierte Empfänger ist bzw. welche Teilnehmer 1, 2, 4 von dem irregulären Diagnoseeingriff betroffen sind. Damit ist es möglich, den Abwehrmechanismus gezielt für die betroffenen Teilnehmer 1, 2, 4 auszulösen.
  • Zur Abwehr irregulärer Diagnoseeingriffe kann dann Teilnehmer 3 mittels weiterer Diagnosefunktionen den designierten Empfänger veranlassen, die irregulär aktivierte Diagnosefunktion zu beenden. Dies kann wie beschrieben über eine generische Methode, über das Verlassen der aktiven non-default-Diagnosesession oder auch einer gezielten Methoden zum Beenden der irregulär aktivierten Diagnosefunktion mittels einer Subfunktion eines weiteren Diagnoseservices erfolgen. Teilnehmer 3 sendet die entsprechenden Anfragen an den designierten Empfänger. Dabei kann die gleiche Adressierung im Netzwerk 10 verwendet werden, mit der der irreguläre Eingriff erfolgt ist, oder alternativ auch über eine andere vordefinierte Adressierung, über welche der designierte Empfänger für Diagnoseanfragen angesprochen werden kann.
  • Es folgt der optionale Schritt 2060, in dem der erkannte irreguläre Diagnoseeingriff aufgezeichnet wird und in einem Speicher im Kraftfahrzeug und/oder außerhalb des Kraftfahrzeugs abgelegt wird.
  • Es folgt der ebenfalls optionale Schritt 2070, in dem der detektierte irreguläre Diagnoseeingriff dem Fahrer des Kraftfahrzeugs oder z.B. dem Hersteller gemeldet wird. Dies kann beispielsweise über eine Meldung im Dashboard und/oder über ein Infotainmentsystem und/oder über eine Mitteilung an angebundene Dienste außerhalb des Kraftfahrzeugs erfolgen.
  • Damit endet dieser Durchlauf des Verfahrens und es wird zurückverzweigt zu Schritt 2010.
  • 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]
  • Zitierte Nicht-Patentliteratur
    • ISO14229 [0009]
    • Norm ISO14229 [0010]
    • ISO14229 [0011]
    • ISO14229 [0011]
    • ISO14229 [0012]
    • ISO14229 [0012]
    • ISO14229 [0020]
    • ISO14229 [0020]

Claims (15)

  1. Verfahren zum Betreiben eines Bussystems (10), bei dem eine Nachricht des Bussystems (10) empfangen und ihre Validität ermittelt wird, dadurch gekennzeichnet, dass dann, wenn ermittelt wurde, dass die Nachricht „nicht valide“ ist, eine Abwehrnachricht an einen designierten Empfänger (2) der Nachricht gesendet wird, wobei die Abwehrnachricht derart ausgebildet ist, dass der designierte Empfänger (2) durch die Abwehrnachricht angewiesen wird, Abwehrmaßnahmen gegen die Nachricht einzuleiten.
  2. Verfahren nach Anspruch 1, wobei die Abwehrnachricht ausgebildet ist, den designierten Empfänger (2) dazu zu veranlassen, eine aktive „non-default“-Diagnosesession zu deaktivieren
  3. Verfahren nach Anspruch 2, wobei die Abwehrnachricht ausgebildet ist, den designierten Empfänger (2) dazu zu veranlassen, eine weitere „non-default“-Diagnosesession zu starten.
  4. Verfahren nach Anspruch 2, wobei die Abwehrnachricht ausgebildet ist, den designierten Empfänger (2) dazu zu veranlassen, einen Protokollwechsel von einem der „non-default“-Diagnosesession zugeordneten Diagnoseprotokoll hin zu einem anderen Diagnoseprotokoll zu veranlassen.
  5. Verfahren nach Anspruch 1, wobei die Abwehrnachricht als ein DISCONNECT-Kommando des CCP- und/oder des XCP-Standards ausgebildet ist.
  6. Verfahren nach Anspruch 1, wobei die Abwehrnachricht ausgebildet ist, den designierten Empfänger (2) dazu zu veranlassen, die Nachricht zu deaktivieren.
  7. Verfahren nach Anspruch 6, wobei die Abwehrnachricht ausgebildet ist, vom designierten Empfänger (2) als nicht valide Nachricht identifiziert zu werden.
  8. Verfahren nach Anspruch 7, wobei die Abwehrnachricht eines oder mehrere der folgenden Merkmale aufweist: – Einen falschen DLC – Einen falschen CRC – Einen falschen Botschaftszähler – Eine gleiche Kennung wie die empfangene Nachricht – Eine Priorität, die höher ist als die Priorität der empfangenen Nachricht – Signalwert – Einen Ersatzwert für ein Signal – Einen falschen Signal-Qualifier
  9. Verfahren nach einem der vorherigen Ansprüche, wobei eine weitere Abwehrnachricht gesendet wird.
  10. Verfahren nach Anspruch 9, wobei weitere Abwehrnachrichten so lange gesendet werden, bis der designierte Empfänger (2) eine Abwehrmaßnahme eingeleitet hat.
  11. Verfahren nach einem der vorherigen Ansprüche, wobei die empfangene Nachricht gespeichert wird, wenn sie als „valide“ eingestuft wurde.
  12. Verfahren nach Anspruch 11, wobei abhängig von empfangenen gespeicherten Nachrichten entschieden wird, ob die Nachricht als „valide“ eingestuft wird.
  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 (3), die eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
DE102016212816.7A 2016-07-13 2016-07-13 Verfahren und Vorrichtung zum Betreiben eines Bussystems Pending DE102016212816A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102016212816.7A DE102016212816A1 (de) 2016-07-13 2016-07-13 Verfahren und Vorrichtung zum Betreiben eines Bussystems
US15/643,791 US10554444B2 (en) 2016-07-13 2017-07-07 Method and device for operating a bus system
CN201710564863.5A CN107623608A (zh) 2016-07-13 2017-07-12 用于运行总线系统的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016212816.7A DE102016212816A1 (de) 2016-07-13 2016-07-13 Verfahren und Vorrichtung zum Betreiben eines Bussystems

Publications (1)

Publication Number Publication Date
DE102016212816A1 true DE102016212816A1 (de) 2018-01-18

Family

ID=60782867

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016212816.7A Pending DE102016212816A1 (de) 2016-07-13 2016-07-13 Verfahren und Vorrichtung zum Betreiben eines Bussystems

Country Status (3)

Country Link
US (1) US10554444B2 (de)
CN (1) CN107623608A (de)
DE (1) DE102016212816A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016219475A1 (de) 2016-10-07 2018-04-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Bussystems

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018217964A1 (de) * 2018-10-19 2020-04-23 Robert Bosch Gmbh Verfahren und Vorrichtung zur Überwachung einer Datenkommunikation
CN113259055B (zh) * 2021-05-19 2022-11-25 金华卓远实业有限公司 一种单线uart高效通讯方法

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 (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4620302A (en) * 1984-01-06 1986-10-28 Burroughs Corporation Programmable digital signal testing system
US4890224A (en) * 1986-06-27 1989-12-26 Hewlett-Packard Company Method and apparatus for fault tolerant communication within a computing system
US5422877A (en) * 1993-06-01 1995-06-06 Otis Elevator Company Dual bus switching
US5894485A (en) * 1997-03-31 1999-04-13 Emc Corporation Disk array write protection at the sub-unit level
US8165160B2 (en) * 2006-09-29 2012-04-24 Intel Corporation Method and system to validate a write for a device on a serial bus
JP4287456B2 (ja) * 2006-10-26 2009-07-01 株式会社東芝 サービス不能攻撃を防止するサーバ装置、方法およびプログラム
US8443256B2 (en) * 2011-01-24 2013-05-14 Xilinx, Inc. Method and apparatus for determining a cyclic redundancy check (CRC) for a data message
US8549389B2 (en) * 2011-05-24 2013-10-01 Honeywell International Inc. Systems and methods for 1553 bus operation self checking
US8925083B2 (en) * 2011-10-25 2014-12-30 GM Global Technology Operations LLC Cyber security in an automotive network
WO2014061021A1 (en) 2012-10-17 2014-04-24 Tower-Sec Ltd. A device for detection and prevention of an attack on a vehicle
US9401923B2 (en) * 2013-10-23 2016-07-26 Christopher Valasek Electronic system for detecting and preventing compromise of vehicle electrical and control systems
US9616828B2 (en) 2014-01-06 2017-04-11 Argus Cyber Security Ltd. Global automotive safety system

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

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ISO14229
Norm ISO14229

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016219475A1 (de) 2016-10-07 2018-04-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Bussystems
US11366938B2 (en) 2016-10-07 2022-06-21 Robert Bosch Gmbh Method and device for operating a bus system

Also Published As

Publication number Publication date
US20180019895A1 (en) 2018-01-18
US10554444B2 (en) 2020-02-04
CN107623608A (zh) 2018-01-23

Similar Documents

Publication Publication Date Title
DE10113917B4 (de) Verfahren und Vorrichtung zur Überwachung von Steuereinheiten
EP3262797B1 (de) Kraftfahrzeug-kommunikationsnetzwerk mit switchvorrichtung
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
DE102007028766A1 (de) Prüfverfahren und elektronische Schaltung zur sicheren seriellen Übertragung von Daten
EP3523941B1 (de) Kommunikationsdaten-authentifizierungsvorrichtung für ein fahrzeug
DE102017208553A1 (de) Verfahren zum Schutz eines Netzwerkes vor einem Cyberangriff
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102013217461B4 (de) Verfahren und Anordnung zur Überwachung einer Komponente in einem Kraftfahrzeug
DE102017209557A1 (de) Verfahren zum Schutz eines Fahrzeugnetzwerks gegen manipulierte Datenübertragung
DE102016212816A1 (de) Verfahren und Vorrichtung zum Betreiben eines Bussystems
DE102017209556A1 (de) Verfahren zum Schutz eines Fahrzeugnetzwerks gegen manipulierte Datenübertragung
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
WO2018060250A1 (de) Verfahren und system zum schutz eines bordkommunikationsnetzwerks eines kraftfahrzeugs
DE102016214279A1 (de) Verfahren und Vorrichtung zum Betreiben eines Bussystems
DE102022201895A1 (de) Mitigation einer manipulation von software eines fahrzeugs
DE102012209445A1 (de) Verfahren und Kommunikationssystem zur sicheren Datenübertragung
DE102018212657A1 (de) Verfahren und Vorrichtung zum Erkennen von Unregelmäßigkeiten in einem Rechnernetz
DE102021210902A1 (de) Techniken zum detektieren eines eindringens in ein bussystem
DE102017223417B4 (de) Verfahren zum Selbsttest, Datenbusanordnung und Verwendung
DE102021203230A1 (de) Frame-Invalidierung im Bussystem mit Eindringenserkennungssystem
DE102013022498A1 (de) Verfahren und Vorrichtung zum Betrieb eines Kommunikationsnetzwerks insbesondere eines Kraftfahrzeugs
DE102010063528A1 (de) Verfahren zum Verbinden von Busleitungen zu Bussen und Vorrichtung zur Ausführung des Verfahrens
DE102020212452B3 (de) Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
DE102016216700A1 (de) Verfahren zum Identifizieren einer defekten Fahrzeugkomponente in einem Kraftfahrzeug sowie Kraftfahrzeug mit über ein Kommunikationsnetzwerk gekoppelten Fahrzeugkomponenten
DE102021206394A1 (de) Bestätigungseinheit und Steuerziel für ein redundantes Steuerungssystem, redundantes Steuerungssystem und -verfahren

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
R084 Declaration of willingness to licence