Method for upgrading device, second device and system

Abstract

The application relates to the technical field of network communication, and discloses an upgrading method of a device, a second device and a system. The method is applied to the second device, the second device comprises a first memory, the first memory comprises a dynamic line area, when the first device is connected with the second device, if the first device is an undeployed device, the information of the first device and the information of the second device are acquired, the upgrading information corresponding to the first device is constructed based on the information of the first device and the information of the second device, and the upgrading information is stored in the dynamic line area. When the first device needs to be upgraded, the upgrading information is acquired from the dynamic line area, and the first device is upgraded based on the upgrading information. Through the design of the dynamic line area, the system can automatically identify, learn and create an upgrading path for a newly-accessed heterogeneous device, the expansibility of the device is improved, and the upgrading efficiency of the device is improved.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method for upgrading a device, a second device, and a system. Background Technology

[0002] Currently, the main method for upgrading device firmware is to remotely update the device firmware through OTA (Over-The-Air) technology. The principle is mainly based on a partition structure, including a BOOT partition, a main program partition (including A / B sub-partitions), and a backup partition. During the upgrade, the new firmware is first written to the sub-partition, and after the BOOT partition verifies its legality, it is marked as a bootable partition. If the upgrade fails, the BOOT partition immediately loads the old firmware from the main partition or the backup partition.

[0003] However, the BOOT area only supports firmware updates for the current model. When a new device is released, older devices may not be compatible with cross-generational device upgrades due to a lack of adaptation logic. Furthermore, when adding new devices or making them compatible with new lower-level sub-devices, the BOOT code needs to be modified or the bootloader needs to be re-flashed, resulting in firmware redundancy and reducing the system's scalability. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a device upgrade method, a second device, and a system, which can improve the scalability of the device and thus increase the efficiency of device upgrades.

[0005] To address the aforementioned technical problems, the embodiments of this application provide the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a device upgrade method applied to a second device, the second device including a first memory, the first memory including a dynamic circuit area, the method including:

[0007] When the first device connects to the second device, if the first device is an undeployed device, then the information of the first device and the information of the second device are obtained.

[0008] Based on the information of the first device and the information of the second device, upgrade information corresponding to the first device is constructed and stored in the dynamic line area;

[0009] When the first device needs to be upgraded, upgrade information is obtained from the dynamic line area, and the first device is upgraded based on the upgrade information.

[0010] In some embodiments, upgrade information corresponding to the first device is constructed based on information from the first device and information from the second device, including:

[0011] Define an array of structures;

[0012] Fill the information of the first device and the information of the second device into a structure array to obtain the upgrade information corresponding to the first device, where the upgrade information corresponding to the first device includes a structure array.

[0013] In some embodiments, the structure array includes at least one of the following: the sender of the upgrade file, the receiver of the upgrade file, the communication interface type, the protocol type, the chip firmware type, the communication target address, the timeout period, and the number of retransmissions.

[0014] The communication interface types include at least one of the following: CAN interface, SPI interface, SCI interface, and USB interface.

[0015] In some embodiments, upgrading the first device based on upgrade information includes:

[0016] Parse the upgrade information obtained from the dynamic line area to obtain the transmission path configuration;

[0017] Obtain the upgrade file from the sender of the upgrade file, and send the upgrade file to the first device based on the transmission path configuration;

[0018] The upgrade file will overwrite the old version file on the first device to upgrade the first device.

[0019] In some embodiments, the first memory includes a static line area for storing preset upgrade information. When the first device is connected to the second device, the method further includes:

[0020] If the first device is a deployed device, then when the first device needs to be upgraded, the preset upgrade information is obtained from the static line area;

[0021] Based on the preset upgrade information, the firmware of the first device is upgraded.

[0022] In some embodiments, the first memory further includes:

[0023] The boot sector is used to store the system initialization program and the path decision program. When the path decision program is started, it determines the upgrade path of the first device.

[0024] The application area is used to store applications;

[0025] Backup area, used to store older versions of files.

[0026] In some embodiments, when firmware is added to the first device, the method further includes:

[0027] Get information about the new firmware;

[0028] The information of the new firmware is filled into the structure array to obtain the upgrade information corresponding to the new firmware, and the upgrade information corresponding to the new firmware is stored in the dynamic line area.

[0029] When upgrading a new firmware, the upgrade information corresponding to the new firmware is obtained from the dynamic line area, and the new firmware is upgraded based on the upgrade information corresponding to the new firmware.

[0030] In some embodiments, the method further includes:

[0031] If the first device upgrade is successful, then update the status of the first device;

[0032] If the first device upgrade fails, the old version file is retrieved from the backup area to restore the firmware of the first device based on the old version file.

[0033] Secondly, embodiments of this application provide a second device, comprising:

[0034] At least one processor; and,

[0035] A second memory communicatively connected to at least one processor; wherein,

[0036] The second memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the method as described in the first aspect.

[0037] Thirdly, embodiments of this application provide a device upgrade system, including:

[0038] Multiple first devices;

[0039] The server is used to store the upgrade files corresponding to the first device;

[0040] The second device is a communication connection server, used to establish a communication connection with the first device, obtain the upgrade file corresponding to the first device from the server, and send the upgrade file to the first device.

