WO2007051958A1

WO2007051958A1 - Update package format and method for grouping and sequencing update payloads

Info

Publication number: WO2007051958A1
Application number: PCT/GB2006/002975
Authority: WO
Inventors: David Gordon
Original assignee: Matsushita Electric Industrial Co. Ltd.
Priority date: 2005-11-04
Filing date: 2006-08-09
Publication date: 2007-05-10
Also published as: GB0522631D0; GB2432020A

Abstract

A method of preparing data forming a software update package for transmission to an embedded device and installing the software update package on the embedded device. The method comprises the steps of generating a header containing an install or uninstall command and package identification information and generating at least one payload containing data related to at least one change to be applied to target software. The step of generating the or each payload comprises the steps of generating a plugin ID for identifying the installation method which is to be used for the payload, generating a group ID for identifying one or more pay loads with which the payload will be grouped, generating a sequence ID for identifying in which order the at least one payload is to be installed and generating a payload command determining whether the payload is used for an installation or an uninstallation.

Description

UPDATE PACKAGE FORMAT AND METHOD FOR GROUPING AND SEQUENCING UPDATE PAYLOADS

The present invention relates to a software update package format containing one or more payloads of software update data, and a method for grouping and sequencing these payloads during their installation into a target device.

Many embedded devices such as mobile telephones support software modifications by patching and by downloading replacement software modules. Software updates are currently delivered to embedded devices as a series of groups of raw data. Known examples are S-Record formats and BIN file formats. However, there are several limitations to these methods.

The software which is available to and which is being installed on embedded devices is growing at an increasingly fast rate. This, coupled with the clear increase in size of mobile networks and the growing intricacy of multiple access techniques, has resulted in the need to manage software updates more effectively. In most known methods, it is assumed that the update completely overwrites the existing code. This has multiple technical drawbacks.

Most existing methods fail to provide a way of permitting an embedded device itself to, in response to a temporary halt in the installation process, either uninstall a software update (rollback) or restart installation of a software update (recovery) in order to provide a dynamically and independently upgradable device. Rollback is the process by which a proposed change in a pending update transaction is aborted and changes which have already been made are cancelled, effectively "rolling back" the state of the software to a point before the update was installed. Recovery is the process by which the installation of software on an embedded device is resumed after a temporary error, such as a power failure.

Also, known methods fail to provide means for effecting multiple independent updates on multiple independent components in one embedded system. For example, were there to be a need to update a Dynamic Linked Library and a specific Device Driver only, or, were there a need to update different aspects of the software of the main processor and the baseband processor, existing methods would not allow both updates to be sent together. This represents clear disadvantages in terms of the flexibility, speed and ease of the update process. There is thus a need for an update package format which permits the embedded device to revert back to a stable condition if an unrecoverable error occurs during a software update or to entirely remove an existing software package. There is also a need for-a software update package which allows multiprocessor or independent multiple software component updates.

In order to provide a solution to the shortcomings of the prior art, the present invention provides a method of preparing data forming a software update package for transmission to an embedded device, the method comprises the steps of: generating a header containing an install or uninstall command and package identification information; and generating at least one payload containing data related to at least one change to be applied to target software; wherein the step of generating the or each payload comprises the steps of: generating a plugin ID for identifying the installation method which is to be used for the payload; generating a group ID for identifying one or more payloads with which the payload will be grouped. generating a sequence ID for identifying in which order the at least one payload is to be installed generating a payload command determining whether the payload is used for an installation or an uninstallation.

The present invention further comprises a method of installing the software update package, the method comprises the step of: installing each payload in order of its sequence ID.

If, during installation of a specific payload, an irrecoverable error occurs, the method further comprises the steps of: uninstalling the completed changes found in the specific payload; uninstalling, in reverse order of their sequence ID, the payloads having the same Group ID as the specific payload; installing, in order of their sequence ID, all remaining payloads which do not share the same Group ID as the specific payload. The present invention further comprises a method of installing the software update package, the method comprises the step of: installing each payload according to its Group ID.

