Vorrichtung zur Absicherung von Diagnosebefehlen an ein Steuergerät und entsprechendes Kraftfahrzeug

Die vorliegende Erfindung betrifft eine Vorrichtung zur Absicherung von

Diagnosebefehlen an ein Steuergerät. Die vorliegende Erfindung betrifft darüber hinaus ein entsprechendes Kraftfahrzeug.

Stand der Technik

Zur Wartung kraftfahrzeugtechnischer Steuergeräte sind vereinheitlichte Diagnosedienste (unified diagnostic Services, U DS) gemäß ISO 14229 hinreichend bekannt. Mittels derartiger Dienste ist es zum Beispiel möglich, den Fehlerspeicher einzelner Steuergeräte (electronic control units, ECUs) abzufragen oder diese mit einer neuen Firmware oder Anwendungssoftware zu aktualisieren. Der UDS-Standard definiert hierzu ein Kommunikationsprotokoll auf der Sitzungsschicht (session layer) und Anwendungsschicht (application layer) des OS I- Referenzmodells.

DE102016201279A1 offenbart ein Verfahren zum Überwachen einer

Aktualisierung eines Fahrzeuges mit folgenden Schritten: Das Fahrzeug wird in einen sicheren Zustand überführt; der sichere Zustand wird verriegelt; ein energetischer Zustand des Fahrzeuges wird abgefragt; abhängig vom energetischen Zustand wird entweder ein Steuergerät des Fahrzeuges aktualisiert oder das Verfahren vorzeitig kontrolliert abgebrochen und der sichere Fahrzeugzustand wird entriegelt. Offenbarung der Erfindung

Die Erfindung stellt eine Vorrichtung zum Überwachen von Diagnosebefehlen an ein oder mehrere Steuergeräte sowie ein entsprechendes Kraftfahrzeug gemäß den unabhängigen Ansprüchen bereit.

Der vorgeschlagene Ansatz fußt hierbei auf der Erkenntnis, dass, um flexible Steuerungsabläufe von Diagnose- oder Software-Aktualisierungsbefehlen zu ermöglichen, entsprechende Befehlssequenzen auf Grundlage von

interpretierten Skriptsprachen (etwa Python) erzeugt werden können. Zum Einsatz kommen ferner Sprachen, welche für eine virtuelle Maschine kompiliert werden, die ihrerseits einen generischen Bytecode ausführt (etwa Lua oder Java).

Derart flexible Steuerungsabläufe werden von potenziell nicht

vertrauenswürdigen Skripts verarbeitet, die von einem ebenso wenig

vertrauenswürdigen Skript-Interpreter ausgeführt werden, der wiederum auf einer ECU läuft, die möglicherweise nicht für Sicherheitsanwendungen ausgelegt ist. In einem sicherheitsrelevanten System kann ein solches Setup Gefahren durch unbeabsichtigte Eingriffe in sicherheitsrelevante Steuergeräte aufgrund fehlerhafter Steuerungsabläufe verursachen, wenn es keine Mechanismen gibt, um dieses Risiko zu mindern.

Skriptbasierte Programmierung bietet somit einerseits hohe Flexibilität und stellt eine dynamische Technik für zukünftige Anwendungen dar. Auf der anderen Seite erfordern die meisten Sicherheitsstandards eine statische Programmierung mit klar definierten Zuständen. Dieses Problem verschärft sich mit der Einführung von Firmware- und Software- Updates über die Luftschnittstelle (over the air, OTA), bei welchen - im Gegensatz zur Aktualisierung in der Werkstatt - jederzeit und überall unbeabsichtigte Aktionen ohne definierte Zustände und

Überwachung durchgeführt werden können.

Um die Verwendung von etablierten Diagnoseprotokollen und eine skriptbasierte Verarbeitung in sicherheitsrelevanten Systemen zu ermöglichen, wird daher eine Systemarchitektur vorgeschlagen, um die Ausführung der Diagnosebefehlsfolgeerzeugung, die Überwachung der Befehle und die empfangende sicherheitsrelevante ECU zu trennen. Zusätzlich wird eine Methode zur Überwachung der Diagnosebefehle eingeführt, um