[0041] The beneficial effects of the embodiments of this application are as follows: Unlike the prior art, the embodiments of this application provide a device upgrade method. This method is applied to a second device, which includes a first memory and a dynamic line area. When the first device is connected to the second device, if the first device is not deployed, information of the first device and information of the second device are obtained. Based on the information of the first device and the second device, upgrade information corresponding to the first device is constructed and stored in the dynamic line area. When the first device needs to be upgraded, the upgrade information is obtained from the dynamic line area, and the first device is upgraded based on the upgrade information. Through the dynamic line area and the standardized configuration structure, the system can automatically identify, learn, and create upgrade paths for newly connected heterogeneous devices, thereby improving the scalability of the device and improving the upgrade efficiency of the device. Attached Figure Description

[0042] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0043] Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application;

[0044] Figure 2 This is a schematic flowchart of a device upgrade method provided in an embodiment of this application;

[0045] Figure 3 yes Figure 2 A detailed flowchart of step S204 in the process;

[0046] Figure 4 yes Figure 2 A detailed flowchart of step S206 in the process;

[0047] Figure 5 This is a schematic diagram of a process for updating upgrade information in a dynamic line area, provided in an embodiment of this application.

[0048] Figure 6 This is a schematic diagram of the overall process of a device upgrade method provided in an embodiment of this application;

[0049] Figure 7 This is a schematic diagram of the structure of an upgrade system for a device provided in an embodiment of this application;

[0050] Figure 8 This is a schematic diagram of the structure of an equipment upgrade device provided in an embodiment of this application;

[0051] Figure 9This is a schematic diagram of the structure of a second device provided in an embodiment of this application.

[0052] Explanation of icon numbers:

[0053] Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. In addition, the terms "first" and "second" used in this application do not limit the data, but only distinguish the same or similar items with basically the same function and effect.

[0056] Before introducing the embodiments of this application, a brief introduction will be given to the device upgrade methods known to the inventors of this application, so as to facilitate the understanding of the embodiments of this application later.

[0057] Currently, devices typically contain multiple storage partitions, namely the BOOT partition, the main program partition, and the backup partition. During an upgrade, the bootloader obtained from the BOOT partition completes system initialization, and the device is upgraded based on the upgrade strategy in the BOOT partition. However, the upgrade strategy is usually fixed in the BOOT partition. When a new device is released or a device needs to be upgraded across generations, the BOOT code needs to be modified and the bootloader needs to be re-flashed to be compatible with the new device, which reduces the scalability of the system.

[0058] To address the aforementioned issues, this application provides a device upgrade method. When a first device connects to a second device, if the first device is not deployed, information about both the first and second devices is obtained. Based on this information, upgrade information corresponding to the first device is constructed and stored in a dynamic line area. When the first device needs an upgrade, the upgrade information is retrieved from the dynamic line area, and the first device is upgraded based on this information. By reserving a dynamic line area to store upgrade information, rapid adaptation to undeployed devices is achieved, improving device scalability and upgrade efficiency.

[0059] The technical solution of this application is described in detail below with reference to the accompanying drawings:

[0060] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application.

[0061] like Figure 1 As shown, the application environment 100 includes a server 10, multiple first devices 20, and second devices 30. The server 10 is connected to the first devices 20 and second devices 30 through a wireless network or a wired network. The wireless network includes 2G, 3G, 4G, 5G, wireless LAN, Bluetooth, and other wireless networks, while the wired network includes serial cables, network cables, and other wired networks.

[0062] In this embodiment of the application, server 10 is used to store upgrade files corresponding to first device 20, and second device 30 is used to establish communication connections with multiple first devices 20. When first device 20 initiates an upgrade request, second device 30 obtains the upgrade file corresponding to first device 20 from server 10 and sends the upgrade file corresponding to first device 20 to first device 20. First device 20 upgrades the firmware in first device 20 based on the upgrade file.

[0063] In this embodiment, server 10 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The first device 20 includes, but is not limited to, battery packs, etc., and the second device 30 includes, but is not limited to, energy storage devices, including, but not limited to, battery energy storage systems, energy storage containers, energy storage power station management systems, etc.

[0064] Please see Figure 2 , Figure 2 This is a schematic flowchart of a device upgrade method provided in an embodiment of this application.

[0065] The upgrade method of the device is applied to the second device. Specifically, the main body executing the upgrade method of the device is one or at least two processors of the second device.

[0066] like Figure 2 As shown, the upgrade method for this device includes:

[0067] Step S201: Establish a communication connection with the first device.

[0068] In this embodiment, the first device may be a battery pack or other device with firmware, which is low-level software embedded in the hardware and responsible for the device's operating instructions and control logic. The second device includes energy storage devices, which serve as the superior device of the first device and are used to support firmware upgrades of the first device.

[0069] Specifically, the second device can obtain the upgrade files required by the first device from the server and transmit the upgrade files to the first device, thereby completing the firmware over-the-air (OTA) upgrade.

[0070] To improve the efficiency of subsequent upgrades, a communication connection is pre-established between the first device and the second device in this embodiment to form a stable data transmission channel. The second device can connect to multiple first devices simultaneously, enabling batch OTA upgrades for multiple devices.

