DE102021211353A1

DE102021211353A1 - Verfahren zur Inbetriebnahme von Programmpaketen in Fahrzeugen

Info

Publication number: DE102021211353A1
Application number: DE102021211353.2A
Authority: DE
Inventors: Carolin Hilbert; Tereza Georgeta Bandino; Catalin-Cristian Ilie
Original assignee: Continental Automotive Technologies GmbH
Current assignee: Continental Automotive Technologies GmbH
Priority date: 2021-10-07
Filing date: 2021-10-07
Publication date: 2023-04-13
Also published as: CN118043774A; WO2023057017A1; KR20240036726A

Abstract

Die Erfindung betrifft ein Verfahren zur Inbetriebnahme von Programmpaketen (70) in Fahrzeugen, insbesondere zur Inbetriebnahme eines neuen Programmpakets (70) auf mindestens einer Fahrzeugrecheneinheit (160) eines Fahrzeugs (100). Das Verfahren weist folgende Schritte auf:laden des Programmpakets (70) aus einem zentralen Archiv (20);speichern des Programmpakets (70) in einem fahrzeugspezifischen Archiv (120);validieren des Programmpakets (70) in dem fahrzeugspezifischen Archiv (120);bestimmen der Fahrzeugrecheneinheit (160) aus einer Vielzahl von Recheneinheiten (160, 161) des Fahrzeugs (100);bereitstellen des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160); undstarten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160),wobei das Programmpaket (70) eine Fahrzeugfunktion ausführt.

Description

Gebiet der Erfindung
Die Erfindung betrifft ein Verfahren zur Inbetriebnahme von Programmpaketen in Fahrzeugen, insbesondere zur Inbetriebnahme eines neuen Programmpakets auf mindestens einer Fahrzeugrecheneinheit eines Fahrzeugs. Weiterhin betrifft die Erfindung ein System, ein Fahrzeug, ein Programmelement, ein computerlesbares Medium und eine Verwendung.
Hintergrund
Fahrzeugfunktionen werden in vielen Fällen bei der Herstellung eines Fahrzeugs in dem Fahrzeug statisch implementiert und sind oft schwierig zu ändern. In zumindest einigen Fällen erfordert eine Änderung einer Fahrzeugfunktion das Aufsuchen einer Werkstatt und/oder den Austausch der Hardware, mittels derer die Fahrzeugfunktion realisiert wird. Dies kann insbesondere dann störend sein, wenn eine Inbetriebnahme eines neuen Programmpakets eine Verbesserung der Fahrzeugfunktion und/oder eine Fehlerkorrektur ermöglichen würde.
Zusammenfassung
Es ist Aufgabe der Erfindung, ein Verfahren zur Verfügung zu stellen, das in zumindest einigen Fällen eine Inbetriebnahme eines neuen Programmpakets vereinfacht. Diese Aufgabe wird durch den Gegenstand der unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen und der folgenden Beschreibung.
Ein Aspekt betrifft ein Verfahren zur Inbetriebnahme eines neuen Programmpakets auf mindestens einer Fahrzeugrecheneinheit eines Fahrzeugs. Das Verfahren weist folgende Schritte auf:

laden des Programmpakets aus einem zentralen Archiv;
speichern des Programmpakets in einem fahrzeugspezifischen Archiv;
validieren des Programmpakets in dem fahrzeugspezifischen Archiv;
bestimmen der Fahrzeugrecheneinheit aus einer Vielzahl von Recheneinheiten des Fahrzeugs;
bereitstellen des validierten Programmpakets auf der Fahrzeugrecheneinheit; und starten des validierten Programmpakets auf der Fahrzeugrecheneinheit, wobei das Programmpaket eine Fahrzeugfunktion ausführt.

