An embedded software upgrading method, system and device

Abstract

The embodiment of the application discloses an embedded software upgrading method, system and device. In the embodiment, when the embedded device is upgraded, the target upgrading component information of the current component to be upgraded in the embedded device is determined from the upgrading package rule information, and then the corresponding target upgrading data is downloaded from the storage location information of the target component information and is upgraded, which realizes software adaptation for the hardware of different components of different manufacturers which are compatible with the main chip from the software level without expanding the embedded hardware storage resources (such as RAM and FLASH), avoids the software maintenance and authentication cost caused by defining different models, reduces the cost increase problem caused by hardware expansion, and finally realizes the embedded software upgrading compatible with hardware differences and saving storage resources.

Description

Technical Field

[0001] This application relates to the field of video surveillance, and in particular to an embedded software upgrade method, system, and device. Background Technology

[0002] In embedded device hardware design, the same main chip, such as a CPU, is often compatible with multiple components from different manufacturers and models, such as WiFi devices and sensors. In such cases, it is often necessary to combine the software programs of all the components compatible with the main chip into a single upgrade package.

[0003] When upgrading components, embedded devices obtain the aforementioned upgrade package and store it in storage media such as RAM and FLASH. Then, based on hardware differences, the upgrade data for the corresponding components in the upgrade package is automatically matched and loaded. However, the storage resources of embedded devices, such as RAM and FLASH, are already quite limited. Storing the aforementioned upgrade package, which combines the software programs for each component, in such storage media would significantly waste storage resources and increase costs. Summary of the Invention

[0004] This application discloses an embedded software upgrade method, system, and apparatus to achieve embedded software upgrades that save storage resources while maintaining compatibility with hardware differences.

[0005] This application provides an embedded software upgrade method, which is applied to an embedded device and includes: If an upgrade is determined to be necessary, and the upgrade package rule information required for the current upgrade is not available locally, the upgrade package rule information required for the current upgrade is obtained through a first connection with the upgrade server. The upgrade package rule information records at least the component information of at least two different components compatible with the main chip in the embedded device. The component information includes at least: component identifier and storage location information of the upgrade data corresponding to the component. Through a second connection with the upgrade server, the header data of the upgrade package required for the current upgrade is downloaded. The header data is verified. After the header data passes the verification, the target upgrade component information of the component to be upgraded in the embedded device is determined from the upgrade package rule information. Through the second connection, and based on the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the storage location information. The component to be upgraded is then upgraded based on the target upgrade data.

[0006] This application provides an embedded software upgrade system, the system including an embedded device and an upgrade server; When the embedded device determines that an upgrade is needed, if the upgrade package rule information required for the current upgrade is not available locally, it obtains the required upgrade package rule information through a first connection with the upgrade server. The upgrade package rule information records component information for at least two different components compatible with the main chip in the embedded device. The component information includes at least: a component identifier, the storage location information of the upgrade data corresponding to the component, and... Through a second connection with the upgrade server, the header data of the upgrade package required for the current upgrade is downloaded. The header data is verified. After the header data passes the verification, the target upgrade component information of the component to be upgraded in the embedded device is determined from the upgrade package rule information. Through the second connection, and based on the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the storage location information. The component to be upgraded is upgraded based on the target upgrade data. The upgrade server is used to store upgrade package rule information and upgrade packages. Based on the upgrade request of the embedded device, it returns the upgrade package rule information required for the current upgrade of the embedded device through a first connection, and returns the upgrade data of the currently upgraded component of the embedded device stored in a specified location through a second connection; the specified location refers to the location used to store the upgrade data of the currently upgraded component.

