Prozesszustands nach einem Remote-Software-Update

Die vorliegende Offenbarung betrifft ein Prozessorsystem für ein Fahrzeug, ein Fahrassistenzsystem mit einem solchen Prozessorsystem, ein Fahrzeug mit einem solchen Fahrassistenzsystem und ein Verfahren zum Überwachen eines Prozesszustands nach einem Remote-Software-Update. Die vorliegende Offenbarung betrifft insbesondere eine Sicherheit von Assistenzsystemen eines Fahrzeugs im Falle eines fehlgeschlagenen Remote-Software- Updates.

Stand der Technik

Die Entwicklung von Assistenzsystemen für Fahrzeuge gewinnt stetig an Bedeutung. Solche Assistenzsysteme sind elektronische Zusatzeinrichtungen in Fahrzeugen zur Unterstützung des Fahrers in bestimmten Fahrsituationen. Beispielhafte Assistenzsysteme umfassen eine Einparkhilfe, eine Lichtautomatik, eine Verkehrszeichenerkennung und Fahrassistenzsysteme zum automatisierten Fahren. In Bezug auf das Letztere kann das automatisierte Fahren mit verschiedenen Automatisierungsgraden erfolgen. Beispielhafte Automatisierungsgrade sind ein assistiertes, teilautomatisiertes, hochautomatisiertes oder vollautomatisiertes Fahren.

Die Software derartiger Assistenzsysteme kann heutzutage mittels eines Remote-Software- Update (RSU) aktualisiert werden. Beim Remote-Software-Update erfolgt die Aktualisierung der Software über eine Drahtlosverbindung zwischen dem Fahrzeug und einem Server. Schlägt das Remote-Software-Update jedoch fehl, kann es nötig sein, aus Sicherheitsgründen die entsprechende Assistenzfunktion zumindest teil weise für die Verwendung zu sperren. Um diese Sperre aufzuheben, kann dann ein Werkstattbesuch nötig sein.

Es kann jedoch vorkommen, dass diese Sperre in bestimmten Situationen umgangen wird bzw. nicht greift und die Assistenzfunktion trotz der vorhandenen Sperre ausgeführt wird. Hierdurch kann es zu Sicherheitsri sken kommen, wenn die Assistenzfunktion mit fehlerhafter Software betrieben wird.

Offenbarung der Erfindung

Es ist eine Aufgabe der vorliegenden Offenbarung, ein Prozessorsystem für ein Fahrzeug, ein Fahrassistenzsystem mit einem solchen Prozessorsystem, ein Fahrzeug mit einem solchen Fahrassistenzsystem und ein Verfahren zum Überwachen eines Prozesszustands nach einem Remote-Software-Update anzugeben, die Sicherheitsrisiken bei einem fehlgeschlagenen Remote-Software-Update minimieren können. Insbesondere ist es eine Aufgabe der vorliegenden Offenbarung, ein Ausführen von bestimmten Prozessen bei einem fehlgeschlagenen Remote-Software-Update zuverlässig zu verhindern.

Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.

Gemäß einem unabhängigen Aspekt der vorliegenden Offenbarung ist ein Prozessorsystem für ein Fahrzeug, insbesondere ein Kraftfahrzeug, angegeben. Das Prozessorsystem umfasst ein Zustandsmanager-Modul (Machine State Manager (MSM)-Modul), das eingerichtet ist, um Zustände in Bezug auf Prozesse zu verwalten; ein Ausführungsmanager-Modul (Execution Manager (EM)-Modul), das eingerichtet ist, um eine Anweisung zum Starten und Stoppen der Prozesse auszugeben; und ein Sicherheitsmodul für Remote-Software-Updates (Remote- Software-Update Degradation Handler, RSU DH), das eingerichtet ist, um ein Fehlersignal (Degradation Signal, DS), das ein fehlgeschlagenes Remote-Software-Update angibt, zu empfangen. Das Sicherheitsmodul ist auf einen Empfang des Fehlersignals hin eingerichtet, um: eine Anweisung an das Zustandsmanager-Modul auszugeben, die einen Wechsel (insbesondere des Zustandsmanager-Moduls und/oder einer Software-Plattform, zu der das Prozessorsystem bzw. die Prozesse gehören) in einen vorbestimmten Zustand anweist, wobei im vorbestimmten Zustand eine Ausführung wenigstens eines Prozesses unerlaubt ist; vom Ausführungsmanager-Modul eine Prozessliste mit gestarteten Prozessen zu empfangen; und ein Abbruchsignal zum Stoppen des wenigstens einen Prozesses auszugeben, falls die Prozessliste den wenigstens einen Prozess umfasst.