Bei dem Fahrzeug handelt es sich beispielsweise um ein Kraftfahrzeug, wie Auto, Bus oder Lastkraftwagen, oder aber auch um ein Schienenfahrzeug, ein Schiff, ein Luftfahrzeug, wie Helikopter oder Flugzeug. Eine Fahrzeugrecheneinheit (Vehicle Computing Platform, VCP) ist ein Prozessor („general-purpose processor“), ein Controller, dedizierte Hardware, z.B. mit Firmware und/oder weitere Typen von Recheneinheiten. Ein Programmpaket ist eine Datei, die auf mindestens einer der Fahrzeugrecheneinheiten ablauffähig, interpretierbar und/oder compilierbar ist. Das Programmpaket kann komprimiert und/oder verschlüsselt sein. Die Inbetriebnahme kann einen Download und ein Bereitstellen (deployment) des Programmpakets umfassen. Die Inbetriebnahme des Programmpakets führt dazu, dass mindestens einer der Fahrzeugrecheneinheiten eine oder mehrere Fahrzeugfunktionen ausführen kann. Das Ausführen der Fahrzeugfunktionen kann sofort nach einer Übertragung des Programmpakets auf die Fahrzeugrecheneinheit (d.h. auf eine Ziel-Recheneinheit) beginnen, es kann aber auch erst zu einem späteren Zeitpunkt gestartet werden.
Das neue Programmpaket kann zum Beispiel eine bereits existierende oder eine ähnliche Fahrzeugfunktion realisieren („Update“), z.B. im Rahmen einer Verbesserung der Leistung und/oder einer Fehlerkorrektur. Das neue Programmpaket kann z.B. eine oder mehrere neue Fahrzeugfunktionen hinzufügen („Upgrade“). In zumindest einigen Fällen können Updates „automatisch“ geladen werden, d.h. beispielsweise gesteuert von einem zentralen Servicepersonal. In zumindest einigen Fällen können Upgrades von einem Benutzer z.B. von einem Fahrer des Fahrzeugs, einem Leasinganbieter, usw. - angefordert und/oder genehmigt werden. Zumindest einige Fahrzeugfunktionen können zu beiden Kategorien gehören, z.B. ein neues Navigationssystem. Der Benutzer kann z.B. optionale Funktionsaktualisierungen ablehnen oder aufschieben. Obligatorische Updates können automatisch installiert werden. Für neue Fahrzeugfunktionen kann das Deployment der Funktion auf einem VCP zu dem Zeitpunkt durchgeführt werden, zu dem die Funktion das erste Mal gestartet werden soll.
Die Programmpakete für ein Fahrzeug können von einem oder von mehreren Herstellern zugeliefert werden. Die Programmpakete können nach dem Zuliefern in einem zentralen Archiv (Online Repository) gespeichert werden. Das Laden des Programmpakets aus dem zentralen Archiv kann über eine Kabelverbindung und/oder kabellos (drahtlos) erfolgen. Das Laden des Programmpakets aus dem zentralen Archiv kann ein optionaler Schritt sein, d.h. zumindest einige Programmpakete können - z.B. bei der Herstellung - auf dem Fahrzeug bereits vorinstalliert sein. Die drahtlose Übertragung des Programmpakets oder der Programmpakete kann z.B. per Bluetooth, WLAN (z.B. WLAN 802.11a/b/g/n oder WLAN 802.11p), ZigBee oder WiMax oder aber auch zellulärer Funksysteme wie GPRS, UMTS, oder LTE und/oder 5G erfolgen. Alternativ oder zusätzlich ist auch die Verwendung anderer Übertragungsprotokolle möglich.
Nach dem Laden des Programmpakets kann dieses in einem fahrzeugspezifischem Archiv (In-Vehicle-Repository) gespeichert werden. Das Speichern kann ein Dekomprimieren, Entschlüsseln, Compilieren und/oder ein Anpassen an das Fahrzeug umfassen. Das fahrzeugspezifische Archiv kann Einrichtungen aufweisen, um das Programmpaket zu validieren; dies kann ein Verifizieren und/oder Testen beinhalten, z.B. mittels Authentifizierung des Programmpakets, Regressionstests, Simulation von Schnittstellen und/oder Systemaufrufen (System Calls) und/oder Weiteres. Diese Einrichtungen können dauerhaft oder bei Bedarf zur Verfügung stehen; so können beispielsweise Regressionstests mit dem Programmpaket mitgeliefert werden. Für Fälle, in denen das Programmpaket nicht auf einer Recheneinheit des fahrzeugspezifischen Archivs (dem „Archivprozessor“) ablauffähig ist - z.B. weil die Ziel-Hardware ein anderer Prozessortyp ist -, kann das fahrzeugspezifische Archiv Mittel zur Simulation und/oder Emulation zur Verfügung stellen.
Das Bestimmen der Fahrzeugrecheneinheit (Ziel-Recheneinheit) aus einer Vielzahl von Recheneinheiten des Fahrzeugs kann eine Analyse der Ziel-Recheneinheit, der aktuellen Prozessorlast, des Programmpakets und/oder weiterer Aspekte beinhalten. Als ein Ergebnis des Bestimmens der Ziel-Recheneinheit wird das validierte Programmpaket auf der Ziel-Fahrzeugrecheneinheit bereitgestellt (deployment).
Nach dem Bereitstellen des Programmpakets kann das Programmpaket auf der Fahrzeugrecheneinheit gestartet werden, so dass das Programmpaket eine Fahrzeugfunktion ausführt. Das Starten kann sofort erfolgen, oder erst nach einem vorbestimmten Ereignis. Beispielsweise kann eine „Fail-Operational Funktion“ (im Fehlerfall auf ein Backup-System umschalten) und/oder eine „Fall-back Funktion“ (im Fehlerfall auf ein Backup-System umschalten, in zumindest einigen Fällen verbunden mit einem Downgrading der ursprünglichen Funktion) zunächst auf einem Backup-Prozessor geladen werden, und erst in einem Fehlerfall aktiviert oder gestartet werden. Auf diese Weise kann z.B. ein sog „Hot Swap“ im Fehlerfall realisiert werden.
Das Verfahren stellt vorteilhafterweise einen Rahmen zur Verfügung, der die Inbetriebnahme eines neuen Programmpakets vereinfacht und dies darüber hinaus schneller und sicherer macht. Weiterhin ist das Verfahren für eine Vielzahl von Anwendungsfällen einsetzbar. Die folgende Liste stellt einige illustrierende Anwendungsfälle vor:

