DE102015203766A1

DE102015203766A1 - Teilsystem für ein Fahrzeug und entsprechendes Fahrzeug

Info

Publication number: DE102015203766A1
Application number: DE102015203766.5A
Authority: DE
Inventors: Volker Blaschke; Gafur Zymeri; Klaus Schneider; Ralf Luebben
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2015-03-03
Filing date: 2015-03-03
Publication date: 2016-09-08
Also published as: CN105939213A; US20160259639A1; CN105939213B; US10007504B2

Abstract

Teilsystem für ein Fahrzeug (10), gekennzeichnet durch folgende Merkmale: – einen über eine Luftschnittstelle (29) mit einem Gerätemanagement-Server (26) des Backends (20) verbundenen Gerätemanagement-Client (16) zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, – einen über eine Luftschnittstelle (29) mit einem Download-Server (21) des Backends (20) verbundenen Download-Client (11) zum Herunterladen eines Softwareupdates von dem Backend (20) in das Fahrzeug (10), – mit dem Download-Client (11) verbundene Softwareupdate-Clients (12, 13) zum Anwenden des Softwareupdates und – einen mit dem Download-Client (11) und den Softwareupdate-Clients (12, 13) verbundenen Fahrzeugupdate-Client (14) zum Koordinieren des Softwareupdates.

Description