Erfindungsgemäß wird das Fehlersignal nicht direkt an das Zustandsmanager-Modul, sondern an ein sicherheitsrelevantes Modul gesendet, das für die Auslösung und Überwachung der Sperre bestimmter Prozesse zuständig ist. Das Sicherheitsmodul fordert dann das Zustandsmanager-Modul auf, seinen Zustand in einen vorbestimmten Zustand, der nach Empfang eines Fehlersignals aufgrund eines fehlgeschlagenen Remote- Software-Updates erwartet wird, zu ändern. In diesem Zustand ist eine Ausführung bestimmter Prozesse nicht erlaubt. Die Überwachung dieser Sperre bestimmter Prozesse durch das Sicherheitsmodul erfolgt, indem das Sicherheitsmodul eine Liste gestarteter Prozesse vom Ausführungsmanager- Modul erhält, also dem Modul, das für das Starten der Prozesse zuständig ist. Wenn das Ausführungsmanager-Modul eine andere Liste von Prozessen startet als erlaubt, wird das Problem beispielsweise über einen Heartbeat an einen Watchdog gemeldet. Damit erfolgt eine Prüfung durch das Sicherheitsmodul mittels einer „indirekten Messung“, ob der Zustand richtig gesetzt wurde. Die erfindungsgemäße Konfiguration ist insbesondere dann von Vorteil, wenn das Zustandsmanager-Modul nicht qualifiziert ist (z.B. QM gemäß der Norm ISO 26262).

Im Ergebnis kann ein Ausführen von bestimmten Prozessen bei einem fehlgeschlagenen Remote-Software-Update zuverlässig verhindert werden, wodurch Sicherheitsrisiken bei einem fehlgeschlagenen Remote-Software-Update minimiert werden können.

Das Zustandsmanager-Modul, das Ausführungsmanager-Modul und das Sicherheitsmodul können Softwaremodule sein, die einen Programm-Code zum Ausführen der beschriebene Funktionalitäten umfassen. Das Zustandsmanager-Modul und/oder das Ausführungsmanager- Modul und/oder das Sicherheitsmodul können in einem gemeinsamen Hardware-Modul, wie einem Prozessor bzw. einer CPU, realisiert sein. Alternativ dazu können das Zustandsmanager- Modul und/oder das Ausführungsmanager-Modul und/oder das Sicherheitsmodul jeweils in getrennten Hardware-Modulen realisiert sein. Das Zustandsmanager-Modul verwaltet verschiedene Zustände zum Beispiel einer Software- Plattform, zu der die Prozesse gehören. Die verschiedenen Zustände können beispielsweise „init“, „running“, „shutdown“ und der vorbestimmte Zustand (z.B. „platformOnly“) sein.

Das Ausführungsmanager-Modul ist eingerichtet, entsprechend dem Zustand, der durch das Zustandsmanager-Modul gegeben ist, Prozesse zu starten.

Das Sicherheitsmodul gibt und verwaltet Informationen in Bezug auf ein fehlgeschlagenes Remote-Software-Update. Insbesondere gibt das Sicherheitsmodul vor, ob das System im vorbestimmten Zustand (z.B. „PlatformOnly“) sein und/oder bleiben soll. Das Zustandsmanager-Modul kann diese Informationen beim Sicherheitsmodul abfragen und kann das System entsprechend in den vorbestimmten Zustand bringen. Damit weiß auch das Ausführungsmanager-Modul, welche Prozesse gestartet werden sollen/können. Das Sicherheitsmodul überwacht anschließend, ob das Ausführungsmanager-Modul tatsächlich nur die erlaubten Prozesse startet.

Der Begriff „Remote-Software-Update“, wie er im Rahmen der vorliegenden Offenbarung verwendet wird, betrifft eine Aktualisierung einer Software über eine Drahtlosverbindung zwischen dem Fahrzeug und einer zentralen Einheit, wie einem Server bzw. Backend.

Die Drahtlosverbindung kann zum Beispiel unter Verwendung eines mobilen Netzwerks implementiert werden. Hierzu kann das Fahrzeug ein Kommunikationsmodul umfassen, das in der Lage ist, in einem mobilen Netzwerk über lokale Netzwerke bzw. Local Area Networks (LANs), wie z.B. Wireless LAN (WiFi/WLAN), oder über Weitverkehrsnetze bzw. Wide Area Networks (WANs) wie z.B. Global System for Mobile Communication (GSM), General Package Radio Service (GPRS), Enhanced Data Rates for Global Evolution (EDGE), Universal Mobile Telecommunications System (UMTS), High Speed Downlink/Uplink Packet Access (HSDPA, HSUPA), Long-Term Evolution (LTE), oder World Wide Interoperability for Microwave Access (WIMAX) drahtlos zu kommunizieren. Eine Kommunikation über weitere gängige Kommunikationstechnologien, z.B. 5G-Mobilfunksysteme, ist möglich. Vorzugsweise umfasst (oder ist) das Prozessorsystem ein Steuergerät (engl. electronic control unit, ECU), oder ist in einem Steuergerät umfasst. Steuergeräte (engl. electronic control unit, ECU) sind elektronische Module, die in Fahrzeugen zur Steuerung oder Regelung verschiedenster Prozesse und Funktionen verwendet werden. Beispielsweise werden Steuergeräte verwendet, um ein Kraftstoffeinspritzung, Komfortfunktionen, Sicherheitssysteme und/oder Fahrerassistenzsystem zu steuern. Die Steuergeräte können über einen Datenbus vernetzt sein, um miteinander kommunizieren zu können. Beispielsweise können die Steuergeräte über den Datenbus Informationen über Betriebszustände des Fahrzeugs und weitere relevanten Daten das Fahrzeug betreffend austauschen.