If₁ during installation of a specific payload, an irrecoverable error occurs, the method further comprises the steps of: uninstalling the completed changes found in the specific payload; uninstalling each payload which was installed during the installation step and which also has the same Group ID as the specific payload; installing, in order of their sequence ID, all remaining payloads which do not share the same Group ID as the specific payload.

In the drawings:

Figure 1 is a block diagram representing an embedded wireless terminal system suitable for carrying out the method of the present invention.

Figure 2 is a block diagram showing the use of a plug-in ID according to one embodiment of the present invention.

Figure 3 is a representation of the update package format according to one example of the present invention.

Figure 4 is a representation of the update package format according to another example of the present invention.

Figure 5 is a representation of the update package format according to a further example of the present invention.

Figure 6 is a representation of the update package format according to yet a further example of the present invention.

Referring to figure 1 , an embedded wireless terminal system 5 suitable for carrying out the method of the present invention comprises a software server 6 connected to a radio transceiver 7 and at least one embedded wireless device 8. Each embedded wireless device 8 comprises an application processor 9, Input/Output means 10, memory means 11 , a transmit/receive means 12 and one or more secondary processors 13 and programmable logic 14 for baseband functions.

In reference to figure 3, the update package 1 comprises three sections, the header 2, the body 3 and the digest 4 the body may be encrypted for security reasons. The header 2 contains information about the^' update package. It may contain at least one of any of a package ID 21 , a package name 22, a package description 23, a package command section 24 and a decryption information section 25. The package ID 21 is an identifier for the specific update package 1. It - may be globally unique, generated by a central authority or it may only have local uniqueness within an unspecified community.

The package name 22 is a free-format text string used to provide a name for the update package 1. Typically, its size will be limited for presentation reasons. The package description 23 is a free-format text string used to provide a description of the update package 1 and/or its contents, Typically, its size is not limited and its contents are stored in the embedded device to be used for management purposes.

The package command 24 contains instructions which are read by the embedded device and instruct it how to handle the update package 1 in a certain way. An install command instructs the embedded device 8 to treat this update package as a new change to be installed. An uninstall command instructs the embedded device 8 to treat this package as removal information for a previously installed update package. The package command 24 thus contains the default action for each payload in the update package. This default can be overridden by an explicit payload command 315, 325 in each payload. In an Install operation, the installing function first checks that the specified changes have not already been made by checking the update package ID and the payload ID against records kept in a registry on the target system. If no pre-existing entry exists, the specified changes are applied to the existing software, and then entries corresponding to the changes are created in the registry. In an uninstall operation, the uninstall function first checks that the specified changes already exist in the registry, indicating that the changes to be removed do exist. Once this check is passed, the changes specified in the update package 1 are applied to the existing software, and then entries in the registry corresponding to the original changes are removed.

The decryption information section 25 contains information needed for the decryption of the update package body 3.

The body 3 contains the update itself. It may be compressed and it may be encrypted using any known method. It contains one or more payloads 31 ,32. The payload 31 ,32 contains information relating to the changes to be made in the target software. Each payload 31 , 32 contains one or more changes that are all intended to be installed the same way. Each payload 31,32 within the body 3 may be directed at a different installation method, such as a "patch install", an "application install", a "device driver install" or a "baseband processor change install". The payload ID 311, 321 is a unique identifier for the payload 31 , 32, and is used for management purposes, rollback and recovery,

The plug-in ID 312, 322 identifies which installation method should be used for the payload 31 , 32. The plug-in ID 312, 322 identifies which software module (called a plug-in) will install or uninstall the payload 31, 32. A particular plug-in may contain software to make changes to a program or flash memory, or may contain software to pass the payload to another processor in the system through an inter- processor message-passing mechanism. Thus, all changes in a specific payload

31 , 32 are handled by the same install/uninstall method.

The group ID 313, 323 is a number assigned to one or more payloads 31 ,

