EP3811203A1

EP3811203A1 - Method for updating software on a target device

Info

Publication number: EP3811203A1
Application number: EP19726990.5A
Authority: EP
Inventors: Lars PLISCHKE; Georg Rudolph; Wolfgang Fischer
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2018-06-20
Filing date: 2019-05-27
Publication date: 2021-04-28
Also published as: DE102018209972A1; WO2019242996A1; CN112567339A

Abstract

The invention relates to a method for updating software on a target device (100) by means of an update device (106). In a first step, an interface (116) to an external data processing device (118) receives distinction information (110) representing a difference between current software installed on the target device (100) and new software to be installed on the target device (100). In a second step the distinction information (110) is combined with a copy of the current software, which is saved in the update device (106), in order to create a data packet (302) representing the new software. Finally, in a third step the data packet (302) and/or the distinction information (110) are output to an interface (126) to the target device (100) in order to update the software on the target device (100).

Description

description

title

METHOD FOR UPDATING SOFTWARE ON A TARGET DEVICE

State of the art

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.

Disclosure of the invention

Against this background, the approach presented here describes a method for updating software on a target device using a

Update device, a corresponding update device, a method for processing a data packet and / or

Differentiation information by means of a target device, a corresponding target device and finally a corresponding computer program according to the main claims. The measures listed in the dependent claims allow advantageous developments and improvements of the device specified in the independent claim. A method for updating software on a target device by means of an update device is presented, the method comprising the following steps:

Receiving, from an interface to an external data processing device, distinctive information representing a difference between current software installed on the target device and new software to be installed on the target device;

Combine the discrimination information with one in the

Update device deposited copy of the current software to create a data packet representing the new software; and

Output of the data packet and / or the differentiation information to an interface to the target device in order to update the software on the target device. 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.

In one embodiment, the target device controls the

Vehicle. For this purpose, 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.

Under an update device, 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. For example, the first interface can be a radio interface for wireless communication, for example with the vehicle. As an alternative or in addition, communication can take place via the first interface in a wired manner. The second interface can

act, for example, a vehicle bus, such as a CAN bus. 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. Such a delta file, also referred to as a delta update file, can be understood to mean, for example, a software update package for software updates to a new version. The differentiation information can represent a significantly smaller amount of data compared to a full version of the new software. For example, 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. For example, 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. Thus, 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

for example, needs to be transmitted to the vehicle in order to

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.

Because, for example, 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

especially since various components are often unable to save a backup version of their respective software due to their resource situation. This can prevent the relevant components from becoming inoperable in the event of an update error and prevent one

Require workshop visit. It can therefore be ensured that the

Components continue to work even with a software update in the field.

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. 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 facility guaranteed. Another point is that 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.

Furthermore, the bus load in the target system can be minimized if the target units themselves have an update unit with a delta installer.

In addition, the target units can carry out a delta update process very quickly, since no additional memory accesses are required.

It is also advantageous that 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. Optionally, the protection of the delta installer against each component

There is no interruption if this case can be classified as rare and can then be repaired by a full update, initiated by the central delta installer.

Since 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.

In addition, 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. In addition, such a method can be applied to any number of components, provided there is enough storage space.

By using less complex delta update mechanisms, the frequency of errors when updating can also be reduced.

According to one embodiment, the method can include a step of

Check the data packet for errors. In the step of outputting, the data packet and / or the differentiation information can be outputted depending on a result of the checking. For example, in the step of 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

Suppress the output of the data packet and / or 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.

According to a further embodiment, that of the

Data packets received by the update device are forwarded directly to the target device without prior calculation. In the second step, the target device and the update device calculate the new software in parallel or in succession.

In a labeling step, 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

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.

According to a further embodiment, if the target device is reset to an earlier version of the software, the

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.

In addition, 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

Processing of a data packet and / or differentiation information from a method according to one of the above embodiments using a target device, for example a vehicle, the method comprising the following steps:

Receiving the data packet and / or the differentiation information via an interface to the update device; and

Update software currently installed on the target device at

Use of the data packet and / or the differentiation information.

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.

The methods mentioned can be, for example, in software or hardware or in a mixed form of software and hardware, for example in one

Target device or an update device can be implemented.

Also advantageous is 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

above embodiments is used, especially when the program product or program is executed on a computer or a device.

Embodiments of the invention are shown in the drawings and explained in more detail in the following description. It shows: Fig. 1 is a schematic representation of a data flow in the

Updating software on target devices in a method according to an embodiment;

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

Update process;

Fig. 4 is a schematic representation of a data flow in the

Updating software on a target device from FIG. 1;

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

Data packets and / or differentiation information according to an embodiment; and

Fig. 7 is a schematic representation of a vehicle according to a

Embodiment.

In the following description of favorable exemplary embodiments of the present invention, the same or similar elements are shown for the elements which are represented in the various figures and have a similar effect

Reference numerals are used, a repeated description of these elements being omitted.

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

Receiving a first assigned to the first target device 100 Differentiation information 110, second differentiation information 112 assigned to second target device 102 and third differentiation information 114 assigned to third target device 104 about first

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. Both

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.

According to this exemplary embodiment, the update device 106 functions as an OTA master (OTA = over-the-air) for wireless reception of the

Distinction information 110, 112, 114 via the first interface 116. An installation unit 120 integrated in the update device 106, also called a central delta installer, is designed to accommodate that of the

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. In particular, the three data packets each represent a full version of the new software to be installed on the respective target devices 100, 102, 104.

In order to avoid an incorrect update, it is advantageous if 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.

According to the exemplary embodiment shown in FIG. 1, the installation unit 120, for example, 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

Interface 126 and an update unit 130 for updating their respective software. The update units 130 each include a suitable software updater. In addition to the 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 In contrast, in this example, 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, on the other hand, 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. To calculate a new version of software to be updated, the update device 106 first receives the corresponding delta file from the receiving unit 108, here, for example, the first

Discrimination information 110, then 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

Distinction information 110 and, after the data packet has been successfully checked, in a further step 204 stores the full version of the new software in the storage unit. FIG. 3 shows a schematic illustration of an update device 106 from FIG. 1 at three successive times one

Update process. As an example, version 1.0 is to be updated to version 1.1. At the beginning of the update process, shown in the image on the left, there is only a copy 300 of a current version 1.0 of the software of a target device, here the example of the first target device, on 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

Updating software on a target device from FIG. 1, here by way of example on the first target device 100. On the storage unit 122 of the

As shown in FIG. 3, the update device 106 contains the copy 300, the first differentiation information 110 and the data packet 302. Depending on the exemplary embodiment, the target device 100 is updated in three ways.

In the case of a regular update, 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.

Alternatively, 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.

Third, in the event of a faulty update, for example, the software of the target device 100 is reset to an earlier version, which is also referred to as rollback. For this purpose, 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. First of all, in a step 510, 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. In a second step 520, the differentiation information is combined with a copy of a current software version stored on the respective target devices stored in the update device. The

resulting data packets represent, for example, a full version of the new software to be installed for each target device. Finally, depending on the exemplary embodiment, the corresponding data packet or else the corresponding one is output in a third step 530

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.

6 shows a flowchart of a method 600 for processing a data packet and / or a differentiation information according to one

Embodiment. 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. In a first step 610, depending on the exemplary embodiment, 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

Full version of the new software to be installed, or using the differentiation information, if the target device for

Implementation of a delta process is formed. The In contrast to the data packet, distinction information only represents the differences between the current and the new one

Software version.

Various exemplary embodiments of the approach presented here are described again in other words below.