[0007] This application provides an embedded software upgrade device, which is applied to an embedded device and includes: The obtaining unit is configured to, when an upgrade is determined to be required, obtain the upgrade package rule information required for the current upgrade through a first connection with the upgrade server if the upgrade package rule information is not available locally. The upgrade package rule information records at least the component information of at least two different components compatible with the main chip in the embedded device. The component information includes at least: component identifier and storage location information of the upgrade data corresponding to the component. The download unit is configured to download the header data of the upgrade package required for the current upgrade through a second connection with the upgrade server; and, triggered by the processing unit, download the corresponding target upgrade data from the storage location information through the second connection based on the storage location information of the upgrade data in the target component information. The processing unit is used to verify the packet header data. After the packet header data passes the verification, it determines the target upgrade component information of the current component to be upgraded in the embedded device from the upgrade package rule information. It then triggers the download unit to download the corresponding target upgrade data from the storage location information based on the second connection and the storage location information of the upgrade data in the target component information. Based on the target upgrade data, it upgrades the current component to be upgraded.

[0008] This application provides an electronic device, which includes a processor and a memory.

[0009] The memory is used to store machine-executable instructions; The processor is configured to read and execute machine-executable instructions stored in the memory to implement the method described above.

[0010] As can be seen from the above description, in this embodiment, when the embedded device is upgraded, the target upgrade component information of the component to be upgraded in the embedded device is first determined from the upgrade package rule information. Then, according to the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the storage location information and the upgrade is performed. This achieves software adaptation for hardware with the same main chip and compatible with multiple components from different manufacturers without expanding the embedded hardware storage resources (such as RAM and FLASH). This avoids the software maintenance and certification costs caused by defining different models, and reduces the cost increase caused by hardware expansion. Finally, it achieves embedded software upgrade that saves storage resources while being compatible with hardware differences. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0012] Figure 1 A flowchart illustrating the method provided in this application embodiment; Figure 2 This is a diagram of the header data structure provided in an embodiment of this application; Figure 3 This is a schematic diagram of the upgrade package structure provided in an embodiment of this application; Figure 4 The system structure diagram provided for the embodiments of this application; Figure 5 This is a structural diagram of the device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of the device provided in the embodiments of this application. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0014] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0015] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0016] The embedded software upgrade method provided in this application differs fundamentally from the commonly used differential upgrade method. Current differential upgrades primarily perform incremental updates based on the differences between two upgrades, while this application's embodiment creates an upgrade package compatible with multiple hardware differences. During the upgrade process, the device downloads and upgrades from a designated location in the package based on the hardware differences and upgrade package rule information. To enable those skilled in the art to better understand the technical solutions provided in this application's embodiments, and to make the above-mentioned objectives, features, and advantages of this application's embodiments more apparent, the technical solutions in this application's embodiments will be further described in detail below with reference to the accompanying drawings.

[0017] See Figure 1 , Figure 1 This is a flowchart illustrating a method provided in an embodiment of this application. The method is applied to an embedded device. This embedded device may be, for example, a camera, gateway, or router; this embodiment is not specifically limited to these.

[0018] Step 101: If an upgrade is required, and the upgrade package rule information required for the current upgrade does not exist locally, the upgrade package rule information required for the current upgrade is obtained through the first connection with the upgrade server. The upgrade package rule information records the component information of at least two different components that are compatible with the main chip in the embedded device.

[0019] In this embodiment, there are many ways to determine that an upgrade is needed, such as receiving an external instruction, detecting that the expiration time of an existing component upgrade package has arrived, or obtaining the first version information of the embedded device recorded by the upgrade server through a first connection, comparing the obtained first version information with the second version information of the device already recorded locally, and if it is found that the first time point in the first version information is after the second time point in the second version information, then it is determined that an upgrade is needed, etc. This embodiment is not specifically limited.

[0020] In this embodiment, the upgrade package rule information, along with the upgrade package, is pre-deployed to the upgrade server. Based on this, applied to step 101, for any embedded device, when an upgrade is determined to be needed, it requests the upgrade package rule information required for the current upgrade through a first connection with the upgrade server. Here, the first connection can be a long-lived connection between the embedded device and the upgrade server, such as a TCP connection, an HTTPS connection, etc., and this embodiment is not specifically limited to this.

[0021] As an example, the upgrade package rule information records at least the component information of at least two different components compatible with the main chip in the embedded device. Here, the main chip is, for example, a CPU. In applications, the same main chip, such as a CPU, can be compatible with multiple different components, such as communication, WIFI, and sensor components; this embodiment is not specifically limited. Examples of upgrade package rule information will be described below, and will not be elaborated upon here.