32. If an irrecoverable error occurs, all changes made in the failed payloads 31 , 32 and all changes due to other payloads 31 , 32 with the same group ID 313, 323 that have already been applied must be undone. In the case of an error during install, all such changes must be uninstalled. In the case of an error during an uninstall, all such changes must also be undone. In both cases the modified code and the registry reverts back to their original states. The failure does not affect payloads 31 , 32 of any other group.

The sequence ID 314, 324 expresses the order in which the payloads 31 , 32 should be installed. In general, the installation of a payload 31 ,32 with a sequence ID 314, 324 must completely finish before the payload 31 , 32 with a later sequence ID 314, 324 can be started. Payloads 31 , 32 with the same sequence ID 314, 324 may be installed at the same time (within the limits of a processing system) provided they have a different plug-in ID 312, 322. This situation is advantageous when changes must be applied to several processors in the system, where each processor can be installing changes simultaneously. The sequence of an installation is followed irrespective of the payload groups present, unless an error occurs in which case the rollback operation is only applied to payloads 31 , 32 in the same group as the failed payload 31 ,32. In this situation, the rollback will occur in reverse sequence order. The values used for the sequence ID can be chosen by bilateral agreement between the creator/sender of the update package and the target system installing (or uninstalling) the update package. The sequence ID may be a numeric value, either lowest first or highest first, or may be a value representing the priority (e.g. high_r medium or low) of the payload. Similarly to the group ID , the sequence ID can have a null value.

The payload command 315, 325 has the same function as the update package command but only applies to the payload in which it is contained. The payload command 315, 325 thus effectively overrides the default of the update package command. Alternatively, the payload command may have a null value.

The payload data 316, 326 contains explicit information needed to implement specific changes, including address information and replacement data. The update data may be raw data to directly overwrite some or all of the existing program, or it may be compressed or encoded using one of a number of algorithms.

In this embodiment, the digest 4 contains error-checking information used to verify that the update package 1 has not been modified since the digest 4 was created. It is calculated from the header 2 and body 3 sections of the update package 1. The digest 4 may contain a fixed-length value encoded using a oneway algorithm such as an MD5 hashing algorithm, also known as a cyclic redundancy check.

Each payload 31 , 32 may be handled and installed differently, based on information contained in the payload 31, 32 itself. A software modification or repair invariably consists of more than one change. Typically, several changes are necessary to effect the update. In reference to figure 1, in an embedded wireless device 8 which consists of an application processor 9 and one or more secondary processors 13 and programmable logic 14 for baseband functions, there may be changes that are to be applied to the application processor 9, one or more of the secondary processors 13 and perhaps to the programable logic 14. Installation of a change is different for each of these, and must be handled in different ways.

For example, a modification to the software of the application processor 9 can involve one or more changes to the program memory of the application processor 9, with each change contained in the payload data 316,326 of one or more payloads 31 ,32. The changes can typically be done by the application processor 9 itself. A modification to a secondary processor 9 software is handled in a different way. As with changes done uniquely by the application processor 9, all the changes necessary will be contained in the payload data 316, 326 of one or more payloads 31 , 32. The application processor 9 can pass the payload data 316,326 through a message-passing mechanism to the secondary processor 13. The secondary processor 13 can receive this and modify its own program memory before notifying the application processor 9 through the message-passing mechanism that the modification is complete. An error can be notified the same way.

In both cases, the application processor 9 makes the decision as to how to handle the payload 31 ,32 (either by directly installing the changes or by passing the payload data 316,326 to the message passing mechanism), using the payload ID 311 , 321 to determine which to do, as illustrated in figure 2.

Referring now to figure 2, and by way of example, installation scheme "A" may be algorithms for the application processor to directly install a series of patches. Installation scheme "B" may be a message passing system to a baseband processor. Installation scheme "C" may store the changes and invoke the bootloader to install operating system patches.

Referring again to figure 1 , in use, the software server 6 is connected to a radio transceiver 7 by any suitable means (e.g. network connection). The radio transceiver 7 may communicate with the at least one embedded wireless device 8 by means of any standard wireless multiple access network (e.g. GSM).

