EP3811203A1 - Verfahren zum aktualisieren von software auf einem zielgerät - Google Patents

Verfahren zum aktualisieren von software auf einem zielgerät

Info

Publication number
EP3811203A1
EP3811203A1 EP19726990.5A EP19726990A EP3811203A1 EP 3811203 A1 EP3811203 A1 EP 3811203A1 EP 19726990 A EP19726990 A EP 19726990A EP 3811203 A1 EP3811203 A1 EP 3811203A1
Authority
EP
European Patent Office
Prior art keywords
update
software
target device
data packet
information
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
EP19726990.5A
Other languages
English (en)
French (fr)
Inventor
Lars PLISCHKE
Georg Rudolph
Wolfgang Fischer
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch 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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP3811203A1 publication Critical patent/EP3811203A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates

Definitions

  • the invention is based on a method or a device according to the type of the independent claims.
  • the present invention also relates to a computer program.
  • So-called delta processes can be used to update the software of components. Differences between two software versions are calculated and transferred to the respective components.
  • Update device a corresponding update device, a method for processing a data packet and / or
  • Update device deposited copy of the current software to create a data packet representing the new software
  • the target device and / or the update device can be used and / or arranged, for example, in a vehicle or in an industrial system or a machine or in various other devices that are connected and connected to one another.
  • a target device or target unit can be understood to mean an electrical device, for example a control device that processes sensor signals and outputs control and / or data signals as a function thereof.
  • the target device can have an interface that can be designed in terms of hardware and / or software.
  • the target device controls the
  • the target device can, for example, access sensor signals such as acceleration, pressure, steering angle or environment sensor signals.
  • the control can take place via corresponding actuators such as brake or steering actuators.
  • a device for example installed in the vehicle, can be used for storing backups and controlling
  • Update processes can be understood in a delta process.
  • the first interface can be a radio interface for wireless communication, for example with the vehicle.
  • communication can take place via the first interface in a wired manner.
  • the second interface can be a radio interface for wireless communication, for example with the vehicle.
  • An external data processing device can be understood to mean, for example, a server or a mobile terminal. Under one
  • Differentiation information can be understood, for example, a so-called delta file.
  • a delta file also referred to as a delta update file
  • the differentiation information can represent a significantly smaller amount of data compared to a full version of the new software.
  • the data package can be a compressed or uncompressed update package for installing the full version of the new software.
  • the issuing step can be dependent on whether that
  • Target device only a software updater or additionally one
  • Update unit for example with a delta installer, for performing a delta method.
  • the data packet can be output in the first case, while in the second case it is sufficient to output only the differentiation information.
  • the approach presented here relates to devices that have software updates or consist of several components, each of which supports a software update, but has its own memory and is connected to one another. Individual components can be restricted due to their resource situation.
  • the approach presented here is based on the knowledge that to update the software of individual components, for example a vehicle, to a new version, a so-called delta file, which contains the differences between a currently installed version and the new version, and a copy of the, for example, stored in the vehicle currently installed version can be used, for example, to calculate and check the new version in the vehicle itself, before the new version is loaded onto the relevant component.
  • a so-called delta file which contains the differences between a currently installed version and the new version
  • a copy of the, for example, stored in the vehicle currently installed version can be used, for example, to calculate and check the new version in the vehicle itself, before the new version is loaded onto the relevant component.
  • security For example, errors affecting the vehicle when updating are kept to a minimum. It also has one
  • Update procedure has the advantage that, instead of a full version of the software, only the delta file assigned to the relevant component
  • Update This enables the update to be carried out particularly quickly and efficiently, in particular if the update is imported, for example, via a radio interface.
  • both the old and the new software are stored in the vehicle as a centrally stored backup, it is possible, for example, in the event of an error, to perform a full update or rollback as required
  • the approach presented here encompasses a system-wide delta update procedure that calculates, saves and verifies new versions from a delta file in an update device, such as a central delta installer with an integrated backup server, in order to use the new software in a second Step to distribute to the appropriate target units in the overall system.
  • an update device such as a central delta installer with an integrated backup server
  • Only one delta update version should ever be transmitted, be it wireless or in the internal system, for example via a vehicle bus.
  • Delta update files can only be transferred if the target unit also has a delta update.
  • Backup software for the individual target units must be available in the update device or at least be able to be loaded.
  • the update device can be created, for example, with one or more central installation units with one or more delta installers with corresponding storage resources, although it is rather common only to have a central point that supports several Delta Installers if necessary.
  • These central installation units with delta installer can have one or more delta update procedures and must also have the current software of the target unit as a backup or at least have access to it. It does not matter whether the target units use an update unit with or without a delta installer. The security of the update process is therefore not solely due to the individual components, but primarily centrally through the
  • Update units with delta installers of the individual components require minimal additional resources and less memory access than with a full update.
  • a major advantage of the approach presented here is that a resource-related expansion of the target units, such as RAM or flash memory, can be omitted and a secure update including rollback can still be supported. This means that even small target systems can use delta update procedures.
  • Another advantage is that wireless data transmission to the overall system, for example, can be minimized by the delta update process. This also applies to individual components that do not themselves support delta updates, and also in the event that a full update is to take place via the internal bus.
  • the bus load in the target system can be minimized if the target units themselves have an update unit with a delta installer.
  • the target units can carry out a delta update process very quickly, since no additional memory accesses are required.
  • the installation unit of the target units with delta installer does not require any rollback functionality for each component, since this can be implemented centrally in the update device.
  • the protection of the delta installer against each component is also advantageous.
  • the update device runs autonomously with the central delta installer and can check the received software without influencing the target unit and save it in a new version as a backup, it can be checked whether the software is correct before the user is even affected by a software update can be.
  • defects in target units can be avoided since the software is pre-checked or a backup of a full version of old and new software is available in the update device with a central delta installer.
  • Such a method can easily be integrated into existing central units, such as a central gateway.
  • such a method can be applied to any number of components, provided there is enough storage space.
  • the method can include a step of
  • the step of outputting the data packet and / or the differentiation information can be outputted depending on a result of the checking.
  • the integrity of the data packet can be determined using a
  • Checksum are checked to detect bit errors in the data packet. This allows errors in the data packet to be recognized early or corrected. This prevents incorrect software updates on the target device. Alternatively, bit errors can already be handled by the software update process. According to a further embodiment, the
  • Discrimination information is suppressed when it is found during the check that the data packet is faulty. This can prevent incorrect update data from being transferred to the target device. Functional failures of the target device as a result of an incorrect update can thus be avoided.
  • Data packets received by the update device are forwarded directly to the target device without prior calculation.
  • the target device and the update device calculate the new software in parallel or in succession.
  • the new software can be labeled as the current software if the result information from the target device indicates that the update was successful. Additionally or alternatively, the step of issuing can be carried out again by the update device in order to obtain the copy and / or reset information
  • the target device Return the target device to an earlier version of the software to the interface to the target device if the result information of the target device indicates that the update was unsuccessful. As a result, the risk of functional failures of the target device as a result of an update can be reduced to a minimum.
  • the target device is reset to an earlier version of the software
  • Update device with a central delta installer calculate a delta version between the new and old version in order to switch from the new software back to the old one. To do this, the installation units with the central delta installer also require a delta generator.
  • the approach presented here creates an update device with units that are designed to execute and / or to control the method according to one of the above embodiments.
  • the approach presented here also creates a process for
  • the approach presented here also relates to a target device with units which are designed to carry out and / or to control the processing method according to the above embodiment.
  • Target device or an update device can be implemented.
  • a computer program product or computer program with program code which can be stored on a machine-readable carrier or storage medium such as a semiconductor memory, a hard disk memory or an optical memory and for carrying out, implementing and / or controlling the steps of a method according to one of the
  • Fig. 1 is a schematic representation of a data flow in the
  • FIG. 2 shows a schematic illustration of the creation of a data packet from FIG. 1;
  • FIG. 3 shows a schematic illustration of an update device from FIG. 1 at three successive points in time
  • Fig. 4 is a schematic representation of a data flow in the
  • FIG. 5 shows a flowchart of a method for updating software according to an exemplary embodiment
  • Fig. 6 is a flowchart of a method for processing a
  • Fig. 7 is a schematic representation of a vehicle according to a
  • Fig. 1 shows a schematic representation of a data flow in the
  • Updating software on three target devices 100, 102, 104 here only by way of example control devices of a machine, here only by way of example of a vehicle, in a method according to an exemplary embodiment.
  • An exemplary sequence of an over-the-air update process is shown with an update device 106, which comprises an installation unit 120 with a central delta installer for target devices 100, 102 with and for a target device 104 without a delta update.
  • the three target devices 100, 102, 104 are each coupled to a central update device 106, for example of the vehicle.
  • the update device 106 comprises a receiving unit 108 for
  • Interface 116 here a radio interface as an example, to an external data processing device 118, which can also be a cable connection or a USB medium, among other things.
  • Differentiation information 110, 112, 114 is, for example, each a delta update file for software update in a so-called delta method.
  • the differentiation information in each case represents differences between current software installed on the respective target device 100, 102, 104 and new software to be installed on the respective target device 100, 102, 104.
  • Receiving unit 108 received differentiation information 110, 112, 114 each with a suitable storage unit 122, such as one
  • Flash memory combined copy of the current software installed on the respective target devices 100, 102, 104 to combine to form a data packet.
  • the three data packets each represent a full version of the new software to be installed on the respective target devices 100, 102, 104.
  • the installation unit 120 checks the data packets for their respective integrity, for example by means of checksums or other suitable check values. Only if a data packet is error-free and the calculation of the full version of the new software was also successful, does the installation unit 120 trigger one
  • Update process for updating the relevant target device 100, 102, 104 is updated.
  • the installation unit 120 provides the first differentiation information 110 after it has been more successful Checking the data packet assigned to the first target device 100, the second differentiation information 112 after successful checking of the data packet assigned to the second target device 102 and a data packet 124 assigned to the third target device 104 after its successful checking, each to a second interface 126, here, for example, to a CAN Bus of the vehicle.
  • the target devices 100, 102, 104 each include one
  • Target device receiving unit 128 for reading in data via the second
  • the update units 130 each include a suitable software updater.
  • the first target device 100 and the second target device 102 each comprise an update unit with a delta installer for carrying out a delta update using the first differentiation information 110 in the case of the first target device 100 or using the second differentiation information 112 in the case of the second
  • the update unit 130 of the third target device 104 is designed to carry out the update exclusively as a full update by means of the third data packet 124.
  • a delta installer is a software component as an extension to a software updater.
  • a software updater is a software component in a target device that is responsible for its own software update.
  • FIG. 2 shows a schematic representation of the creation of a data packet from FIG. 1.
  • the receiving unit 108 and the installation unit 120 are shown.
  • the update device 106 first receives the corresponding delta file from the receiving unit 108, here, for example, the first
  • Discrimination information 110 searches in a step 200 in the
  • Storage unit after the corresponding copy of the current software, creates the data packet in a subsequent step 202 by calculating the full version of the new software using the
  • FIG. 3 shows a schematic illustration of an update device 106 from FIG. 1 at three successive times one
  • version 1.0 is to be updated to version 1.1.
  • the storage unit 122 After receiving the discrimination information 110, the storage unit 122 has the first in addition to the copy 300
  • Distinction information 110 which represents a delta between version 1.0 and a new version 1.1 of the software, as shown in the middle image.
  • the right picture shows the content of the storage unit 122 after the calculation of the full version 1.1.
  • Fig. 4 shows a schematic representation of a data flow in the
  • the update device 106 contains the copy 300, the first differentiation information 110 and the data packet 302.
  • the target device 100 is updated in three ways.
  • the update device 106 merely provides the target device 100 with the differentiation information 110.
  • the target device 100 then updates the current software using the delta installer and finally stores the version of the new software in a target device storage unit 400, for example a flash memory.
  • the update device 106 provides the target device 100 with the data package 302 with the full version 1.1 for updating the current software, for example if the update using the delta installer fails.
  • the update device 106 provides the target device 100 with the copy 300 of version 1.0, for example.
  • 5 shows a flowchart of a method 500 for updating software according to an exemplary embodiment.
  • the method 500 can be carried out, for example, using an update device, as described above with reference to FIGS. 1 to 4.
  • the differentiation information or, depending on the number of target devices to be updated, a plurality of differentiation information assigned to one target device is received via the first interface to the data processing device external to the vehicle, for example.
  • the differentiation information is combined with a copy of a current software version stored on the respective target devices stored in the update device.
  • resulting data packets represent, for example, a full version of the new software to be installed for each target device.
  • Distinguishing information about the second interface to the target devices If the target device to be updated has, for example, a suitable delta installer, the update to the new software version can take place in a particularly resource-saving manner solely by means of the differentiation information transmitted to the target device and the current version on the target device.
  • FIG. 6 shows a flowchart of a method 600 for processing a data packet and / or a differentiation information according to one
  • the method 600 can be carried out, for example, using one of the target devices, as described above with reference to FIGS. 1 to 5.
  • the corresponding data packet or the corresponding differentiation information is received via the second interface, for example a CAN bus. This takes place in a second step 620
  • Update of the current software available on the target device in question using the data packet for example a
  • each target unit in the vehicle in FIG. 1 the three target devices 100, 102, 104 in this example, each has a software updater 128 with full update functionality and possibly a delta installer 130.
  • software updaters with delta Installers receive software updaters without a delta installer, not a delta file, but a full version for software updates.
  • the vehicle has a central delta installer.
  • This central delta installer previously called installation unit 120, is either part of an already existing component, for example a central gateway or an over-the-air master, or is implemented as an independent unit. If an existing central component is expanded, the installation unit 120 or the central component is the update master, for example.
  • the installation unit 120 has direct access via the storage unit 122 to backups of all software in the system which are to be updated by this method.
  • versions of the currently used software of all components should be available as full versions and be stored in a correspondingly large persistent storage unit 122.
  • These software backups for example, are flashed once during production or even pre-flashed.
  • the installation unit 120 accepts the delta update file of each individual target unit, searches for the corresponding backup in the storage unit 122 and uses this combination by means of a delta installer in the storage unit 122, as is shown schematically in FIG. 2.
  • the installation unit 120 now checks the calculated new software for correctness and saves it locally as the new backup version 302.
  • the update device 106 thus has the full version of the current software of each target unit, the full version of the new software of each target unit and the respective delta update file of each target unit. This can be seen from FIGS. 3 and 4.
  • the entire or subsystem is put into update mode.
  • the individual software updates of the target units are offered the previously received delta update file or the full version of the new software as an update package.
  • Target units now also use the delta update method, for example, and confirm the respective result to installation unit 120.
  • the installation unit 120 sends the previously self-calculated new full version in the form of the data packet 302 as a full update, compressed or uncompressed, to the relevant target unit, as shown in FIG. 4.
  • the old backup version for example, is transmitted in the form of a copy 300 as a full update.
  • the new version 302 of the software is noted in the installation unit 120 as the currently valid version, so that it can be used as a reference for further updates.
  • a condition for the update using the delta method is also that the delta installer in the installation unit 120 and the delta installer in the target unit to be updated are compatible.
  • a direct update for example via the vehicle bus, the
  • Installation unit 120 can also be updated so that the versions remain identical. Otherwise, a later over-the-air update in the field would only be possible with a full update.
  • the copy 300 of the current software is not permanently available in the storage unit 122, but is only loaded by the relevant target unit when required. Thus, an initial flashing of the memory unit 122 can be omitted.
  • the installation unit 120 additionally comprises a delta generator, for example in order to also be able to transmit a rollback file, which is calculated by the packages 302 and 300, as a delta file.
  • the vehicle 700 for example a road vehicle for the transportation of people, has a target device 100.
  • the target device 100 is, for example, an engine control device or an airbag control device with a functionality as implemented in known control devices.
  • the target device 100 has a rewritable memory for storing software for operating the target device 100. To the software too
  • an update device 106 is integrated in the vehicle 700, which is designed to transmit a data packet 302 and additionally or alternatively a signal comprising differentiation information 110 to the target device 100.
  • the data packet comprises
  • Embodiment an updated version of the software for storage in the memory of the target device 100.
  • the distinction information 110 comprises data which is a difference between the software stored in the target device 100 and the updated Define software version.
  • Differentiation information 110 is transmitted in the form of electrical signals according to one exemplary embodiment.
  • the update device 106 is designed to receive a signal, which includes the differentiation information 110, from a data processing device 118 arranged outside the vehicle and to use it to generate the data packet 302.
  • the data processing device 118 has a combining device which is designed to combine the differentiation information 110 with a copy 300 of the software currently stored in the target device 100, which is stored in a memory of the update device 106.
  • the data processing device 118 has a combining device which is designed to combine the differentiation information 110 with a copy 300 of the software currently stored in the target device 100, which is stored in a memory of the update device 106.
  • Data processing device 118 has a checking device which is designed to check the data packet 302 for errors.
  • the update device 106 is designed to, depending on a result of the check carried out in the checking device, either the data packet 302 or the
  • an exemplary embodiment comprises a “and / or” link between a first feature and a second feature, this is to be read in such a way that the embodiment according to one embodiment has both the first feature and the second feature and according to a further embodiment either only that has the first feature or only the second feature.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Aktualisieren von Software auf einem Zielgeräte (100) mittels einer Aktualisierungseinrichtung (106). Dabei wird in einem ersten Schritt von einer Schnittstelle (116) zu einer externen Datenverarbeitungseinrichtung (118) eine Unterscheidungsinformation (110) empfangen, die einen Unterschied zwischen einer auf dem Zielgerät (100) installierten aktuellen Software und einer auf dem Zielgerät (100) zu installierenden neuen Software repräsentiert. In einem zweiten Schritt wird die Unterscheidungsinformation (110) mit einer in der Aktualisierungseinrichtung (106) hinterlegten Kopie der aktuellen Software kombiniert, um ein neues Software repräsentierendes Datenpaket (302) zu erstellen. Schließlich werden in einem dritten Schritt das Datenpaket (302) und/oder die Unterscheidungsinformation (110) an eine Schnittstelle (126) zum Zielgerät (100) ausgegeben, um die Software auf dem Zielgerät (100) zu aktualisieren.