[0022] As another embodiment, if it is determined that an upgrade is needed, and the upgrade package rule information has been obtained beforehand, then step 102 is executed directly.

[0023] Step 102: Download the header data of the upgrade package required for the current upgrade through the second connection with the upgrade server, verify the header data, and execute step 103 after the header data passes the verification.

[0024] In this embodiment, when the embedded device obtains the aforementioned upgrade package rule information, it establishes a second connection by interacting with the upgrade server. This second connection can be a short connection such as TCP or HTTPS, and this embodiment is not specifically limited to this.

[0025] After successfully establishing a second connection between the embedded device and the upgrade server, the embedded device executes the steps described in step 102, downloading the header data of the upgrade package required for the current upgrade through the second connection. Optionally, in this embodiment, the embedded device sends a header request (to request the header data of the upgrade package required for the current upgrade) to the upgrade server through the second connection. When the upgrade server receives the header request, it returns the header data of the upgrade package required for the current upgrade through the second connection. This ultimately enables the embedded device to successfully download the header data of the upgrade package required for the current upgrade. Figure 2 An example is shown illustrating the knot in the header data. For example... Figure 2 For example, the header data should include at least the manufacturer identification information, upgrade header checksum, upgrade header length, device type identifier, hash algorithm type, number of upgrade components, and hardware main chip platform checksum.

[0026] After downloading the header data, the embedded device performs verification on the header data as described in step 102. This includes verifying the manufacturer identification information, upgrade header checksum, device type identifier, and hardware main chip platform check bits (identifiers) within the header data. Once the header data passes verification, step 103 is executed. The purpose of verifying the header data here is to pre-verify the legitimacy of the upgrade package required for the current upgrade of the embedded device before downloading the upgrade data in the upgrade package. Only if the upgrade package required for the current upgrade of the embedded device is verified to be legitimate will step 103 be executed.

[0027] Step 103: Determine the target upgrade component information of the current component to be upgraded in the embedded device from the upgrade package rule information, download the corresponding target upgrade data from the storage location information of the target upgrade data through the second connection, and upgrade the current component to be upgraded based on the target upgrade data.

[0028] As an example, the storage location information of the upgrade data is characterized by offset and data length; wherein, offset is used to represent the offset relative to the starting position of the upgrade package, and data length refers to the size of the upgrade data.

[0029] As an example, the storage location information of the upgrade data can also be characterized by a start position and an end position; wherein, the start position is used to indicate the starting position of the upgrade data recorded in the upgrade package, and the end position is used to indicate the ending position of the upgrade data in the upgrade package.

[0030] Based on the above description, as described in step 103, the target upgrade data can be downloaded directly from the storage location information of the upgrade data in the target component information. This ultimately achieves the goal of downloading only the upgrade data required by the component to be upgraded from the specified location in the upgrade package, instead of downloading the entire upgrade package. This achieves compatibility adaptation for some hardware differences at the software level, reduces software maintenance and certification costs, and eliminates the need for expansion in cases of insufficient hardware resources, thus reducing hardware costs.

[0031] This concludes the process. Figure 1 The process is shown below.

[0032] pass Figure 1 As shown in the process, in this embodiment, when the embedded device is upgraded, the target upgrade component information of the component to be upgraded in the embedded device is first determined from the upgrade package rule information. Then, according to the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the storage location information and the upgrade is performed. This achieves software adaptation for hardware with the same main chip and compatible with multiple components from different manufacturers without expanding the embedded hardware storage resources (such as RAM and FLASH). This avoids the software maintenance and certification costs caused by defining different models, and reduces the cost increase caused by hardware expansion. Finally, it achieves embedded software upgrade that saves storage resources while being compatible with hardware differences.

