EP4413455A1 - Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen - Google Patents

Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen

Info

Publication number
EP4413455A1
EP4413455A1 EP22800077.4A EP22800077A EP4413455A1 EP 4413455 A1 EP4413455 A1 EP 4413455A1 EP 22800077 A EP22800077 A EP 22800077A EP 4413455 A1 EP4413455 A1 EP 4413455A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
program package
computing unit
function
vehicle computing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22800077.4A
Other languages
English (en)
French (fr)
Inventor
Carolin HILBERT
Tereza Georgeta BANDINO
Catalin-Cristian ILIE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aumovio Germany GmbH
Original Assignee
Continental Automotive Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of EP4413455A1 publication Critical patent/EP4413455A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3457—Performance evaluation by simulation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the invention relates to a method for starting up program packages in vehicles, in particular for starting up a new program package on at least one vehicle computing unit of a vehicle. Furthermore, the invention relates to a system, a vehicle, a program element, a computer-readable medium and a use.
  • Vehicle functions are in many cases implemented statically in the vehicle when a vehicle is manufactured and are often difficult to change. In at least some cases, changing a vehicle function requires a workshop visit and/or replacement of the hardware that implements the vehicle function. This can be disruptive in particular if starting a new program package would enable the vehicle function to be improved and/or error correction to be made.
  • One aspect relates to a method for starting up a new program package on at least one vehicle computing unit of a vehicle.
  • the method has the following steps: loading the program package from a central archive; storing the program package in a vehicle-specific archive; validate the program package in the vehicle-specific archive; determine the vehicle computing unit from a plurality of computing units of the vehicle; providing the validated program package on the vehicle computing unit; and starting the validated program package on the vehicle computing unit, the program package executing a vehicle function.
  • the vehicle is, for example, a motor vehicle such as a car, bus or truck, or else a rail vehicle, a ship, an aircraft such as a helicopter or airplane.
  • a vehicle computing unit (Vehicle Computing Platform, VCP) is a processor ("general-purpose processor"), a controller, dedicated hardware, e.g. with firmware and/or other types of computing units.
  • a program package is a file that can be run, interpreted and/or compiled on at least one of the vehicle computing units.
  • the program package can be compressed and/or encrypted.
  • the commissioning can include a download and a provision (deployment) of the program package.
  • the commissioning of the program package means that at least one of the vehicle computing units can perform one or more vehicle functions.
  • the execution of the vehicle functions can begin immediately after the program package has been transferred to the vehicle computing unit (i.e. to a target computing unit), but it can also only be started at a later point in time.
  • the new program package can, for example, implement an already existing or a similar vehicle function (“update”), for example as part of an improvement in performance and/or error correction.
  • the new program package can, for example, add one or more new vehicle functions (“upgrade”).
  • updates can be loaded "automatically", ie for example controlled by a central service staff.
  • upgrades may be requested and/or approved by a user—e.g., a driver of the vehicle, a leasing provider, etc.
  • At least some vehicle features may belong to both categories, eg a new navigation system.
  • the user can decline or defer optional feature updates.
  • Mandatory updates can be installed automatically.
  • the function can be deployed on a VCP at the time when the function is to be started for the first time.
  • the program packages for a vehicle can be supplied by one or more manufacturers. After delivery, the program packages can be stored in a central archive (online repository). The loading of the program package from the central archive can take place via a cable connection and/or wirelessly (wireless). Loading the program package from the central archive can be an optional step, i.e. at least some program packages can already be pre-installed on the vehicle - e.g. during manufacture.
  • the wireless transmission of the program package or packages can e.g. via Bluetooth, WLAN (e.g. WLAN 802.11 a/b/g/n or WLAN 802.11 p), ZigBee or WiMax or also cellular radio systems such as GPRS, UMTS, or LTE and/or 5G take place. Alternatively or additionally, the use of other transmission protocols is also possible.
  • the vehicle-specific archive may include facilities to validate the program package; this can include verification and/or testing, eg by means of authentication of the program package, regression tests, simulation of interfaces and/or system calls and/or others. These facilities can be available permanently or on demand stand; for example, regression tests can be supplied with the program package.
  • the vehicle-specific archive can provide means for simulation and/or emulation.
  • Determining the vehicle processing unit (target processing unit) from a plurality of processing units of the vehicle can include an analysis of the target processing unit, the current processor load, the program package and/or other aspects.
  • the validated program package is made available (deployment) on the target vehicle computing unit.
  • the program package can be started on the vehicle computing unit, so that the program package executes a vehicle function.
  • Starting can be immediate, or only after a predetermined event.
  • a "fail-operational function” switch to a backup system in the event of an error
  • a "fall-back function” switch to a backup system in the event of an error, in at least some cases associated with a downgrading of the original function ) must first be loaded on a backup processor and only activated or started in the event of an error. In this way, for example, a so-called "hot swap" can be implemented in the event of an error.
  • the method advantageously provides a framework that simplifies the commissioning of a new program package and also makes it faster and safer. Furthermore, the method can be used for a large number of applications.
  • the following list provides some illustrative use cases: • Extended child safety locks for the rear doors can, for example, exclude the operation of the window winders to prevent small children from being trapped.
  • An advanced navigation system can, for example, include specifics such as clearance heights, a higher resolution of certain routes and/or predefined colors. This can also be offered as a paid feature, and commissioning and/or delivery can be linked to a payment system.
  • a functionally reduced (fall-back) function can be available, which is provided on a target vehicle computing unit and which is activated in the event of an event.
  • a dynamic deployment and redeployment of vehicle functions can be supported via a preferably vehicle computing unit. This can make it easier to install new vehicle applications and/or update existing functions without requiring service personnel or a workshop each time. This can also be a basis for new business models, such as "pay per function", "pay per function usage”, etc.
  • the method can provide a basis for optimizing the use of resources, e.g. computing and/or network resources, energy consumption , etc., and/or an improvement in the running time of the vehicle processing units, for example because only those processing units that are actually required for a specific application are loaded.
  • funds can be made available for a consistent redundancy concept, e.g. for "fail-safe” or "fail-operational" functions.
  • validating the program package includes emulating functions that are not executable on an archive processor of the vehicle-specific archive.
  • the target vehicle computing unit must be a different processor type or hardware type than the processor ("archive processor") of the vehicle-specific archive.
  • the target vehicle processing unit can consist of or have dedicated hardware, a different processor type, different interfaces (eg ioctl) and/or others, so that the program package cannot be run on the archive processor without further ado.
  • the hardware dependencies can be significantly reduced by simulating and/or emulating functions.
  • loading of the program package is triggered by a request from a user, by a request from an allocator and monitor, and/or by version control.
  • the user can, for example, be the driver, a leasing provider, a workshop and/or other people and/or institutions.
  • the user can be a monitoring program, for example, which automatically loads a corrected program package when critical errors are detected.
  • the user can be a version control to optimize certain functions.
  • determining the vehicle computing unit is controlled by a list of criteria that includes:
  • a dynamic function assignment is therefore carried out, ie a decision is made about the target vehicle computing unit for the new vehicle function and/or the function update based on an assignment algorithm, taking into account functional dependencies and application restrictions of the function.
  • Determining a type of vehicle computing unit can include determining, for example, the hardware of the vehicle computing unit.
  • the function can be, for example, the control of window regulators or an infotainment function.
  • Determining a computing power of the vehicle computing unit may include, for example, comparing the current power, the maximum power, and/or a history of the power of other processors. This can, for example, lead to a (e.g. temporary) downgrading of the function and/or the selection of an alternative function. It may include analysis of a stay-alive signal. It may include detecting an error and/or marking a faulty vehicle processing unit as unavailable.
  • Determining a memory size and/or memory capacity of the vehicle computing unit may relate to throughput and/or latency, for example.
  • determining the vehicle computing unit includes selecting an alternative function of the program package.
  • the alternative function can be part of the program package, or another function, such as an older function, for example in the event of an error after reinstalling a new function, e.g. just on this vehicle.
  • determining the vehicle computing unit and/or providing the validated program package includes storing information about the program package in a vehicle register (Global Function Registry). This means that an overview of the current functions and/or software versions (etc.) can be provided at any time.
  • a vehicle register Global Function Registry
  • the method further includes stopping and/or uninstalling the vehicle function on another vehicle computing unit; or to stop and optionally uninstall the vehicle function.
  • the vehicle function can be a bundle of selected functions.
  • the other vehicle computing unit can thus be relieved. This can advantageously be used, for example, in the event of an error and/or in the event of a high load (overload) and/or for an optimization (resource optimization scenario).
  • stopping the vehicle function of another vehicle processing unit includes evaluating the criticality of the vehicle function. For example, critical functions can be started on a different processor. For example, non-critical functions can be stopped - at least for a predefined period of time.
  • starting the validated program package on the vehicle computing unit is controlled by a start trigger.
  • start triggers that only become effective in the event of an overload or error.
  • loading the package, saving the package, validating the package, providing the validated package, and/or launching the validated package includes authentication of that action. This can be realized e.g. with cryptographic methods. This advantageously increases security against unauthorized access to vehicle functions.
  • One aspect relates to a program element which, when executed on one or more computing units of a vehicle system of a vehicle and/or on another computing unit, instructs at least one computing unit to carry out the method as described above and/or below.
  • One aspect relates to a computer-readable medium on which the program element described herein is stored.
  • the vehicle system has a vehicle-specific archive (in-vehicle repository) configured to store a program package from the plurality of program packages and to validate the program package.
  • vehicle-specific archive can be seen as a local application server in the vehicle.
  • VCP Vehicle Computing Platform
  • vehicle computing units which are set up for executing vehicle-specific commands. These commands can be sent from a CAM (see below) and include, for example, functions such as start, stop, restart one or more functions, send the ECU alive status, and/or others.
  • the vehicle processing unit can be general processor (Electronic Control Unit, ECU), a multiprocessor, dedicated hardware, can include interfaces, buses and/or network components, and/or it can be suitable for different degrees of real-time requirements.
  • ECU Electronic Control Unit
  • the VCP can send activity signals (alive status).
  • the VCP can receive and process control functions such as start, stop, restart, etc.
  • the vehicle system also has an allocation and monitoring unit (Central Allocation Manager, CAM), which is set up to determine the vehicle computing unit from the plurality of computing units of the vehicle, to provide the validated program package on the vehicle computing unit, and to start the validated program package on the vehicle computing unit is.
  • the allocation and monitoring unit can be designed as a central component or control unit (ECU) in the vehicle and/or be designed as a redundant component.
  • the allocation and monitoring unit can manage the dynamic deployment and redeployment of vehicle functions and vehicle function updates. Furthermore, all control units are monitored with regard to resource consumption and use as well as control unit failures.
  • this component takes over the detection of hardware failures, resource overloads and carrying out a load balancing for each control unit by means of dynamic function reallocation, ie the redistribution of functions.
  • the allocation and monitoring unit is also set up to monitor the vehicle computing units, in particular to detect hardware errors, to detect overloading, and/or to implement load balancing by transferring subfunctions.
  • the assignment and monitoring unit can also include a vehicle register (Global Function Registry), having information about which vehicle function is assigned (deployed) to which vehicle computing unit.
  • vehicle register Global Function Registry
  • the vehicle register can contain information about which functions are not yet activated and/or about which functions can be considered as a replacement function and/or "degraded" function of another function - which is activated on another vehicle computing unit, for example.
  • the vehicle-specific archive includes a test unit that is set up for testing, simulating and/or emulating vehicle functions.
  • the test unit can "know" interfaces and/or system calls (system calls) of the program package, i.e. be able to process them - e.g. by means of simulation and/or emulation - especially if the program package cannot be run on an archive processor.
  • the program package can include a test package and/or other files related to the program package and/or the test package.
  • One aspect relates to a system for starting up a new program package on at least one target processor of a vehicle.
  • the system has a central archive (online repository) that is set up for storing a large number of program packages for a vehicle, and a vehicle system as described above and/or below.
  • the program packages can come from one or more suppliers.
  • One aspect relates to a vehicle with a vehicle system as described above and/or below.
  • One aspect relates to the use of a vehicle system as described above and/or below or a system as described above and/or below to start up a new program package on at least one vehicle computing unit of a vehicle, for updating, upgrading, load balancing and/or for Correction of errors in at least one vehicle function.
  • FIG. 1 schematically shows a system according to an embodiment
  • FIG. 2 schematically shows a vehicle system according to an embodiment
  • FIG. 3 shows a flowchart with a method according to an embodiment.
  • the system 10 is set up for starting up a new program package 70 on at least one target processor of a vehicle 100 .
  • the program package 70 can initially be stored in a central archive (online repository) 20 .
  • the central archive can be used to store a large number of program packages 70 for a vehicle 100 may be set up.
  • the program packages for a vehicle can be supplied by one or more manufacturers.
  • the central archive can be arranged on a server, a database and/or in a cloud 30 .
  • the program package 70 can be transmitted to a vehicle system 110 via a transmission channel 40, for example; this may be via a wired connection and/or wireless (wireless).
  • the vehicle system 110 transmits the program package 70 to one or more vehicle computing units (Vehicle Computing Platform, VCP) 160 by means of a transmission and monitoring channel 116.
  • VCP Vehicle Computing Platform
  • the vehicle system 110 loads a program package 70, e.g. from a central archive 20 (see Fig. 1), and stores the program package 70, e.g. via a transmission channel 112, in a vehicle-specific archive (in-vehicle repository) 120, e.g. in a memory 122. Transferring may include unpacking, decrypting and/or other actions.
  • the program package 70 can be tested on a test unit 124 in the vehicle-specific archive 120, for example by means of an archive processor 126. In cases where the program package 70 is not or only partially executable on the archive processor 126, the interfaces, system calls, etc. can be simulated and/or emulated.
  • An allocation and monitoring unit (Central Allocation Manager, CAM) 140 can then determine a vehicle processing unit VCP 160 from a plurality of processing units 160, 161 of the vehicle 100 to which the validated program package 70 is transmitted via a transmission and monitoring channel 116. Subsequently or at a later point in time, the program package 70 can be started on the vehicle computing unit 160, and the program package 70 can thus execute a vehicle function.
  • VCP 160 Vehicle Processing Unit
  • CAM Central Allocation Manager, CAM
  • Allocation and monitoring unit 140 can also be set up to monitor vehicle computing units 160, in particular to detect hardware errors, to detect overload, to implement load balancing by transferring subfunctions, and/or other central functions functions.
  • Allocation and monitoring unit 140 can also include a vehicle register 142 having information about which vehicle function is assigned to which vehicle computing unit 160, performs this function, the extent to which vehicle computing unit 160 is utilized, and/or whether vehicle computing unit 160 is functional.
  • FIG. 3 shows a flow diagram 200 with a method according to an embodiment.
  • a program package 70 (see FIG. 1 or 2) is loaded from a central archive 20.
  • FIG. Step 201 may be optional; it is possible, for example, that at least some program packages 70—for example program packages for a failover and/or another error-compensating function—were already installed in the vehicle during manufacture.
  • the program package 70 is stored in a vehicle-specific archive 120 .
  • the program package 70 in the vehicle-specific archive 120 is tested.
  • the vehicle computing unit 160 is determined from a large number of computing units 160 , 161 of the vehicle 100 .
  • the validated program package 70 is made available on the vehicle computing unit 160 .
  • the validated program package 70 is started on the vehicle computing unit 160, with the program package 70 executing one or more vehicle functions.
  • VCP Vehicle Computing Platform

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

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); und starten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160), wobei das Programmpaket (70) eine Fahrzeugfunktion ausführt.

