-
Die vorliegende Erfindung betrifft ein Verfahren zum Verwalten von Applikationen für Fahrzeuge. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Bekannt sind Verfahren zum Verteilen oder Aktualisieren von Software (SW) über eine - mitunter als „Luftschnittstelle“ (over the air, OTA) bezeichnete - drahtlose Datenschnittstelle. Gattungsmäßige Verfahren finden Anwendung sowohl auf Anwendungssoftware (SOTA) als auch auf eingebettete Systemsoftware (firmware, FOTA). Sofern im Folgenden die Abkürzung „SOTA“ verwendet wird, bezieht diese sich vorrangig auf Anwendungssoftware im engeren Sinn.
-
DE102015203766A1 offenbart ein Teilsystem für ein Fahrzeug mit einem über eine Luftschnittstelle mit einem Gerätemanagement-Server des Backends verbundenen Gerätemanagement-Client zum Austauschen von Geräte-, Fahrzeug- und von Diagnose- sowie Softwareupdateinformationen, einem über die Luftschnittstelle mit einem Download-Server des Backends verbundenen Download-Client zum Herunterladen eines Softwareupdates von dem Backend in das Fahrzeug, mit dem Download-Client verbundenen Softwareupdate-Clients zum Anwenden des Softwareupdates und einen mit dem Download-Client und den Softwareupdate-Clients verbundenen Fahrzeugupdate-Client zum Koordinieren des Softwareupdates.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Verwalten von Applikationen für Fahrzeuge, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Der vorgeschlagene Ansatz fußt hierbei auf der Erkenntnis, dass Fahrzeugnetzwerke strengen Anforderungen an die Dienstgüte (quality of service, QoS) beispielsweise hinsichtlich Latenz oder Laufzeitvarianz (jitter) unterliegen. Nach dem Stand der Technik erfolgt in der Regel eine lediglich statische Kommunikationsplanung innerhalb von Fahrzeugen, um diese Anforderungen zu befriedigen: Kommunikationspfade und Netzwerkzugriff werden statisch zur Entwicklungszeit ausgeplant und dementsprechend in die Kommunikationssoftware der beteiligten Steuergeräte einprogrammiert. Das Einbringen dynamischen Netzwerkverkehrs könnte diese statische Planung und damit die geforderte Dienstgüte gefährden.
-
Ein Grundgedanke der nachfolgend erörterten Lösung ist es, SOTA für Fahrzeugapplikationen hoher funktionaler Sicherheitsintegritätsstufe (automotive safety integrity level, ASIL), etwa Fahrerassistenzsysteme zu ermöglichen. Hierbei gilt es sicherzustellen, dass eine neue Applikation entwickelt, freigegeben und in das bestehende Fahrzeugkommunikationsnetzwerk integriert werden kann, ohne sich selbst oder andere, bereits installierte Applikationen negativ (im Sinne ihrer Funktionssicherheit gemäß ISO 26262) zu beeinflussen. Eine angesichts steigender Komplexität zunehmende Systemmodularisierung (Hardwareabstraktion, Einsatz von Middleware usw.) in der Fahrzeugtechnik sowie neue Geschäfts- und Software-Zuliefermodelle lassen eine derartige Lösung wünschenswert erscheinen.
-
Ein Vorzug des vorgestellten Konzeptes liegt in der Schaffung eines Systems zur Verwaltung von Ressourcen und Anwendungsanforderungen in Fahrzeugnetzen. „Ressourcen“ in diesem Sinne sind beispielsweise benötigte oder bereitgestellte Softwaredienste bestimmter Ausprägung, benötigte Rechenleistung zum Betrieb der jeweiligen Anwendung, frei verfügbare Rechenleistung des Fahrzeugs, benötigter statischer und dynamischer Speicher der Anwendung oder des Fahrzeugs sowie benötigte Kommunikationskanäle mit bestimmten Eigenschaften (z. B. Bandbreite oder ASIL).
-
Hierzu werden Anforderungsprofile der entsprechenden Applikationen definiert, welche via SOTA ins Fahrzeug eingebracht werden sollen. Können diese Anforderungen nicht befriedigt werden, so kann die betreffende Applikation nicht geladen oder gestartet werden. Vorteilhaft ist es, diesen Zustand vor einem etwaigen Download zu identifizieren und letzteren somit erst gar nicht anzubieten.
-
Besagten Anforderungsprofilen stehen Ressourcenangebote des Fahrzeugs bzw. seiner Fahrzeugcomputer gegenüber, z. B. die auf verschiedenen Fahrzeugcomputern frei verfügbare Rechenkapazität oder die Verfügbarkeit von Softwarediensten in bestimmter Qualität hinsichtlich Auflösung, maximaler Aktualisierungsfrequenz etc.
-
Das vorgeschlagene System setzt sich aus den folgenden Bestandteilen zusammen:
-
Durch ein Erstellsystem werden die benötigten Ressourcen beschrieben und mit den entsprechenden Instanzen („Apps“) in Zusammenhang gebracht. Es empfiehlt sich dabei, zur Beschreibung Profile zu nutzen.
-
Ein Prüfsystem überprüft, ob die zu ladende App auch im Fahrzeugkontext installations- und lauffähig ist. Dies wird durch die Auswertung aller Profile erreicht. Dieses Prüfsystem ist vorzugsweise nicht nur im Fahrzeug, sondern auch im Back-End vorhanden.
-
Auch ein Einstellsystem ist im Fahrzeug angeordnet und stellt die gewünschte Fahrzeug-Konfiguration (Netzwerke, Routing, Firewalls, etc.) ein. Somit ist die neue App lauffähig und kann letztlich gestartet werden.
-
Ein ebenfalls im Fahrzeug angeordnetes Überwachungssystem prüft die Einhaltung der in den Profilen der Applikationen bezüglich der Ressourcennutzung getroffenen Aussagen. Verletzt eine Applikation diese Randbedingung, so können Maßnahmen eingeleitet werden.
-
Wichtige Aspekte bilden die Beschreibung des Fahrzeugs und der Systemleistung der Fahrzeugcomputer („Angebote“), die Beschreibung aller erforderlichen Ressourcen, um im Fahrzeug eine vollständige Einstellung der Kommunikationskanäle vornehmen zu können sowie das Einstellsystem, welches die fahrzeugrelevanten Ressourcen (FlexRay, CAN und Ethernet) und Gateways entsprechend einstellen kann. Dieses Einstellsystem kann auch die ASIL-relevante Kommunikation konfigurieren, indem es z. B. bei Bedarf doppelte Kommunikationskanäle anlegt.
-
Ein weiterer Vorteil dieses Systems ist seine Eignung für ASIL-relevante Applikationen.
-
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.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 einen Systemüberblick.
- 2 einen möglichen Ablauf für das Anlegen eines neuen Kommunikationspfades als Flussdiagramm.
- 3 den möglichen Ablauf für das Anlegen eines neuen Kommunikationspfades als Sequenzdiagramm.
- 4 die durchgehende Architektur eines exemplarischen Fahrzeugs.
- 5 eine vereinfachte Darstellung der Software-Architektur eines Steuergerätes (electronic control unit, ECU).
- 6 eine Neukonfiguration der Fahrzeugkommunikation.
- Figur 7 mögliche Profile einer Applikation oder eines anderweitigen Softwarepakets.
-
Ausführungsformen der Erfindung
-
Ein Aspekt ist die dynamische Planung und Konfiguration von Kommunikationspfaden zur Laufzeit des Systems. Hierdurch wird es ermöglicht, Netzwerkverkehr zur Laufzeit zu- oder abzuschalten und gleichzeitig die Einhaltung der Dienstgüte zu garantieren. Unter Dienstgüte sind alle Eigenschaften zu verstehen, welche die Qualität einer Kommunikationsbeziehung bestimmen, insbesondere deren Datenrate, Informations- und Funktionssicherheit, Latenz und Verhalten bei Übertragungsfehlern (z. B. Korrekturen oder Wiederholung der Übertragung).
-
Eine Ausführungsform wird anhand von 1 erläutert und umfasst acht Schritte:
- 1. Beispielsweise von einem Erstausrüster (original equipment manufacturer, OEM) bereitgestellte Fahrzeugprofile (13) und Fahrzeugrechnerprofile (14) beschreiben die Möglichkeiten und Angebote des Fahrzeuges bzw. seiner Rechnersysteme. Die Gesamtmenge aller Beschreibungen - bezogen auf ein konkretes Fahrzeug - bestimmt dann die Menge an verfügbaren Ressourcen und ihrer Attribute, aus denen SW-Applikationen (12) und sonstige Artefakte sich gleichsam „bedienen“ können. Diese Ressourcenangebote werden in einem Back-End auf einem App-Marktplatz (app store 11) für Fahrzeuganwendungen bereitgestellt.
- 2. Der Bedarf der SW-Applikationen (12) wird nun in entsprechender Weise beschrieben. Hierzu bedarf es einer Festlegung darauf, welche Ressource mit welcher Mindest-Qualität benutzt werden soll. Auch diese Anforderungsprofile (9) werden im Back-End bereitgestellt.
- 3. Das Fahrzeug verbindet sich mit dem Back-End und liefert Informationen über Identität und bereits installierte SW-Applikationen (12).
- 4. Im Zuge eines ersten Abgleiches prüft das Back-End nun, welche der angebotenen SW-Applikationen (12) - einschließlich der bereits im Fahrzeug verfügbaren Anwendungen - im Rahmen des Ressourcenangebotes des Fahrzeuges oder seiner Computer installiert werden könnten. Diese Menge an SW-Applikationen (12) steht nun (z. B. dem Fahrer) zum Download ins Fahrzeug zur Verfügung.
- 5. Eine hierzu Berechtigte Instanz (Fahrer, Computersystem o. ä.) wählt nun eine SW-Applikation aus und lädt diese ins Fahrzeug herunter; deren Anforderungsprofil (9) ist als Metadatum verfügbar. Die SW-Applikation oder eine berechtigte SW-Instanz für die SW-Applikation (ein sog. SOTA-Client) im Fahrzeug verbindet sich mit einer Middleware, welche den weiteren Registrierungsprozess bereitstellt.
- 6. Die Middleware legt das neue Anforderungsprofil (9) einem zweiten Abgleich zugrunde, um die tatsächliche Verfügbarkeit der angeforderten Ressourcen zu prüfen. Dieser zweite Abgleich innerhalb des Fahrzeuges ist wünschenswert, da - etwa zum Schutz des Fahrzeuges - Änderungen zwischen Download- und Installations-Zeitpunkt denkbar sind. Die Funktion wird beispielsweise durch softwaredefinierte Vernetzung (software-defined networking, SDN) mittels eines entsprechenden Controllers realisiert. Dieser berechnet nun aufgrund des Zustandes des Fahrzeuges und der gewünschten Änderung eine mögliche neue Konfiguration und reserviert diese.
- 7. Nach positiver Rückmeldung wird nun die Middleware die eigentliche Konfigurationsänderung durchführen; auch diese Funktion ist beispielsweise durch einen SDN-Controller abgedeckt. Die vorab reservierte neue Konfiguration wird aktiviert - ab diesem Zeitpunkt ist die neue Applikation (5) in die Fahrzeugkommunikation eingebunden.
- 8. Parallel zur Nutzung der neuen Applikation (5) sorgt ein Überwachungssystem dafür, dass das tatsächliche Kommunikationsverhalten der SW-Applikation (5) nicht die definierten Grenzen übersteigt. Kommt es dennoch dazu, können Maßnahmen wie das Abschalten der Applikation (5) oder Begrenzen von Bandbreiten erfolgen.
-
Ein Erstellsystem hat die Aufgabe, die nötigen Ressourcen zu beschreiben sowie insbesondere die für die Dienstgüte maßgeblichen Attribute zu definieren. Zudem muss eine Zuordnung einer solchen Beschreibung zu jedem SW-Artefakt und insbesondere den Applikationen (12) sowie zum Fahrzeug selbst und den als Zielsystemen vorgesehenen Fahrzeugcomputern erfolgen. Diese Beschreibung kann entweder manuell separat erstellt oder den SW-Artefakten teil- oder vollautomatisiert entnommen werden. Ein neuartiger Aspekt liegt darin, dass die Anforderungen als strukturierte Informationen zur dynamischen Ressourcenverwaltung von entsprechenden Systemkomponenten nach einem Mechanismus - z. B. unter Nutzung einer Anwendungsprogrammierschnittstelle (application programming interface, API) gemäß den nachfolgend erläuterten Aktivitätsdiagrammen und Zustandsmodellen - benutzt werden und nicht nur, dass die Anforderungen als strukturierte Informationen bereitstehen und in beliebiger Weise (JSON, XML, etc.) repräsentiert werden können.
-
Die Inhalte der Anforderungsprofile (10), also die Anforderungen an die Eigenschaften einer Kommunikation, und somit die Anforderungsprofile (9) selbst werden automatisiert außerhalb des Fahrzeuges im Rahmen der Softwareerstellung (build) und -verteilung (deployment) generiert und entsprechen dem, was die SW-Applikationen (12) implementieren und zu ihrer sicheren Funktion an Ressourcen benötigt. Die Anforderungsprofile (9) sind entsprechend als strukturierte Informationen im Fahrzeug (API-konform) bearbeitbar und zur dynamischen Ressourcenverwaltung nutzbar.
-
Die Funktionsweise des fahrzeugseitigen Prüf- und Einstellsystems (7) illustriert 2. Das Prüfsystem ist Bestandteil der Middleware und interagiert somit mit einer Applikation (5). Kern des Prüfsystems ist ein Kommunikations-Manager, der beispielsweise durch SDN-Technologie realisiert wird, die aktuelle Konfiguration der Kommunikation kennt und in der Lage ist, Änderungswünsche zu prüfen, zu reservieren (Schritt 22) und einzustellen. Ein wichtiger Aspekt liegt darin, das eine Applikation (5) über die Middleware zur Laufzeit Kommunikationspfade im Fahrzeug einrichten kann, welche eine vorgegebene Dienstgüte aufweisen und die diesbezüglichen Eigenschaften bestehender Kommunikationspfade nicht beeinflussen. Hierzu werden alle im Fahrzeug genutzten Kommunikationspfade vom SDN-Controller (41 - 4) zugewiesen und überwacht. Der SDN-Controller (41) nutzt hierzu Informationen, welche entweder extern zur Verfügung gestellt (siehe oben) oder durch Anwendung geeigneter Messmethoden erhoben wurden (Topologie-Erkennung, Buslastmessung etc.). Die nachzuladende SW-Applikation oder für die nachzuladende SW-Applikation berechtigte, nachfolgend als „SOTA-Client“ bezeichnete SW-Instanz (5) ist, wie in 5 dargestellt, Teil eines Steuergerätes (50) und verfügt über eine Schnittstelle zu der Middleware (52), welche physikalische Ressourcen wie beispielsweise Kommunikationshardware (51) abstrahiert.
-
Wie in 3 beispielhaft dargestellt fragt die SW-Applikation oder der SOTA-Client (5) hierzu den gewünschten Kommunikationspfad bei der Middleware (52) an (Schritt 20). Hierbei werden die Anforderungen an die Eigenschaften des Kommunikationspfades wie beispielsweise die maximale Latenz oder die Periodizität mit übergeben. Die Middleware (52) berechnet hieraus die notwendigen Kommunikationsressourcen wie beispielsweise die für den Kommunikationspfad notwendige Bandbreite (Schritt 21).
-
Diese Kommunikationsressourcen werden beim SDN-Controller (41) zur Reservierung (22) angefragt. Der SDN-Controller (41) kennt die Topologie des Netzwerks sowie alle derzeit angelegten oder registrierten Kommunikationspfade und deren genutzte Kommunikationsressourcen. Der SDN-Controller (41) kennt ebenso die Kapazitäten der Netzwerkverbindungen und somit die Grenzen der möglichen Kommunikationsressourcen für durchgehende Kommunikationspfade (end-to-end limits). Der SDN-Controller (41) nutzt diese Information ebenfalls zur Reservierung (22) oder Registrierung (25) eines Kommunikationspfades oder von Kommunikationsressourcen.
-
Mit diesem Wissen prüft der SDN-Controller (41) wie folgt, ob die von der Middleware (52) angefragten Kommunikationsressourcen zur Verfügung stehen:
- 1. Der angefragte Kommunikationspfad wird zunächst in die einzelnen physikalischen Strecken aufgeteilt.
- 2. Anschließend wird für jede Teilstrecke sowie für jedes verbindende Gateway (42 - 4) geprüft, ob unter Betrachtung der Kommunikationskapazitäten (z. B. Bandbreite oder Latenz), der derzeitigen Auslastung und der zusätzlichen Belastung durch den angefragten neuen Pfad eine sichere Kommunikation weiterhin möglich wäre.
- 3. Ist dies der Fall, bestätigt der SDN-Controller (41) die Reservierung (22) gegenüber der Middleware (52), welche den Kommunikationspfad mit den geforderten Eigenschaften wiederum der SW-Applikation oder dem SOTA-Client (5) anbietet.
- 4. Die Applikation oder der SOTA-Client (5) kann das Angebot (24) in Anspruch nehmen, indem sie bzw. er den Kommunikationspfad bei der Middleware (52) analog zur Reservierung (22) endgültig registriert und somit neukonfiguriert (Schritt 25).
-
Diese Funktionsweise des Prüf- und Einstellsystems (7) ist 2 zu entnehmen.
-
Entscheidet sich das Prüfsystem für eine Registrierung (25), so übernimmt das Einstellsystem (7) das reservierte Angebot (24) und stellt sicher, dass diese Kommunikationsressourcen für die SW-Applikation (5) freigegeben sind und die SW-Applikation (5) auch nur die vom System freigegebenen Ressourcen verwenden kann (Schritt 26). Eine von der ursprünglichen Vereinbarung und Registrierung (25) abweichende Kommunikationspfad- und Kommunikationsressourcennutzung der Fahrzeugressourcen wird durch den sicheren Softwareanwendungsreservierungsprozess (60) und Softwareanwendungsregistrierungsprozess (61) verhindert bzw. nicht ermöglicht (6). Wichtig ist, dass das System anhand wohldefinierter Informationen aus den Anforderungsprofilen (9) arbeitet und diese auf Anfrage (20) zur Konfigurationsänderung von Kommunikationsressourcen verwendet. Die SW-Applikation (5) genügt hierzu nicht nur den APIs der Middleware (52), sondern entspricht auch den strukturierten und wohldefinierten Informationen ihres Anforderungsprofiles (10).
-
Die Überwachung (62) zugewiesener und registrierter Kommunikationspfade und Kommunikationsressourcen kann -je nach genutzter Kommunikationstechnologie - bei Ethernet etwa durch Eingriffe in die sogenannten Forwarding-Tabellen der Switches (40 - 4) oder bei Bussystemen durch direkte Eingriffe in die Kommunikationstreiber (53) der beteiligten Steuergeräte erfolgen.
-
Das Überwachungssystem (8) vergleicht permanent die aktuelle Kommunikation mit dem Anforderungsprofil (9) jeder Applikation (5) sowie dem Ressourcenangebot der Steuergeräte (50) und anderer Einheiten des Fahrzeuges und stellt sicher, dass ein fehlerhaftes Verhalten erkannt und darauf reagiert werden kann. Das Überwachungssystem (8) ist als fakultativ zu betrachten, sofern der Richtigkeit der Anforderungsprofile (9) vertraut werden kann.
-
Eine Alternative zum besagten SDN-Controller (41) kann ein verteiltes System sein. Eine entsprechende Ausprägung ist vorteilhaft zur Erhöhung der Ausfallsicherheit. Mögliche Implementierungsvarianten reichen von zwei SDN-Controllern, die sich z. B. durch eine dedizierte Netzwerkverbindung (heartbeat) gegenseitig synchronisieren und überwachen, wobei der erste Controller (41) aktiv ist und der zweite als sofort einsetzbarer Ersatz (hot standby) bereitsteht, um beim Ausfall des ersten Controllers (41) dessen Aufgaben zu übernehmen bis hin zu drei oder mehr SDN-Controllern (41), die sich gegenseitig synchronisieren und überwachen und welche zudem per Stimmabgabe (voting) oder Plausibilitätskontrolle gegenseitig ihre Integrität prüfen. Letztere Variante ist vorteilhaft zur Erhöhung der Fehlertoleranz.
-
Eine sinnbildliche Umwandlung des Kommunikationspfades in Kommunikationsressourcen kann auch durch den SDN-Controller (41) oder ein anderes Element erfolgen, ohne den Rahmen der Erfindung zu verlassen.
-
Alternativ erfolgt eine Kommunikation der Applikation (5) direkt mit dem SDN-Controller (41) ohne Middleware (52) oder anderweitigen Mittler.
-
Ferner können Feststellung oder Überwachung (62) der Topologie bzw. der Ressourcennutzung durch ein anderes Element als den SDN-Controller (41) erfolgen.
-
Für den Fall, dass die angefragten Kommunikationsressourcen nicht vollständig angeboten werden können, kann der SDN-Controller (41) auch eine Ressourcenreservierung (22) unter Einschränkungen anbieten.
-
In Erweiterung des dargestellten Verfahrens kann das Überwachungssystem (8) genutzt werden, um einem Angriffserkennungssystem (intrusion detection system, IDS) Informationen zu liefern, da es ja fortlaufend die Applikation (5) bzgl. ihr Verhalten überwacht (62). Somit können diese Daten auch zum Erkennen von Unregelmäßigkeiten durch einen Angriff oder eine Softwarefehlfunktion („Anomalie“) - zum Beispiel anhand einer untypischen Ressourcennutzung - benutzt werden. Schließlich kann das Prüfsystem auch im App-Store (11) des Back-Ends verfügbar sein; somit können nur jene Applikationen (12) zum Download angezeigt und bereitgestellt werden, welche im Fahrzeug tatsächlich lauffähig sind.
-
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 102015203766 A1 [0003]