• Eine erweiterte Kindersicherung der hinteren Türen kann zum Beispiel die Betätigung der Fensterheber ausschließen, um bei kleinen Kindern ein Einklemmen zu verhindern.
• Ein erweitertes Navigationssystem kann z.B. Spezifika wie Durchfahrtshöhen, eine höhere Auflösung von bestimmten Strecken und/oder vordefinierte Farben umfassen. Dies kann auch als kostenpflichtiges Merkmal angeboten werden, und die Inbetriebnahme und/oder Auslieferung kann an ein Zahlsystem gekoppelt werden.
• Für bestimmte Überlastfunktionen und/oder Ausfälle einer Fahrzeugrecheneinheit kann eine funktionsreduzierte (fall-back) Funktion bereitstehen, auf die auf einer Ziel-Fahrzeugrecheneinheit bereitgestellt ist und die im Ereignisfall aktiviert wird.

Weiterhin kann dies zu einer Reduzierung der Hardware-Abhängigkeit von Fahrzeugfunktionen beitragen, durch die gemeinsame „Middleware“ und durch ein Framework, das mehrere Hardware-Plattformen unterstützen kann. Ferner kann ein dynamisches Deployment und Redeployment von Fahrzeugfunktionen über ein vorzugsweise von Fahrzeugrecheneinheit unterstützt werden. Dies kann die Installation neuer Fahrzeuganwendungen und/oder die Aktualisierung bestehender Funktionen erleichtern, ohne dass jedesmal Servicepersonal oder eine Werkstatt benötigt wird. Auch kann dies eine Basis sein für neue Geschäftsmodelle, wie z.B. „pay per function“, „pay per function usage“, etc. Das Verfahren kann eine Basis liefern für eine Optimierung der Ressourcennutzung, z.B. Rechen- und/oder Netzwerk-Ressourcen, Energieverbrauch, etc., und/oder eine Verbesserung Laufzeit der Fahrzeugrecheneinheiten, beispielsweise weil nur diejenigen Recheneinheiten belastet werden, die für eine bestimmte Anwendung tatsächlich benötigt werden. Darüber hinaus können Mittel für ein konsistentes Redundanzkonzept zur Verfügung gestellt werden, z.B. für „Fail-Safe“ oder „Fail-Operational“ Funktionen.
In einigen Ausführungsformen umfasst das Validieren des Programmpakets ein Emulieren von Funktionen, die nicht auf einem Archivprozessor des fahrzeugspezifischen Archivs ablauffähig sind. Beispielsweise kann die Ziel-Fahrzeugrecheneinheit ein anderer Prozessortyp oder Hardwaretyp sein als der Prozessor („Archivprozessor“) des fahrzeugspezifischen Archivs. Zum Beispiel kann die Ziel-Fahrzeugrecheneinheit aus einer dedizierten Hardware bestehen oder diese aufweisen, ein anderer Prozessor-Typ, andere Schnittstellen (z.B. ioctl) und/oder Weiteres aufweisen, so dass das Programmpaket nicht ohne Weiteres auf dem Archivprozessor ablauffähig ist. Durch das Simulieren und/oder Emulieren von Funktionen können die Hardwareabhängigkeiten deutlich reduziert werden.
In einigen Ausführungsformen wird das Laden des Programmpakets durch eine Anforderung eines Benutzers, durch eine Anforderung einer Zuordnungs- und Überwachungseinheit und/oder durch eine Versionskontrolle getriggert. Der Benutzer kann z.B. der Fahrer, ein Leasinganbieter, eine Werkstatt und/oder weitere Personen und/oder Institutionen sein. Der Benutzer kann z.B. ein Überwachungsprogramm sein, das zum Beispiel bei erkannten kritischen Fehlern ein korrigiertes Programmpaket automatisiert lädt. Der Benutzer kann z.B. eine Versionskontrolle sein, um bestimmte Funktionen zu Optimieren.
In einigen Ausführungsformen wird das Bestimmen der Fahrzeugrecheneinheit durch eine Liste von Kriterien gesteuert wird, welche umfasst:

Bestimmen eines Typs der Fahrzeugrecheneinheit;
Bestimmen einer Funktion der Fahrzeugrecheneinheit;
Bestimmen einer Rechenleistung der Fahrzeugrecheneinheit;
Bestimmen einer Speichergröße und/oder Speicherleistung der Fahrzeugrecheneinheit; und/oder
Bestimmen eines Energieverbrauchs der Fahrzeugrecheneinheit.

Es erfolgt also eine Durchführung einer dynamischen Funktionszuweisung, d.h. eine Entscheidung über die Ziel-Fahrzeugrecheneinheit für die neue Fahrzeugfunktion und/oder die Funktionsaktualisierung auf Basis eines Zuweisungsalgorithmus unter Berücksichtigung funktionaler Abhängigkeiten und Einsatzbeschränkungen der Funktion.
Das Bestimmen eines Typs der Fahrzeugrecheneinheit kann das Bestimmen z.B. der Hardware der Fahrzeugrecheneinheit umfassen. Bei dem Bestimmen einer Funktion der Fahrzeugrecheneinheit kann die Funktion z.B. das Steuern von Fensterhebern oder eine Infotainment-Funktion sein.
Das Bestimmen einer Rechenleistung der Fahrzeugrecheneinheit kann z.B. ein Vergleichen der aktuellen Leistung beinhalten, der maximalen Leistung und/oder einer Historie der Leistung von anderen Prozessoren beinhalten. Dies kann z.B. zu einem (z.B. zeitweisen) Downgrading der Funktion führen, und/oder ein Auswählen einer Alternativ-Funktion beinhalten. Es kann eine Analyse eines stay-alive-Signals beinhalten. Es kann das Erkennen eines Fehlers und/oder das Markieren einer fehlerhaften Fahrzeugrecheneinheit als unverfügbar beinhalten. Das Bestimmen einer Speichergröße und/oder Speicherleistung der Fahrzeugrecheneinheit kann z.B. Durchsatz und/oder Latenz betreffen.
In einigen Ausführungsformen umfasst das Bestimmen der Fahrzeugrecheneinheit ein Auswählen einer Alternativ-Funktion des Programmpakets. Die Alternativ-Funktion: kann Teil des Programmpakets sein, oder eine andere Funktion, wie z.B. eine ältere Funktion, zum Beispiel bei einem Fehler nach einer Neuinstallation einer neuen Funktion, z.B. gerade auf diesem Fahrzeug.
In einigen Ausführungsformen umfasst das Bestimmen der Fahrzeugrecheneinheit und/oder Bereitstellen des validierten Programmpakets ein Speichern von Informationen über das Programmpaket in einem Fahrzeugregister (Global Function Registry). Damit kann jederzeit zentral ein Überblick über die aktuellen Funktionen und/oder Software-Versionen (etc.) gewährt werden.
In einigen Ausführungsformen weist das Verfahren weiterhin auf, die Fahrzeugfunktion auf einer anderen Fahrzeugrecheneinheit zu stoppen und/oder zu deinstallieren; bzw. die Fahrzeugfunktion zu stoppen und optional zu deinstallieren. Die Fahrzeugfunktion kann ein Bündel von ausgewählten Funktionen sein. Damit kann die andere Fahrzeugrecheneinheit entlastet werden. Dies kann vorteilhafterweise z.B. bei einem Fehler und/oder bei hoher Last (Overload) eingesetzt werden und/oder für eine Optimierung (resource optimisation scenario) verwendet werden.
In einer Ausführungsform beinhaltet das Stoppen der Fahrzeugfunktion einer anderen Fahrzeugrecheneinheit ein Bewerten der Kritikalität der Fahrzeugfunktion. So können kritische Funktionen z.B. auf einem anderen Prozessor gestartet werden. Unkritische Funktionen können beispielsweise - zumindest für einen vordefinierten Zeitraum - gestoppt werden.
In einigen Ausführungsformen wird das Starten des validierten Programmpakets auf der Fahrzeugrecheneinheit mittels eines Starttriggers gesteuert. Beispiele können Starttrigger sein, die erst bei Overload oder Fehler wirksam werden.
In einigen Ausführungsformen beinhaltet das Laden des Programmpakets, das Speichern des Programmpakets, das Validieren des Programmpakets, das Bereitstellen des validierten Programmpakets und/oder das Starten des validierten Programmpakets eine Authentifizierung dieser Aktion. Dies kann z.B. mit kryptographischen Methoden realisiert werden. Dies erhöht vorteilhafterweise eine Sicherheit gegenüber unzulässigem Zugriff auf Fahrzeugfunktionen.
Ein Aspekt betrifft ein Programmelement, welches, wenn es auf einer oder mehreren Recheneinheiten eines Fahrzeugsystems eines Fahrzeugs und/oder auf einer anderen Recheneinheit ausgeführt wird, die mindestens eine Recheneinheit anweist, das Verfahren wie oben und/oder nachfolgend beschrieben durchzuführen.
Ein Aspekt betrifft ein computerlesbares Medium, auf dem das hier beschriebene Programmelement gespeichert ist.
Ein Aspekt betrifft ein Fahrzeugsystem zur Inbetriebnahme eines neuen Programmpakets auf mindestens einer Fahrzeugrecheneinheit eines Fahrzeugs. Das Fahrzeugsystem weist ein fahrzeugspezifisches Archiv (In-Vehicle-Repository) auf, das zur Speicherung eines Programmpakets aus der Vielzahl von Programmpaketen und zum Validieren des Programmpakets eingerichtet ist. Das fahrzeugspezifische Archiv kann als lokaler Applikationsserver in dem Fahrzeug gesehen werden.
Weiterhin weist es eine Vielzahl von Fahrzeugrecheneinheiten (Vehicle Computing Platform, VCP) auf, die zur Ausführung von fahrzeugspezifischen Befehlen eingerichtet ist. Diese Befehle können von einem CAM (siehe unten) gesandt werden und beispielsweise Funktionen wie Start, Stopp, Restart einer oder mehrerer Funktionen, Senden des ECU-Alive-Status, und/oder weitere umfassen. Die Fahrzeugrecheneinheit kann allgemeiner Prozessor sein (Electronic Control Unit, ECU), ein Multiprozessor, dedizierte Hardware, kann Interfaces, Busse und/oder Netzwerkkomponenten umfassen, und/oder sie kann für verschiedene Grade von Echtzeitanforderungen geeignet sein. Die VCP kann Aktivitätssignale (alive status) senden. Die VCP kann Steuerfunktionen wie Start, Stopp, Restart, etc. empfangen und verarbeiten.
Das Fahrzeugsystem weist ferner eine Zuordnungs- und Überwachungseinheit (Central Allocation Manager, CAM) auf, die zum Bestimmen der Fahrzeugrecheneinheit aus der Vielzahl von Recheneinheiten des Fahrzeugs, zum Bereitstellen des validierten Programmpakets auf der Fahrzeugrecheneinheit, und zum Starten des validierten Programmpakets auf der Fahrzeugrecheneinheit eingerichtet ist. Die Zuordnungs- und Überwachungseinheit kann als eine zentrale Komponente bzw. Steuergerät (ECU) in dem Fahrzeug ausgelegt sein und/oder als eine redundante Komponente ausgelegt sein. Die Zuordnungs- und Überwachungseinheit kann das dynamische Deployment und Redeployment von Fahrzeugfunktionen und Fahrzeugfunktions-Updates verwalten. Weiterhin erfolgt damit eine Überwachung aller Steuergeräte hinsichtlich Ressourcenverbrauch und -nutzung sowie Steuergeräteausfällen. Ferner übernimmt diese Komponente das Erkennen von Hardwareausfällen, Ressourcenüberlastungen und Durchführen eines Lastausgleichs für jedes Steuergerät mittels dynamischer Funktionsreallokation, d.h. der Neuverteilung von Funktionen.
In einigen Ausführungsformen ist die Zuordnungs- und Überwachungseinheit weiterhin zur Überwachung (Monitoring) der Fahrzeugrecheneinheiten eingerichtet, insbesondere zum Detektieren von Hardware-Fehlern, zum Detektieren von Überlastung, und/oder zur Realisierung von Load Balancing durch Übertragen von Teilfunktionen.
Zudem kann die Zuordnungs- und Überwachungseinheit weiterhin ein Fahrzeugregister (Global Function Registry) umfassen, aufweisend eine Information, welche Fahrzeugfunktion welcher Fahrzeugrecheneinheit zugeordnet (deployed) ist. Das Fahrzeugregister kann eine Information darüber enthalten, welche Funktionen noch nicht aktiviert sind, und/oder darüber, welche Funktionen als Ersatzfunktion und/oder „degraded“ Funktion einer anderen Funktion - die z.B. auf einer anderen Fahrzeugrecheneinheit aktiviert ist - betrachtet werden kann.
In einigen Ausführungsformen umfasst das fahrzeugspezifische Archiv eine Testeinheit, die zum Testen, zum Simulieren und/oder zum Emulieren von Fahrzeugfunktionen eingerichtet ist. Die Testeinheit kann Schnittstellen und/oder Systemaufrufe (System Calls) des Programmpakets „kennen“, d.h. in der Lage sein, diese - z.B. mittels Simulation und/oder Emulation - zu verarbeiten, insbesondere wenn das Programmpaket nicht auf einem Archivprozessor ablauffähig ist. Das Programmpaket kann ein Testpaket und/oder weitere Dateien, die auf das Programmpaket und/oder das Testpaket bezogen sind, umfassen.
Ein Aspekt betrifft ein System zur Inbetriebnahme eines neuen Programmpakets auf mindestens einem Ziel-Prozessor eines Fahrzeugs. Das System weist ein zentrales Archiv (Online Repository) auf, das zur Speicherung einer Vielzahl von Programmpaketen für ein Fahrzeug eingerichtet ist, und ein Fahrzeugsystem wie oben und/oder nachfolgend beschrieben. Die Programmpakete können von einem oder von mehreren Zulieferern stammen.
Ein Aspekt betrifft ein Fahrzeug mit einem Fahrzeugsystem wie oben und/oder nachfolgend beschrieben.
Ein Aspekt betrifft eine Verwendung eines Fahrzeugsystems wie oben und/oder nachfolgend beschrieben oder eines Systems wie oben und/oder nachfolgend beschrieben zur Inbetriebnahme eines neuen Programmpakets auf mindestens einer Fahrzeugrecheneinheit eines Fahrzeugs, zum Update, zum Upgrade, zum Load Balancing und/oder zur Korrektur von Fehlern von mindestens einer Fahrzeugfunktion.
Es sei noch angemerkt, dass die verschiedenen Ausführungsformen miteinander kombiniert werden können.
Zur weiteren Verdeutlichung wird die Erfindung anhand von in den Figuren abgebildeten Ausführungsformen beschrieben. Diese Ausführungsformen sind nur als Beispiel, nicht aber als Einschränkung zu verstehen.
Figurenliste
Dabei zeigt:

1 schematisch ein System gemäß einer Ausführungsform;
2 schematisch ein Fahrzeugsystem gemäß einer Ausführungsform;
3 ein Flussdiagramm mit einem Verfahren gemäß einer Ausführungsform.

Detaillierte Beschreibung von Ausführungsformen
1 zeigt schematisch ein System 10 gemäß einer Ausführungsform. Das System 10 ist zur Inbetriebnahme eines neuen Programmpakets 70 auf mindestens einem Ziel-Prozessor eines Fahrzeugs 100 eingerichtet. Das Programmpaket 70 kann zunächst auf einem zentralen Archiv (Online Repository) 20 gespeichert sein. Das zentrale Archiv kann zur Speicherung einer Vielzahl von Programmpaketen 70 für ein Fahrzeug 100 eingerichtet sein. Die Programmpakete für ein Fahrzeug können von einem oder von mehreren Herstellern zugeliefert werden. Das zentrale Archiv kann auf einem Server, einer Datenbank und/oder in einer Cloud 30 angeordnet sein. Das Programmpaket 70 kann z.B. über einen Übertragungskanal 40 auf ein Fahrzeugsystem 110 übertragen werden; dies kann über eine Kabelverbindung und/oder kabellos (drahtlos) erfolgen. Das Fahrzeugsystem 110 überträgt das Programmpaket 70 auf eine oder mehrere Fahrzeugrecheneinheiten (Vehicle Computing Platform, VCP) 160, mittels eines Übertragungs- und Überwachungskanal 116.
2 zeigt schematisch ein Fahrzeugsystem 110 gemäß einer Ausführungsform. Das Fahrzeugsystem 110 lädt ein Programmpaket 70, z.B. aus einem zentralen Archiv 20 (siehe 1), und speichert das Programmpaket 70, z.B. über einen Übertragungskanal 112, in einem fahrzeugspezifischen Archiv (In-Vehicle-Repository) 120, z.B. in einem Speicher 122. Das Übertragen kann ein Entpacken, Entschlüsseln und/oder weitere Aktionen beinhalten. Das Programmpaket 70 kann in dem fahrzeugspezifischen Archiv 120, z.B. mittels eines Archivprozessors 126, auf einer Testeinheit 124 getestet werden. In Fällen, bei denen das Programmpaket 70 nicht oder nur teilweise auf dem Archivprozessor 126 ablauffähig ist, können die Schnittstellen, Systemaufrufe, etc. simuliert und/oder emuliert werden. Eine Zuordnungs- und Überwachungseinheit (Central Allocation Manager, CAM) 140 kann dann eine Fahrzeugrecheneinheit VCP 160 aus einer Vielzahl von Recheneinheiten 160, 161 des Fahrzeugs 100 bestimmen, auf die das validierte Programmpaket 70, über einen Übertragungs- und Überwachungskanal 116, übertragen wird. Anschließend oder zu einem späteren Zeitpunkt kann das Programmpaket 70 auf der Fahrzeugrecheneinheit 160 gestartet werden, und damit kann das Programmpaket 70 eine Fahrzeugfunktion ausführen.
Die Zuordnungs- und Überwachungseinheit 140 kann weiterhin zur Überwachung der Fahrzeugrecheneinheiten 160 eingerichtet sein, insbesondere zum Detektieren von Hardware-Fehlern, zum Detektieren von Überlastung, zur Realisierung von Load Balancing durch Übertragen von Teilfunktionen, und/oder weiterer zentraler Funktionen. Weiterhin kann die Zuordnungs- und Überwachungseinheit 140 ein Fahrzeugregister 142 umfassen, aufweisend eine Information, welche Fahrzeugfunktion welcher Fahrzeugrecheneinheit 160 zugeordnet ist, diese Funktion ausführt, in welchem Maße die Fahrzeugrecheneinheit 160 ausgelastet ist, und/oder ob die Fahrzeugrecheneinheit 160 funktionsfähig ist.
3 zeigt ein Flussdiagramm 200 mit einem Verfahren gemäß einer Ausführungsform. In einem Schritt 201 wird ein Programmpaket 70 (siehe 1 oder 2) aus einem zentralen Archiv 20 geladen. Schritt 201 kann optional sein; es ist z.B. möglich, dass zumindest einige Programmpakete 70 - z.B. Programmpakete für eine Failover- und/oder eine andere fehlerkompensierende Funktion - bereits bei der Herstellung in dem Fahrzeug installiert wurden. In einem Schritt 202 wird das Programmpaket 70 in einem fahrzeugspezifischen Archiv 120 gespeichert. In einem Schritt 203 wird das Programmpaket 70 in dem fahrzeugspezifischen Archiv 120 getestet. In einem Schritt 204 erfolgt das Bestimmen der Fahrzeugrecheneinheit 160 aus einer Vielzahl von Recheneinheiten 160, 161 des Fahrzeugs 100. In einem Schritt 205 wird das validierte Programmpaket 70 auf der Fahrzeugrecheneinheit 160 bereitgestellt. In einem Schritt 206 wird das validierte Programmpaket 70 auf der Fahrzeugrecheneinheit 160 gestartet, wobei das Programmpaket 70 eine oder mehrere Fahrzeugfunktionen ausführt.
Bezugszeichenliste