Der Begriff „Prozess“, wie er im Rahmen der vorliegenden Offenbarung verwendet wird und dem Fachmann bekannt ist, ist ein Computerprogramm zur Laufzeit. Insbesondere ist ein Prozess eine konkrete Instanziierung eines Programms. Ein Prozess kann auch als „Task“ oder „Programminstanz“ bezeichnet werden.

Ein Prozessor ist ein programmierbares Rechenwerk, also eine Maschine oder eine elektronische Schaltung, die gemäß übergebenen Befehlen andere Elemente steuert und dabei einen Algorithmus (Prozess) vorantreibt.

Vorzugsweise ist eine Prozessliste mit Prozessen, die im vorbestimmten Zustand gestartet werden sollen/dürfen, in einem Konfigurationsmodul (Konfigurationszeit) z.B. des Sicherheitsmoduls hinterlegt. Wenn das Sicherheitsmodul erkennt, dass ein Prozess gestartet wurde, der nicht auf der Liste der erlaubten Prozesse steht, wird das Abbruchsignal ausgegeben.

Vorzugsweise umfasst das Prozessorsystem ein nicht-flüchtiges Speichermodul, wobei das Sicherheitsmodul eingerichtet ist, um das Fehlersignal im nicht-flüchtigen Speichermodul zu speichern. Insbesondere können das Fehlersignal und/oder Informationen in Bezug auf das fehlgeschlagene Remote-Software-Update im nicht-flüchtigen Speichermodul gespeichert werden, so dass diese Information auch bei einem Neustart des Prozessorsystems noch zur Verfügung steht und eine Aktivierung der gesperrten Prozesse bzw. Funktionen verhindert wird. Das nicht-flüchtigen Speichermodul kann einen nicht-flüchtigen Speicher wie einen Flash, magnetische Medien, z.B. eine Festplatte oder einen optischen Speicher usw. oder Kombinationen davon umfassen.

Vorzugsweise umfasst das Prozessorsystem weiter ein Überwachungsmodul, das eingerichtet ist, um: das Abbruchsignal vom Sicherheitsmodul zu empfangen; und auf einen Empfang des Abbruchssignals hin einen Shutdown zumindest eines Teils des Prozessorsystems zu initiierten.

Vorzugsweise ist das Überwachungsmodul ein Platform Health Management (PHM)-Modul. In einigen Ausführungsformen kann das Überwachungsmodul, insbesondere das PHM-Modul, ein Soft Watchdog sein.

Vorzugsweise ist das Überwachungsmodul eingerichtet, um den Shutdown mittels eines Heartbeat an einen Watchdog zu initiieren.

Der Begriff „Heartbeat“, wie er im Rahmen der vorliegenden Offenbarung verwendet wird, bezieht sich auf eine Netzwerkverbindung zwischen zwei (oder mehr) Prozessoren in einem Cluster, um sich gegenseitig darüber zu benachrichtigen, dass sie betriebsbereit sind und ihre Aufgaben noch erfüllen können.

Der Begriff „Watchdog“, wie er im Rahmen der vorliegenden Offenbarung verwendet wird, bezieht sich auf eine Schaltung bzw. ein Modul, die/das aufgrund des Fehlersignals einen Reset auslöst, damit das Prozessorsystem seine Aufgabe wieder erledigen kann.

Vorzugsweise ist das Ausführungsmanager-Modul eingerichtet, um das Sicherheitsmodul zu starten, insbesondere bei einem Start des Prozessorsystems. Insbesondere kann das Ausführungsmanager-Modul eingerichtet sein, um einige, insbesondere alle Module des Prozessorsystems zu starten. Falls das Ausführungsmanager-Modul das Sicherheitsmodul nicht startet, also ein Fehler vorliegt, kann das Überwachungsmodul dies signalisieren, beispielsweise an einen externen Watchdog auf einem anderen Prozessor des Prozessorsystems. Für diese Signalisierung kann das Überwachungsmodul zum Beispiel den Heartbeat stoppen. Wenn der Heartbeat gestoppt wird, kann der Watchdog bzw. der andere Prozessor ein zumindest teilweises Herunterfahren des Prozessorsystem auslösen.

In einigen Ausführungsformen kann das Zustandsmanager-Modul mit QM gemäß der Norm ISO 26262 indiziert sein.

Ergänzend oder alternativ kann das Ausführungsmanager-Modul mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein.

Ergänzend oder alternativ kann das Sicherheitsmodul mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein.

Ergänzend oder alternativ kann das Überwachungsmodul mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein.

Ergänzend oder alternativ kann das Fehlersignal mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein.

Damit muss nicht das gesamte Lebenszyklusmanagement auf dem Prozessor mit dem Zustandsmanager-Modul, dem Ausführungsmanager-Modul, dem Sicherheitsmodul und dem Überwachungsmodul qualifiziert werden, wodurch Kosten reduziert werden können. Insbesondere kann lediglich das (kleine) Sicherheitsmodul implementiert werden, das indirekt Abweichungen vom erwarteten Zustand nach einer RSU-Degradation überwacht.