Description

Beschreibung
Titel
VERFAHREN ZUM AKTUALISIEREN VON SOFTWARE AUF EINEM ZIELGERÄT
Stand der Technik
Die Erfindung geht aus von einem Verfahren oder einer Vorrichtung nach Gattung der unabhängigen Ansprüche. Gegenstand der vorliegenden Erfindung ist auch ein Computerprogramm.
Zur Aktualisierung der Software von Komponenten können sogenannte Delta- Verfahren eingesetzt werden. Dabei werden Unterschiede zwischen zwei Softwareversionen berechnet und an die jeweiligen Komponenten übertragen.
Offenbarung der Erfindung
Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz ein Verfahren zum Aktualisieren von Software auf einem Zielgerät mittels einer
Aktualisierungseinrichtung, eine entsprechende Aktualisierungseinrichtung, ein Verfahren zum Verarbeiten eines Datenpakets und/oder einer
Unterscheidungsinformation mittels eines Zielgeräts, ein entsprechendes Zielgerät sowie schließlich ein entsprechendes Computerprogramm gemäß den Hauptansprüchen vorgestellt. Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen der im unabhängigen Anspruch angegebenen Vorrichtung möglich. Es wird ein Verfahren zum Aktualisieren von Software auf einem Zielgerät mittels einer Aktualisierungseinrichtung vorgestellt, wobei das Verfahren folgende Schritte umfasst:
Empfangen einer Unterscheidungsinformation, die einen Unterschied zwischen einer auf dem Zielgerät installierten aktuellen Software und einer auf dem Zielgerät zu installierenden neuen Software repräsentiert, von einer Schnittstelle zu einer externen Datenverarbeitungseinrichtung;
Kombinieren der Unterscheidungsinformation mit einer in der
Aktualisierungseinrichtung hinterlegten Kopie der aktuellen Software, um ein die neue Software repräsentierendes Datenpaket zu erstellen; und
Ausgeben des Datenpakets und/oder der Unterscheidungsinformation an eine Schnittstelle zum Zielgerät, um die Software auf dem Zielgerät zu aktualisieren. Das Zielgerät und/oder die Aktualisierungseinrichtung kann beispielsweise in einem Fahrzeug oder in einer Industrieanlage oder einer Maschine oder in diversen anderen Software umfassenden und miteinander verbundenen Geräten genutzt werden und/oder angeordnet sein.
Unter einem Zielgerät oder Zieleinheit kann ein elektrisches Gerät verstanden werden, beispielsweise, ein Steuergerät das Sensorsignale verarbeitet und in Abhängigkeit davon Steuer- und/oder Datensignale ausgibt. Das Zielgerät kann eine Schnittstelle aufweisen, die hard- und/oder softwaremäßig ausgebildet sein kann.
In einer Ausgestaltung erfolgt durch das Zielgerät eine Steuerung des
Fahrzeugs. Hierzu kann das Zielgerät beispielsweise auf Sensorsignale wie Beschleunigungs-, Druck-, Lenkwinkel- oder Umfeldsensorsignale zugreifen. Die Ansteuerung kann über entsprechende Aktoren wie beispielsweise Brems- oder Lenkaktoren erfolgen.
Unter einer Aktualisierungseinrichtung kann eine, beispielsweise im Fahrzeug verbaute, Einrichtung zum Speichern von Backups und Steuern von
Aktualisierungsprozessen in einem Delta-Verfahren verstanden werden. Beispielsweise kann es sich bei der ersten Schnittstelle um eine Funkschnittstelle zur drahtlosen Kommunikation, beispielsweise mit dem Fahrzeug, handeln. Alternativ oder zusätzlich kann die Kommunikation über die erste Schnittstelle kabelgebunden erfolgen. Bei der zweiten Schnittstelle kann es sich
beispielsweise um einen Fahrzeugbus, etwa einen CAN-Bus, handeln. Unter einer externen Datenverarbeitungseinrichtung kann beispielsweise ein Server oder ein mobiles Endgerät verstanden werden. Unter einer
Unterscheidungsinformation kann beispielsweise eine sogenannte Delta-Datei verstanden werden. Unter einer solchen Delta-Datei, auch als Delta-Update- Datei bezeichnet, kann etwa ein Software- Update- Paket zum Software-Update auf eine neue Version verstanden werden. Die Unterscheidungsinformation kann im Vergleich zu einer Vollversion der neuen Software eine deutlich geringere Datenmenge repräsentieren. Beispielsweise kann es sich bei dem Datenpaket um ein komprimiertes oder unkomprimiertes Update- Paket zum Installieren der Vollversion der neuen Software handeln.
Der Schritt des Ausgebens kann in Abhängigkeit davon erfolgen, ob das
Zielgerät lediglich einen Software- Updater oder zusätzlich eine
Aktualisierungseinheit, beispielsweise mit einem Delta-Installer, zum Durchführen eines Delta-Verfahrens aufweist. So kann beispielsweise im ersten Fall das Datenpaket ausgegeben werden, während es im zweiten Fall ausreicht, lediglich die Unterscheidungsinformation auszugeben.
Der hier vorgestellte Ansatz betrifft Geräte, die über Software- Updates verfügen oder aus mehreren Komponenten bestehen, die je ein Software-Update unterstützen, aber einen eigenen Speicher haben und untereinander verbunden sind. Dabei können einzelne Komponenten aufgrund ihrer Ressourcensituation eingeschränkt sein. Der hier vorgestellte Ansatz beruht auf der Erkenntnis, dass zur Aktualisierung von Software einzelner Komponenten beispielsweise eines Fahrzeugs auf eine neue Version eine sogenannte Delta-Datei, die Unterschiede zwischen einer aktuell installierten Version und der neuen Version beinhaltet, und eine beispielsweise im Fahrzeug hinterlegte Kopie der aktuell installierten Version verwendet werden können, um die neue Version beispielsweise im Fahrzeug selbst zu berechnen und zu überprüfen, bevor die neue Version auf die betreffende Komponente aufgespielt wird. Somit können die Sicherheit beispielsweise des Fahrzeugs beeinträchtigende Fehler beim Aktualisieren auf ein Minimum beschränkt werden. Ferner hat ein derartiges
Aktualisierungsverfahren den Vorteil, dass statt einer Vollversion der Software lediglich die der betreffenden Komponente zugeordnete Delta-Datei
beispielsweise an das Fahrzeug übermittelt zu werden braucht, um die
Aktualisierung durchzuführen. Dadurch kann die Aktualisierung besonders schnell und effizient erfolgen, insbesondere wenn das Update beispielsweise über eine Funkschnittstelle eingespielt wird.
Dadurch, dass beispielsweise im Fahrzeug sowohl die alte als auch die neue Software als zentral hinterlegtes Backup vorhanden ist, ist es beispielsweise im Fehlerfall möglich, je nach Bedarf ein Vollupdate oder ein Rollback
durchzuführen, zumal diverse Komponenten aufgrund ihrer Ressourcensituation oftmals nicht in der Lage sind, eine Backup-Version ihrer jeweiligen Software zu speichern. Somit kann verhindert werden, dass die betreffenden Komponenten im Fall eines Update- Fehlers funktionsunfähig werden und einen
Werkstattbesuch erfordern. Es kann also sichergestellt werden, dass die
Komponenten auch bei einem Softwareupdate im Feld weiterhin funktionieren.
Der hier vorgestellte Ansatz umfasst ein systemweites Delta-Update-Verfahren, das in einer Aktualisierungseinrichtung, etwa einem zentralen Delta-Installer mit integriertem Backup-Server, neue Versionen aus einer Delta-Datei berechnet, speichert und verifiziert, um die neue Software in einem zweiten Schritt an die entsprechenden Zieleinheiten im Gesamtsystem zu verteilen. Dabei sollte immer nur eine Delta-Update-Version übertragen werden, sei es drahtlos oder im internen System, etwa über einen Fahrzeugbus. Wobei Delta- Update- Dateien nur dann übertragen werden können wenn auch die Zieleinheit über ein Delta- Update verfügt.
In der Aktualisierungseinrichtung muss eine Backup-Software für die einzelnen Zieleinheiten vorliegen oder diese zumindest geladen werden können..
Die Aktualisierungseinrichtung kann beispielsweise mit einer oder mehreren zentralen Installationseinheiten mit einem oder mehreren Delta-Installer mit entsprechenden Speicherressourcen angelegt sein, obwohl es eher üblich ist nur eine zentrale Stelle zu haben, die ggf. mehrere Delta Installer unterstützt. Diese zentralen Installationseinheiten mit Delta- Installer können über ein oder mehrere Delta-Update-Verfahren verfügen und müssen ebenfalls die jeweilige aktuelle Software der Zieleinheit als Backup besitzen oder zumindest Zugriff drauf haben. Es ist unabhängig ob die Zieleinheiten eine Aktualisierungseinheit mit oder ohne Delta-Installer verwendet. Die Sicherheit beim Update-Prozess wird also nicht alleine durch die Einzelkomponenten, sondern primär zentral durch die
Aktualisierungseinrichtung gewährleistet. Ein weiterer Punkt ist, dass die
Aktualisierungseinheiten mit Delta-Installer der Einzelkomponenten nur minimale zusätzliche Ressourcen erfordern und auch weniger Speicherzugriffe als bei einem Vollupdate stattfinden.
Ein wesentlicher Vorteil des hier vorgestellten Ansatzes besteht somit darin, dass eine ressourcentechnische Erweiterung der Zieleinheiten, etwa von RAM oder Flashspeicher, entfallen kann und trotzdem ein sicheres Update einschließlich Rollback unterstützt werden kann. So können auch kleine Zielsysteme Delta- Update-Verfahren nutzen.
Ein weiterer Vorteil ist, dass die beispielsweise drahtlose Datenübertragung zum Gesamtsystem durch das Delta-Update-Verfahren grundsätzlich minimiert werden kann. Dies gilt auch für Einzelkomponenten, die selbst keine Delta- Updates unterstützen, und auch für den Fall, dass über den internen Bus ein Vollupdate stattfinden soll.
Des Weiteren kann die Bus-Auslastung im Zielsystem minimiert werden, falls die Zieleinheiten selbst über eine Aktualisierungseinheit mit Delta-Installer verfügt.
Zudem können die Zieleinheiten ein Delta-Update-Verfahren sehr schnell ausführen, da keine zusätzlichen Speicherzugriffe erforderlich sind.
Vorteilhaft ist ferner, dass die Installationseinheit der Zieleinheiten mit Delta- Installer je Komponente keine Rollback- Funktionalität erfordert, da diese zentral in der Aktualisierungseinrichtung implementiert werden kann. Optional kann der Schutz der Delta-Installer je Komponente gegen
Unterbrechung entfallen, falls dieser Fall als selten eingestuft werden kann und dann durch ein Vollupdate, angestoßen durch den zentralen Delta-Installer, repariert werden kann.
Da die Aktualisierungseinrichtung mit zentralen Delta-Installer autark laufen und die empfangene Software ohne Einfluss auf die Zieleinheit prüfen und in einer neuen Version als Backup abspeichern können, kann geprüft werden, ob die Software korrekt ist, bevor der Nutzer überhaupt durch ein Software-Update beeinträchtigt werden kann.
Zudem können Defekte von Zieleinheiten vermieden werden, da die Software vorgeprüft wird bzw. im der Aktualisierungseinrichtung mit zentralem Delta- Installer ein Backup einer Vollversion von alter wie auch von neuer Software vorliegt.
Ein solches Verfahren kann einfach in bestehende zentrale Einheiten, etwa in ein zentrales Gateway, integriert werden. Außerdem kann ein solches Verfahren auf beliebig viele Komponenten angewendet werden, sofern genügend Speicherplatz vorhanden ist.
Durch die Anwendung weniger komplexer Delta-Update-Mechanismen kann schließlich auch die Fehlerhäufigkeit beim Aktualisieren reduziert werden.
Gemäß einer Ausführungsform kann das Verfahren einen Schritt des
Überprüfens des Datenpakets auf Fehler umfassen. Dabei kann im Schritt des Ausgebens das Datenpaket und/oder die Unterscheidungsinformation abhängig von einem Ergebnis des Überprüfens ausgegeben werden. Beispielsweise kann im Schritt des Überprüfens die Integrität des Datenpakets anhand einer
Prüfsumme überprüft werden, um Bitfehler im Datenpaket zu erkennen. Dadurch können Fehler im Datenpaket frühzeitig erkannt oder auch korrigiert werden. Somit kann eine fehlerhafte Aktualisierung der Software auf dem Zielgerät vermieden werden. Alternativ können Bitfehler bereits durch den Software- Update- Prozess behandelt werden. Gemäß einer weiteren Ausführungsform kann in einem Schritt des
Unterdrückens das Ausgeben des Datenpakets und/oder der
Unterscheidungsinformation unterdrückt werden, wenn sich beim Überprüfen ergibt, dass das Datenpaket fehlerhaft ist. Dadurch kann verhindert werden, dass fehlerhafte Aktualisierungsdaten auf das Zielgerät überspielt werden. Somit können Funktionsausfälle des Zielgeräts infolge einer fehlerhaften Aktualisierung vermieden werden.
Gemäß einer weiteren Ausführungsform kann das von der
Aktualisierungseinrichtung empfangene Datenpaket ohne vorherige Berechnung direkt an das Zielgerät weitergeleitet werden. Im zweiten Schritt berechnen das Zielgerät und die Aktualisierungseinrichtung parallel oder nacheinander die neue Software.
In einem Schritt des Kennzeichnens kann die neue Software als die aktuelle Software gekennzeichnet werden, wenn die Ergebnisinformation vom Zielgerät anzeigt, dass das Aktualisieren erfolgreich war. Zusätzlich oder alternativ kann der Schritt des Ausgebens von der Aktualisierungseinrichtung erneut ausgeführt werden, um die Kopie und/oder eine Zurücksetzungsinformation zum
Zurücksetzen des Zielgeräts auf eine frühere Version der Software an die Schnittstelle zum Zielgerät auszugeben, wenn die Ergebnisinformation des Zielgerätes anzeigt, dass das Aktualisieren nicht erfolgreich war. Dadurch kann das Risiko von Funktionsausfällen des Zielgeräts infolge einer Aktualisierung auf ein Minimum reduziert werden.
Gemäß einer weiteren Ausführungsform kann im Falle eines Zurücksetzen des Zielgeräts auf eine frühere Version der Software auch die
Aktualisierungseinrichtung mit zentralen Delta-Installer eine Delta Version zwischen neuer und alter Version berechnen um von der neuen SW wieder auf die alte zu kommen, dazu benötig die Installationseinheiten mit zentralen Delta- Installer auch einen Delta Generator.
Zusätzlich schafft der hier vorgestellte Ansatz eine Aktualisierungseinrichtung mit Einheiten, die ausgebildet sind, um das Verfahren gemäß einer der vorstehenden Ausführungsformen auszuführen und/oder anzusteuern. Der hier vorgestellte Ansatz schafft darüber hinaus ein Verfahren zum
Verarbeiten eines Datenpakets und/oder einer Unterscheidungsinformation aus einem Verfahren gemäß einer der vorstehenden Ausführungsformen mittels eines Zielgeräts beispielweise eines Fahrzeugs, wobei das Verfahren folgende Schritte umfasst:
Empfangen des Datenpakets und/oder der Unterscheidungsinformation über eine Schnittstelle zur Aktualisierungseinrichtung; und
Aktualisieren einer auf dem Zielgerät aktuell installierten Software unter
Verwendung des Datenpakets und/oder der Unterscheidungsinformation.
Gegenstand des hier vorgestellten Ansatzes ist auch ein Zielgerät mit Einheiten, die ausgebildet sind, um das Verarbeitungsverfahren gemäß der vorstehenden Ausführungsform auszuführen und/oder anzusteuern.
Die genannten Verfahren können beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware, beispielsweise in einem
Zielgerät oder einer Aktualisierungseinrichtung, implementiert sein.
Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie etwa einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte eines Verfahrens nach einer der
vorstehenden Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt: Fig. 1 eine schematische Darstellung eines Datenflusses bei der
Aktualisierung von Software auf Zielgeräten in einem Verfahren gemäß einem Ausführungsbeispiel;
Fig. 2 eine schematische Darstellung einer Erstellung eines Datenpakets aus Fig. 1;
Fig. 3 eine schematische Darstellung einer Aktualisierungseinrichtung aus Fig. 1 zu drei aufeinanderfolgenden Zeitpunkten eines
Aktualisierungsprozesses;
Fig. 4 eine schematische Darstellung eines Datenflusses bei der
Aktualisierung von Software auf einem Zielgerät aus Fig. 1;
Fig. 5 ein Ablaufdiagramm eines Verfahrens zum Aktualisieren von Software gemäß einem Ausführungsbeispiel;
Fig. 6 ein Ablaufdiagramm eines Verfahrens zum Verarbeiten eines
Datenpakets und/oder einer Unterscheidungsinformation gemäß einem Ausführungsbeispiel; und
Fig. 7 eine schematische Darstellung eines Fahrzeugs gemäß einem
Ausführungsbeispiel.
In der nachfolgenden Beschreibung günstiger Ausführungsbeispiele der vorliegenden Erfindung werden für die in den verschiedenen Figuren dargestellten und ähnlich wirkenden Elemente gleiche oder ähnliche
Bezugszeichen verwendet, wobei auf eine wiederholte Beschreibung dieser Elemente verzichtet wird.
Fig. 1 zeigt eine schematische Darstellung eines Datenflusses bei der
Aktualisierung von Software auf drei Zielgeräten 100, 102, 104, hier lediglich beispielhaft Steuergeräten einer Maschine, hier lediglich beispielhaft eines Fahrzeugs, in einem Verfahren gemäß einem Ausführungsbeispiel. Gezeigt ist ein beispielhafter Ablauf eines Over-the-Air-Updateprozesses mit einer Aktualisierungseinrichtung 106, die eine Installationseinheit 120 mit zentralem Delta-Installer für Zielgeräte 100, 102 mit und für ein Zielgerät 104 ohne Delta- Update umfasst. Die drei Zielgeräte 100, 102, 104 sind je mit einer zentralen Aktualisierungseinrichtung 106, beispielsweise des Fahrzeugs, gekoppelt. Die Aktualisierungseinrichtung 106 umfasst eine Empfangseinheit 108 zum
Empfangen einer dem ersten Zielgerät 100 zugeordneten ersten Unterscheidungsinformation 110, einer dem zweiten Zielgerät 102 zugeordneten zweiten Unterscheidungsinformation 112 sowie einer dem dritten Zielgerät 104 zugeordneten dritten Unterscheidungsinformation 114 über eine erste
Schnittstelle 116, hier beispielhaft einer Funkschnittstelle, zu einer externen Datenverarbeitungseinrichtung 118, wobei diese unter anderen auch eine Kabelverbindung oder ein USB-Medium sein kann. Bei den
Unterscheidungsinformationen 110, 112, 114 handelt es sich beispielsweise je um eine Delta- Update- Datei zur Software-Aktualisierung in einem sogenannten Delta-Verfahren. Dabei repräsentieren die Unterscheidungsinformationen jeweils Unterschiede zwischen einer auf dem jeweiligen Zielgerät 100, 102, 104 installierten aktuellen Software und einer auf dem jeweiligen Zielgerät 100, 102, 104 zu installierenden neuen Software.
Die Aktualisierungseinrichtung 106 fungiert gemäß diesem Ausführungsbeispiel als OTA-Master (OTA = Over-the-Air) zum drahtlosen Empfangen der
Unterscheidungsinformationen 110, 112, 114 über die erste Schnittstelle 116. Eine in die Aktualisierungseinrichtung 106 integrierte Installationseinheit 120, auch zentraler Delta-Installer genannt, ist ausgebildet, um die von der
Empfangseinheit 108 empfangenen Unterscheidungsinformationen 110, 112, 114 jeweils mit einer in einer geeigneten Speichereinheit 122, etwa einem
Flashspeicher, hinterlegten Kopie der auf den jeweiligen Zielgeräten 100, 102, 104 installierten aktuellen Software zu je einem Datenpaket zu kombinieren. Insbesondere repräsentieren die drei Datenpakete dabei je eine Vollversion der auf den jeweiligen Zielgeräten 100, 102, 104 zu installierenden neuen Software.
Um eine fehlerhafte Aktualisierung zu vermeiden, ist es vorteilhaft, wenn die Installationseinheit 120 die Datenpakete auf ihre jeweilige Integrität hin überprüft, beispielsweise mittels Prüfsummen oder sonstiger geeigneter Prüfwerte. Nur wenn ein Datenpaket fehlerfrei ist und auch die Berechnung der Vollversion der neuen Software erfolgreich war, stößt die Installationseinheit 120 einen
Aktualisierungsprozess zum Aktualisieren des betreffenden Zielgeräts 100, 102, 104 an.
Gemäß dem in Fig. 1 gezeigten Ausführungsbeispiel gibt die Installationseinheit 120 beispielsweise die erste Unterscheidungsinformation 110 nach erfolgreicher Überprüfung des dem ersten Zielgerät 100 zugeordneten Datenpakets, die zweite Unterscheidungsinformation 112 nach erfolgreicher Überprüfung des dem zweiten Zielgerät 102 zugeordneten Datenpakets und ein dem dritten Zielgerät 104 zugeordnetes Datenpaket 124 nach dessen erfolgreicher Überprüfung je an eine zweite Schnittstelle 126 aus, hier beispielhaft an einen CAN-Bus des Fahrzeugs. Die Zielgeräte 100, 102, 104 umfassen je eine
Zielgeräteempfangseinheit 128 zum Einlesen von Daten über die zweite
Schnittstelle 126 sowie eine Aktualisierungseinheit 130 zum Aktualisieren ihrer jeweiligen Software. Die Aktualisierungseinheiten 130 umfassen je einen geeigneten Software- Updater. Zusätzlich zum Software-Updater umfassen das erste Zielgerät 100 und das zweite Zielgerät 102 je eine Aktualisierungseinheit mit einem Delta-Installer zum Durchführen eines Delta-Updates mittels der ersten Unterscheidungsinformation 110 im Fall des ersten Zielgeräts 100 oder mittels der zweiten Unterscheidungsinformation 112 im Fall des zweiten Zielgeräts 104. Die Aktualisierungseinheit 130 des dritten Zielgeräts 104 ist in diesem Beispiel hingegen ausgebildet, um die Aktualisierung ausschließlich als Vollupdate mittels des dritten Datenpakets 124 durchzuführen. Unter einem Delta-Installer ist hier eine Software- Komponente als Erweiterung zu einem Software-Updater zu verstehen. Unter einem Software-Updater ist hingegen eine Software- Komponente in einem Zielgerät, das für sein eigenes Software-Update zuständig ist, zu verstehen.
Fig. 2 zeigt eine schematische Darstellung einer Erstellung eines Datenpakets aus Fig. 1. Gezeigt sind die Empfangseinheit 108 und die Installationseinheit 120. Zur Berechnung einer neuen Version einer zu aktualisierenden Software empfängt die Aktualisierungseinrichtung 106 zunächst die entsprechende Delta- Datei von der Empfangseinheit 108, hier beispielsweise die erste
Unterscheidungsinformation 110, sucht dann in einem Schritt 200 in der
Speichereinheit nach der entsprechenden Kopie der aktuellen Software, erstellt in einem nachfolgenden Schritt 202 das Datenpaket durch Berechnung der Vollversion der neuen Software unter Verwendung der
Unterscheidungsinformation 110 und hinterlegt schließlich nach erfolgreicher Überprüfung des Datenpakets in einem weiteren Schritt 204 die Vollversion der neuen Software in der Speichereinheit. Fig. 3 zeigt eine schematische Darstellung einer Aktualisierungseinrichtung 106 aus Fig. 1 zu drei aufeinanderfolgenden Zeitpunkten eines
Aktualisierungsprozesses. Als Beispiel soll hier eine Version 1.0 auf eine Version 1.1 aktualisiert werden. Zu Beginn des Aktualisierungsprozesses, dargestellt im linken Bild, befindet sich auf der Speichereinheit 122 lediglich eine Kopie 300 einer aktuellen Version 1.0 der Software eines Zielgeräts, hier beispielhaft des ersten Zielgeräts. Nach dem Empfangen der Unterscheidungsinformation 110 weist die Speichereinheit 122 zusätzlich zur Kopie 300 die erste
Unterscheidungsinformation 110 auf, die ein Delta zwischen der Version 1.0 und einer neuen Version 1.1 der Software repräsentiert, wie es im mittleren Bild dargestellt ist. Das rechte Bild zeigt den Inhalt der Speichereinheit 122 nach der Berechnung der Vollversion 1.1.
Fig. 4 zeigt eine schematische Darstellung eines Datenflusses bei der
Aktualisierung von Software auf einem Zielgerät aus Fig. 1, hier beispielhaft auf dem ersten Zielgerät 100. Auf der Speichereinheit 122 der
Aktualisierungseinrichtung 106 befinden sich, wie in Fig. 3 gezeigt, die Kopie 300, die erste Unterscheidungsinformation 110 und das Datenpaket 302. Je nach Ausführungsbeispiel erfolgt die Aktualisierung des Zielgeräts 100 auf drei Arten.
Bei einem regulären Update stellt die Aktualisierungseinrichtung 106 dem Zielgerät 100 lediglich die Unterscheidungsinformation 110 bereit. Das Zielgerät 100 führt dann die Aktualisierung der aktuellen Software mittels Delta-Installer durch und speichert abschließend die Version der neuen Software in einer Zielgerätespeichereinheit 400 ab, beispielsweise einem Flashspeicher.
Alternativ stellt die Aktualisierungseinrichtung 106 dem Zielgerät 100 das Datenpaket 302 mit der Vollversion 1.1 zur Aktualisierung der aktuellen Software bereit, etwa wenn die Aktualisierung mittels Delta-Installer fehlschlägt.
Drittens wird etwa im Fall einer fehlerhaften Aktualisierung die Software des Zielgeräts 100 auf eine frühere Version zurückgesetzt, was auch als Rollback bezeichnet wird. Hierzu stellt die Aktualisierungseinrichtung 106 dem Zielgerät 100 beispielsweise die Kopie 300 der Version 1.0 bereit. Fig. 5 zeigt ein Ablaufdiagramm eines Verfahrens 500 zum Aktualisieren von Software gemäß einem Ausführungsbeispiel. Das Verfahren 500 kann beispielsweise mittels einer Aktualisierungseinrichtung, wie sie vorangehend anhand der Figuren 1 bis 4 beschrieben ist, ausgeführt werden. Dabei wird zunächst in einem Schritt 510 die Unterscheidungsinformation oder, je nach Anzahl der zu aktualisierenden Zielgeräte, mehrere je einem Zielgerät zugeordnete Unterscheidungsinformationen über die erste Schnittstelle zur beispielsweise fahrzeugexternen Datenverarbeitungseinrichtung empfangen. In einem zweiten Schritt 520 werden die Unterscheidungsinformationen je mit einer in der Aktualisierungseinrichtung gespeicherten Kopie einer auf den jeweiligen Zielgeräten vorhandenen aktuellen Softwareversion kombiniert. Die
resultierenden Datenpakete repräsentieren dabei beispielsweise jeweils eine Vollversion der zu installierenden neuen Software je Zielgerät. Schließlich erfolgt in einem dritten Schritt 530 je nach Ausführungsbeispiel die Ausgabe des entsprechenden Datenpakets oder aber der entsprechenden
Unterscheidungsinformationen über die zweite Schnittstelle zu den Zielgeräten. Verfügt das zu aktualisierende Zielgerät beispielsweise über einen geeigneten Delta- Installer, so kann die Aktualisierung auf die neue Softwareversion besonders ressourcenschonend allein mittels der an das Zielgerät übertragenen Unterscheidungsinformation und der aktuellen Version auf dem Zielgerät stattfinden.
Fig. 6 zeigt ein Ablaufdiagramm eines Verfahrens 600 zum Verarbeiten eines Datenpakets und/oder einer Unterscheidungsinformation gemäß einem
Ausführungsbeispiel. Das Verfahren 600 kann beispielsweise unter Verwendung eines der Zielgeräte, wie sie vorangehend anhand der Figuren 1 bis 5 beschrieben sind, ausgeführt werden. Dabei wird in einem ersten Schritt 610 je nach Ausführungsbeispiel das entsprechende Datenpaket oder aber die entsprechende Unterscheidungsinformation über die zweite Schnittstelle, etwa einen CAN-Bus, empfangen. In einem zweiten Schritt 620 erfolgt die
Aktualisierung der auf dem betreffenden Zielgerät vorhandenen aktuellen Software unter Verwendung des Datenpakets, das beispielsweise eine
Vollversion der zu installierenden neuen Software repräsentiert, bzw. unter Verwendung der Unterscheidungsinformation, sofern das Zielgerät zur
Durchführung eines Delta-Verfahrens ausgebildet ist. Die Unterscheidungsinformation repräsentiert im Gegensatz zum Datenpaket lediglich die Unterschiede zwischen der aktuellen und der neuen
Softwareversion.
Nachfolgend werden verschiedene Ausführungsbeispiele des hier vorgestellten Ansatzes nochmals mit anderen Worten beschrieben.
Mittels des in Fig. 1 dargestellten Aktualisierungsprozesses soll die Software innerhalb eines Gesamtsystems, etwa eines Fahrzeugs, durch ein Software- Update auf eine aktuelle Version gebracht werden. Dabei ist es unerheblich, ob das Update in einer Werkstatt oder drahtlos im Feld stattfindet. Jede Zieleinheit im Fahrzeug, in Fig. 1 die in diesem Beispiel drei Zielgeräte 100, 102, 104, besitzt hierzu je einen Software-Updater 128 mit Vollupdate- Funktionalität und gegebenenfalls einen Delta-Installer 130. Im Unterschied zu Software-Updatern mit Delta-Installer empfangen Software-Updater ohne Delta-Installer keine Delta- Datei, sondern eine Vollversion zur Software-Aktualisierung.
Zusätzlich zu den standardmäßig im Fahrzeug befindlichen Modulen weist das Fahrzeug einen zentralen Delta-Installer auf. Dieser zentrale Delta-Installer, vorangehend Installationseinheit 120 genannt, ist entweder Teil einer bereits bestehenden Komponente, etwa eines zentralen Gateways oder eines Over-the- Air-Masters, oder ist als eigenständige Einheit realisiert. Bei einer Erweiterung einer bestehenden Zentralkomponente ist beispielsweise die Installationseinheit 120 oder die Zentralkomponente der Update-Master.
Die Installationseinheit 120 hat über die Speichereinheit 122 direkten Zugriff auf Backups sämtlicher Software im System, die durch dieses Verfahren aktualisiert werden sollen. Insbesondere sollten Versionen der aktuell genutzten Software aller Komponenten als Vollversionen vorliegen und in einer entsprechend großen persistenten Speichereinheit 122 hinterlegt sein. Diese Software- Backups werden beispielsweise schon bei der Produktion einmalig geflasht oder sogar vorgeflasht.
Die Installationseinheit 120 nimmt die Delta-Update-Datei jeder einzelnen Zieleinheit entgegen, sucht das entsprechende Backup in der Speichereinheit 122 und wendet diese Kombination mittels Delta- Installer in der Speichereinheit 122 an, wie dies schematisch in Fig. 2 dargestellt ist. Die Installationseinheit 120 prüft jetzt die berechnete neue Software auf Korrektheit und speichert diese lokal als neue Backup-Version 302 ab. Somit verfügt die Aktualisierungseinrichtung 106 über die Vollversion der aktuellen Software einer jeden Zieleinheit, die Vollversion der neuen Software einer jeden Zieleinheit und über die jeweilige Delta-Update-Datei einer jeden Zieleinheit. Dies ist aus den Figuren 3 und 4 ersichtlich.
Nach erfolgreicher Berechnung und Prüfung aller voneinander abhängigen Versionen wird das Gesamt- oder Teilsystem in den Update-Modus versetzt. Dabei wird den einzelnen Software-Updatern der Zieleinheiten je nach deren Ausstattung die zuvor empfangene Delta-Update-Datei oder die Vollversion der neuen Software als Update-Paket angeboten. Die Software-Updater der
Zieleinheiten wenden nun beispielsweise ebenfalls das Delta-Update-Verfahren an und bestätigen der Installationseinheit 120 das jeweilige Ergebnis.
Im Falle eines Fehlers, was aufgrund der Vorprüfung eher selten Vorkommen sollte, sendet die Installationseinheit 120 die zuvor selbst berechnete neue Vollversion in Form des Datenpakets 302 als Vollupdate komprimiert oder unkomprimiert an die betreffende Zieleinheit, wie es in Fig. 4 gezeigt ist. Im Falle eines Rollback auf die alte Version wird beispielsweise die alte Backup-Version in Form der Kopie 300 als Vollupdate übermittelt. Nach erfolgreichem Update wird in der Installationseinheit 120 die neue Version 302 der Software als aktuell gültige Version vermerkt, sodass diese als Referenz für weitere Updates nutzbar ist.
Wann und ob alte Versionen in der Installationseinheit 120 gelöscht werden, hängt unter anderem von der Größe der Speichereinheit 122 ab. Wichtig ist, dass das Backup der aktuellen Software einer zu aktualisierenden Komponente nicht gelöscht wird.
Bedingung für die Aktualisierung mittels Delta-Verfahren ist ferner, dass der Delta-Installer in der Installationseinheit 120 und der Delta-Installer in der zu aktualisierenden Zieleinheit kompatibel sind. Bei einem direkten Update, etwa über den Fahrzeugbus, sollte die
Installationseinheit 120 zusätzlich aktualisiert werden, damit die Versionen identisch bleiben. Ansonsten wäre ein späteres Over-the-Air-Update im Feld nur per Vollupdate möglich.
Gemäß einem Ausführungsbeispiel liegt die Kopie 300 der jeweils aktuellen Software nicht dauerhaft in der Speichereinheit 122 vor, sondern wird erst bei Bedarf von der betreffenden Zieleinheit geladen. Somit kann ein initales Flashen der Speichereinheit 122 entfallen.
Um die Gesamtzeit der Aktualisierung weiter zu reduzieren, ist es beispielsweise auch möglich, die Unterscheidungsinformation 110 direkt, d. h. ohne vorherige Überprüfung oder sonstige Zwischenschritte, an die Zieleinheit weiterzuleiten.
Gemäß einem weiteren Ausführungsbeispiel umfasst die Installationseinheit 120 zusätzlich einen Delta-Generator, etwa um eine Rollback-Datei, welche durch die Pakete 302 und 300 berechnet wird, ebenfalls als Delta-Datei übertragen zu können.
Fig. 7 zeigt eine schematische Darstellung eines Fahrzeugs 700 gemäß einem Ausführungsbeispiel. Das Fahrzeug 700, beispielsweise ein Straßenfahrzeug zur Personenbeförderung, weist ein Zielgerät 100 auf. Bei dem Zielgerät 100 handelt es sich beispielweise um ein Motorsteuergerät oder ein Airbagsteuergerät mit einer Funktionalität, wie sie in bekannten Steuergeräten um gesetzt wird. Das Zielgerät 100 weist einen wiederbeschreibbaren Speicher zum Speichern einer Software zum Betreiben des Zielgeräts 100 auf. Um die Software zu
aktualisieren, ist in dem Fahrzeug 700 eine Aktualisierungseinrichtung 106 integriert, die ausgebildet ist, um ein Datenpaket 302 und zusätzlich oder alternativ eine Unterscheidungsinformation 110 umfassendes Signal an das Zielgerät 100 zu übermitteln. Das Datenpaket umfasst gemäß einem
Ausführungsbeispiel eine aktualisierte Version der Software zur Abspeicherung in dem Speicher des Zielgeräts 100. Die Unterscheidungsinformation 110 umfasst gemäß einem Ausführungsbeispiel Daten, die einen Unterschied zwischen der im Zielgerät 100 gespeicherten Software und der aktualisierten Version der Software definieren. Die Datenpaket 302 und die
Unterscheidungsinformation 110 werden gemäß einem Ausführungsbeispiel in Form elektrischer Signale übertragen. Die Aktualisierungseinrichtung 106 ist ausgebildet, um ein Signal, das die Unterscheidungsinformation 110 umfasst, von einer fahrzeugextern angeordneten Datenverarbeitungseinrichtung 118 zu empfangen und zum Generieren des Datenpakets 302 zu verwenden. Dazu weist die Datenverarbeitungseinrichtung 118 eine Kombiniereinrichtung auf, die ausgebildet ist, um die Unterscheidungsinformation 110 mit einer in einem Speicher der Aktualisierungseinrichtung 106 gespeicherten Kopie 300 der aktuell in dem Zielgerät 100 gespeicherten Software zu kombinieren. Optional weist die
Datenverarbeitungseinrichtung 118 eine Überprüfungseinrichtung auf, die ausgebildet ist, um das Datenpaket 302 auf Fehler zu überprüfen. Gemäß einem Ausführungsbeispiel ist die Aktualisierungseinrichtung 106 ausgebildet, um abhängig von einem Ergebnis der in der Überprüfungseinrichtung durchgeführten Überprüfung entweder das Datenpaket 302 oder die
Unterscheidungsinformation 110 an das Zielgerät 100 zu übermitteln.
Umfasst ein Ausführungsbeispiel eine„und/oder“-Verknüpfung zwischen einem ersten Merkmal und einem zweiten Merkmal, so ist dies so zu lesen, dass das Ausführungsbeispiel gemäß einer Ausführungsform sowohl das erste Merkmal als auch das zweite Merkmal und gemäß einer weiteren Ausführungsform entweder nur das erste Merkmal oder nur das zweite Merkmal aufweist.