10: System
20: zentrales Archiv (Online Repository)
30: Cloud
40: Übertragungskanal
70: Programmpaket
100: Fahrzeug
110: Fahrzeugsystem
112: Übertragungskanal
116: Übertragungs- und Überwachungskanal
120: fahrzeugspezifisches Archiv (In-Vehicle-Repository)
122: Speicher
124: Testeinheit
140: Zuordnungs- & Überwachungseinheit (Central Allocation Manager, CAM)
142: Fahrzeug-Register (Global Function Registry)
160, 161: Fahrzeugrecheneinheit (Vehicle Computing Platform, VCP)
126: Archivprozessor
200: Flussdiagramm
201 -206: Schritte

Claims

Verfahren zur Inbetriebnahme eines neuen Programmpakets (70) auf mindestens einer Fahrzeugrecheneinheit (160) eines Fahrzeugs (100), das Verfahren aufweisend: laden des Programmpakets (70) aus einem zentralen Archiv (20); speichern des Programmpakets (70) in einem fahrzeugspezifischen Archiv (120); validieren des Programmpakets (70) in dem fahrzeugspezifischen Archiv (120); bestimmen der Fahrzeugrecheneinheit (160) aus einer Vielzahl von Recheneinheiten (160, 161) des Fahrzeugs (100); bereitstellen des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160); und starten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160), wobei das Programmpaket (70) eine Fahrzeugfunktion ausführt.
Verfahren nach Anspruch 1, wobei das Validieren des Programmpakets (70) ein Simulieren und/oder Emulieren von Funktionen umfasst, die nicht auf einem Archivprozessor (126) des fahrzeugspezifischen Archivs (120) ablauffähig sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Laden des Programmpakets (70) durch eine Anforderung eines Benutzers, durch eine Anforderung einer Zuordnungs- und Überwachungseinheit (140) und/oder durch eine Versionskontrolle getriggert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestimmen der Fahrzeugrecheneinheit (160) durch eine Liste von Kriterien gesteuert wird, welche umfasst: Bestimmen eines Typs der Fahrzeugrecheneinheit (160); Bestimmen einer Funktion der Fahrzeugrecheneinheit (160); Bestimmen einer Rechenleistung der Fahrzeugrecheneinheit (160); Bestimmen einer Speichergröße und/oder Speicherleistung der Fahrzeugrecheneinheit (160); und/oder Bestimmen eines Energieverbrauchs der Fahrzeugrecheneinheit (160).
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestimmen der Fahrzeugrecheneinheit (160) ein Auswählen einer Alternativ-Funktion des Programmpakets (70) umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestimmen der Fahrzeugrecheneinheit (160) und/oder Bereitstellen des validierten Programmpakets (70) ein Speichern von Informationen über das Programmpaket in einem Fahrzeugregister (142) umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin aufweisend: stoppen und/oder deinstallieren der Fahrzeugfunktion auf einer anderen Fahrzeugrecheneinheit (161).
Verfahren nach Anspruch 7, wobei das Stoppen der Fahrzeugfunktion einer anderen Fahrzeugrecheneinheit (161) ein Bewerten der Kritikalität der Fahrzeugfunktion beinhaltet.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Starten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160) mittels eines Starttriggers gesteuert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Laden des Programmpakets (70), das Speichern des Programmpakets (70), das Testen des Programmpakets (70), das Bereitstellen des validierten Programmpakets (70) und/oder das Starten des validierten Programmpakets (70) eine Authentifizierung dieser Aktion beinhaltet.
Programmelement, welches, wenn es auf einer oder mehreren Recheneinheiten eines Fahrzeugsystems (110) eines Fahrzeugs (100) und/oder auf einer anderen Recheneinheit ausgeführt wird, die mindestens eine Recheneinheit anweist, das Verfahren nach einem der vorhergehenden Ansprüche durchzuführen.
Computerlesbares Medium, auf dem ein Programmelement nach Anspruch 11 gespeichert ist.
Fahrzeugsystem (110), eingerichtet zur Inbetriebnahme eines neuen Programmpakets (70) auf mindestens einer Fahrzeugrecheneinheit (160) eines Fahrzeugs (100), das Fahrzeugsystem (110) aufweisend: ein fahrzeugspezifisches Archiv (120), eingerichtet zur Speicherung eines Programmpakets (70) aus der Vielzahl von Programmpaketen und zum Testen des Programmpakets (70); eine Vielzahl von Fahrzeugrecheneinheiten (160, 161), eingerichtet zur Ausführung von fahrzeugspezifischen Befehlen; und eine Zuordnungs- und Überwachungseinheit (140), eingerichtet zum Bestimmen der Fahrzeugrecheneinheit (160) aus der Vielzahl von Recheneinheiten (160, 161) des Fahrzeugs (100), Bereitstellen des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160), und Starten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160).
Fahrzeugsystem (110) nach Anspruch 13, wobei die Zuordnungs- und Überwachungseinheit (140) weiterhin zur Überwachung der Fahrzeugrecheneinheiten (160) eingerichtet ist, insbesondere zum Detektieren von Hardware-Fehlern, zum Detektieren von Überlastung, und/oder zur Realisierung von Load Balancing und/oder zur Realisierung eines Fail-Operational durch Übertragen von Teilfunktionen, und/oder wobei die Zuordnungs- und Überwachungseinheit (140) weiterhin ein Fahrzeugregister (142) umfasst, aufweisend eine Information, welche Fahrzeugfunktion welcher Fahrzeugrecheneinheit (160) aus der Vielzahl von Recheneinheiten (160, 161) zugeordnet ist.
Fahrzeugsystem (110) nach Anspruch 13 oder 14, wobei das fahrzeugspezifische Archiv (120) eine Testeinheit (124) umfasst, die zum Testen, zum Simulieren und/oder zum Emulieren von Fahrzeugfunktionen eingerichtet ist.
System (10) zur Inbetriebnahme eines neuen Programmpakets (70) auf mindestens einem Ziel-Prozessor eines Fahrzeugs (100), das System aufweisend: ein zentrales Archiv (20), eingerichtet zur Speicherung einer Vielzahl von Programmpaketen für ein Fahrzeug (100); und ein Fahrzeugsystem (110) nach einem der Ansprüche 13 bis 15.
Fahrzeug (100) mit einem Fahrzeugsystem (110) nach einem der Ansprüche 13 bis 15.
Verwendung eines Fahrzeugsystems (110) nach einem der Ansprüche 13 bis 15 oder eines Systems (10) nach Anspruch 16 zur Inbetriebnahme eines neuen Programmpakets (70) auf mindestens einer Fahrzeugrecheneinheit (160) eines Fahrzeugs (100), zum Update, zum Upgrade, zum Load Balancing und/oder zur Korrektur von Fehlern und/oder zur Realisierung eines Fail-Operational von mindestens einer Fahrzeugfunktion.