To effect an upgrade, the software server 6 prepares an update package 1 according to the present invention which it then sends to the radio transceiver 7 for transmission to the embedded wireless device 8. The radio transceiver 7 transmits the update package format to the embedded wireless device 8. The embedded wireless device then receives the update package 1 through a transmitter/receiver portion 12 and sends the update package 1 to the application processor 9. The plug-in ID 312, 322 in each payload is then used to determine which plug-in is to be used to install the contents of each payload 31 ,32.

The majority of software installations comprise a single payload 31 , 32 with multiple individual changes. However, certain situations may require a more complex procedure involving multiple payloads, where the order of installation is important and where changes are linked so that either all must be present, or all must be removed. This situation occurs when a particular update requires changes to the software of several processors in the system 8.

By way of example, where the update package contains one single payload. In this situation, the group ID and sequence ID have no effect on the processing of the update package and can therefore have null values.

If the payload 31, 32 contains a payload command 315, 316 which does not have a null value, that command will determine whether the changes in the payload 31 , 32 are treated as the installation of new changes or removal of existing changes that were installed in a previous install. If the payload 31 , 32 contains a null payload command 315, 325, then the update package command 24 determines how the payload 31 , 32 is treated.

The changes contained in the payload 31, 32 are installed or uninstalled as one operation. If the installation or uninstallation fails and cannot be resumed all the changes in the payload 31 , 32 that have already been processed, are reversed.

As a further example, where the update package 1 contains a number of payloads 31, 32, with group ID 313, 323 and sequence ID 314, 324 either not being used or being of a null value.

The changes contained in each payload 31 , 32 are installed as one operation, and the payloads 31 , 32 are installed in any order. The installation function may install them in the order presented in the update package 1, or may examine the contents of the payloads 31, 32 and decide, for efficiency or other reasons, to install them in a different order.

If the installation or uninstallation of a particular change fails and cannot be resumed, then that change and all other completed changes in that payload 31 , 32 are removed. The changes from other completed payloads 31 , 32 of this update package 1 are not removed. Following removal of the failed payload 31, 32, the remaining uncompleted payloads 31 , 32 are installed. Subsequent errors are handled in the same way.

As a further example, where the update package 1 contains a number of payloads with changes for more than one processing element, with the group ID 313, 323 and sequence ID 314, 324 not being used or being of null value. However, the target system 8 is made up of more than one processing element, and the payloads 31, 32 contain changes for more than one of these processing elements, with the condition that all changes in a particular payload 31 , 32 are all directed at the same processor. In this case, changes in each payload are installed as one operation and the payloads are installed in any order. If an unrecoverable error occurs during the installation or uninstallation of a payload, all the changes already completed from that payload are removed, as in previous examples. The remaining payloads are then completed.

As a further example, where the update package 1 contains a number of payloads 31 , 32 some with one group ID 313, 323 and the remainder with other group IDS 313, 323. The sequence ID 314, 324 is not used or is of null value.

The installation of this type of update package 1 is the same as that described in the case of a simple multi-payload update package, where all payloads 31 , 32 are installed in any order. However, the error response is different, as follows.

If the installation of a particular change fails and cannot be continued, then that change and all other completed changes in that payload 31 , 32 are removed as in the case of a simple multi-payload update package, but in addition the changes from all other completed payloads 31 , 32 of this update package with the same group ID 313, 323 are also removed. Following this removal, the remaining payloads 31 , 32 of the other groups are installed or uninstalled according to the appropriate command. Again, if another unrecoverable error occurs while installing or uninstalling these payloads, all completed payloads 31, 32 of that group are removed.

In reference to Figure 4, a multi-payload with sequencing update package, contains a number of payloads 40, 41 , 42, all of which contain sequence IDs 314, 324 (in this case Seq = 1, Seq = 2 and Seq = 3) and all of which have null valued group IDs 313, 323 or, in the example of Figure 4, an identical group ID 313, 323 (i.e. Group = A).