Die vorliegende Erfindung betrifft ein Teilsystem für ein Fahrzeug. Die vorliegende Erfindung betrifft darüber hinaus ein entsprechend ausgestattetes Fahrzeug.
Stand der Technik
In der Funktechnik wird die Übertragung von Daten mittels elektromagnetischer Wellen, also scheinbar durch das Medium Luft (over the air, OTA), mitunter als Luftschnittstelle bezeichnet. Eine solche Luftschnittstelle ist insbesondere dadurch gekennzeichnet, dass kein festkörperliches Übertragungsmedium wie Kupfer- oder Glasfaserkabel verwendet wird, was für die Zwecke der nachfolgenden Ausführungen die Übertragung im Vakuum nicht ausschließt. Telekommunikationstechnische Ansätze, die sich einer solchen Übertragung bedienen, sind etwa als Over-the-Air-Programmierung (OTA), Over-the-Air Service Provisioning (OTASP), Over-the-Air Provisioning (OTAP) oder Over-the-Air Parameter Administration (OTAPA) bekannt.
Von besonderer Bedeutung sind die genannten Technologien für die Aktualisierung sogenannter Firmware, also solcher Software, die in elektronische Geräte eingebettet ist. Auf Firmware angepasste Abwandlungen der oben genannten OTA-Technologien werden in der Telekommunikation unter dem Oberbegriff der Firmware-Over-the-Air-Programmierung (FOTA) zusammengefasst.
DE 10105454 A1 schlägt ein Verfahren zur automatischen Ergänzung von Software über eine Luftschnittstelle vor, das dazu dient, Software, die auf einem System läuft, durch neue Softwaremodule zu ergänzen, wobei diese Softwaremodule zunächst getestet werden und von diesen Softwaremodulen dann Applikationsmodule abgeleitet werden.
Offenbarung der Erfindung
Die Erfindung stellt ein Teilsystem für ein Fahrzeug sowie ein mit einem solchen Teilsystem ausgestattetes Fahrzeug gemäß den unabhängigen Ansprüchen bereit.
Ein Vorzug dieser Lösung liegt in seiner Modularität sowohl auf der Backend- als auch auf der Fahrzeugseite. Dies ermöglicht es, OEM-spezifische Varianten leicht zu integrieren, da die Funktionalitäten schon auf der Architekturebene voneinander getrennt sind.
Die vorgeschlagene Architektur beinhaltet dabei gleichsam die Obermenge aller Funktionalitäten und kann je nach Bedarf durch Entfernen angepasst werden. Somit können bestehende Schnittstellen weiter genutzt werden, und damit wird letztendlich eine hohe Entwicklungs- und Anpassungsgeschwindigkeit ermöglicht.
Schließlich ist die vorgeschlagene Architektur so beschaffen, dass sie leicht um zusätzliche Anwendungsfälle erweiterbar ist. Konkret bedeutet dies, dass viele Komponenten im Sinne einer Wiederverwendung auch für andere Anwendungsfälle genutzt werden können. Zu denken ist unter anderem an eine Diagnose oder Felddatenerfassung.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Teilsystems möglich.
Kurze Beschreibung der Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
1 das Blockdiagramm eines Systems zum Aktualisieren eines Fahrzeuges.
2 das Blockdiagramm eines Teilsystems gemäß einer Ausführungsform.
Ausführungsformen der Erfindung
1 illustriert ein System, welches aus einem Backend 20 und dem zugehörigen Teilsystem 30 eines Fahrzeuges 10 besteht. Der Kern des Systems besteht aus den im Folgenden beschriebenen Komponenten und deren Interaktion.
Der Daten-Download ist in einer Komponente separiert, welche sowohl als Download-Server 21 im Backend 20 als auch als Download-Clients 11 im Fahrzeug 10 implementiert wird. Das Device-Management ist in einer Komponente separiert, welche sowohl als Gerätemanagement-Server 26 im Backend 20 als auch als Gerätemanagement-Client 16 im Fahrzeug 10 implementiert wird. Ein fahrzeugseitiger Proxy wird genutzt, um verteilte Implementierungen des Device-Managements – zum Beispiel in mehreren Domänen – zu einer einzigen Implementierung zu bündeln.
Das Software-Update und -Management ist in einer Komponente separiert, welche sowohl als SCOS-Server 22 und FCOS-Server 23 im Backend 20 als auch als Anwendungssoftware-Update-Client 12 und Firmware-Update-Client 13 im Fahrzeug 10 implementiert wird. SCOMO/FUMO bezeichnet hier die Funktionalität entsprechend OMA-DM als einer beispielhaften Umsetzung.
Ein Fahrzeugmanagement 25 dient der Konkretisierung eines „Devices“ zu dem Fahrzeug 10 inklusive seiner relevanten Topologie, also Steuergeräte und Sub-Systeme.
Das fachliche Datenhandling seitens des Backends 20 ist in einem Fahrzeug-Content-Management 28 separiert, welche die unterschiedlichen Versionen und Varianten von Datenständen an das Fahrzeug 10 bindet. Separiert ist auch die Update-Logik einschließlich der Kampagnensteuerung, welche sowohl als Fahrzeugupdate-Server 24 im Backend 20 als auch als Fahrzeugupdate-Client 14 im Fahrzeug 10 implementiert wird.
Als Content-Management 18 ist das Daten-Management im Fahrzeug 10 separiert. Entsprechendes gilt für die als ECU-Updater im Fahrzeug 10 separierte Firmware-Update-Komponente, welche in mehreren Varianten und Instanzen – etwa jener eines Anwendungssoftware-Update-Clients 12 oder eines Firmware-Update-Clients 13 – vorliegen kann und in der Lage ist, die unterschiedlichen Systeme und Technologien zu aktualisieren.
Die Inhalte und Funktionen der aufgeführten Komponenten seien nunmehr im Einzelnen erläutert, wobei zusätzlich zu der Basis-Aufteilung gemäß 1 auf die bevorzugte Variante gemäß 2 Bezug genommen wird.
Das Fahrzeugmanagement 25 ist für die Kenntnis der Fahrzeuge 10 – im Sinne eines Satzes oder einer Gruppe von Fahrzeugen 10 –, des Fahrzeuges 10 selbst und seiner Fahrzeugtopologie für alle Zwecke verantwortlich und in der Lage, ein Gerät auf das vom Gerätemanagement 15, 16, 26 gelieferte Fahrzeug 10 abzubilden. Das Gerätemanagement 15, 16, 26 identifiziert und kommuniziert hierzu mit einem Gerät, nicht notwendigerweise einem Fahrzeug 10 oder einem bekannten Fahrzeug 10. Mehrere Geräte können dabei zu einem Fahrzeug 10 zusammengefasst sein. Gleichwohl kann das Gerätemanagement 15, 16, 26 einen anderen Gerätetyp, beispielsweise einen Rasenmäher, identifizieren. Das Gerätemanagement 15, 16, 26 identifiziert somit den Gerätetyp, um die Weiterleitung an dessen Verwaltungsfunktion zu erlauben. Im vorliegenden Beispiel handelt es sich dabei um das Fahrzeugmanagement 25.
Der Gerätemanagement-Server 26 ist in der Lage, alle Verwaltungsaktionen mit dem zugehörigen Gerät durchzuführen. Hierzu ist ein Protokoll vonnöten, um solcherlei Verwaltungsobjekte zum und vom Gerät zu befördern.
Das Gerätemanagement 15, 16, 26 ist in der Lage, mehrere Geräte unterschiedlichen Typs zu handhaben. Bekannte Geräte werden mithilfe des Datenmanagements 27 identifiziert und typisiert, um ein „bekanntes Gerät“ zu werden. Ein bekanntes Gerät wird der zugehörigen Verwaltungsfunktion – vorliegend dem Fahrzeugmanagement 25 – zugeleitet. Für die Zwecke der folgenden Ausführungen sei angenommen, dass alle Geräte als „Straßenfahrzeuge“ typisiert und durch das Fahrzeugmanagement 25 verarbeitet werden. Nichtsdestotrotz ist das Gerätemanagement vorzugsweise in der Lage, auch andere Typen und Anwendungsfälle zu unterstützen.
Der Gerätemanagement-Client 16 ermöglicht es, Softwarekomponentenmanagement in der zugehörigen Laufzeitumgebung von einem Gerätemanagement-Server 26 aus einzuleiten. Der Gerätemanagement-Treiber unterstützt Geräteerkennung und Parameterkonfiguration durch den Gerätemanagement-Client 16. Der Gerätemanagement-Client 16 wiederum interagiert mit einem oder mehreren Gerätemanagement-Agent (15) in der Umgebung, die über einen optionalen Gerätemanagement-Proxy für die Durchführung der Verwaltungsaktivitäten mittels eines gelieferten Softwarekomponentenmanagementobjektes ist. Der Gerätemanagement-Client 16 setzt den allgemeinen Warnmechanismus ein, um die den Status der Verwaltungsaktivität umfassende endgültige Benachrichtigung mitzuteilen.
Wenn mehrere Instanzen des Gerätemanagement-Clients 16 existieren, dann wird diese Aktivität als bestmögliche Alternative durch eine einzige Instanz des Gerätemanagement-Client 16 und zusätzlichen Gerätemanagement-Agent (15) ausgeführt. Um bei einem einzigen Gerät pro Fahrzeug 10 gleichwohl mehrere Gerätemanagement-Clients 16 unterstützen zu können, wird ein Gerätemanagement-Proxy verwendet. Auf jedem IP-fähigen System 46 läuft somit eine Instanz des Gerätemanagement-Agents 15 und nutzt den zentralen Proxy des Gerätemanagement-Client 16.
Die Gerätemanagement-Proxy-Komponente ermöglicht es, mehrere Instanzen des Gerätemanagement-Clients 16 zu vermeiden. Hierzu leitet und aggregiert jeder Gerätemanagement-Agent das Gerätemanagement-Verwaltungsobjekt an den Gerätemanagement-Client 16. Die Gerätemanagement-Agent können in unterschiedlichen Laufzeitumgebungen laufen. Der Proxy ist zuständig und stellt die eindeutige Zuordnung zwischen Fahrzeug 10 und Gerät sicher.
Das Fahrzeug-Content-Management 28 ist seitens des Backends 20 dafür zuständig, den Inhalt abzubilden, für die Übertragung gegebenenfalls zu komprimieren und für die Verwendung bzgl. Software Updates zu paketieren. Es empfängt die Daten und Inhalt vom Datenmanagement 27, dieses speichert die Daten und Inhalt auf einheitliche Art. So wird die OEM-Varianz hinsichtlich Daten und Inhalt innerhalb des Fahrzeuges 10 vom Datenmanagement 27 vollständig abgedeckt. Dies bringt auch die eindeutige semantische und syntaktische Beziehung zwischen der Ausgabe des Datenmanagements 27 und dem zugehörigen Content-Management 18 seitens des Fahrzeuges 10 mit sich.
Der SW Component Server 22 ist für das Aufbauen und Übertragen der Management-Objekte für Applikationssoftware Updates verantwortlich. Im Falle einer Verwendung von OMA-DM kann dies durch Nutzung des SCOMO-Protokolls und Management-Objekte realisiert werden. Der SW Update Client 12 ist für die Ausführung von SWCOS 22-Anweisungen zuständig. Er verbraucht die an das Gerät gelieferte Softwarekomponente und garantiert, dass ein Erfolgs- oder Fehlerergebnis übermittelnde Warnungen zurück an den SWComponent-Server 22 geleitet werden. Um bei einem einzigen Gerät pro Fahrzeug 10 gleichwohl mehrere SW Update Clients unterstützen zu können, werden mehrere Varianten und Instanzen verwendet. Alle SW Update Client Instanzen 12 werden hierbei vom Fahrzeugupdate-Server 14 orchestriert. So kann auf jedem IP-fähigen System eine Instanz des SW Update Clients 12 laufen.
Der Download-Server 21 ist für die Bereitstellung der später zu übertragenden Update-Pakete verantwortlich. Der Download-Server 21 bezieht seinen Inhalt vom Fahrzeug-Datenmanagement 27, koordiniert durch den Fahrzeugupdate-Server 24. Dies stellt sicher, dass nur jene Update-Pakete durch den Download-Server 21 verfügbar sind, die tatsächlich durch das Fahrzeug 10 gebraucht und benötigt werden.
Die Wertschöpfungskette „Fahrzeugupdateanforderung, Content-Zusammenstellung, Content-Bereitstellung“ durch den Download-Server 21 wird somit nur für aktive Fahrzeuge 10 innerhalb einer definierten Kampagne durchgeführt.
Der Download-Client 11 ist für das Herunterladen von Softwarekomponenten, Firmware oder anderem Inhalt in das Fahrzeug 10 zuständig. Der Download-Client 11 kann DLOTA oder irgendeine andere, beispielsweise auf http, HTTPS oder FTP basierende Luftschnittstelle 29 unterstützen. Der Download-Client 11 verfügt vorzugsweise über eine Schnittstelle zu einem Content-Speicher 17 via Content-Management 18.
Der Fahrzeugupdate-Server 24 ist für die Orchestrierung des Fahrzeugupdate-Prozesses zuständig. Mit anderen Worten: Er führt die definierte Update-Kampagne oder die definierten Update-Kampagnen aus. Die ursprünglich durch das OEM-Daten- und -Servicemanagement geschriebene Spezifikation der Kampagne für ein bestimmtes Fahrzeug 10 lässt sich vom Datenmanagement 27 beziehen. Diese Spezifikation verbindet die erforderlichen Dienste und Abläufe zu einem resultierenden Update-Prozess. Wenn das Fahrzeug 10 durch das Fahrzeugmanagement 25 erkannt und vermerkt wird, werden sein Zustand und Status dauerhaft durch das Datenmanagement 27 überwacht.
Der Fahrzeugupdate-Client 14 ist für die Ausführung der Anforderungen des Fahrzeugupdate-Servers 24 zuständig. Der Fahrzeugupdate-Client 14 koordiniert somit den Fahrzeugupdate-Prozess oder einen beliebigen Teil davon – Anwendungssoftware-Updates eingeschlossen – für das Fahrzeug 10. Um Flexibilität und einfache Anbindung an bestehende Technologien zu ermöglichen, implementiert der Fahrzeugupdate-Client 14 auch eine Management-Schnittstelle zum Gerätemanagement. Des Weiteren übernimmt der Fahrzeugupdate-Client 14 die Verantwortung für den heruntergeladenen Inhalt, empfängt den auf das Fahrzeug 10 bezogenen Teil – etwa die Update-Prozessdaten und andere Hilfsinformationen – und delegiert Update und Inhalt an die Client 12 bzgl. 13. Wird beispielsweise OMA-DM verwendet, so können FUMO und/oder SCOMO Objekte verwendet werden.
Das Datenmanagement 27 ist seitens des Backends 20 dafür zuständig, konsistente Daten und Inhalt an die Dienste zu liefern.
Das Content-Management 18 ist dafür zuständig, jedwede Art von Inhalt innerhalb des Fahrzeuges 10 persistent abzulegen. Es dient gleichsam als netzgebundener Speicher (network-attached storage, NAS) des Fahrzeuges 10 einschließlich der Fähigkeit, die Daten aus einer Web-Quelle zu laden. Mehrere Instanzen eines Content-Speichers 17 können innerhalb des Fahrzeuges 10 existieren und werden durch das Content-Management 18 verwaltet. Das Content-Management 18 kümmert sich um Speicherung, Depaketierung und Zusammenfügen von Daten und kann für jede Art von Anwendung innerhalb des Fahrzeuges 10 genutzt werden.
Der Content-Speicher 17 ist dafür zuständig, jedwede Art von Inhalt innerhalb des Steuergerätes (electronic control unit, ECU) persistent abzulegen. Es wird gleichsam wie eine zeichenorientierte Gerätedatei (raw device) verwendet. Mehrere Instanzen des Content-Speichers 17 können innerhalb des Fahrzeuges 10 existieren und werden durch das Content-Management 18 verwaltet. Der Content-Speicher 17 kümmert sich um die Speicherung und kann für jede Art von Anwendung innerhalb des Fahrzeuges 10 genutzt werden.
Der Steuergerät-Update-Client 12 resp. 13 ist für die Ausführung des Anwendungssoftware- oder Firmware-Updates für ein bestimmtes Steuergerät oder einen bestimmten Teilbereich zuständig. Der Steuergerät-Update-Client 12 resp. 13 fungiert als Client und ist mit dem Fahrzeugupdate-Client 14 verbunden. Er verwaltet den Anwendungssoftware (12)- oder Firmware (13)-Update-Prozess einschließlich des Rollbacks für ein bestimmtes Steuergerät oder einen bestimmten Teilbereich. Er ist darüber hinaus dafür zuständig, dass der Zustand des Steuergerätes oder Teilbereiches jederzeit bekannt ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 10105454 A1 [0004]