[0071] In another embodiment, the first device can also act as the parent node of its subordinate devices, undertaking similar upgrade scheduling functions. That is, the first device can obtain the corresponding upgrade file from the second device or server and forward it to its connected subordinate devices to assist the subordinate devices in completing firmware upgrades.

[0072] Step S202: Determine whether the first device is an undeployed device.

[0073] Specifically, after the first device and the second device establish a communication connection, it is determined whether the first device is an undeployed device. If the first device is determined to be an undeployed device, the process jumps to step S203. If the first device is determined to be a deployed device, the process jumps to step S207.

[0074] In this embodiment of the application, the second device receives an information acquisition request from the first device. After receiving the information acquisition request, the second device queries information related to the first device. If information related to the first device is found, the second device determines that the first device is a deployed device and can directly return the information to the first device. If no information related to the first device is found, the second device determines that the first device is an undeployed device and sends feedback information indicating that the information acquisition failed to the first device. The information related to the first device includes the deployment configuration, adaptation protocol, historical upgrade records, etc. of the first device.

[0075] Step S203: Obtain information about the first device and information about the second device.

[0076] Specifically, if the first device is determined to be an undeployed device, then the information of the first device and the information of the second device are obtained. The information of the first device includes the protocol type, firmware type, identifier, preset firmware write address, and current firmware version of the first device. The information of the second device includes the protocol type, currently used data transmission channel, data transmission timeout, and retransmission threshold of the second device.

[0077] Step S204: Based on the information of the first device and the information of the second device, construct the upgrade information corresponding to the first device and store the upgrade information in the dynamic line area.

[0078] In this embodiment, the second device includes a first memory, which includes a dynamic circuit area for storing upgrade information corresponding to the first device. The upgrade information includes a structure array, which includes at least one of the following: the sender of the upgrade file, the receiver of the upgrade file, the communication interface type, the protocol type, the chip firmware type, the communication target address, the timeout period, and the number of retransmissions. The communication interface type includes at least one of the following: CAN interface, SPI interface, SCI interface, and USB interface. The protocol type includes at least one of the following: SPI protocol, SCI protocol, USB protocol, TCP / IP protocol, and UART protocol.

[0079] In this embodiment of the application, the first memory includes flash memory.

[0080] In this embodiment of the application, after obtaining the information of the first device and the information of the second device, the information of the first device and the information of the second device are standardized to obtain the processed information of the first device and the processed information of the second device. Macro functions corresponding to the first device and the second device are defined. The processed information of the first device is written into the macro function corresponding to the first device, and the processed information of the second device is written into the macro function corresponding to the second device.

[0081] Specifically, a structure array is defined, and the structure data is initialized through a macro function to fill the structure array with the information of the first device and the second device to obtain the upgrade information corresponding to the first device, and the upgrade information of the first device is stored in the dynamic line area.

[0082] In this embodiment, the macro function is a structure initializer used to initialize and assign values ​​to members in a structure array in batches. For example, if the current structure array is a structure array from the CAN bus, the TO_CAN_BROADCAST macro function is defined to simplify the structure configuration of the CAN bus. This macro accepts multiple configuration parameters (message identifier, timeout, firmware type, CAN index, protocol type, number of repetitions, etc.) and directly assigns values ​​to specific members of the structure array Param when expanded. For example, after calling this macro, Param[0] is set to the E_TO_CAN_BROADCAST enumeration value, and Param[4] and Param[5] are assigned the CanIndex and ProtocolType parameters respectively, thereby quickly completing the initialization configuration of CAN communication.

[0083] By structurally integrating the interface, protocol, address, and other communication parameters of the second device and its connected downstream devices, a usable, parameterized upgrade data transmission path is constructed. This ensures that undeployed downstream devices also have a standardized transmission path for subsequent upgrade file transfers, and upgrades can be performed based on this configuration. This improves compatibility and deployment efficiency for new devices, enables plug-and-play upgrade preparation, and provides an underlying configuration framework for unified OTA upgrades in heterogeneous device hybrid networking environments.

[0084] Please see Figure 3 , Figure 3 yes Figure 2 A detailed flowchart of step S204 is shown.

[0085] like Figure 3 As shown, step S204 includes:

[0086] Step S241: Define a structure array.

[0087] In this embodiment of the application, a standardized structure array is defined to store the specific upgrade information of the first device connected to the second device. When the first device needs to be upgraded, the upgrade information can be quickly identified through the structure array to determine the upgrade path of the first device, which facilitates the subsequent transmission of upgrade files.

[0088] Specifically, based on the first device information and the second device information, the fields of the structure array are determined to obtain the structure array.

[0089] Specifically, once a communication connection is established between the first device and the second device, and it is determined that the first device is an undeployed device, the communication parameters between the first and second devices and the upgrade control parameters of the first device are obtained based on the communication connection between the devices. For example, the communication parameters include the communication interface between the first and second devices, the communication protocol type, and the node identifier of the first device. The upgrade control parameters include the upgrade firmware type of the first device (such as ARM, DSP, etc.), timeout time, number of retransmissions, and whether ACK is required. The communication-related parameters and upgrade-related parameters are organized to obtain multiple fields, and the type of each field is determined to obtain a structure array, which includes multiple fields.