The installation of this update package 1 is similar to that described in the example of a simple multi-payload update package, except that the payloads 40, 41 , 42 are installed in the order defined by the sequence IDs 314, 324. If two or more payloads 40, 41 , 42 have the same sequence ID 314, 324, they can then be installed in any order relative to each other.

In this example, the first payload to be installed will be payload 40, then payload 41 will be installed and finally payload 42 will be installed. If the installation or uninstallation of a particular change fails and cannot be continued, then that change and all other completed changes in that payload are removed as in the case of a simple multi-payload update package. For example, were there to be an irrecoverable failure in the installation or uninstallation of payload 42, every completed change in payload 42 would first be uninstalled. Then, the changes of payload 42 would be removed followed by the changes of payload 40.

Processed according to the appropriate command.

If the update package 31 , 32 contains an uninstall command, the payloads 31 , 32 are still handled in the order specified by the sequence ID 314, 324.

As a further example, where the update package contains multi-payloads 31, 32 using grouping and sequencing, the update package 31 , 32 contains a number of payloads, some with one group ID 313, 323, and the remainder with another. All have sequence IDs 314, 324. Two methods may be adopted to install (or uninstall) this type of update package 1 , the method being chosen by bilateral agreement between the creator/sender of the update package 1 and the target system 8.

The first method is that the payloads 31 , 32 are processed in the order determined by the sequence ID 314, 324, and the group ID 313, 323 is ignored. However, if a particular change within a payload 31 , 32 fails, then that change and all other changes in that payload 31 , 32 are undone, and then all payloads 31 , 32 in the same group are removed using the reverse sequence from the sequence ID 314, 324. Following this, the remaining payloads 31 , 32 of the other groups are processed in the order specified by the sequence ID 314, 324.

An example of the first method of installing multi-payload update packages with grouping and sequencing can be understood in reference to Figure 5, where, payload 43 would be installed first in that it has the lowest sequence number. Then, payload 44 would be installed, followed by 45, 46 and 47, respectively. Were there to be an irrecoverable failure during the installation of payload 46, all completed changes in payload 46 would be removed first, then, the changes of payload 45 would be removed, followed by 43. Then, payload 47 would be installed, thereby completing a successful installation of payloads having a Group ID equal to "B".

A further example of the first method of installing multi-payload update packages with grouping and sequencing can be understood in reference to Figure 6, where, payload 48 would be installed first, followed by payload 49, payload 50, payload 51 , payload 55, payload 52, payload 53 and payload 54 respectively. Were there to be an irrecoverable failure during the installation of payload 52, all completed changes in payload -52.would be removed first, then, the changes of payload 55 would be removed followed by payload 49. Then, payloads 53 and 54 would be installed in sequence, thereby completing a successful installation of payloads having a Group ID equal to "A" or "C".

In the second method, the payloads 31, 32 of one group are installed in the order determined by the sequence ID 314, 324, followed by the next group, and so on until all payloads 31, 32 of every group are installed. The ordering of the groups is unspecified. If a particular change within a payload 31, 32 fails, then all changes of that payload 31 , 32, and then all payloads 31 , 32 of that group in reverse order, are removed. The installation then proceeds with the next group.

An example of the second method of installing multi-payload update packages with grouping and sequencing can be understood in reference to Figure

5, where, payload 43 would be installed first. Then, payload 45 would be installed, followed by 46, 44 and 47, respectively. Were there to be an irrecoverable failure during the installation of payload 46, all completed changes in payload 46 would be remobed first, then, the changes of payload 45 would be removed, followed by payload 43. Then, payloads 44 and 47 would be installed in sequence, thereby completing a successful installation of payloads having a Group ID equal to "B".

A further example of the second method of installing multi-payload update packages with grouping and sequencing can be understood in reference to Figure