Claims

Ansprüche
1. Verfahren (500) zum Aktualisieren von Software auf einem
Zielgerät (100) mittels einer Aktualisierungseinrichtung (106), wobei das Verfahren (500) folgende Schritte umfasst:
Empfangen (510) einer Unterscheidungsinformation (110), die einen Unterschied zwischen einer auf dem Zielgerät (100) installierten aktuellen Software und einer auf dem Zielgerät (100) zu installierenden neuen Software repräsentiert, von einer Schnittstelle (116) zu einer externen Datenverarbeitungseinrichtung (118);
Kombinieren (520) der Unterscheidungsinformation (110) mit einer in der Aktualisierungseinrichtung (106) hinterlegten Kopie (300) der aktuellen Software, um ein die neue Software repräsentierendes Datenpaket (302) zu erstellen; und
Ausgeben (530) des Datenpakets (302) und/oder der
Unterscheidungsinformation (110) an eine Schnittstelle (126) zum Zielgerät (100), um die Software auf dem Zielgerät (100) zu
aktualisieren.
2. Verfahren (500) gemäß Anspruch 1, mit einem Schritt des Überprüfens des Datenpakets (302) auf Fehler, wobei im Schritt des
Ausgebens (530) das Datenpaket (302) und/oder die
Unterscheidungsinformation (110) abhängig von einem Ergebnis des Überprüfens ausgegeben wird.
3. Verfahren (500) gemäß Anspruch 2, mit einem Schritt des
Unterdrückens des Ausgebens (530) des Datenpakets (302) und/oder der Unterscheidungsinformation (110), wenn sich beim Überprüfen ergibt, dass das Datenpaket (302) fehlerhaft ist.
4. Verfahren (500) gemäß einem der vorangegangenen Ansprüche, bei dem im Schritt des Kombinierens (520) eine Vollversion der neuen Software als das Datenpaket (302) erstellt wird.
5. Verfahren (500) gemäß einem der vorangegangenen Ansprüche, mit einem weiteren Schritt des Empfangens, in dem nach dem Ausgeben ein Ergebnis des Aktualisierens repräsentierende Ergebnisinformation von der Schnittstelle (126) zum Zielgerät (100) empfangen wird, wobei in einem Schritt des Kennzeichnens die neue Software als die aktuelle Software gekennzeichnet wird, wenn die Ergebnisinformation anzeigt, dass das Aktualisieren erfolgreich war, und/oder der Schritt des
Ausgebens (530) erneut ausgeführt wird, um das Datenpaket (302) und/oder die Kopie (300) und/oder eine Zurücksetzungsinformation zum Zurücksetzen des Zielgeräts (100) auf eine frühere Version der Software an die Schnittstelle (126) zum Zielgerät (100) auszugeben, wenn die Ergebnisinformation anzeigt, dass das Aktualisieren nicht erfolgreich war.
6. Verfahren (600) zum Verarbeiten eines Datenpakets (302) und/oder einer Unterscheidungsinformation (110) aus einem Verfahren (500) gemäß einem der Ansprüche 1 bis 5 mittels eines Zielgeräts (100), wobei das Verfahren (600) folgende Schritte umfasst:
Empfangen (610) des Datenpakets (302) und/oder der
Unterscheidungsinformation (110) über eine Schnittstelle (126) zur Aktualisierungseinrichtung (106); und
Aktualisieren (620) einer auf dem Zielgerät (100) aktuell installierten Software unter Verwendung des Datenpakets (302) und/oder der Unterscheidungsinformation (110).
7. Aktualisierungseinrichtung (106) mit Einheiten (108, 120, 122), die
ausgebildet sind, um das Verfahren (500) gemäß einem der Ansprüche 1 bis 5 auszuführen und/oder anzusteuern.
8. Zielgerät (100) mit Einheiten (128, 130; 400), die ausgebildet sind, um das Verfahren (600) gemäß Anspruch 6 auszuführen und/oder anzusteuern.
9. Computerprogramm, das ausgebildet ist, um das Verfahren (500) gemäß einem der Ansprüche 1 bis 5 und/oder das Verfahren (600) gemäß Anspruch 6 auszuführen und/oder anzusteuern. io. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 9 gespeichert ist.
EP19726990.5A 2018-06-20 2019-05-27 Verfahren zum aktualisieren von software auf einem zielgerät Pending EP3811203A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018209972.3A DE102018209972A1 (de) 2018-06-20 2018-06-20 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
PCT/EP2019/063602 WO2019242996A1 (de) 2018-06-20 2019-05-27 Verfahren zum aktualisieren von software auf einem zielgerät