1, the software within an overall system, for example a vehicle, is to be updated to a current version by means of a software update. It is irrelevant whether the update takes place in a workshop or wirelessly in the field. For this purpose, 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. In contrast to software updaters with delta Installers receive software updaters without a delta installer, not a delta file, but a full version for software updates.

In addition to the standard modules in the vehicle, 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. In particular, 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.

After successful calculation and testing of all interdependent versions, the entire or subsystem is put into update mode. Depending on their configuration, 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. The software updater of

Target units now also use the delta update method, for example, and confirm the respective result to installation unit 120.

In the event of an error, which should occur rather rarely due to the preliminary check, 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. In the case of a rollback to the old version, the old backup version, for example, is transmitted in the form of a copy 300 as a full update. After a successful 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.

When and whether old versions in the installation unit 120 are deleted depends, among other things, on the size of the storage unit 122. It is important that the backup of the current software of a component to be updated is not deleted.

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. With 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.

According to one exemplary embodiment, 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.

In order to further reduce the total time of the update, it is also possible, for example, to directly distinguish information 110. H. without prior verification or other intermediate steps to forward to the target unit.

According to a further exemplary embodiment, 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.

7 shows a schematic illustration of a vehicle 700 according to an exemplary embodiment. 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

update, 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. According to one, the data packet comprises

Embodiment an updated version of the software for storage in the memory of the target device 100. According to an embodiment, 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. The data packet 302 and the

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. For this purpose, 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. Optionally, the

Data processing device 118 has a checking device which is designed to check the data packet 302 for errors. According to one exemplary embodiment, 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

To transmit distinction information 110 to the target device 100.

If 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.

Claims

Expectations

1. Method (500) for updating software on a

Target device (100) using an update device (106), the method (500) comprising the following steps:

Receiving (510) discrimination information (110), which represents a difference between current software installed on the target device (100) and new software to be installed on the target device (100), from an interface (116) to an external data processing device (118 );

Combining (520) the differentiation information (110) with a copy (300) of the current software stored in the update device (106) in order to create a data packet (302) representing the new software; and

Outputting (530) the data packet (302) and / or the

Discrimination information (110) to an interface (126) to the target device (100) to the software on the target device (100)

To update.

2. The method (500) according to claim 1, with a step of checking the data packet (302) for errors, wherein in the step of

Output (530) the data packet (302) and / or the

Discrimination information (110) is output depending on a result of the checking.

3. The method (500) according to claim 2, comprising a step of

Suppressing the output (530) of the data packet (302) and / or the discrimination information (110) if the check reveals that the data packet (302) is faulty.

4. The method (500) according to one of the preceding claims, in which in the step of combining (520) a full version of the new software is created as the data packet (302).

5. The method (500) according to one of the preceding claims, with a further step of receiving, in which, after the output, a result information representing a result of the update is received from the interface (126) to the target device (100), wherein in a step of labeling the new software is flagged as the current software if the result information indicates that the update was successful and / or the step of

Outputting (530) is performed again to transfer the data packet (302) and / or the copy (300) and / or reset information for resetting the target device (100) to an earlier version of the software at the interface (126) to the target device (100 ) if the result information indicates that the update was not successful.

6. A method (600) for processing a data packet (302) and / or a differentiation information (110) from a method (500) according to one of claims 1 to 5 by means of a target device (100), the method (600) comprising the following steps :

Receiving (610) the data packet (302) and / or the

Distinction information (110) via an interface (126) to the update device (106); and

Update (620) software currently installed on the target device (100) using the data packet (302) and / or the differentiation information (110).

7. Update device (106) with units (108, 120, 122) that

are designed to carry out and / or to control the method (500) according to one of claims 1 to 5.

8. target device (100) with units (128, 130; 400) which are designed to execute and / or to control the method (600) according to claim 6.

9. Computer program which is designed to execute and / or to control the method (500) according to one of claims 1 to 5 and / or the method (600) according to claim 6. io. Machine-readable storage medium on which the computer program according to claim 9 is stored.