Die Norm ISO 26262 definiert ein Risikoklassifizierungsschema, nämlich den Integritätsgrad der Fahrzeugsicherheit („Automotive Safety Integrity Level“, ASIL). Diese Klassifizierung unterstützt eine Definition von Sicherheitsanforderungen. Der ASIL wird durch eine Risikoanalyse einer potenziellen Gefahr erstellt, und zwar indem ein Schweregrad, eine Exposition und eine Beherrschbarkeit eines Betriebsszenarios eines Fahrzeugs betrachtet werden. Es existieren vier ASILs, die durch die Norm ISO 26262 gegeben sind: ASIL A, ASIL B, ASIL C und ASIL D.

ASIL D diktiert die höchsten Integritätsanforderungen und ASIL A die niedrigsten Integritätsanforderungen. Gefährdungen, die als QM („Quality Management“) identifiziert werden, geben keine Sicherheitsanforderungen vor. Das Sicherstellen der durch die Norm ISO 26262 definierten Integritätsanforderungen kann bei der Entwicklung von Assistenzfunktionen beispielsweise zum (teil-)autonom Fahren eine große Herausforderung darstellen.

Vorzugsweise sind das Zustandsmanager-Modul, das Ausführungsmanager-Modul und das Sicherheitsmodul (und optional das Überwachungsmodul) in einem einzigen SoC (System-on- a-Chip)-basierten Prozessor (oder CPU) umfasst.

Unter System-on-a-Chip wird im Allgemeinen eine Integration aller oder eines Teils der Funktionen eines programmierbaren elektronischen Systems auf einem Chip verstanden.

Vorzugsweise betrifft der wenigstens eine Prozess eine Fahrfunktion zum automatisierten Fahren.

Ein automatisiert fahrendes Fahrzeug lenkt und/oder bremst und/oder beschleunigt selbstständig basierend auf einer Fahr Strategie. Die Fahrstrategie kann basierend auf Umfelddaten der Umfeldsensorik, Straßenzustand, Verkehrslage, Wetterlage, etc. bestimmt werden. Die Umsetzung der bestimmten Fahrstrategie erfolgt durch den Antrieb, die Lenkung und/oder die Bremsen.

Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist ein Fahrassistenzsystem zum automatisierten Fahren eines Fahrzeugs angegeben. Das Fahrassistenzsystem umfasst das Prozessorsystem gemäß den Ausführungsformen der vorliegenden Offenbarung. Unter dem Begriff „automatisiertes Fahren“ kann im Rahmen des Dokuments ein Fahren mit automatisierter Längs- oder Querführung oder ein autonomes Fahren mit automatisierter Längs- und Querführung verstanden werden. Bei dem automatisierten Fahren kann es sich beispielsweise um ein zeitlich längeres Fahren auf der Autobahn oder um ein zeitlich begrenztes Fahren im Rahmen des Einparkens oder Rangierens handeln. Der Begriff „automatisiertes Fahren“ umfasst ein automatisiertes Fahren mit einem beliebigen Automatisierungsgrad. Beispielhafte Automatisierungsgrade sind ein assistiertes, teilautomatisiertes, hochautomatisiertes oder vollautomatisiertes Fahren. Diese Automatisierungsgrade wurden von der Bundesanstalt für Straßenwesen (BASt) definiert (siehe BASt-Publikation „Forschung kompakt“, Ausgabe 11/2012).

Beim assistierten Fahren führt der Fahrer dauerhaft die Längs- oder Querführung aus, während das System die jeweils andere Funktion in gewissen Grenzen übernimmt. Beim teilautomatisierten Fahren (TAF) übernimmt das System die Längs- und Querführung für einen gewissen Zeitraum und/oder in spezifischen Situationen, wobei der Fahrer das System wie beim assistierten Fahren dauerhaft überwachen muss. Beim hochautomatisierten Fahren (HAF) übernimmt das System die Längs- und Querführung für einen gewissen Zeitraum, ohne dass der Fahrer das System dauerhaft überwachen muss; der Fahrer muss aber in einer gewissen Zeit in der Lage sein, die Fahrzeugführung zu übernehmen. Beim vollautomatisierten Fahren (VAF) kann das System für einen spezifischen Anwendungsfall das Fahren in allen Situationen automatisch bewältigen; für diesen Anwendungsfall ist kein Fahrer mehr erforderlich.

Die vorstehend genannten vier Automatisierungsgrade entsprechen den SAE-Level 1 bis 4 der Norm SAE J3016 (SAE - Society of Automotive Engineering). Beispielsweise entspricht das hochautomatisierte Fahren (HAF) Level 3 der Norm SAE J3016. Ferner ist in der SAE J3016 noch der SAE-Level 5 als höchster Automatisierungsgrad vorgesehen, der in der Definition der BASt nicht enthalten ist. Der SAE-Level 5 entspricht einem fahrerlosen Fahren, bei dem das System während der ganzen Fahrt alle Situationen wie ein menschlicher Fahrer automatisch bewältigen kann; ein Fahrer ist generell nicht mehr erforderlich. Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist ein Fahrzeug, insbesondere Kraftfahrzeug, angegeben. Das Fahrzeug umfasst das Prozessorsystem und/oder das Fahrassi stenz system gemäß den Ausführungsformen der vorliegenden Offenbarung.