sicherheitsrelevante eingebettete Ziel-ECUs vor unbeabsichtigten Eingriffen zu schützen. Der Begriff„Diagnosebefehle" wird hierbei in einem weiten Sinne für beliebige Befehlsfolgen verwendet, um eingebettete Ziel-ECUs zum Zwecke der Diagnose, Softwareaktualisierung oder im Rahmen anderer Anwendungen zu steuern.

Sowohl die Softwarearchitektur als auch die Methode der Überwachung der Diagnosebefehle erlaubt die Verwendung von etablierten

Diagnosekommunikationsprotokollen wie UDS für sicherheitsrelevante

Anwendungen.

Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann ein Befehlsfilter vorgesehen sein, um gültige Befehle unter den Diagnosebefehlen anhand vorgegebener Bedingungen zu selektieren. Diese Bedingungen können angepasst werden, um die Anforderungen unterschiedlichster

Sicherheitsstandards zu erfüllen.

Kurze Beschreibung der Zeichnungen

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

Figur 1 die Systemarchitektur gemäß einer Ausführungsform der Erfindung.

Figur 2 schematisch eine Sicherungseinrichtungskomponente dieser

Ausführungsform.

Figur 3 den beispielhaften Ablauf einer Sicherung. Ausführungsformen der Erfindung

Die in Figur 1 dargestellte Systemarchitektur der vorgeschlagenen

Vorrichtung (10) ist in drei Teile gegliedert. Erkennbar ist zunächst ein dynamischer Bereich (12), dessen flexible Ausführungsplattform (18) zur skriptbasierten Generierung von Diagnosebefehlen (16), Software- Updates oder zukünftige Anwendungen dient und diese an das Ziel-Steuergerät (14) weiterleitet. Der dynamische Bereich (12) erfüllt hierbei nicht notwendigerweise die Anforderungen einer bestimmten Sicherheitsanforderungsstufe (safety integrity level, SIL), wie sie etwa für sicherheitsrelevante Systeme in

Kraftfahrzeugen definiert ist. Die Skripte (15) werden somit nicht unbedingt nach

Sicherheitsnormen entwickelt.

Der dynamische Bereich (12) kann die Skripte (15) - z. B. im Falle von

OTA-Anwendungen wie Ferndiagnose, Firmware- oder Software-Updates - aus einer anderen Domäne z.B. über eine drahtlose Verbindung von einer Backend- Infrastruktur beziehen, die nachfolgend als Konnektivitätsbereich (11) bezeichnet wird. Dieser Konnektivitätsbereich (11) kann - muss aber nicht zwingend - auf einer separaten ECU ohne Sicherheitsanforderungen vorgesehen sein. Im dynamischen Bereich (12) werden die Skripte (15) verarbeitet und in Sequenzen von Diagnosebefehlen (16) übersetzt. Vorgesehen ist ferner ein abgesicherter Bereich (13) auf einer

Sicherheitsanforderungsstufe, die der Sicherheitsrelevanz einer unbeabsichtigten Aktivierung des eingebetteten Ziel-Steuergerätes (14) durch die externen Diagnosebefehle (16) Rechnung trägt. Dieser abgesicherte Bereich (13) kann jeder ECU mit einer entsprechenden Sicherheitsintegrität zugeordnet werden. Der abgesicherte Bereich (13) umfasst insbesondere eine - gleichsam als

Brandmauer fungierende - Sicherungseinrichtung (19), welche die

Diagnosebefehle (16) aus dem dynamischen Bereich (12) überwacht und lediglich selektiv ans Ziel-Steuergerät (14) weitergibt, um einen unbeabsichtigten Eingriff in dessen Funktion zu verhindern. Antworten (30) des Ziel-Steuergerätes (14) werden im Normalfall an den dynamischen Bereich (12) zurückgegeben und vom abgesicherten Bereich (13) überwacht. Im Fall von Fehlerrückmeldungen, können diese von der

Sicherheitseinrichtung (19) zum Blockieren von Diagnosebefehlen (16) ausgewertet werden.

Informationen (17) von der Sicherheitseinrichtung (19) an den dynamischen Bereich (12) oder den Konnektivitätsbereich (11) können zum Beispiel

Informationen zu blockierten Befehlen (29) oder Betriebszustände der

Sicherheitseinrichtung (19) sein.