[0090] For example, an array of structures is defined for CAN bus communication configuration. The members of the structure include: dev_sn (device unique identifier), chip_type (chip type), Interface_Type (communication interface type), and firmware_ver (firmware version).

[0091] Step S242: Fill the information of the first device and the second device into the structure array to obtain the upgrade information corresponding to the first device.

[0092] Specifically, a macro function is used to fill the information of the first device and the second device into a structure array to obtain the upgrade information corresponding to the first device. Then, a preset function is used to write the upgrade information corresponding to the first device into the dynamic line area of ​​the second device, thus constructing a specific transmission path to facilitate subsequent upgrade file transmission based on this upgrade information. For example, the preset function is WriteFlash().

[0093] For example, an array of structures is defined for CAN bus communication configuration. The members of this structure include: `dev_sn` (device unique identifier), `chip_type` (chip type), `Interface_Type` (communication interface type), and `firmware_ver` (firmware version). The elements of the structure array are initialized using macro functions to achieve the following configuration:

[0094] Assign the value "001" to the dev_sn field.

[0095] Assign the value "ARM" to the chip_type field.

[0096] Set the Interface_Type field to "CAN".

[0097] The firmware_ver field is assigned the value "V1.0.0". Subsequently, the second device, based on this transmission path configuration, transmits the upgrade file to the first device, enabling it to perform an upgrade based on the received upgrade file.

[0098] In this embodiment, parameterized macro configuration encapsulates upgrade information through a structure array, replacing the traditional hard-coding method. This improves the flexibility of system configuration. When the communication protocol or interface of the first or second device changes, the new device type, communication method, or upgrade requirements can be quickly adapted by adjusting the parameters of the macro function or adding a new macro definition. Furthermore, the standardized macro definition unifies the configuration logic of upgrade information, avoids redundant development, improves code reusability and subsequent maintenance efficiency, and reduces configuration errors caused by hard coding.

[0099] Step S205: Determine whether the first device needs to be upgraded.

[0100] Specifically, the current firmware version number and the latest version number of the first device are compared to determine whether the first device needs to be upgraded. If the current firmware version number and the latest version number of the first device are not the same, it is determined that the first device needs to be upgraded, and the process jumps to step S206. If the current firmware version number and the latest version number of the first device are the same, it is determined that the first device does not need to be upgraded, and the process jumps to step S209.

[0101] Step S206: Obtain upgrade information from the dynamic line area, and upgrade the first device based on the upgrade information.

[0102] Specifically, when it is determined that the first device needs to be upgraded, upgrade information is obtained from the dynamic line area, and the first device is upgraded based on the upgrade information.

[0103] Please see Figure 4 , Figure 4 yes Figure 2 A detailed flowchart of step S206 is shown.

[0104] like Figure 4 As shown, step S206 includes:

[0105] Step S261: Parse the upgrade information obtained from the dynamic line area and obtain the transmission path configuration.

[0106] In this embodiment of the application, the upgrade information obtained from the dynamic line area includes a structure array, which includes the sender of the upgrade file, the receiver of the upgrade file, the communication interface type, the protocol type, the firmware type, the communication target address, the timeout time, and the number of retransmissions.

[0107] Specifically, the second device obtains upgrade information from the dynamic line area, parses and obtains the sender (server address), receiver (first device identifier), communication interface (such as CAN1), protocol type (such as CAN), target address (first device communication address, such as 0x0001), timeout (such as 5ms) of the upgrade file, and executes subsequent upgrade file transmission based on this transmission path configuration.

[0108] Step S262: Obtain the upgrade file from the sender of the upgrade file, and send the upgrade file to the first device based on the transmission path configuration.

[0109] In this embodiment, the second device actively initiates an upgrade request to the upgrade file sending end, obtains the upgrade file of the first device, and sends the upgrade file to the first device through the transmission path.

[0110] Specifically, after receiving the upgrade request from the first device, the second device proactively initiates a request to the server to obtain the upgrade file for the first device. Based on the request, the server sends the upgrade file to the second device. After receiving the upgrade file, the second device transmits the upgrade file to the first device through the transmission path parsed from the upgrade information.

[0111] In another embodiment, the second device responds to the upgrade notification actively pushed by the upgrade file sender, receives the upgrade file transmitted by the server, and sends the upgrade file to the first device based on the transmission path.

[0112] Specifically, triggered by an external event, the server proactively sends an upgrade notification to the second device. The second device responds to the upgrade notification and receives the upgrade file from the first device. After receiving the file, it transmits it to the first device via the transmission path parsed from the upgrade information.

[0113] Step S263: Upgrade the first device by overwriting the old version file with the upgrade file.

[0114] In this application implementation, the first device includes a cache space and an application area. The cache space is used to temporarily cache information, and the application area is used to store applications, including old version files.

[0115] Specifically, after receiving the upgrade file, the first device caches the upgrade file in the cache space and verifies the upgrade file. If the verification passes, the old version file of the first device in the application area is erased, and the upgrade file received by the first device is written to the application area to overwrite the old version file of the first device. The first device is then restarted to load the upgrade file in the application area to complete the upgrade of the first device.