Der Begriff Fahrzeug umfasst PKW, LKW, Busse, Wohnmobile, Krafträder, etc., die der Beförderung von Personen, Gütern, etc. dienen. Insbesondere umfasst der Begriff Kraftfahrzeuge zur Personenbeförderung.

Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist ein Verfahren zum Überwachen eines Prozesszustands nach einem Remote-Software-Update in einem Fahrzeug angegeben. Das Verfahren umfasst ein Empfangen, durch ein Sicherheitsmodul für Remote-Software-Updates, eines Fehlersignals, das ein fehlgeschlagenes Remote-Software- Update angibt; ein Ausgeben, durch das Sicherheitsmodul, einer Anweisung an ein Zustandsmanager-Modul, das eingerichtet ist, um Zustände in Bezug auf Prozesse zu verwalten, wobei die Anweisung einen Wechsel in einen vorbestimmten Zustand anweist, und wobei im vorbestimmten Zustand eine Ausführung wenigstens eines Prozesses unerlaubt ist; ein Empfangen, durch das Sicherheitsmodul, einer Prozessliste mit gestarteten Prozessen von einem Ausführungsmanager-Modul, das eingerichtet ist, um eine Anweisung zum Starten und Stoppen der Prozesse auszugeben; und ein Ausgeben, durch das Sicherheitsmodul, eines Abbruchsignals zum Stoppen des wenigstens einen Prozesses, falls die Prozessliste den wenigstens einen Prozess umfasst.

Das Verfahren kann die Aspekte des in diesem Dokument beschriebenen Prozessorsystems implementieren.

Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist ein Software (SW) Programm angegeben. Das SW Programm kann eingerichtet werden, um auf einem oder mehreren Prozessoren ausgeführt zu werden, und um dadurch das in diesem Dokument beschriebene Verfahren zum Überwachen eines Prozesszustands nach einem Remote- Software-Update auszuführen. Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist ein Speichermedium angegeben. Das Speichermedium kann ein SW Programm umfassen, welches eingerichtet ist, um auf einem oder mehreren Prozessoren ausgeführt zu werden, und um dadurch das in diesem Dokument beschriebene Verfahren zum Überwachen eines Prozesszustands nach einem Remote-Software-Update auszuführen.

Gemäß einem weiteren unabhängigen Aspekt der vorliegenden Offenbarung ist eine Software mit Programmcode zur Durchführung des Verfahrens zum Überwachen eines Prozesszustands nach einem Remote- Software-Update auszuführen, wenn die Software auf einer oder mehreren softwaregesteuerten Einrichtungen abläuft.

Kurze Beschreibung der Zeichnungen

Ausführungsbeispiele der Offenbarung sind in den Figuren dargestellt und werden im Folgenden näher beschrieben. Es zeigen:

Figur 1 schematisch ein Remote-Software-Update gemäß Ausführungsformen der vorliegenden Offenbarung,

Figur 2 schematisch ein Steuergerät für ein Fahrzeug gemäß Ausführungsformen der vorliegenden Offenbarung,

Figur 3 schematisch einen Prozessor für ein Fahrzeug gemäß Ausführungsformen der vorliegenden Offenbarung,

Figur 4 schematisch ein Fahrzeug mit einem Fahrassistenzsystem zum automatisierten Fahren gemäß Ausführungsformen der vorliegenden Offenbarung, und

Figur 5 ein Flussdiagram eines Verfahrens zum Überwachen eines Prozesszustands nach einem Remote-Software-Update gemäß Ausführungsformen der vorliegenden Offenbarung. Ausführungsformen der Offenbarung

Im Folgenden werden, sofern nicht anders vermerkt, für gleiche und gleichwirkende Elemente gleiche Bezugszeichen verwendet.

Figur 1 zeigt schematisch ein Remote- Software-Update (RSU) gemäß Ausführungsformen der vorliegenden Offenbarung.

Beispielhaft ist ein Steuergerät 100 mit einer aktuellen Partition 110 und einer Spiegelpartition 120 gezeigt. Die Spiegelpartition 120 wird über eine Drahtlosverbindung zwischen dem Fahrzeug und einer zentralen Einheit, wie einem Server bzw. Backend, aktualisiert. Die Drahtlosverbindung kann zum Beispiel unter Verwendung eines mobilen Netzwerks, wie eines 5G-Netzwerks, implementiert werden.

Tritt nun beim Remote-Software-Update ein Fehler auf bzw. war das Remote-Software-Update nicht erfolgreich, wird dieser Umstand dem Steuergerät mittels eines Fehlersignals DS („Degradation Signal“) angezeigt. Insbesondere kann es vorkommen, dass bei einem fehlerhaften Update keine sicherheitsrelevante Funktion gestartet werden darf. Das Steuergerät 100 kann zwar starten, aber die Funktionen können nicht ausgeführt werden (erhöhtes Debugging).