[0033] The rules for the upgrade package are described below: In this embodiment, the upgrade package rule information is deployed to the upgrade server along with the upgrade package. In specific implementations, the upgrade package rule information records component information for at least two different components compatible with the main chip in the embedded device. As an example, this component information includes at least: a component identifier and the storage location information of the upgrade data corresponding to the component. If the storage location information of the upgrade data is represented by an offset and a data length, where the offset represents the offset relative to the starting position of the upgrade package, and the data length refers to the size of the upgrade data, the following example illustrates the upgrade rule information: { “model”: "CS-C8W-1J4WKFL", / / Equipment model identifier "version": "V5.3.8 build 220302", / / Version information "upgradeifno": [ { "name": "app.img", / / Component "num": 2 / / Number of components with differences "value": [ { "name": "app1", / / Component identifier "startoffset": 128, / / offset "size": 1152, / / Data length "checksum": "B0A997691C777528C5884720D0124389" / / Checksum information }, { "name": "app2", "startoffset": 1280, "size": 1152, "checksum": "B0A997691C777528C5884720D0124399" } ] }, { "name": "uImage", "num": 1, "value": [ { "name": "", "startoffset": 2432, "size": 2152, "checksum": "B0A997691C777528C5884720D0124366" } ] } } In the above description, "checksum" such as "B0A997691C777528C5884720D0124366" represents the checksum, which can be identified using hash functions such as SHA256.

[0034] The structure of the upgrade package is described below: As described above, the upgrade package rules information is deployed to the upgrade server along with the upgrade package. The upgrade package mainly includes package header data, at least one component header data, and upgrade data. An upgrade package typically contains one package header data and N component header data. Each component header data contains 1 to K different component structures (also called component difference items), where K and N can be set according to actual needs. For example, each component header data should at least include: component difference item header data for each different component; the component difference item header data should at least include: the component difference item identifier and the storage location information of the corresponding upgrade data. Figure 3 The structure of the upgrade package is illustrated in the example, and will not be described in detail here.

[0035] The upgrade package and upgrade rule information provided in the embodiments of this application have been described above. The following is an extended description of step 103: As an example, in step 103, before upgrading the current component to be upgraded based on the target upgrade data, the downloaded target upgrade data can be further verified for integrity. After successful verification, the target upgrade data is written to a specified partition of the embedded device, such as a partition of FLASH. This example is not specifically limited.

[0036] As an example, in step 103, after upgrading the current component to be upgraded based on the target upgrade data, the obtained upgrade package rule information can be further deleted to save storage resources.

[0037] The methods provided in the embodiments of this application have been described above. The systems and apparatus provided in the embodiments of this application are described below: See Figure 4 , Figure 4 This is a system architecture diagram provided for an embodiment of this application. The system includes an embedded device and an upgrade server.

[0038] Specifically, when an embedded device determines that an upgrade is needed, if the required upgrade package rule information is not available locally, it obtains the required upgrade package rule information through a first connection with the upgrade server. The upgrade package rule information records component information for at least two different components compatible with the main chip in the embedded device. The component information includes at least: a component identifier, the storage location information of the upgrade data corresponding to the component, and... Through a second connection with the upgrade server, the header data of the upgrade package required for the current upgrade is downloaded. The header data is verified. After the header data passes the verification, the target upgrade component information of the component to be upgraded in the embedded device is determined from the upgrade package rule information. Through the second connection, and based on the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the storage location information. The component to be upgraded is upgraded based on the target upgrade data. An upgrade server is used to store upgrade package rule information and upgrade packages. Based on the upgrade request of the embedded device, it returns the upgrade package rule information required for the current upgrade of the embedded device through a first connection, and returns the upgrade data of the currently upgraded components of the embedded device stored in a specified location through a second connection; the specified location refers to the location used to store the upgrade data of the currently upgraded components.

[0039] In this embodiment, the embedded device mainly performs the following functions: Figure 1 The process shown will not be repeated here.

[0040] In this embodiment, the upgrade server stores the upgrade package; the upgrade package includes at least: package header data, at least one component header data, and component upgrade data; Each component header data includes at least: component difference header data for each different component; the component difference header data includes at least: component difference identifier and storage location information of the upgrade data corresponding to the component difference.

[0041] This concludes the process. Figure 4 The system structure is described as shown.

[0042] See Figure 5 , Figure 5 This is a structural diagram of a device provided in an embodiment of this application. The device is applied to an embedded device and includes: The obtaining unit is configured to, when an upgrade is determined to be required, obtain the upgrade package rule information required for the current upgrade through a first connection with the upgrade server if the upgrade package rule information is not available locally. The upgrade package rule information records at least the component information of at least two different components compatible with the main chip in the embedded device. The component information includes at least: component identifier and storage location information of the upgrade data corresponding to the component. The download unit is configured to download the header data of the upgrade package required for the current upgrade through a second connection with the upgrade server; and, triggered by the processing unit, download the corresponding target upgrade data from the storage location information through the second connection based on the storage location information of the upgrade data in the target component information. The processing unit is used to verify the packet header data. After the packet header data passes the verification, it determines the target upgrade component information of the current component to be upgraded in the embedded device from the upgrade package rule information. It then triggers the download unit to download the corresponding target upgrade data from the storage location information based on the second connection and the storage location information of the upgrade data in the target component information. Based on the target upgrade data, it upgrades the current component to be upgraded.

[0043] Optionally, determining that an upgrade is needed includes: The first version information of the embedded device recorded by the upgrade server is obtained through the first connection; Compare the obtained first version information with the second version information of this device that has been recorded locally. If it is found that the first time point in the first version information is after the second time point in the second version information, it is determined that an upgrade is needed.

[0044] Optionally, the upgrade packet header data includes at least: manufacturer identification information, upgrade packet header checksum, device type identifier, and hardware main chip platform identifier; Verification of the upgrade packet header data includes: At least the manufacturer identification information, upgrade header checksum, device type identifier, and hardware main chip platform identifier in the upgrade header data should be verified.

[0045] Optionally, the storage location information of the upgrade data is characterized by an offset and a data length; wherein the offset is used to represent the offset relative to the starting position of the upgrade package, and the data length refers to the size of the upgrade data.

[0046] Optionally, before upgrading the currently upgraded component based on the target upgrade data, the process further includes: The downloaded target upgrade data is verified for integrity. After successful verification, the target upgrade data is written to the designated partition of the embedded device.

[0047] Optionally, after upgrading the currently upgraded component based on the target upgrade data, the process further includes: Delete the obtained upgrade package rule information.

[0048] This concludes the process. Figure 5 Structural description of the device shown.

[0049] Correspondingly, embodiments of this application also provide Figure 5 The hardware structure diagram of the device shown is as follows: Figure 6 As shown, the electronic device can be a device implementing the above-described method. Figure 6As shown, the hardware architecture includes a processor and memory.

[0050] The memory is used to store machine-executable instructions; The processor is configured to read and execute machine-executable instructions stored in the memory to implement the method embodiment shown above.

[0051] As one embodiment, the memory can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, the memory can be volatile memory, non-volatile memory, or similar storage media. Specifically, the memory can be RAM (Random Access Memory), flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0052] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An embedded software upgrade method, characterized in that, The method is applied to an embedded device, and the method includes: If an upgrade is determined to be necessary, and the required upgrade package rule information is not available locally, the required upgrade package rule information is obtained through a first connection with the upgrade server. The upgrade package rule information records at least two different components compatible with the main chip in the embedded device. The component information includes at least: a component identifier and storage location information of the upgrade data corresponding to the component. The storage location information is used to characterize the start and end positions of the upgrade data in the upgrade package. Through a second connection with the upgrade server, the header data of the upgrade package required for the current upgrade is downloaded. The manufacturer identification information, upgrade header checksum, device type identifier, and hardware main chip platform identifier in the header data are verified. After the header data passes the verification, the target component information of the component to be upgraded in the embedded device is determined from the upgrade package rule information. Through the second connection, and according to the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the upgrade package. The component to be upgraded is upgraded based on the target upgrade data. The upgrade package includes at least: header data, at least one component header data, and component upgrade data; wherein, each component header data includes at least: component difference item header data of different components; the component difference item header data includes at least: component difference item identifier and storage location information of the upgrade data corresponding to the component difference item.