Publications (1)

Publication Number Publication Date
EP3811203A1 true EP3811203A1 (de) 2021-04-28

Family

ID=66668936

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19726990.5A Pending EP3811203A1 (de) 2018-06-20 2019-05-27 Verfahren zum aktualisieren von software auf einem zielgerät

Country Status (4)

Country Link
EP (1) EP3811203A1 (de)
CN (1) CN112567339A (de)
DE (1) DE102018209972A1 (de)
WO (1) WO2019242996A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113505363B (zh) * 2021-08-04 2022-11-29 上海瓶钵信息科技有限公司 通过软件方式实现存储空间防重放的方法和系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103699408A (zh) * 2013-12-12 2014-04-02 乐视网信息技术（北京）股份有限公司 一种软件升级的方法和设备
JP6216730B2 (ja) * 2015-03-16 2017-10-18 日立オートモティブシステムズ株式会社 ソフト更新装置、ソフト更新方法
US10101992B2 (en) * 2015-06-15 2018-10-16 Lear Corporation Telematics control unit comprising a differential update package
US10437680B2 (en) * 2015-11-13 2019-10-08 Kabushiki Kaisha Toshiba Relay apparatus, relay method, and computer program product
JP6755158B2 (ja) * 2016-09-30 2020-09-16 株式会社日立製作所 計算機システム、計算機システムによるソフトウェアの更新方法、及び、そのためのプログラム