Figur 2 zeigt schematisch ein beispielhaftes Steuergerät 200 für ein Fahrzeug gemäß Ausführungsformen der vorliegenden Offenbarung.

Das Steuergerät 200 umfasst, oder ist, das Prozessorsystem gemäß den Ausführungsformen der vorliegenden Offenbarung. Insbesondere umfasst das Prozessorsystem einen ersten Prozessor 210, der die erfindungsgemäße Auslösung und Überwachung der Sperre bestimmter Prozesse implementiert. Ein beispielhafter erster Prozessor ist in der Figur 3 gezeigt und wird später im Detail beschrieben. In Figur 2 ist weiter ein zweiten Prozessor 210 gezeigt, der das Fehlersignal DS bzw. das Degradationssignal an den ersten Prozessor 210 liefert. Der zweite Prozessor 220 kann im Prozessorsystem und/oder Steuergerät 200 integriert sein, oder kann ein externer Prozessor sein. Beispielsweise kann die RSU-Degradation nach dem Ausfall eines RSU-Zyklus durch den zweiten Prozessor 210 erzwungen werden, wobei der erste Prozessor 210 auch nach einem Neustart einen bestimmten Zustand (z.B. PlatformOnly), in dem bestimmte Prozesse gesperrt sind, beibehalten muss. Dadurch wird sichergestellt, dass keine Funktion ausgeführt wird, falls ein Software-Upgrade fehlschlägt.

In einigen Ausführungsformen kann der zweite Prozessor 220 ein BCP (Body Control Processor) sein.

Das Prozessorsystem umfasst weiter einen dritten Prozessor 230, der über einen Heartbeat HB mit dem ersten Prozessor 210 verbunden ist. Der dritte Prozessor 230 kann zum Beispiel eine geplante Trajektorie an Steuergeräte entsprechender Aktuatoren eines automatisiert fahrenden Fahrzeugs ausgeben. Der dritte Prozessor 230 kann eine Watchdog-Funktionalität implementieren. Beispielsweise kann der erste Prozessor 210 bei einem fehlerhaften Update den Heartbeat HB stoppen, so dass der dritte Prozessor 230 die geplante Trajektorie nicht mehr ausgibt. Alternativ kann der dritte Prozessor 230 anstatt der geplanten Trajektorie eine vorbestimmte Notfalltrajektorie ausgeben.

Zumindest einige Prozessoren, insbesondere der erste Prozessor 210 und der dritte Prozessor 230, können Teil einer bestimmten Plattform sein, wie es durch die gestrichelte Linie in Figur 2 angedeutet ist.

Figur 3 zeigt schematisch einen Prozessor 300 für ein Fahrzeug gemäß Ausführungsformen der vorliegenden Offenbarung. Der Prozessor 300 kann im erfindungsgemäßen Prozessorsystem umfasst sein oder kann das erfindungsgemäße Prozessorsystem bilden. Insbesondere kann der Prozessor 300 der in Figur 2 gezeigte erste Prozessor 210 sein. Der Prozessor 300 umfasst ein Zustandsmanager-Modul 310 (Machine State Manager (MSM)- Modul), das eingerichtet ist, um Zustände in Bezug auf Prozesse 340 zu verwalten. Das Zustandsmanager-Modul verwaltet verschiedene Zustände zum Beispiel einer Software- Plattform, zu der die Prozesse gehören. Die verschiedenen Zustände können beispielsweise „init“, „running“, „shutdown“ und der vorbestimmte Zustand (z.B. „platformOnly“) sein.

Der Prozessor 300 umfasst weiter ein Ausführungsmanager-Modul 320 (Execution Manager (EM)-Modul), das eingerichtet ist, um eine Anweisung zum Starten und Stoppen der Prozesse 340 auszugeben. Das Ausführungsmanager-Modul 320 steuert die Ausführung der Prozesse 340 mittels entsprechender Vorgaben PR vom Zustandsmanager-Modul 310. Insbesondere ist das Ausführungsmanager-Modul 320 eingerichtet, entsprechend dem Zustand, der durch das Zustandsmanager-Modul 310 gegeben ist, Prozesse zu starten.

Der Prozessor 300 umfasst weiter ein Sicherheitsmodul 330 für Remote-Software-Updates (Remote-Software-Update Degradation Handler, RSU DH), das eingerichtet ist, um ein Fehlersignal DS (Degradation Signal), das ein fehlgeschlagenes Remote-Software-Update angibt, zu empfangen.

In einigen Ausführungsformen kann das Sicherheitsmodul 330 ein nicht-flüchtiges Speichermodul 332 zum Speichern des Fehlersignals DS umfassen. Insbesondere können das Fehlersignal DS und/oder Informationen in Bezug auf das fehlgeschlagene Remote-Software- Update im nicht-flüchtigen Speichermodul 332 gespeichert werden, so dass diese Information auch bei einem Neustart des Prozessors 300 noch zur Verfügung steht und eine Aktivierung der gesperrten Prozesse bzw. Funktionen verhindert wird.