Wie Figur 2 verdeutlich, leitet diese„Firewall"- Komponente nur gemäß definierten Bedingungen (20) gültige Befehle (29) an das eingebettete Ziel-Steuergerät (14) weiter. Diese Bedingungen (20) können das Ergebnis einer oder mehrerer endlicher Zustandsautomaten (finite State machines, FSMs 22, 23, 24) auf verschiedenen Ebenen innerhalb der Vorrichtung (10) sein. In Betracht kommen insbesondere Anwendungszustände (25) - z. B. für Ferndiagnose oder Update - oder Gesamt-Vorrichtungszustände (26). Diese Zustände (25, 26) können - müssen aber nicht zwingend - voneinander abhängen, etwa im Wege eines Informationsaustausches (27) oder durch eine wechselseitige

Sperrbeziehung (28). Es mögen auch Schnittstellen zur externen Vorgabe von Bedingungen (20) oder Abhängigkeiten der Bedingungen (20) von Antworten (30) der Ziel-Steuergeräte (14) vorgesehen sein.

Mit diesen Bedingungen (20) können bereits im Zuge der Entwicklung abgesicherte Betriebszustände der Vorrichtung (10) definiert werden. Abhängig von den Bedingungen (20) gibt es vorzugsweise eine Positivliste von gültigen Befehlen (29), die den Befehlsfilter (21) passieren dürfen, während ungültige Befehle unterdrückt werden. Das Filtern und Blockieren kann gemäß

verschiedenen Konfigurationsvorgaben der Sicherungseinrichtung (19) erfolgen. Zu denken ist etwa an

1. ein Blockieren jeglicher Diagnosebefehle (16),

2. ein Blockieren derjenigen Diagnosebefehle (16), die von bestimmten ECUs stammen oder an ein bestimmtes Steuergerät (14) adressiert sind, 3. ein Überprüfen und Filtern auf der Ebene einzelner Diagnosebefehle (16), um bestimmte gültige Befehle (29) in bestimmten Zuständen (25, 26) zuzulassen und unter anderem Sicherheitszugriffe, Rücksetz- (reset) oder andere unerlaubte Diagnosebefehle (16) zu unterdrücken,

4. ein Überprüfen von Diagnosebefehlen (16) und deren Parametern, um gültige Befehle (29) anhand bestimmter Parameter zu identifizieren und anderweitige Zugriffe - z. B. das Schreiben auf bestimmte

Speicheradressen des Steuergerätes (14) - zu verhindern,

5. ein Blockieren von Diagnosebefehlen (16), deren Auftreten eine

vorgegebene Häufigkeit überschreitet, um den fachsprachlich mit „blubbering idiot" umschriebenen Ausfallmodus zu vermeiden. Genauso können Diagnosebefehle (16) blockiert werden, die Verfälschungen, Verzögerungen oder unbeabsichtigte Wiederholungen aufweisen, die über einer bestimmten Grenze liegen oder

6. ein Blockieren von Diagnosebefehlen (16) an das Steuergerät (14), wenn dieses mit bestimmten Fehlercodes (30) antwortet.

Eine Ausführungsform der Sicherheitseinrichtung (19) mit Befehlsfilter (21) enthält unter anderem die in Figur 3 veranschaulichten Aktivitäten. In konkreten Ausführungsformen müssen nicht immer alle Aktivitäten die ausführenden Komponenten in der tatsächlichen Ausführung unterscheiden:

1. Die Aktualisierung von Firmware, Anwendungssoftware oder anderer Dienste mittels Diagnosebefehlen darf nur ausgeführt werden, wenn sich die Gesamtvorrichtung (z. B. das Fahrzeug) in einem sicheren Zustand befindet. Ein solcher Zustand wäre im Falle eines

Fahrzeuges etwa der Stillstand mit angezogenen Bremsen. Dieser Zustand darf bis zum erfolgreichen Abschluss des Dienstes, z. B. der überprüften Aktualisierung der Firmware oder Anwendungssoftware, nicht verlassen werden. Dazu wird von dem Dienst aus dem dynamischen Bereich eine Zustandssperre angefordert (41). Es sind auch andere Bauformen möglich, bei denen die Anforderung der Zustandssperre (41) beispielsweise im abgesicherten Bereich (13) gestellt wird.

