WO2019072840A1 - Vorrichtung zur absicherung von diagnosebefehlen an ein steuergerät und entsprechendes kraftfahrzeug - Google Patents
Vorrichtung zur absicherung von diagnosebefehlen an ein steuergerät und entsprechendes kraftfahrzeug Download PDFInfo
- Publication number
- WO2019072840A1 WO2019072840A1 PCT/EP2018/077464 EP2018077464W WO2019072840A1 WO 2019072840 A1 WO2019072840 A1 WO 2019072840A1 EP 2018077464 W EP2018077464 W EP 2018077464W WO 2019072840 A1 WO2019072840 A1 WO 2019072840A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- commands
- states
- following features
- area
- execution platform
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/034—Test or assess a computer or a system
Definitions
- the present invention relates to a device for securing
- the present invention also relates to a corresponding motor vehicle.
- Standardized diagnostic services in accordance with ISO 14229 are sufficiently well-known for servicing motor vehicle control units. By means of such services it is possible, for example, to query the fault memory of individual control units (electronic control units, ECUs) or to update them with a new firmware or application software.
- the UDS standard defines a communication protocol on the session layer and application layer of the OS I reference model.
- DE102016201279A1 discloses a method for monitoring a
- Updating a vehicle with the following steps: the vehicle is transferred to a safe state; the safe state is locked; an energetic state of the vehicle is queried; Depending on the energetic state, either a control unit of the vehicle is updated or the method is terminated prematurely controlled and the safe vehicle state is unlocked. Disclosure of the invention
- the invention provides an apparatus for monitoring diagnostic commands to one or more controllers and a corresponding motor vehicle according to the independent claims.
- the proposed approach is based on the recognition that to allow flexible control of diagnostic or software update instructions, corresponding instruction sequences based on
- interpreted scripting languages such as Python
- languages are used which are compiled for a virtual machine which in turn executes a generic bytecode (such as Lua or Java).
- trusted script interpreter which in turn runs on an ECU that may not be designed for security applications.
- a safety-related system such a setup can cause hazards due to unintentional interventions in safety-related ECUs due to faulty control processes, if there are no mechanisms to reduce this risk.
- script-based programming offers high flexibility and represents a dynamic technique for future applications.
- most security standards require static programming with clearly defined states. This problem is exacerbated by the introduction of firmware and software updates via the air interface (OTA), which - unlike the update in the workshop - anytime, anywhere unintentional actions without defined states and
- OTA air interface
- a system architecture is proposed to avoid the execution of the Diagnostic Instruction Generation to separate the supervision of the commands and the receiving safety related ECU.
- a method for monitoring the diagnostic commands is introduced to
- diagnostic commands is used herein in a broad sense for arbitrary command sequences to control embedded target ECUs for the purposes of diagnostics, software updates, or other applications.
- a command filter may be provided to select valid commands among the diagnostic commands based on predetermined conditions. These conditions can be adjusted to meet the requirements of a wide variety
- Figure 1 shows the system architecture according to an embodiment of the invention.
- FIG. 2 schematically a fuse component of this
- Figure 3 shows the exemplary sequence of a fuse.
- a dynamic area (12) can be recognized, whose flexible execution platform (18) is used for the script-based generation of diagnostic commands (16), software updates or future applications and forwards them to the destination control unit (14).
- the dynamic range (12) does not necessarily meet the requirements of a certain safety integrity level (SIL), such as those for safety-relevant systems in
- the dynamic range (12) may be the scripts (15) - z. B. in the case of
- connectivity area (11) OTA applications such as remote diagnostics, firmware or software updates - from another domain e.g. via a wireless connection from a backend infrastructure, hereinafter referred to as connectivity area (11).
- This connectivity area (11) may or may not be provided on a separate ECU without safety requirements.
- the scripts (15) are processed and translated into sequences of diagnostic instructions (16).
- This secured area (13) can be assigned to each ECU with a corresponding safety integrity.
- the secured area (13) comprises in particular one - as it were
- Responses (30) of the destination controller (14) are normally returned to the dynamic area (12) and from the secured area (13). supervised. In the case of error feedback, these may be from the
- Information (17) from the security device (19) to the dynamic area (12) or the connectivity area (11) may be, for example
- this "firewall" component only forwards valid commands (29) to the embedded target controller (14) according to defined conditions (20) .
- These conditions (20) can be the result of one or more finite state machines (finite State machines, FSMs 22, 23, 24) at different levels within the device 10.
- FSMs 22, 23, 24 finite State machines
- application states (25) for example for remote diagnosis or update-or overall device states (26) are considered.
- 25, 26) can - but need not necessarily - depend on each other, for example by means of an exchange of information (27) or by a reciprocal exchange
- Locking relationship (28) There may also be interfaces for externally specifying conditions (20) or dependencies of the conditions (20) of responses (30) of the destination controllers (14).
- An embodiment of the security device (19) with command filter (21) contains, inter alia, the activities illustrated in FIG. In concrete embodiments, not all activities must always distinguish the executing components in the actual execution:
- Updating firmware, application software or other services using diagnostic commands may only be performed when the overall device (such as the vehicle) is in a safe state. Such a condition would be in the case of one
- the request for the status lock (41) is based on
- the diagnostic commands (16) are scanned in the safe area and in the command filter (21) on the basis of the conditions (20)
- the conditions (20) may in turn depend on information about, for example, the application state (25), the overall device state (26), the status of the status lock (40, 84), driver acknowledgments or sensor and other information.
- Diagnostically evaluated diagnostic instructions may be checked in a sequence filter for a valid order or frequency (60). If the rules (60) for the diagnostic command sequence are satisfied (61), the valid diagnostic command (29) is sent to the controller
- Diagnostic commands (16) that were detected as inadmissible in the command filter (21, 50) or sequence filters (60, 61) are blocked and are not forwarded to the control unit (14). Error handling (90) provides information (17) about the blocked commands.
- NRC Negative Response Codes
- verification (80, 83) of the updated software is performed.
- the verification is e.g. requested from the dynamic range (82).
- Such verification may, for. These include, for example, verifying the updated software version, pertinent error memory entries, or dependencies on the software versions of other controllers.
- Verification of the updated software version is done z. Based on meta-information (81), e.g. describe the desired version of the software of the control unit (14) after successful updating or the dependence on other control units. This makes it possible to check for consistency and completeness, for example by whether all required control devices (14) for a service have been updated (71).
- the MetaInformationen come here z. B. unchanged from the
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Mathematical Physics (AREA)
- Stored Programmes (AREA)
- Automation & Control Theory (AREA)
- Debugging And Monitoring (AREA)
- Human Computer Interaction (AREA)
- Transportation (AREA)
- Mechanical Engineering (AREA)
- Safety Devices In Control Systems (AREA)
Abstract
Vorrichtung (10) zum Überwachen von Diagnosebefehlen (16) an ein Steuergerät (14), gekennzeichnet durch folgende Merkmale: - die Vorrichtung (10) umfasst eine Ausführungsplattform (18) und eine mit der Ausführungsplattform (18) verbundene Sicherungseinrichtung (19) mit einem Befehlsfilter (21) und Zustandsautomaten (22, 23, 24), - die Ausführungsplattform (18) ist eingerichtet, die Diagnosebefehle (16) anhand vorgegebener Skripte (15) zu erzeugen, - der Befehlsfilter (21) ist eingerichtet, gültige Befehle (29) unter den Diagnosebefehlen (16) anhand aus Zuständen (25, 26) der Zustandsautomaten (22, 23, 24) folgender Bedingungen (20) zu selektieren und - die Sicherungseinrichtung (19) ist eingerichtet, die Befehle (29) an das Steuergerät (14) weiterzuleiten.
Description
Beschreibung Titel
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.
Claims
Vorrichtung (10) zum Überwachen von Diagnosebefehlen (16) an ein Steuergerät (14),
gekennzeichnet durch folgende Merkmale:
- die Vorrichtung (10) umfasst eine Ausführungsplattform (18) und eine mit der Ausführungsplattform (18) verbundene
Sicherungseinrichtung (19) mit einem Befehlsfilter (21) und
Zustandsautomaten (22, 23, 24),
- die Ausführungsplattform (18) ist eingerichtet, die Diagnosebefehle (16) anhand vorgegebener Skripte (15) zu erzeugen,
- der Befehlsfilter (21) ist eingerichtet, gültige Befehle (29) unter den Diagnosebefehlen (16) anhand aus Zuständen (25, 26) der
Zustandsautomaten (22, 23, 24) folgender Bedingungen (20) zu selektieren und
- die Sicherungseinrichtung (19) ist eingerichtet, die Befehle (29) an das Steuergerät (14) weiterzuleiten oder zu blockieren.
Vorrichtung (10) nach Anspruch 1,
gekennzeichnet durch folgende Merkmale:
- die Vorrichtung (10) weist einen dynamischen Bereich (12) und einen abgesicherten Bereich (13) auf,
- der dynamische Bereich (12) umfasst die Ausführungsplattform (18) und
- der abgesicherte Bereich (13) umfasst die Sicherungseinrichtung (19).
Vorrichtung (10) nach Anspruch 2,
gekennzeichnet durch folgende Merkmale:
- die Vorrichtung (10) weist ferner einen Konnektivitätsbereich (11) auf und
- die Ausführungsplattform (18) ist ferner eingerichtet, die Skripte (15) aus dem Konnektivitätsbereich (11) entgegenzunehmen.
Vorrichtung (10) nach Anspruch 3,
gekennzeichnet durch folgendes Merkmal:
- die Ausführungsplattform (18) ist ferner eingerichtet, Informationen (17) aus dem abgesicherten Bereich (13) in den dynamischen Bereich (12) oder Konnektivitätsbereich (11) zurückzuliefern.
Vorrichtung (10) nach einem der Ansprüche 1 bis 4,
gekennzeichnet durch folgendes Merkmal:
- das Selektieren der gültigen Befehle (29) erfolgt ferner anhand
bestimmter Antworten (30) des Zielsteuergerätes (14).
Vorrichtung (10) nach einem der Ansprüche 1 bis 5,
gekennzeichnet durch folgende Merkmale:
- um eine Software des Steuergerätes (14) zu aktualisieren, wird anhand vorgegebener Regeln (40) auf Anforderung (41) eine Zustandssperre (42) verhängt und
- nach einer erfolgreichen Verifizierung (83) der aktualisierten Software wird die Zustandssperre (42) aufgehoben (84, 85).
Vorrichtung (10) nach einem der Ansprüche 1 bis 6,
gekennzeichnet durch folgende Merkmale:
- die Sicherungseinrichtung (19) umfasst ferner einen Sequenzfilter und
- der Sequenzfilter ist eingerichtet, die gültigen Befehle anhand weiterer Regeln (60) auf eine zulässige Reihenfolge oder Frequenz zu prüfen (61).
Vorrichtung (10) nach einem der Ansprüche 1 bis 7,
gekennzeichnet durch mindestens eines der folgenden Merkmale:
- die Zustände (25, 26) umfassen Anwendungszustände (25) oder
- die Zustände (25, 26) umfassen Vorrichtungszustände (26).
Vorrichtung (10) nach einem der Ansprüche 1 bis 8,
gekennzeichnet durch mindestens eines der folgenden Merkmale:
- die Zustandsautomaten (22, 23, 24) stehen in einem wechselseitigen Informationsaustausch (27) oder
- die Zustände (25, 26) stehen in einer wechselseitigen
Sperrbeziehung (28).
Kraftfahrzeug mit einem Steuergerät (14) nach einem der Ansprüche 1 bis 9.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/753,614 US11455393B2 (en) | 2017-10-13 | 2018-10-09 | Device for securing diagnostic commands to a control unit, and corresponding motor vehicle |
CN201880066196.0A CN111183412B (zh) | 2017-10-13 | 2018-10-09 | 用于保护对控制仪器的诊断指令的设备和相应的机动车 |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102017218359 | 2017-10-13 | ||
DE102017218359.4 | 2017-10-13 | ||
DE102018214999.2 | 2018-09-04 | ||
DE102018214999.2A DE102018214999A1 (de) | 2017-10-13 | 2018-09-04 | Vorrichtung zur Absicherung von Diagnosebefehlen an ein Steuergerät und entsprechendes Kraftfahrzeug |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019072840A1 true WO2019072840A1 (de) | 2019-04-18 |
Family
ID=65910404
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2018/077464 WO2019072840A1 (de) | 2017-10-13 | 2018-10-09 | Vorrichtung zur absicherung von diagnosebefehlen an ein steuergerät und entsprechendes kraftfahrzeug |
Country Status (4)
Country | Link |
---|---|
US (1) | US11455393B2 (de) |
CN (1) | CN111183412B (de) |
DE (1) | DE102018214999A1 (de) |
WO (1) | WO2019072840A1 (de) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11586383B2 (en) | 2018-10-16 | 2023-02-21 | Micron Technology, Inc. | Command block management |
US20210182386A1 (en) * | 2019-12-11 | 2021-06-17 | Samsung Electronics Co., Ltd. | Electronic apparatus that monitors a safety function and a controlling method thereof |
CN111660815B (zh) * | 2020-05-20 | 2021-11-02 | 摩登汽车有限公司 | 电池管理系统的控制方法 |
DE102020215545A1 (de) | 2020-12-09 | 2022-06-09 | Robert Bosch Gesellschaft mit beschränkter Haftung | Verfahren zur Ansteuerung eines Fahrzeugs |
DE102022123487A1 (de) | 2022-09-14 | 2024-03-14 | Dr. Ing. H.C. F. Porsche Aktiengesellschaft | System, Verfahren und Computerprogrammprodukt zum kontrollierten Updaten einer Software für eine Steuerungseinrichtung |
DE102022210020A1 (de) | 2022-09-22 | 2024-03-28 | Robert Bosch Gesellschaft mit beschränkter Haftung | Sicherheitsdatenverarbeitungseinheit für eine Recheneinheit |
DE102022211725A1 (de) | 2022-11-07 | 2024-05-08 | Robert Bosch Gesellschaft mit beschränkter Haftung | Verfahren zur Überwachung von Schnittstellen zwischen einer Software-Applikation und einem Steuergerät |
DE102023001975A1 (de) | 2023-05-15 | 2024-06-20 | Mercedes-Benz Group AG | Kommunikationssystem und Fahrzeug |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104572141A (zh) * | 2013-10-10 | 2015-04-29 | 上海信耀电子有限公司 | 车用电控单元ecu的引导程序的在线更新方法 |
DE102015209116A1 (de) * | 2015-05-19 | 2016-11-24 | Robert Bosch Gmbh | Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes |
DE102016201279A1 (de) | 2016-01-28 | 2017-08-03 | Robert Bosch Gmbh | Verfahren und Vorrichtung zum Überwachen einer Aktualisierung eines Fahrzeuges |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102011100106A1 (de) * | 2011-04-30 | 2012-10-31 | Daimler Ag | System zur Diagnose einer Komponente in einem Fahrzeug |
US10142420B2 (en) | 2015-08-25 | 2018-11-27 | Ford Global Technologies, Llc | On-board web server telematics systems and methods |
EP3347850B1 (de) * | 2015-09-07 | 2020-04-01 | Karamba Security | Kontextbasierter sicherer betrieb eines steuergeräts und malware-prävention |
WO2018079004A1 (ja) * | 2016-10-27 | 2018-05-03 | 住友電気工業株式会社 | 制御装置、プログラム更新方法、およびコンピュータプログラム |
JP6852604B2 (ja) * | 2017-07-12 | 2021-03-31 | 住友電気工業株式会社 | 車載装置、管理方法および管理プログラム |
-
2018
- 2018-09-04 DE DE102018214999.2A patent/DE102018214999A1/de active Pending
- 2018-10-09 US US16/753,614 patent/US11455393B2/en active Active
- 2018-10-09 CN CN201880066196.0A patent/CN111183412B/zh active Active
- 2018-10-09 WO PCT/EP2018/077464 patent/WO2019072840A1/de active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104572141A (zh) * | 2013-10-10 | 2015-04-29 | 上海信耀电子有限公司 | 车用电控单元ecu的引导程序的在线更新方法 |
DE102015209116A1 (de) * | 2015-05-19 | 2016-11-24 | Robert Bosch Gmbh | Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes |
DE102016201279A1 (de) | 2016-01-28 | 2017-08-03 | Robert Bosch Gmbh | Verfahren und Vorrichtung zum Überwachen einer Aktualisierung eines Fahrzeuges |
Also Published As
Publication number | Publication date |
---|---|
US11455393B2 (en) | 2022-09-27 |
CN111183412A (zh) | 2020-05-19 |
CN111183412B (zh) | 2024-03-01 |
DE102018214999A1 (de) | 2019-04-18 |
US20200272735A1 (en) | 2020-08-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2019072840A1 (de) | Vorrichtung zur absicherung von diagnosebefehlen an ein steuergerät und entsprechendes kraftfahrzeug | |
DE102013003040B4 (de) | Kraftfahrzeug mit nachträglich per Anwendungsprogramm veränderbarem Fahrverhalten sowie Verfahren hierzu | |
DE102016206630A1 (de) | Verfahren und Vorrichtung zur Vermeidung von Manipulation einer Datenübertragung | |
WO2019081395A1 (de) | Verfahren und vorrichtung zum aktualisieren von software eines kfz-steuergerätes | |
EP3709166B1 (de) | Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten | |
DE102018116676A1 (de) | Fahrzeugnetzwerk mit Implementierung einer XCP-Protokoll-Richtlinie und Verfahren | |
DE102014111361A1 (de) | Verfahren zum Betreiben einer Sicherheitssteuerung und Automatisierungsnetzwerk mit einer solchen Sicherheitssteuerung | |
DE102019104055A1 (de) | Diagnosesystem für Kraftfahrzeuge | |
EP1804144A1 (de) | Überprüfung des Steuerprogramms eines Steuergerätes für eine Maschine | |
DE102007006614A1 (de) | Anwendung einer verteilten Diagnosearchitektur in AUTOSAR | |
DE102018213616A1 (de) | Kryptografiemodul und Betriebsverfahren hierfür | |
EP1860565A1 (de) | Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug | |
DE102023110645A1 (de) | Sicherheitsverfahren und Sicherheitsvorrichtung | |
DE102019004612A1 (de) | Verfahren zum Betreiben eines Fahrzeugs mit einem Steuergerät | |
DE102021208459B4 (de) | Verfahren zur authentischen Datenübertragung zwischen Steuergeräten eines Fahrzeugs, Anordnung mit Steuergeräten, Computerprogramm und Fahrzeug | |
DE102019201515A1 (de) | Fahrzeugkommunikationsnetzwerk und -verfahren | |
EP2279480B1 (de) | Verfahren und system zum überwachen eines sicherheitsbezogenen systems | |
EP3499324A1 (de) | Verfahren zur modularen verifikation einer konfiguration eines geräts | |
EP1683016A1 (de) | Sichere erfassung von eingabewerten | |
DE102020213809A1 (de) | Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts | |
DE102013213402A1 (de) | Mikrocontroller mit mindestens zwei Kernen | |
DE102014213503A1 (de) | Verfahren zum Überwachen einer Software in einem Straßenfahrzeug | |
DE102018208832A1 (de) | Verfahren zum Eindämmen eines Angriffs auf ein Steuergerät | |
DE102018209835B3 (de) | Verfahren zum Betreiben einer Steuervorrichtung eines Geräts sowie Konfigurationssystem für eine Steuervorrichtung eines Geräts | |
DE102015205607A1 (de) | Verfahren zum Überwachen einer Netzwerkkomponente sowie Anordnung mit einer Netzwerkkomponente und einer Überwachungs-Einrichtung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18786708 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18786708 Country of ref document: EP Kind code of ref document: A1 |