Das Sicherheitsmodul 330 ist auf einen Empfang des Fehlersignals DS hin eingerichtet, um eine Anweisung ST an das Zustandsmanager-Modul 310 auszugeben, die einen Wechsel des Zustandsmanager-Moduls 310 in einen vorbestimmten Zustand anweist, wobei im vorbestimmten Zustand eine Ausführung wenigstens eines Prozesses der Prozesse 340 unerlaubt ist. Dadurch soll sichergestellt werden, dass keine Funktion ausgeführt wird, falls ein Software-Upgrade fehlschlägt. Insbesondere gibt das Sicherheitsmodul 330 vor, ob das System im vorbestimmten Zustand sein und/oder bleiben soll. Das Zustandsmanager-Modul 310 kann diese Informationen beim Sicherheitsmodul abfragen und kann das System entsprechend in den vorbestimmten Zustand bringen. Damit weiß auch das Ausführungsmanager-Modul 320, welche Prozesse gestartet werden sollen/können.

Das Sicherheitsmodul 330 ist weiter eingerichtet, um vom Ausführungsmanager-Modul 320 eine Prozessliste PL mit gestarteten Prozessen zu empfangen und ein Abbruchsignal PS zum Stoppen des wenigstens einen Prozesses auszugeben, falls die Prozessliste PL den wenigstens einen Prozess umfasst. Vorzugsweise ist eine Prozessliste mit Prozessen, die im vorbestimmten Zustand gestartet werden sollen/ dürfen, in einem Konfigurationsmodul (Konfigurationszeit) z.B. des Sicherheitsmoduls 330 hinterlegt. Wenn das Sicherheitsmodul 330 erkennt, dass ein Prozess gestartet wurde, der nicht auf der Liste der erlaubten Prozesse steht, wird das Abbruchsignal ausgegeben.

Damit erfolgt eine Überwachung der Sperre bestimmter Prozesse durch das Sicherheitsmodul 330, indem das Sicherheitsmodul 330 eine Liste gestarteter Prozesse vom Ausführungsmanager-Modul 320 erhält, also dem Modul, das für das Starten der Prozesse zuständig ist. Wenn das Ausführungsmanager-Modul 320 eine andere Liste von Prozessen startet als erlaubt, wird das Problem bei spielsweise über einen Heartbeat HB an einen Watchdog (in Figur 3 nicht gezeigt) gemeldet. Im Ergebnis kann ein Ausführen von bestimmten Prozessen bei einem fehlgeschlagenen Remote-Software-Update zuverlässig verhindert werden, wodurch Sicherheitsrisiken bei einem fehlgeschlagenen Remote-Software-Update minimiert werden können.

In einigen Ausführungsformen kann der Prozessor 300 weiter ein Überwachungsmodul 350 umfassen, das eingerichtet ist, um das Abbruchsignal PS vom Sicherheitsmodul 330 zu empfangen und auf einen Empfang des Abbruchssignals PS hin einen Shutdown und Neustart zu initiierten. Dies kann zum Beispiel über den Heartbeat HB erfolgen.

In einigen Ausführungsformen kann das Zustandsmanager-Modul 310 mit QM gemäß der Norm ISO 26262 indiziert sein. Ergänzend oder alternativ kann das Ausführungsmanager- Modul 320 mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein. Ergänzend oder alternativ kann das Sicherheitsmodul 330 mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein. Ergänzend oder alternativ kann das Überwachungsmodul 350 mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein. Ergänzend oder alternativ kann das Fehlersignal DS mit ASIL A, ASIL B, ASIL C oder ASIL D gemäß der Norm ISO 26262 indiziert sein.

Damit muss nicht das gesamte Lebenszyklusmanagement auf dem Prozessor 300 mit dem Zustandsmanager-Modul 310, dem Ausführungsmanager-Modul 320, dem Sicherheitsmodul 330 und dem Überwachungsmodul 350 qualifiziert werden, wodurch Kosten reduziert werden können. Insbesondere kann lediglich das (kleine) Sicherheitsmodul 330 implementiert werden, das indirekt Abweichungen vom erwarteten Zustand nach einer RSU-Degradation überwacht.

Figur 4 zeigt schematisch ein Fahrzeug 10 mit einem Fahrassistenzsystem 400 zum automatisierten Fahren gemäß Ausführungsformen der vorliegenden Offenbarung.

Beim automatisierten Fahren erfolgt die Längs- und/oder Querführung des Fahrzeugs 10 automatisch. Das Fahrassistenzsystem 400 übernimmt also die Fahrzeugführung. Hierzu steuert das Fahrassistenzsystem 400 den Antrieb 20, das Getriebe 22, die hydraulische Betriebsbremse 24 und die Lenkung 26 über nicht dargestellte Zwischeneinheiten.