Description

Verfahren zur Inbetriebnahme von Programmpaketen in Fahrzeugen
Gebiet der Erfindung
Die Erfindung betrifft ein Verfahren zur Inbetriebnahme von Programm paketen 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 Programm pakets 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 Programm pakets 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 Programm pakete 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 Programm pakets 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 Programm pakete kann z.B. per Bluetooth, WLAN (z.B. WLAN 802.11 a/b/g/n oder WLAN 802.11 p), 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 System aufrufen (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-Fahrzeug- recheneinheit 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 Histone der Leistung von anderen Prozessoren beinhalten. Dies kann z.B. zu einem (z.B. zeitweisen) Downgrading der Funktion führen, und/oder ein Auswahlen 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 Auswahlen einer Alternativ-Funktion des Programmpakets. Die Alternativ-Funktion: kann Teil des Programm pakets 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 Programm pakets, das Speichern des Programmpakets, das Validieren des Programmpakets, das Bereitstellen des validierten Programmpakets und/oder das Starten des validierten Programm pakets 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 Programm paketen 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 Programm pakets auf mindestens einer Fahrzeugrecheneinheit eines Fahrzeugs, zum Update, zum Upgrade, zum Load Balancing und/oder zur Korrektur von Fehlem 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.
Kurze der Fi
Dabei zeigt:
Fig. 1 schematisch ein System gemäß einer Ausführungsform;
Fig. 2 schematisch ein Fahrzeugsystem gemäß einer Ausführungsform;
Fig. 3 ein Flussdiagramm mit einem Verfahren gemäß einer Ausführungsform.
Detaillierte von
Fig. 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.
Fig. 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 Fig. 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.
Fig. 3 zeigt ein Flussdiagramm 200 mit einem Verfahren gemäß einer Ausführungsform. In einem Schritt 201 wird ein Programmpaket 70 (siehe Fig. 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.
Liste der
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

1 . Verfahren zur Inbetriebnahme eines neuen Programm pakets (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.
2. 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.
3. 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.
4. 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).
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestimmen der Fahrzeugrecheneinheit (160) ein Auswahlen einer Alternativ-Funktion des Programmpakets (70) umfasst.
6. 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.
7. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin aufweisend: stoppen und/oder deinstallieren der Fahrzeugfunktion auf einer anderen Fahrzeugrecheneinheit (161 ).
8. Verfahren nach Anspruch 7, wobei das Stoppen der Fahrzeugfunktion einer anderen Fahrzeugrecheneinheit (161 ) ein Bewerten der Kritikalität der Fahrzeugfunktion beinhaltet.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Starten des validierten Programmpakets (70) auf der Fahrzeugrecheneinheit (160) mittels eines Starttriggers gesteuert wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Laden des Programmpakets (70), das Speichern des
Programm pakets (70), das Testen des Programmpakets (70), das Bereitstellen des validierten Programmpakets (70) und/oder das Starten des validierten
Programm pakets (70) eine Authentifizierung dieser Aktion beinhaltet. 17
11 . 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.
12. Computerlesbares Medium, auf dem ein Programmelement nach Anspruch 11 gespeichert ist.
13. Fahrzeugsystem (110), eingerichtet zur Inbetriebnahme eines neuen Programm pakets (70) auf mindestens einer Fahrzeugrecheneinheit (160) eines Fahrzeugs (100), das Fahrzeugsystem (110) aufweisend: ein fahrzeugspezifisches Archiv (120), eingerichtet zur Speicherung eines Programm pakets (70) aus der Vielzahl von Programm paketen und zum Testen des Programm pakets (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).
14. 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 18
Fahrzeugfunktion welcher Fahrzeugrecheneinheit (160) aus der Vielzahl von Recheneinheiten (160, 161 ) zugeordnet ist.
15. 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.
16. 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 Programm paketen für ein Fahrzeug (100); und ein Fahrzeugsystem (110) nach einem der Ansprüche 13 bis 15.
17. Fahrzeug (100) mit einem Fahrzeugsystem (110) nach einem der Ansprüche 13 bis 15.
18. Verwendung eines Fahrzeugsystems (110) nach einem der Ansprüche 13 bis 15 oder eines Systems (10) nach Anspruch 16 zur Inbetriebnahme eines neuen Programm pakets (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.
EP22800077.4A 2021-10-07 2022-09-29 Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen Pending EP4413455A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021211353.2A DE102021211353A1 (de) 2021-10-07 2021-10-07 Verfahren zur Inbetriebnahme von Programmpaketen in Fahrzeugen
PCT/DE2022/200227 WO2023057017A1 (de) 2021-10-07 2022-09-29 Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen

Publications (1)

Publication Number Publication Date
EP4413455A1 true EP4413455A1 (de) 2024-08-14

Family

ID=84245941

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22800077.4A Pending EP4413455A1 (de) 2021-10-07 2022-09-29 Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen

Country Status (6)

Country Link
US (1) US20240430334A1 (de)
EP (1) EP4413455A1 (de)
KR (1) KR20240036726A (de)
CN (1) CN118043774A (de)
DE (1) DE102021211353A1 (de)
WO (1) WO2023057017A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102024202281A1 (de) * 2024-03-11 2025-09-11 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zur Überprüfung der Gültigkeit und/oder Aktualisierung einer digital implementierten Funktion in einem Fahrzeug
USD1123009S1 (en) * 2024-09-20 2026-04-21 Shenzhen Yishunxing Technology Co., Ltd. Digital camera

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2851815A1 (de) * 2013-09-18 2015-03-25 dSPACE digital signal processing and control engineering GmbH Testeinrichtung zum Echtzeittest eines virtuellen Steuergeräts
DE102015203776A1 (de) * 2015-03-03 2016-09-08 Robert Bosch Gmbh Verfahren zur Programmierung eines Steuergeräts eines Kraftfahrzeugs
JP6723829B2 (ja) * 2015-09-14 2020-07-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、ファームウェア更新方法及び制御プログラム
US12001825B2 (en) * 2016-02-19 2024-06-04 Ford Global Technologies, Llc Method and apparatus for vehicle software update installation
US11146401B2 (en) * 2016-08-10 2021-10-12 Ford Global Technologies, Llc Software authentication before software update
US10967880B2 (en) * 2018-07-23 2021-04-06 International Business Machines Corporation Remotely controlling use of features based on automatic validation requests
CN110874233A (zh) * 2019-09-30 2020-03-10 南京市晨枭软件技术有限公司 一种车用软件更新系统及更新方法
US20240419429A1 (en) * 2023-06-14 2024-12-19 Amazon Technologies, Inc. Vehicle software deployment service

Also Published As

Publication number Publication date
US20240430334A1 (en) 2024-12-26
DE102021211353A1 (de) 2023-04-13
KR20240036726A (ko) 2024-03-20
CN118043774A (zh) 2024-05-14
WO2023057017A1 (de) 2023-04-13

Similar Documents

Publication Publication Date Title
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
EP4413455A1 (de) Verfahren zur inbetriebnahme von programmpaketen in fahrzeugen
DE102018206720A1 (de) Verfahren zum Durchführen eines Softwareupdates in einem Steuergerät eines Kraftfahrzeugs sowie entsprechend eingerichtetes Kraftfahrzeug
DE102021131252A1 (de) Die vorliegende Erfindung betrifft eine Steuereinheit für ein Fahrzeug sowie ein Fehlermanagementverfahren dafür
DE102022113922A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE112017003052B4 (de) Steuerungssystem mit einer verteilten dienstorientierten Architektur
DE102017208986A1 (de) Verfahren zum Testen eines geplanten Softwareupdates für ein Fahrzeug
DE102022107393A1 (de) Center, verteilungssteuerungsverfahren undnicht-transitorisches speichermedium
DE102021129232A1 (de) Center, managementverfahren und nicht-transitorisches speichermedium
WO2017050557A1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
WO2020099023A2 (de) Steuergerät für eine fahrzeugkomponente, kit umfassend ein steuergerät und eine testereinrichtung, fahrzeug, verfahren zum aktualisieren eines steuergeräts und computerlesbares speichermedium
DE102021212595A1 (de) Verfahren zum Überwachen eines Rechensystems
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
DE102022208004A1 (de) Verfahren für eine Kontrolle eines Zugriffs verschiedener Applikationen bei einem Fahrzeug
DE102018210733A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
DE102021106282A1 (de) Verfahren und Vorrichtung zur Überwachung der Interaktion zwischen einer SW-Anwendung und einer Fahrzeug-Komponente
DE102018209972A1 (de) Verfahren zum Aktualisieren von Software auf einem Zielgerät mittels einer Aktualisierungseinrichtung und Verfahren zum Verarbeiten eines Datenpakets und/oder einer Unterscheidungsinformation mittels eines Zielgeräts
DE102020216481A1 (de) Verfahren zum Betreiben eines Steuergeräts und Steuergerät
EP3991037A1 (de) Steuergerät für ein fahrzeug, system, verfahren und kraftfahrzeug mit einem solchen steuergerät
DE112023000867T5 (de) Zentralvorrichtung und verfahren zur erzeugung von verteilungspaket
Wenzel et al. „SOVD–Service Oriented Vehicle Diagnostics,“
DE102017204212A1 (de) Verfahren und Vorrichtung zum Verwalten von Applikationen für Fahrzeuge
DE102017222292B4 (de) Parallelisierungsverfahren und parallelisierungs-tool
DE102023208876A1 (de) Ein Verfahren zum Aktualisieren einer Anwendung einer elektronischen Kraftfahrzeug-Steuereinheit
DE102017216797B4 (de) Verfahren zum Durchführen einer Eigendiagnose eines Steuergeräts sowie Steuergerät und Kraftfahrzeug

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240507

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: AUMOVIO GERMANY GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20260130