Claims

Teilsystem (30) für ein Fahrzeug (10), gekennzeichnet durch folgende Merkmale: – einen über eine Luftschnittstelle (29) mit einem Gerätemanagement-Server (26) des Backends (20) verbundenen Gerätemanagement-Client (16) zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, – einen über eine Luftschnittstelle (29) mit einem Download-Server (21) des Backends (20) verbundenen Download-Client (11) zum Herunterladen eines Softwareupdates von dem Backend (20) in das Fahrzeug (10), – mit dem Download-Client (11) verbundene Softwareupdate-Clients (12, 13) zum Anwenden des Softwareupdates und – einen mit dem Download-Client (11) und den Softwareupdate-Clients (12, 13) verbundenen Fahrzeugupdate-Client (14) zum Koordinieren des Softwareupdates.
Teilsystem (30) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: – mindestens einen Gerätemanagement-Client (16) zum Verwalten eines Gerätes des Fahrzeuges (10) und – einen mit dem Fahrzeugupdate-Client (14) und über die Luftschnittstelle (29) mit einem Gerätemanagement-Server (26) des Backends (20) verbundenen Gerätemanagement-Client (16) zum Führen des Gerätemanagements.
Teilsystem (30) nach Anspruch 1 oder 2, gekennzeichnet durch folgende Merkmale: – mindestens einen Gerätemanagement-Client (16) zum Verwalten eines Gerätes des Fahrzeuges (10) und – optionalen Gerätemanagement-Agent (15), die mit dem Gerätemanagement-Client (16) verbunden sind.
Teilsystem (30) nach Anspruch 1 oder 2 oder 3, gekennzeichnet durch folgende Merkmale: – mindestens einen Content-Speicher (17) zum Speichern des Softwareupdates und – ein mit dem Download-Client (11), den Softwareupdate-Clients (12, 13) und dem Fahrzeugupdate-Client (14) verbundenes Content-Management (18) zum Verwalten des Content-Speichers (17).
Teilsystem (30) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Softwareupdate-Clients (12, 13) mindestens einen Anwendungssoftware-Update-Client (12) und mindestens einen Firmware-Update-Client (13) umfassen.
Teilsystem (30) nach Anspruch 5, gekennzeichnet durch folgende Merkmale: – eine zumindest den Firmware-Update-Client (13) umfassende Fahrzeugelektronik-Domäne (40), – eine zumindest den Download-Client (11) umfassende Unterhaltungselektronik-Domäne (50) und – eine die Fahrzeugelektronik-Domäne (40) und die Unterhaltungselektronik-Domäne (50) verbindende abgesicherte Kommunikation (60).
Teilsystem (30) nach Anspruch 6, gekennzeichnet durch folgende Merkmale: – mindestens ein von der Fahrzeugelektronik-Domäne (40) umfasstes eingebettetes System (41) und – mindestens ein von der Fahrzeugelektronik-Domäne (40) umfasstes IP-fähiges System.
Teilsystem (30) nach Anspruch 7, gekennzeichnet durch folgende Merkmale: – das eingebettete System (41) umfasst zumindest ein Zentralgateway (44) oder eine Motorsteuerung (42) oder ein Fahrgetriebe (43) des Fahrzeuges (10) und entspricht einer offenen Fahrzeug-Systemarchitektur (45), – das IP-fähige System (46) umfasst zumindest den Firmware-Update-Client (13), und einen Unterhaltungselektronik-Proxy (48), – die Unterhaltungselektronik-Domäne (50) umfasst ein Sicherheitsprofil (51) zumindest des Download-Clients (11), eine Anwendungssicherheit-Engine (52) und einen Fahrzeugelektronik-Proxy (58) und – die abgesicherte Kommunikation (60) verbindet den Unterhaltungselektronik-Proxy (48) und den Fahrzeugelektronik-Proxy (58).
Teilsystem (30) nach Anspruch 7, gekennzeichnet durch folgende Merkmale: – die Fahrzeugelektronik-Domäne (40) umfasst ein an die Fahrzeugelektronik-Domäne (40) angepasstes Betriebssystem (49), welches den Unterhaltungselektronik-Proxy (48) ausführt und – die Unterhaltungselektronik-Domäne (50) umfasst ein an die Unterhaltungselektronik-Domäne (50) angepasstes Betriebssystem, welches den Fahrzeugelektronik-Proxy (58) ausführt.
Teilsystem (30) nach Anspruch 8, dadurch gekennzeichnet, dass die Unterhaltungselektronik-Domäne (50) ferner einen von dem an die Unterhaltungselektronik-Domäne (50) angepassten Betriebssystem (59) ausgeführten Steuergerät-Update-Client (53) umfasst.
Fahrzeug (10) mit einem Teilsystem (30) nach einem der Ansprüche 1 bis 10.