[0116] Whether the upgrade file is requested by the second device or actively distributed by the server, after obtaining the upgrade file from the first device, the second device will transmit the upgrade file to the first device based on the transmission path parsed from the upgrade information obtained from the dynamic line area. That is, regardless of the source of the upgrade file, the subsequent transmission, verification, and activation processes are strictly driven by the same standardized configuration (the structure in the dynamic line area), ensuring consistency and reliability in the execution process. This guarantees the system's ability to centrally distribute tasks, facilitating large-scale, planned device firmware management.

[0117] Step S207: When the first device needs to be upgraded, obtain the preset upgrade information from the static line area.

[0118] In this embodiment, the first memory of the second device further includes a static line area, which is used to store preset upgrade information. The preset upgrade information includes the sender of the upgrade file, a preset communication interface type, a preset protocol type, a timeout period, a number of retransmissions, firmware type, and a communication target address. The preset communication interface type includes CAN interface, SPI interface, SCI interface, USB interface, etc., and the preset protocol type includes SPI protocol, SCI protocol, USB protocol, TCP / IP protocol, UART protocol, etc.

[0119] In this embodiment, the preset upgrade information in the static line area is the predefined, standard equipment upgrade information of the second device. It is either fixed before the second device leaves the factory or uniformly written during the initialization of the second device. When the second device is connected to the deployed first device, the preset upgrade information can be directly obtained from the static line area for upgrading.

[0120] Specifically, if the first device is determined to be a deployed device, when the first device needs to be upgraded, the preset upgrade information is directly obtained from the static line area, its transmission path is parsed, and the upgrade file is transmitted to the first device.

[0121] Step S208: Upgrade the firmware of the first device based on the preset upgrade information.

[0122] Specifically, the first device communicates with the sender of the upgrade file based on a preset communication interface and a preset protocol to send an upgrade request to the second device. After receiving the request, the second device sends an upgrade file retrieval request to the server to obtain the upgrade file corresponding to the firmware type of the first device, and sends the upgrade file to the first device based on the communication target address. The first device receives the upgrade file and performs an upgrade based on the upgrade file. The upgrade file retrieval request includes firmware type, communication target address, etc.

[0123] As a dual-zone collaborative design, the static line zone stores predefined, stable basic configurations, providing a reliable upgrade path for known deployed devices. The dynamic line zone, on the other hand, can dynamically generate and store unique upgrade configurations for newly identified or undeployed devices during system operation. This dual-zone collaborative design ensures the stability and reliability of the core upgrade process while providing the system with sufficient flexibility to cope with future changes and expansions. Under a unified architecture, it balances the dual goals of standardized operation and maintenance with elastic adaptation, guaranteeing both system stability and providing ample flexibility.

[0124] In this embodiment of the application, the first memory of the second device further includes a boot area, an application area, and a backup area. The boot area is used to store the system initialization program and the path decision program. When the path decision program is started, it decides whether to obtain the corresponding upgrade path configuration from the static line area or the dynamic line area according to the deployment status of the first device. The application area is used to store applications, and the backup area is used to store old version files.

[0125] In this embodiment, the application in the application area is used to implement the core business of the second device, such as data collection and generation of upgrade information.

[0126] In this embodiment of the application, when the first device needs to be upgraded, the path decision program in the second device guidance area determines the upgrade path of the first device according to the deployment status of the first device. For example, if the first device is a deployed device, the preset upgrade information is obtained from the static line area; if the first device is an undeployed device, the upgrade information is obtained from the dynamic line area.

[0127] In this embodiment, when the communication interface and communication protocol of the first device change, the application in the application area updates the upgrade information of the first device and stores the updated upgrade information in the dynamic line area. When the first device is upgraded in the future, the updated upgrade information is directly obtained from the dynamic line area for updating, without modifying the underlying code, thus improving the system's operating efficiency.

[0128] Step S209: End the upgrade process.

[0129] Specifically, when it is determined that the first device does not need to be upgraded, the current upgrade process ends.

[0130] Please see Figure 5 , Figure 5 This is a schematic diagram of a process for updating upgrade information in a dynamic line area, provided in an embodiment of this application.

[0131] like Figure 5 As shown, the process for updating upgrade information in the dynamic line area includes:

[0132] Step S501: Obtain information about the newly added firmware.

[0133] In this embodiment of the application, when new firmware is added to the first device, the upgrade information corresponding to the new firmware needs to be reconstructed so that when the new firmware needs to be upgraded, the upgrade information corresponding to the new firmware can be directly obtained for upgrading.

[0134] Specifically, it retrieves information about newly added firmware, including firmware type, communication protocol, firmware version number, and firmware identifier.

[0135] Step S502: Fill the structure array with the information of the new firmware to obtain the upgrade information corresponding to the new firmware, and store the upgrade information corresponding to the new firmware in the dynamic line area.

[0136] Specifically, the information of the new firmware and the information of the first device are filled into the structure array using a macro function to obtain the upgrade information corresponding to the new firmware, and the upgrade information corresponding to the new firmware is stored in the dynamic circuit area. For the specific process of filling information using the macro function, please refer to step S204.