6, where, payload 48 would be installed first, followed by payload 50, payload 51 , payload 49, payload 55, payload 52, payload 53 and payload 54 respectively. Were there to be an irrecoverable failure during the installation of payload 52, all completed changes in payload 52 would be removed first, then, the changes of payload 55 would be removed followed by payload 49. Then, payloads 53 and 54 would be installed in sequence, thereby completing a successful installation of payloads having a Group ID equal to "A" or "C".

As a further example, where a payloads 31 , 32 contains install/uninstall commands with no groups or sequencing, the update package 1 contains a number of payloads, with null valued group IDs 313, 323 and sequence ID 314, 324 present. However, the payloads 31 , 32 contain a mixture of install payload commands 315, 325, uninstall payload command 315, 325 and null valued payload command 315, 325.

The changes contained in each payload 31, 32 are installed or uninstalled as one operation as determined by the payload command 315, 325, or by the update package command 24 in the case where no payload command 315, 325 is present. The payloads 31, 32 are processed in any order. The installation/uninstallation function may process them in the order presented in the update package 1 , or may examine the contents of the payloads 31, 32 and decide, for efficiency or other reasons, to process them in a different order.

If the installation or uninstallation of a particular change fails and cannot be recovered, then that change and all other completed changes in that payload 31 , 32 are reversed. The changes from all other processed payloads 31 , 32 of this update package 1 are not reversed.

Following removal of the failed changes of the payload 31 , 32, the remaining unprocessed payloads 31 , 32 are processed. Subsequent errors are handled in the same way.

As a further example, where the update package 1 contains a number of payloads, some with one group ID 313, 323, and the remainder with another. All have sequence IDs 314, 324. Some payloads 31, 32 have a payload command 315, 325 of "install", others with "uninstall" and some with a null payload command 315, 325.

The processing of this update package 1 generally follows the two schemes described in the case of a multi-payload with grouping and sequencing update package, with the addition that payloads 31, 32 with a payload command 315, 325 of "uninstall" are treated as an uninstallation (i.e. the changes are applied as normal, but the existing registry entry is removed), and payloads 31 , 32 with no payload command 315, 325 are treated using the update package command 24.

If an unrecoverable error occurs for one change in one of the payloads, processing of that payload 31 , 32 does not continue. The changes of this payload 31, 32 that have already been processed are undone (uninstalled if the original action was to install, or re-installed if the original action was to uninstall), and then any payloads 31 , 32 in the same group that have already been processed (either installed or uninstalled) are undone or reversed in the reverse order determined by the sequence ID 314, 324. Processing of the remaining payloads 31 , 32 of other groups is then resumed.

Claims

1. A method of preparing data forming a software update package for transmission to an embedded device, the method comprising the steps of: generating a header containing an install or unJnstall command and package identification information; and generating at least one payload containing data related to at least one change to be applied to target software; wherein the step of generating the or each payload comprises the steps of; generating a plugin ID for identifying the installation method which is to be used for the payload; generating a group ID for identifying one or more payloads with which the payload will be grouped. generating a sequence ID for identifying in which order the at least one payload is to be installed generating a payload command determining whether the payload is used for an installation or an uninstallation.

2. A method of installing the software update package of claim 1 , the method comprising the step of: installing each payload in order of its sequence ID.

3. The method of installing the software update package according to claim 2, wherein, if, during installation of a specific payload, an irrecoverable error occurs, the method further comprises the steps of: uninstalling the completed changes found in the specific payload; uninstalling, in reverse order of their sequence ID, the payloads having the same Group ID as the specific payload; installing, in order of their sequence ID, all remaining payloads which do not share the same Group ID as the specific payload.

4. A method of installing the software update package of claim 1 , the method comprising the step of: installing each payload in order of its Group ID.

5. The method of installing the software update package according to claim 4, wherein, if, during installation of a specific payload, an irrecoverable error occurs, the method further comprises the steps of: uninstalling the completed changes found- in the specific payload; uninstalling each payload which was installed during the installation step and which also has the same Group ID as the specific payload; installing, in order of their sequence ID₁ all remaining payloads which do not share the same Group ID as the specific payload.