Also Published As

Publication number Publication date
CN112567339A (zh) 2021-03-26
WO2019242996A1 (de) 2019-12-26
DE102018209972A1 (de) 2019-12-24

Similar Documents

Publication Publication Date Title
DE102019109672A1 (de) Rückgängigmachung nach einem teilausfall in mehreren elektronischen steuergeräten mittels over-the-air-updates
EP3218804A1 (de) Update einer firmware
DE19839680A1 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
WO2019096840A1 (de) Verfahren und system zum aktualisieren einer fahrzeugsoftware
WO2019137773A1 (de) Absicherung eines softwareupdates eines steuergerätes eines fortbewegungsmittels
EP3811203A1 (de) Verfahren zum aktualisieren von software auf einem zielgerät
DE102021211908A1 (de) Verfahren zum Verarbeiten von Daten
EP3353650A1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
DE102015207795A1 (de) Verfahren und Vorrichtung zum Aktualisieren von Software in einem Transportmittel
WO2017178211A1 (de) Verfahren zum betreiben eines steuergeräts für ein fahrzeug, steuergerät, betriebssystem, kraftfahrzeug
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
EP3384411B1 (de) Verfahren zum übertragen eines funktionsbefehls zwischen einem kraftfahrzeug und einer fahrzeugexternen einrichtung sowie schnittstellenvorrichtung und system
EP3724758B1 (de) Verfahren zum durchführen eines updates einer softwareapplikation in einem gerät, das sich im betrieb befindet, sowie gerät und kraftfahrzeug
EP2962162B1 (de) Verfahren zur einrichtung oder aktualisierung einer programmierung eines steuergerätes eines verkehrsmittels
DE102019000493A1 (de) Verfahren zur Aktualisierung einer jeweiligen Software mehrerer Steuergeräte 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
DE102020216481A1 (de) Verfahren zum Betreiben eines Steuergeräts und Steuergerät
DE102012217312B4 (de) Verfahren und System zur Aktualisierung von Code in Verarbeitungssystemen
DE102012218665B4 (de) Applikationssystem für Steuergeräte
WO2009103728A1 (de) Verfahren und vorrichtung zum speichern von informationsdaten
DE202014010619U1 (de) Update einer Firmware
DE102017222267A1 (de) System und Verfahren zum Aktualisieren von Softwaremodulen mindestens eines Schienenfahrzeugs
WO2023006531A1 (de) Verfahren zur überprüfung digitaler signaturen, fahrzeug-recheneinheit und fahrzeug
DE102020216071A1 (de) Verfahren zum Betreiben einer Vorrichtung, ein Steuergerät eines Kraftfahrzeugs, und Vorrichtung
WO2023020807A1 (de) Automatisches erkennen und korrigieren von speicherfehlern in einem sicheren mehrkanaligen rechner

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

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: 20210120

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

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
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: 20230213