[0137] In this embodiment, when a new firmware is received from the server, the information of the new firmware is obtained, and the upgrade information of the new firmware is filled into a structure array to obtain a structure array corresponding to the new firmware. At the same time, the second device establishes communication with the first device to obtain the information of the first device, which includes information such as address and communication protocol. The information of the first device is filled into a structure array to obtain a structure array corresponding to the first device. The structure array corresponding to the new firmware and the structure array corresponding to the first device are saved in the dynamic line area to generate the upgrade information corresponding to the new firmware. The upgrade information of the new firmware includes the structure array corresponding to the new firmware and the structure array corresponding to the first device.

[0138] In this embodiment of the application, when an upgrade is required, the structure array corresponding to the new firmware and the structure array corresponding to the first device are obtained from the dynamic line area to obtain the upgrade file corresponding to the new firmware, and the upgrade file corresponding to the new firmware is sent to the first device, which then completes the upgrade based on the upgrade file.

[0139] In this embodiment, when new firmware is added to the first device, upgrade information for the new firmware is quickly generated by a macro function and written into the dynamic circuit area. There is no need to modify the program code in the boot area. Only one upgrade message corresponding to the new firmware needs to be added to adapt to the upgrade requirements of the device, thereby improving the scalability of the device.

[0140] Please see Figure 6 , Figure 6This is a schematic diagram of the overall process of a device upgrade method provided in an embodiment of this application.

[0141] like Figure 6 As shown, the overall process of upgrading this device includes:

[0142] Step S601: Establish a communication connection with the first device.

[0143] Specifically, a communication connection is pre-established between the first and second devices to form a stable data transmission channel. The second device can connect to multiple first devices simultaneously, enabling batch OTA upgrades for multiple devices.

[0144] Step S602: Determine whether the first device is an undeployed device.

[0145] Specifically, determine whether the first device is an undeployed device. If the first device is a deployed device, proceed to step S603; if the first device is an undeployed device, proceed to step S605.

[0146] In this embodiment of the application, the second device receives an information acquisition request from the first device. After receiving the information acquisition request, the second device queries information related to the first device. If information related to the first device is found, the second device determines that the first device is a deployed device and can directly return the information to the first device. If no information related to the first device is found, the second device determines that the first device is an undeployed device and sends feedback information indicating that the information acquisition failed to the first device. The information related to the first device includes the deployment configuration, adaptation protocol, historical upgrade records, etc. of the first device.

[0147] Step S603: Obtain preset upgrade information from the static line area.

[0148] In this embodiment, the second device includes a first memory, which includes a static line area for storing preset upgrade information. The preset upgrade information is predefined and standard device upgrade information of the second device. The preset upgrade information is either fixed before the second device leaves the factory or uniformly written during the initialization of the second device. The preset upgrade information includes the sending end of the upgrade file, the preset communication interface type, the preset protocol type, the timeout time, the number of retransmissions, the firmware type, the communication target address, etc.

[0149] Specifically, if the first device is an already deployed device, when the first device needs to be upgraded, the preset upgrade information is directly obtained from the static line area, its transmission path is parsed, and the upgrade file is transmitted to the first device based on the transmission path.

[0150] Step S604: Upgrade the first device based on preset upgrade information.

[0151] Specifically, the second device sends an upgrade file to the first device based on preset upgrade information, and the first device performs the upgrade based on the upgrade file after receiving it.

[0152] Step S605: Obtain upgrade information from the dynamic line area.

[0153] In this embodiment, the first memory includes a dynamic circuit area for storing upgrade information of the first device. The upgrade information of the first device includes a structure array, which includes at least one of the following: the sender of the upgrade file, the receiver of the upgrade file, the communication interface type, the protocol type, the chip firmware type, the communication target address, the timeout period, and the number of retransmissions.

[0154] In this embodiment, when the first device fails to establish a stable communication link with the second device, or when new firmware is added to the first device, it is necessary to construct upgrade information corresponding to the new firmware. The upgrade information of the new firmware includes firmware type, communication protocol, storage address, etc., and the upgrade information corresponding to the new firmware is stored in the dynamic line area. When it is necessary to upgrade the new firmware, the upgrade information corresponding to the new firmware is obtained from the dynamic line area, and the new firmware is upgraded based on the upgrade information corresponding to the new firmware.

[0155] Specifically, if the first device is an undeployed device, upgrade information is obtained from the dynamic line area.

[0156] Step S606: Upgrade the first device based on the upgrade information.

[0157] Specifically, the upgrade information is parsed to obtain the sender (server address), receiver (first device identifier), communication interface (e.g., CAN1), protocol type (e.g., CAN), target address (first device communication address, e.g., 0x0001), timeout (e.g., 5ms) of the upgrade file. Based on this transmission path configuration, the upgrade file is sent to the first device.

[0158] Specifically, after receiving the upgrade file, the first device caches the upgrade file in its cache space and verifies the upgrade file. If the verification passes, the old version file of the first device in the application area is erased, and the upgrade file received by the first device is written to the application area of ​​the first device, so as to overwrite the old version file of the first device with the upgrade file. The first device is then restarted to load the upgrade file in the application area, thereby upgrading the first device.

[0159] Step S607: Determine whether the upgrade of the first device was successful.

[0160] Specifically, after the first device is upgraded, the first device automatically triggers a self-test process to determine whether the upgrade of the first device is successful. If the upgrade of the first device is successful, the process jumps to step S608; if the upgrade of the first device fails, the process jumps to step S609.