Zur Planung und Durchführung des automatisierten Fahrens werden Umfeldinformationen einer Umfeldsensorik, die das Fahrzeugumfeld beobachtet, vom Fahrerassistenzsystem 400 entgegengenommen. Insbesondere kann das Fahrzeug wenigstens einen Umgebungssensor 12 umfassen, der zur Aufnahme von Umgebungsdaten, die das Fahrzeugumfeld angeben, eingerichtet ist. Der wenigstens eine Umgebungssensor 12 kann beispielsweise ein LiDAR- System, ein oder mehrere Radar-Systeme und/oder eine oder mehrere Kameras umfassen.

Das Fahrassistenzsystem 400 umfasst das erfmdungsgemäße Prozessorsystem. Das Prozessorsystem kann zum Beispiel für eine Trajektorienplanung für das automatisierte Fahren eingerichtet sein. Figur 5 zeigt schematisch ein Flussdiagramm eines Verfahrens 500 zum Überwachen eines Prozesszustands nach einem Remote-Software-Update gemäß Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 500 kann durch eine entsprechende Software implementiert werden, die durch einen oder mehrere Prozessoren (z.B. eine CPU) ausführbar ist.

Das Verfahren 500 umfasst im Block 510 ein Empfangen, durch ein Sicherheitsmodul für Remote-Software-Updates, eines Fehlersignals, das ein fehlgeschlagenes Remote- Software- Update angibt; im Block 520 ein Ausgeben, durch das Sicherheitsmodul, einer Anweisung an ein Zustandsmanager-Modul, das eingerichtet ist, um Zustände in Bezug auf Prozesse zu verwalten, wobei die Anweisung einen Wechsel in einen vorbestimmten Zustand anweist, und wobei im vorbestimmten Zustand eine Ausführung wenigstens eines Prozesses unerlaubt ist; im Block 530 ein Empfangen, durch das Sicherheitsmodul, einer Prozessliste mit gestarteten Prozessen von einem Ausführungsmanager-Modul, das eingerichtet ist, um eine Anweisung zum Starten und Stoppen der Prozesse auszugeben; und im Block 540 ein Ausgeben, durch das Sicherheitsmodul, eines Abbruchsignals zum Stoppen des wenigstens einen Prozesses, falls die Prozessliste den wenigstens einen Prozess umfasst.

Erfindungsgemäß wird das Fehlersignal nicht direkt an das Zustandsmanager-Modul, sondern an ein sicherheitsrelevantes Modul gesendet, das für die Auslösung und Überwachung der Sperre bestimmter Prozesse zuständig ist. Das Sicherheitsmodul fordert dann das Zustandsmanager-Modul auf, seinen Zustand in einen vorbestimmten Zustand, der nach Empfang eines Fehlersignals aufgrund eines fehlgeschlagenen Remote- Software-Updates erwartet wird, zu ändern. In diesem Zustand ist eine Ausführung bestimmter Prozesse nicht erlaubt. Die Überwachung dieser Sperre bestimmter Prozesse durch das Sicherheitsmodul erfolgt, indem das Sicherheitsmodul eine Liste gestarteter Prozesse vom Ausführungsmanager- Modul erhält, also dem Modul, das für das Starten der Prozesse zuständig ist. Wenn das Ausführungsmanager-Modul eine andere Liste von Prozessen startet als erlaubt, wird das Problem beispielsweise über einen Heartbeat an einen Watchdog gemeldet. Damit erfolgt eine Prüfung durch das Sicherheitsmodul mittels einer „indirekten Messung“, ob der Zustand richtig gesetzt wurde. Die erfindungsgemäße Konfiguration ist insbesondere dann von Vorteil, wenn das Zustandsmanager-Modul nicht qualifiziert ist (z.B. QM gemäß der Norm ISO 26262).

Im Ergebnis kann ein Ausfuhren von bestimmten Prozessen bei einem fehlgeschlagenen Remote-Software-Update zuverlässig verhindert werden, wodurch Sicherheitsrisiken bei einem fehlgeschlagenen Remote- Software-Update minimiert werden können.

Obwohl die Erfindung im Detail durch bevorzugte Ausführungsbeispiele näher illustriert und erläutert wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Es ist daher klar, dass eine Vielzahl von Variationsmöglichkeiten existiert. Es ist ebenfalls klar, dass beispielhaft genannte Ausführungsformen wirklich nur Beispiele darstellen, die nicht in irgendeiner Weise als Begrenzung etwa des Schutzbereichs, der Anwendungsmöglichkeiten oder der Konfiguration der Erfindung aufzufassen sind. Vielmehr versetzen die vorhergehende Beschreibung und die Figurenbeschreibung den Fachmann in die Lage, die beispielhaften Ausführungsformen konkret umzusetzen, wobei der Fachmann in Kenntnis des offenbarten Erfindungsgedankens vielfältige Änderungen beispielsweise hinsichtlich der Funktion oder der Anordnung einzelner, in einer beispielhaften Ausführungsform genannter Elemente vornehmen kann, ohne den Schutzbereich zu verlassen, der durch die Ansprüche und deren rechtliche Entsprechungen, wie etwa weitergehenden Erläuterungen in der Beschreibung, definiert wird.