2. The method according to claim 1, characterized in that, The determination that an upgrade is needed includes: The first version information of the embedded device recorded by the upgrade server is obtained through the first connection; Compare the obtained first version information with the second version information of this device that has been recorded locally. If it is found that the first time point in the first version information is after the second time point in the second version information, it is determined that an upgrade is needed.

3. The method according to claim 1, characterized in that, The storage location information of the upgrade data is characterized by offset and data length; wherein, the offset is used to represent the offset relative to the starting position of the upgrade package, and the data length refers to the size of the upgrade data.

4. The method according to claim 1, characterized in that, Before upgrading the currently upgraded component based on the target upgrade data, the process further includes: The downloaded target upgrade data is verified for integrity. After successful verification, the target upgrade data is written to the designated partition of the embedded device.

5. The method according to claim 1, characterized in that, After upgrading the currently upgraded component based on the target upgrade data, the process further includes: Delete the obtained upgrade package rule information.

6. An embedded software upgrade system, characterized in that, The system includes embedded devices and an upgrade server; If the embedded device determines that an upgrade is needed, and the upgrade package rule information required for the current upgrade is not available locally, it obtains the upgrade package rule information required for the current upgrade through a first connection with the upgrade server. The upgrade package rule information records component information for at least two different components that are compatible with the main chip in the embedded device; The component information includes at least: a component identifier, and storage location information of the upgrade data corresponding to the component; the storage location information is used to characterize the start and end positions of the upgrade data in the upgrade package; and, Through a second connection with the upgrade server, the header data of the upgrade package required for the current upgrade is downloaded. The manufacturer identification information, upgrade header checksum, device type identifier, and hardware main chip platform identifier in the header data are verified. After the header data passes the verification, the target component information of the component to be upgraded in the embedded device is determined from the upgrade package rule information. Through the second connection, and based on the storage location information of the upgrade data in the target component information, the corresponding target upgrade data is downloaded from the upgrade package. The component to be upgraded is then upgraded based on the target upgrade data. The upgrade package includes at least: header data, at least one component header data, and component upgrade data. Each component header data includes at least: component difference item header data for each different component. The component difference item header data includes at least: a component difference item identifier and the storage location information of the upgrade data corresponding to the component difference item. The upgrade server is used to store upgrade package rule information and upgrade packages. Based on the upgrade request of the embedded device, it returns the upgrade package rule information required for the current upgrade of the embedded device through a first connection, and returns the upgrade data of the currently upgraded component of the embedded device stored in a specified location through a second connection; the specified location refers to the location used to store the upgrade data of the currently upgraded component.