[0161] In this embodiment, the self-test process includes firmware integrity verification and firmware running status verification. Firmware integrity verification involves calculating the checksum of the upgrade file and comparing it with a preset checksum. If the checksum matches the preset checksum, the firmware file is determined to be free of data corruption. If the checksum does not match the preset checksum, the upgrade file is determined to be abnormal (e.g., corrupted). Firmware running status verification involves checking whether the core modules (e.g., communication modules) of the firmware are loaded normally after the firmware is started. If they are loaded normally, the firmware is determined to be running normally. If loading fails, the firmware is determined to be running abnormally.

[0162] In this embodiment of the application, the first device is determined to have been successfully upgraded only if both firmware integrity verification and firmware running status verification pass.

[0163] Step S608: Update the status of the first device.

[0164] Specifically, if the first device is confirmed to have been successfully upgraded, the status of the first device is updated to change the status from pending upgrade to successful upgrade.

[0165] Step S609: Trigger the first device rollback mechanism.

[0166] In this embodiment, the first memory includes a backup area for storing older versions of files.

[0167] Specifically, if the upgrade of the first device fails, a rollback mechanism is triggered to retrieve the old version file from the backup area and restore the first device to its normal operating state before the upgrade based on the old version file.

[0168] Step S610: Report the error log.

[0169] Specifically, after the first device rollback mechanism is triggered, an error log is recorded and reported. The error log includes information about the upgrade failure and the rollback process.

[0170] Step S611: End the upgrade process.

[0171] In this embodiment, by reserving a dynamic line area to store the latest upgrade information, it is possible to quickly adapt to undeployed devices, thereby improving the scalability of the devices and increasing the efficiency of device upgrades.

[0172] Please see Figure 7 , Figure 7This is a schematic diagram of the structure of an upgrade system for a device provided in an embodiment of this application.

[0173] like Figure 7 As shown, the upgrade system 700 of the device includes a server 10, multiple first devices 20, and second devices 30. The second devices 30 include a first memory 31, which includes a boot sector 311, a static line sector 312, a dynamic line sector 313, an application sector 314, and a backup sector 315.

[0174] Server 10 is connected to the second device 30 and is used to store the upgrade files corresponding to the first device 20.

[0175] The second device 30 is connected to the server 10. The second device 30 is used to establish a communication connection with the first device 20, obtain the upgrade file corresponding to the first device 20 from the server 10, and send the upgrade file to the first device 20.

[0176] In this embodiment of the application, when the first device 20 needs to be upgraded, it sends an upgrade request to the second device 30. The second device 30 sends the upgrade file corresponding to the upgrade request to the first device 20. The first device 20 upgrades the firmware in the first device 20 based on the upgrade file.

[0177] In this embodiment, the guide area 311 is used to store the system initialization program and the path decision program. When the path decision program is started, the upgrade path of the first device is determined by the path decision program. The static line area 312 is used to store the preset upgrade information. The dynamic line area 313 is used to store the latest upgrade information of the first device 20. The application area 314 is used to store the application program. The backup area 315 is used to store the old version file.

[0178] In this embodiment of the application, when the first device 20 needs to be upgraded, if the first device 20 is a deployed device, then the preset upgrade information is obtained from the static line area 312, and the first device 20 is upgraded based on the preset upgrade information. If there is no upgrade information in the static line area, or if the first device 20 is an undeployed device, then the upgrade information is obtained from the dynamic line area, and the first device 20 is upgraded based on the upgrade information in the dynamic line area 313.

[0179] In this embodiment of the application, by reserving a dynamic circuit area in the first memory to store upgrade information, rapid adaptation to undeployed devices is achieved, thereby improving the scalability of the devices and increasing the efficiency of device upgrades.

[0180] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an upgrade device for an equipment provided in an embodiment of this application.

[0181] like Figure 8 As shown, the upgrade device 800 of the equipment includes:

[0182] The acquisition unit 801 is used to acquire information about the first device and information about the second device when the first device is connected to the second device, if the first device is an undeployed device.

[0183] The upgrade information construction unit 802 is used to construct upgrade information corresponding to the first device based on the information of the first device and the information of the second device, and store the upgrade information in the dynamic line area.

[0184] The upgrade unit 803 is used to obtain upgrade information from the dynamic line area when the first device needs to be upgraded, and to upgrade the first device based on the upgrade information.

[0185] In this embodiment, the device upgrade apparatus can be a software module. The software module includes several instructions, which are stored in a memory. The processor can access the memory and call the instructions to execute them, so as to complete the device upgrade methods of the above embodiments.

[0186] In the embodiments of this application, the device upgrade apparatus can also be constructed from hardware devices. For example, the device upgrade apparatus can be constructed from one or more chips, and the chips can work together to complete the device upgrade method described in the above embodiments. As another example, the device upgrade apparatus can also be constructed from various logic devices, such as general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), microcontrollers, ARM (Acorn RISC Machine) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0187] The device upgrade apparatus in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0188] The device upgrade apparatus in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0189] The device upgrade apparatus provided in this application embodiment can achieve... Figure 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0190] It should be noted that the above-described apparatus can execute the device upgrade method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the apparatus embodiments can be found in the device upgrade method provided in the embodiments of this application.