Die Anforderung der Zustandssperre (41) wird, basierend auf

Informationen (31) über den Gerätezustand im abgesicherten Bereich

(13) , über Regeln (40) auf Zulässigkeit geprüft. Sind die Regeln (40) erfüllt, wird die Zustandssperre verhängt. Die Zustandssperre (42) selbst ist durch weitere, abgesicherte Maßnahmen in der

Gesamtvorrichtung zu realisieren, z. B. durch die Verhinderung eines Motorstarts oder die Betätigung einer Feststellbremse.

Nach Anforderung der Zustandssperre (41) sendet die

Ausführungsplattform (18) im dynamischen Bereich (12) eine Abfolge von Diagnosebefehlen (16).

Die Diagnosebefehle (16) werden im abgesicherten Bereich gescannt und im Befehlsfilter (21) anhand der Bedingungen (20) auf

Zulässigkeit geprüft. Die Bedingungen (20) können wiederum von Informationen beispielsweise über den Anwendungszustand (25), den Gesamt-Vorrichtungszustand (26), den Status der Zustandssperre (40, 84), Fahrerbestätigungen oder Sensor- und anderweitigen Informationen abhängen.

Als zulässig bewertete Diagnosebefehle können in einem Sequenz- Filter bezüglich einer gültigen Reihenfolge oder Frequenz geprüft werden (60). Sind die Regeln (60) für die Diagnosebefehl-Sequenz erfüllt (61), wird der gültige Diagnosebefehl (29) an das Steuergerät

(14) weitergeleitet. Es sind auch Bauformen ohne diesen Sequenz- Filter möglich.

Diagnosebefehle (16), die im Befehlsfilter (21, 50) oder Sequenz- Filter (60, 61) als unzulässig erkannt wurden, werden blockiert und nicht an das Steuergerät (14) weitergeleitet. Über eine Fehlerbehandlung (90) werden Informationen (17) zu den blockierten Befehlen bereitgestellt, dies können z. B. Negative Response Codes (NRC) sein. Anschließend wird vom Steuergerät (14) der Flash-Zustand abgefragt (30) und ausgewertet (70). Sind noch nicht alle Software- Blöcke aktualisiert, wird der Dienst fortgesetzt.

Sind alle Software- Blöcke aktualisiert, erfolgt eine Verifizierung (80, 83) der aktualisierten Software. Die Verifizierung wird z.B. aus dem dynamischen Bereich angefordert (82). Eine solche Verifizierung kann z. B. die Überprüfung der aktualisierten Software-Version, einschlägiger Fehlerspeichereinträge oder Abhängigkeiten von den Software-Versionen anderer Steuergeräte einschließen. Die

Verifizierung der aktualisierten Software-Version erfolgt z. B. anhand von Meta-Informationen (81), die z.B. die Soll-Version der Software des Steuergerätes (14) nach erfolgreicher Aktualisierung oder die Abhängigkeit von anderen Steuergeräten beschreiben. Damit ist es möglich, eine Überprüfung auf Konsistenz und Vollständigkeit durchzuführen, beispielsweise dadurch, ob alle erforderlichen Steuergeräte (14) für einen Dienst aktualisiert wurden (71). Die MetaInformationen kommen dabei z. B. unverändert aus dem

Konnektivitätsbereich (11) oder dynamischen Bereich (12). Es sind Maßnahmen auf der Ebene der Gesamt- Vorrichtung zu treffen, die eine Manipulation dieser Meta-Daten über die Luftschnittstelle bis in den abgesicherten Bereich verhindern.

Nach erfolgreicher Verifizierung (80, 83) der aktualisierten Software, wobei diese alle von dem Dienst betroffenen Steuergeräte (14) betreffen kann, wird die eingangs erteilte Zustandssperre wieder aufgehoben (84, 85). Damit ist der Dienst erfolgreich abgeschlossen. Welche Steuergeräte (14) in die Verifizierung einzubeziehen sind, wird durch besagte Meta-Informationen (81) festgelegt.

Ist die Verifizierung der ECUs (14) nicht erfolgreich (83), wird das Ergebnis der Verifizierung einer Fehlerbehandlung (90) zugeführt, in deren Rahmen entsprechende Informationen (17) ausgegeben werden.