7. An embedded software upgrade device, characterized in that, The device is used in an embedded device, and the device includes: The obtaining unit is configured to, when an upgrade is determined to be needed, obtain the upgrade package rule information required for the current upgrade through a first connection with the upgrade server if the upgrade package rule information is not available locally. The upgrade package rule information records at least the component information of at least two different components compatible with the main chip in the embedded device. The component information includes at least: a component identifier and storage location information of the upgrade data corresponding to the component. The storage location information is used to characterize the start and end positions of the upgrade data in the upgrade package. The download unit is configured to download the header data of the upgrade package required for the current upgrade via a second connection with the upgrade server; and, triggered by the processing unit, download the corresponding target upgrade data from the upgrade package via the second connection and according to the storage location information of the upgrade data in the target component information; the upgrade package includes at least: header data, at least one component header data, and upgrade data of the component; wherein, each component header data includes at least: component difference item header data of each different component; the component difference item header data includes at least: component difference item identifier, and storage location information of the upgrade data corresponding to the component difference item; The processing unit is used to verify the manufacturer identification information, upgrade package header checksum, device type identification, and hardware main chip platform identification in the package header data. After the package header data passes the verification, it determines the target component information of the currently upgraded component in the embedded device from the upgrade package rule information; and triggers the download unit to download the corresponding target upgrade data from the upgrade package through the second connection and according to the storage location information of the upgrade data in the target component information, and upgrades the currently upgraded component based on the target upgrade data.

8. An electronic device, characterized in that, Electronic devices include: processors and memory; The memory is used to store machine-executable instructions; The processor is configured to read and execute machine-executable instructions stored in the memory to implement the method as claimed in any one of claims 1 to 4.

Images