[0191] In this embodiment, the cooperation of the various modules of the device upgrade device can improve the rapid adaptation to undeployed devices, enhance the scalability of the device, and improve the efficiency of device upgrades.

[0192] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a second device provided in an embodiment of this application.

[0193] like Figure 9 As shown, the second device 30 includes one or more processors 32 and a second memory 33. Wherein, Figure 9 Take a processor 32 as an example.

[0194] The processor 32 and the second memory 33 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0195] Processor 32 is configured to execute a device upgrade method according to any embodiment of this application, applied to a first device, the first device including a first memory, the first memory including a dynamic circuit area, the method including:

[0196] When the first device connects to the second device, if the first device is an undeployed device, then the information of the first device and the information of the second device are obtained.

[0197] Based on the information of the first device and the information of the second device, upgrade information corresponding to the first device is constructed and stored in the dynamic line area;

[0198] When the first device needs to be upgraded, upgrade information is obtained from the dynamic line area, and the first device is upgraded based on the upgrade information.

[0199] The second memory 33, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the device upgrade method in the embodiments of the present invention. The processor 32 executes various functional applications and data processing of the electronic device by running the non-volatile software programs, instructions, and modules stored in the second memory 33, thereby implementing the device upgrade method of the above-described method embodiments.

[0200] The second memory 33 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the second memory 33 may optionally include memory remotely located relative to the processor 32. Examples of the above-described networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0201] One or more modules are stored in the second memory 33. When executed by one or more processors 32, they perform the device upgrade method in any of the above method embodiments, for example, the method described above. Figure 2 The steps shown.

[0202] This application also provides a computer program product, which includes one or more lines of program code stored in a non-volatile computer-readable storage medium. The processor of an electronic device reads the program code from the non-volatile computer-readable storage medium and executes the program code to complete the steps of the device upgrade method provided in the above embodiments.

[0203] Based on the above description of the embodiments, those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program or program code related to hardware. The program can be stored in a non-volatile computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0204] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The non-volatile computer-readable storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0205] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations as described above in different aspects of this application, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for upgrading equipment, characterized in that, Applied to a second device, the second device including a first memory, the first memory including a dynamic circuit area and a static circuit area, the static circuit area being used to store preset upgrade information, the method including: When the first device connects to the second device, if the first device is an undeployed device, then information about the first device and information about the second device are obtained. Based on the information of the first device and the information of the second device, upgrade information corresponding to the first device is constructed, and the upgrade information is stored in the dynamic line area; When the first device needs to be upgraded, the upgrade information is obtained from the dynamic line area, and the first device is upgraded based on the upgrade information; When the first device is connected to the second device, if the first device is a deployed device, then when the first device needs to be upgraded, preset upgrade information is obtained from the static line area; Based on the preset upgrade information, the firmware of the first device is upgraded.

2. The method according to claim 1, characterized in that, The step of constructing upgrade information corresponding to the first device based on the information of the first device and the information of the second device includes: Define an array of structures; The information of the first device and the information of the second device are filled into the structure array to obtain the upgrade information corresponding to the first device, wherein the upgrade information corresponding to the first device includes the structure array.

3. The method according to claim 2, characterized in that, The structure array includes at least one of the following: the sender of the upgrade file, the receiver of the upgrade file, the communication interface type, the protocol type, the chip firmware type, the communication target address, the timeout period, and the number of retransmissions. The communication interface type includes at least one of CAN interface, SPI interface, SCI interface, and USB interface.

4. The method according to claim 3, characterized in that, The upgrade of the first device based on the upgrade information includes: Parse the upgrade information obtained from the dynamic line area to obtain the transmission path configuration; The upgrade file is obtained from the sender of the upgrade file, and the upgrade file is sent to the first device based on the transmission path configuration; The upgrade file is used to overwrite the old version file of the first device in order to upgrade the first device.

5. The method according to claim 1, characterized in that, The first memory further includes: The boot sector is used to store the system initialization program and the path decision program. When the path decision program is started, the upgrade path of the first device is determined through the path decision program. The application area is used to store applications; Backup area, used to store older versions of files.

6. The method according to claim 5, characterized in that, When adding firmware to the first device, the method further includes: Obtain information about the newly added firmware; The information of the newly added firmware is filled into the structure array to obtain the upgrade information corresponding to the newly added firmware, and the upgrade information corresponding to the newly added firmware is stored in the dynamic line area; When upgrading the newly added firmware, upgrade information corresponding to the newly added firmware is obtained from the dynamic line area, and the newly added firmware is upgraded based on the upgrade information corresponding to the newly added firmware.

7. The method according to claim 5, characterized in that, The method further includes: If the first device upgrade is successful, then update the status of the first device; If the upgrade of the first device fails, the old version file is obtained from the backup area to restore the firmware of the first device based on the old version file.

8. A second device, characterized in that, include: At least one processor; as well as, A second memory communicatively connected to the at least one processor; wherein, The second memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

9. An equipment upgrade system, characterized in that, include: Multiple first devices; A server is used to store the upgrade files corresponding to the first device; The second device is communicatively connected to the server, used to establish a communication connection with the first device, obtain the upgrade file corresponding to the first device from the server, and send the upgrade file to the first device.

Images