-
Die Erfindung betrifft ein Verfahren zum Betreiben einer externen Schnittstelle in einem Steuergeräteverbund, insbesondere einem Steuergeräteverbund in einem Kraftfahrzeug, und eine Anordnung zur Durchführung des Verfahrens.
-
Stand der Technik
-
In Kraftfahrzeugen werden Steuergeräte zum Steuern und Regeln technischer Abläufe eingesetzt. Die Steuergeräte bilden einen Steuergeräteverbund, in welchem sie miteinander verbunden sind. Zum Ansprechen der Steuergeräte von außen, bspw. zu Diagnosezwecken, ist es erforderlich, eine externe Schnittstelle bereitzustellen, die den hierfür erforderlichen Datenaustausch ermöglicht und auch ggf. unterschiedliche Bussysteme und Netzwerkprotokolle miteinander verbindet. Hierzu werden bspw. sogenannte Gateways eingesetzt.
-
Mit Gateway wird allgemein eine Übergabestelle bezeichnet, die dazu dient, Rechnernetze, die unterschiedliche Netzwerkprotokolle verwenden, zu verbinden. In Steuergeräten werden Gateways als Vermittlungsgeräte eingesetzt, um einen Datenaustausch zwischen Steuergeräte-Netzwerken, also ein Lesen und Schreiben von Steuergeräten, zu ermöglichen. In einem Steuergeräteverbund dient in vielen Fällen eines der Steuergeräte als externe Schnittstelle bzw. Gateway.
-
Fahrzeug-Steuergeräte verfügen über Diagnosefunktionen, um eine On-Board-Diagnose (OBD), die ein Fahrzeugdiagnosesystem darstellt, durchführen zu können. Bei OBD sind Form und Inhalt standardisiert. Dabei werden bspw. vereinheitlichte Diagnosedienste, die als Unified Diagnostic Services (UDS) bezeichnet werden, eingesetzt. Dies stellt ein Diagnosekommunikationsprotokoll insbesondere im Steuergerätebereich innerhalb der Automobilelektronik dar. Dieses Protokoll wird mittlerweile Fahrzeughersteller-übergreifend verwendet und stellt keinen firmenspezifischen Standard dar.
-
UDS stellt ein zusätzliches Protokoll bzw. Format dar, das in den Steuergeräten von unterschiedlichen Software-Modulen verarbeitet wird. Dabei wird in vielen Fällen über die gleiche Schnittstelle auf das Bus-Netzwerk bzw. auf die Steuergeräte zugegriffen.
-
Die UDS-Botschaft ist einheitlich aufgebaut und umfasst ein Parameterfeld und ein Datenfeld. Jeder Dienst muss durch einen Aufruf eines Klienten gestartet werden und ist erst beendet, wenn das Steuergerät die Anfrage beantwortet hat. Zu beachten ist, dass bei UDS nur das Format standardisiert ist, der Inhalt wird OEM-spezifisch definiert. Insbesondere sind Aufbau und Dienstkennungen bzw. Service IDs standardisiert. Fahrzeug bzw. OEM spezifisch sind (CAN-)Adressen der Steuergeräte und über die ServiceID auslesbare bzw. veränderbare Daten.
-
So sind externe Schnittstellen in einem Fahrzeug, z. B. eine OBD-2-Buchse oder eine GSM-fähige Head-Einheit bzw. Unit mit Bus-Anbindung, bekannt, über die von extern Diagnosebefehle auf den Fahrzeugbus, z.B. CAN, gegeben werden können. Diese stellen Gateway-Module auf dem Fahrzeugbus dar, die bspw. CAN-Botschaften anhand ihrer CAN-Kennung bzw. ID filtern.
-
Zu beachten ist, dass immer mehr Drittanbieter nachrüstbare Lösungen anbieten, um über die gegebenen externen Schnittstellen, bspw. OBD-2-Buchse mit OBD-Dongle oder Telematics mit Smartphone-App, standardisierte OBD-Befehle an die OBD-fähigen Steuergeräte zu schicken. Dies dient bspw. dazu, um bspw. Fahrzeug- oder Motordaten, wie Verbrauch, gefahrene Kilometer, DTCs (Diagnostic Trouble Code; Fehlereintrag) usw., auszulesen.
-
Weiterhin ist zu berücksichtigen, dass es über ein Reverse Engineering auch möglich ist, die für ein spezifisches Steuergerät gültigen UDS-Befehle zu ermitteln und z. B. in einer App anzubieten. Über diese UDS-Befehle sind weitaus mehr Daten aus dem Fahrzeug abrufbar und damit erweiterte Geschäftsmodelle möglich.
-
Über UDS können jedoch auch Aktuatoren beeinflusst werden, so dass sich daraus sicherheitskritische Situationen ergeben können, z. B. durch ungewollte Aktuatoransteuerung bei hoher Geschwindigkeit.
-
Es muss daher eine Möglichkeit geschaffen werden, diese Dienste nutzen zu können, ohne die damit verbundenen Nachteile und Gefahren in Kauf nehmen zu müssen.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund werden ein Verfahren mit den Merkmalen des Anspruchs 1 und eine Anordnung gemäß Anspruch 8 vorgestellt. Ausführungsformen ergeben sich aus den abhängigen Ansprüchen und der Beschreibung.
-
Das vorliegende Verfahren verwendet somit in Ausgestaltung ein Bus-Gateway mit Filter für Befehle eines Diagnosedienstprotokolls, bspw. UDS-Befehle, der es ermöglicht, auf Basis einer externen Vorgabe spezifische Dienste, bspw. UDS-Services, die typischerweise standardisiert sind, zu blockieren oder passieren zu lassen. Wenn dieser Filter vor der externen Schnittstelle, dem Gateway, platziert wird, können die entsprechenden Botschaften von externen, nachgerüsteten Geräten gar nicht mehr an die am Fahrzeugbus angeschlossenen Steuergeräte gelangen.
-
Der Filter kann derart eingerichtet sein, dass dieser vor Manipulationen geschützt ist. Dies dient der Sicherheit bzw. Security. Mit dem Filter kann ein steuergerätespezifisches Filtern bspw. dadurch erfolgen, dass die Kennung bzw. ID des empfangenden Steuergeräts bekannt und entsprechend verwendet wird. Es kann jedoch auch ein Filter verwendet werden, der diese Kennung bzw. die Kennungen nicht berücksichtigt und somit Dienste bzw. Services für alle Steuergeräte blockiert.
-
Die Freigabe von derartigen Diensten, wie bspw. UDS-Services, bzw. die Aktivierung der Filterung kann fahrzeugintern über ein zentrales Fahrzeugsteuergerät, bspw. mittels hinterlegter Schlüssel, Dongle usw., über den Fahrzeug-Bus oder fahrzeugextern, bspw. über eine Cloud-Online-Aktivierung, über direkte GSM-Verbindung oder fahrzeugextern durch ein davor geschaltetes Freischaltungsverfahren, z. B. mit zufälliger Startzahl bzw. Seed & Key, mit dem Sender der UDS-Botschaften erfolgen.
-
Unter einer Cloud wird hierin ein entferntes Rechenzentrum verstanden, in dem Daten abgelegt sind, auf die Teilnehmer bzw. Nutzer der Cloud von entfernt zugreifen können.
-
Das vorgestellte Verfahren hat, zumindest in einigen der Ausführungsformen, eine Reihe von Vorteilen:
-
So können UDS-basierte Funktionen, die bspw. über Aftermarket-Produkte bzw. Drittanbieter realisiert werden, zentral oder sogar von der Ferne bzw. "remote" aktiviert oder deaktiviert werden, um z. B.
- – Verfügbarkeitseinschränkungen durch schlecht programmierte externe Apps zu vermeiden,
- – die Freischaltung separat bezahlen zu lassen von einem Fahrer oder Drittanbieter, und
- – die Freischaltung erst nach einer Aufklärung oder Schulung des Fahrers über die Gefahren durch den Einsatz externer Apps durchzuführen.
-
UDS-Funktionen, die Aktuatoren beeinflussen und damit je nach aktueller Fahrsituation sicherheitskritisch sein können, können auf Basis von fahrzeugexternen Daten, z. B. einer GPS-Position zur Cloud, blockiert werden, um Gefährdungen zu vermeiden. Es kann z. B. die Anweisung
$2F = "Input Output Control By Identifier"
während Autobahnfahrt blockiert werden.
-
Die Filterung erfolgt anhand der im UDS-Standard definierten Dienste, z. B.
- – $22 ("Read Data By Identifier"; Lese Daten mittels Kennung) dauerhaft erlaubt,
- – $2E ("Write Data By Identifier"; Schreibe Daten mittels Kennung) aktivierbar,
- – $2F ("Input Output Control By Identifier"; Eingabe-Ausgabe-Steuerung mittels Kennung) aktivierbar.
-
Die vorstehend aufgeführten UDS-Dienste sind nur beispielhaft genannt, das vorgestellte Verfahren ist selbstverständlich auch bei anderen Diensten anderer Diagnoseprotokolle anwendbar. Diese Diagnoseprotokolle ermöglichen es, in einem Kraftfahrzeug verbaute Steuergeräte, die in einem Steuergeräteverbund vorliegen, mit Hilfe der in dem Protokoll definierten Anweisungen kontaktieren und warten zu können. Die Diagnosedienste spielen sich hierbei üblicherweise auf einer anderen Ebene wie z. B. das CAN-Protokoll ab, das nur die erste und zweite Schicht des OSI-Modells verwendet.
-
Zu beachten ist, dass Diagnosedienste in der Regel lesende und schreibende Befehle umfassen. Das hierin beschriebene Verfahren ist dazu ausgelegt, nach Bedarf lesende und/oder schreibende Befehle zu erkennen und diese ggf. zu filtern, d. h. zu blockieren, oder diese durchzulassen.
-
Weiterhin ist das Verfahren anwendbar in einem Steuergeräteverbund mit mindestens einem Steuergerät. Die externe Schnittstelle bzw. das Gateway kann dabei als eigenes Steuergerät ausgebildet sein oder als Modul, das in einem von dem mindestens einen Steuergerät integriert ist.
-
Es ist weiterhin zu berücksichtigen, dass die Filterung auch die CAN-Kennung bzw. ID mit einbeziehen kann, um nur spezifische Steuergeräte von Diagnosediensten, bzw. UDS-Services, abzuschotten.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt eine Ausführung eines Steuergeräteverbunds mit Aktivierungs- und Filtersystem für ein einzelnes Steuergerät.
-
2 zeigt einen weiteren Steuergeräteverbund mit Aktivierungs- und Filtersystem für mehrere Steuergeräte.
-
Ausführungsformen der Erfindung
-
Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
-
1 zeigt einen Steuergeräteverbund, der insgesamt mit der Bezugsziffer 10 bezeichnet ist. Weiterhin zeigt die Darstellung ein Diagnosesystem 12, ein Filter bzw. Filtersystem 14, ein Aktuator-Steuergerät 16, einen Aktuator 18, eine Cloud 20, ein fahrzeuginternes System 22, ein Sensoriksystem 24, einen ersten Signalweg 26, einen zweiten Signalweg 28, einen dritten Signalweg 30 und einen vierten Signalweg 32. Mit Bezugsziffer 34 ist eine externe Schnittstelle bzw. ein Gateway bezeichnet.
-
Das Diagnosesystem 12 ist über den ersten Signalweg 26, z. B. eine OBD-2-Buchse auf CAN, an das Filtersystem 14, bspw. ein CAN-Gateway oder Steuergeräte-intern, angeschlossen und schickt über das Filtersystem 14 und den zweiten Signalweg 28, z. B. CAN oder Steuergeräte-intern, UDS-Befehle an das Aktuator-Steuergerät 16. Dieses steuert unter Umständen auf Grundlage dieser Befehle bzw. Anweisungen den Aktuator 18 an.
-
Auf Basis von vorgegebenen Aktivierungsbedingungen werden einzelne UDS-Befehle in der Cloud 20 freigegeben oder gesperrt. Die Aktivierungsbedingungen können sein z.B.
- – Freischaltung nach Bezahlung,
- – über das fahrzeuginterne System 22 über bspw. das Sensoriksystem 24 erkannte Fahrsituation oder Bedingung, z. B. GPS-Position, die über den vierten Signalweg 32 an die Cloud 20 gesendet wurde,
- – weitere.
-
Die Entscheidung über die Freigabe wird dem Filtersystem 14 über den dritten Signalweg 30 mitgeteilt. Somit erfolgt die Aktivierung der Filterung von extern.
-
Alternativen für den Einsatz der Cloud 20 können sein:
- – Freischaltung über das fahrzeuginterne System 22, wie bspw. ein Schlüssel oder ein Fahrerassistenzsystem oder Telematiksystem, das mit der Cloud 20 Informationen austauscht oder eine Head Unit oder ein Steuergerät, mit dem der Fahrer bzw. der Werkstattmechaniker direkt interagieren kann,
- – Freischaltung über ein fahrzeugexternes UDS-System, bspw. mittels eines zufälligen Startwerts bzw. Seed & Key.
-
Dies bedeutet, dass alternativ auch ein Aktivieren der Filterung von intern vorgesehen sein kann. Das interne Filtern kann bspw. durch ein internes Steuergerät oder ggf. auch durch einen angeschlossenen Diagnosetester, bspw. in der Werkstatt, aktiviert werden. Dieser setzt den Filter im Gateway direkt oder indirekt über ein anderes Steuergerät, bspw. eine Head Unit.
-
Je nach gemeldeter Freigabe filtert das Filtersystem 14 spezifische UDS-Befehle/-Services, z. B. anhand einer Tabelle, von dem Diagnosesystem 12 heraus, so dass sie erst gar nicht von dem Aktuator-Steuergerät 16 empfangen werden.
-
Je nach Platzierung des Gateways 34 können somit auch mehrere Steuergeräte abgeschottet werden. Es wird hierzu auf 2 verwiesen, die eine weitere Ausführung des Steuergeräteverbunds 50 zeigt. Die Darstellung zeigt weiterhin ein Diagnosesystem 52, ein Filtersystem 54, ein erstes Aktuator-Steuergerät 56, einen ersten Aktuator 58, eine Cloud 60, ein fahrzeuginternes System 62, ein Sensoriksystem 64, einen ersten Signalweg 66, einen zweiten Signalweg 68, einen dritten Signalweg 70 und einen vierten Signalweg 72. Bezugsziffer 74 bezeichnet eine externe Schnittstelle bzw. ein Gateway.
-
Weiterhin zeigt die Darstellung ein zweites Aktuator-Steuergerät 80, einen zweiten Aktuator 82, ein drittes Aktuator-Steuergerät 84 und einen dritten Aktuator 86. Darüber hinaus ist ein Speicherelement 90 dargestellt, das dem Gateway 74 zugeordnet ist und in dem eine Liste 92 abgelegt ist, in der zu blockierende und/oder freigegebene Anweisungen bzw. Befehle abgelegt sind. Diese Liste 92 kann bspw. in der Werkstatt eingegeben werden und ggf. in regelmäßigen Abständen über die Cloud 60 aktualisiert werden.
-
Mit dem vorgestellten Verfahren ist es somit möglich, mehrere Steuergeräte, in diesem Fall die Aktuatorsteuergeräte 65, 80 und 84 abzuschotten, d. h. eingehende Anweisungen nicht an diese weiterzuleiten.
-
Es ist weiterhin zu berücksichtigen, dass die Freischaltung in einer Werkstatt, bspw. mit einem Diagnosetester, wie bisher oder zusätzlich über eine GPS-Ortung der Werkstatt erfolgen kann.
-
Es ist somit vorgesehen, dass über die externe Schnittstelle 74 Anweisungen eines Diagnosedienstes des Diagnosesystems 52 an die Aktuator-Steuergeräte 56, 80 und 84 weitergeleitet werden können. Dabei ist die externe Schnittstelle 74 derart eingerichtet ist, dass eine Filterung aktiviert werden kann, so dass das Weiterleiten ausgewählter Anweisungen des Diagnosedienstes zu wenigstens einem der Steuergeräte 56, 80, 84 blockiert wird.
