OTA upgrade method and device based on AUTBUS bus

Abstract

The present application relates to an OTA upgrade method and device based on AUTBUS bus, which is applied to terminal nodes, including: receiving an OTA start command broadcasted by a control node, wherein the OTA start command includes the identifiers of each terminal node to be upgraded; when it is determined that the identifiers of each terminal node to be upgraded include its own node identifier, preparing a storage area; receiving each OTA data packet broadcasted by the control node in sequence, and writing them into the storage area; after receiving the OTA end command broadcasted by the control node, executing the upgrade based on the upgrade data composed of each OTA data packet stored in the storage area. The present application can realize OTA upgrade based on AUTBUS bus.

Description

Technical Field

[0001] The present application relates to the technical field of bus upgrade, and in particular to an OTA upgrade method and apparatus, a computing device and a storage medium based on an AUTBUS bus. Background Art

[0002] AUTBUS bus is a two-wire non-bridged medium with multi-node, high bandwidth and time-sensitive industrial fieldbus. AUTBUS bus is commonly used for the transmission and application of real-time data and non-real-time data in industrial automation control fields such as process control and discrete control, and is compatible with ISO / IEC / IEEE 8802-3 Ethernet, IPv6 and other applications. AUTBUS bus has the characteristics of high bandwidth, high real-time, long distance and high reliability transmission. It is simple to wire and install, and is easy to maintain the network and supports the use of existing cable assets. AUTBUS uses bus networking to provide fixed bandwidth data services and variable bandwidth data services that support burst data through bus pre-configuration or dynamic application. AUTBUS bus can provide reliable and deterministic bearing for periodic sampling data, burst control, alarm and IPv4 / IPv6 data in ISO / IEC / IEEE 8802-3 Ethernet format, and has the function of high-precision clock synchronization. It can provide deterministic data transmission services for time-sensitive and non-time-sensitive services based on time triggering. Therefore, AUTBUS bus is widely used in industrial control, automotive electronics, aviation, smart cities and other fields.

[0003] The AUTBUS bus is a new type of high-speed industrial field bus, which is different from the common communication mechanism of the existing industrial bus. For example, AUTBUS emphasizes the high real-time performance of data transmission, while the common communication mechanism of the existing industrial bus mostly adopts the "send + reply" mechanism to ensure the successful transmission of data. This communication mechanism affects the high real-time performance of data transmission. In short, there is currently no OTA online upgrade solution suitable for the AUTBUS bus. Therefore, this application is to provide an OTA upgrade solution based on the AUTBUS bus. Summary of the invention

[0004] In view of the above problems in the prior art, the present application provides an OTA upgrade method and apparatus based on AUTBUS bus, a computing device and a storage medium to implement OTA upgrade based on AUTBUS bus.

[0005] To achieve the above-mentioned object, the first aspect of the present application provides an OTA upgrade method based on AUTBUS bus, which is applied to a terminal node, comprising:

[0006] Receive an OTA start command broadcast by a control node, wherein the OTA start command includes an identifier of each terminal node to be upgraded;

[0007] When it is determined that the terminal node identifiers to be upgraded include the own node identifier, preparing a storage area;

[0008] receiving in sequence the OTA data packets broadcasted in sequence by the control node, and writing them into the storage area;

[0009] After receiving the OTA end command broadcast by the control node, the upgrade is performed based on the upgrade data composed of each OTA data packet stored in the storage area.

[0010] From the above, the present application can realize OTA upgrade based on AUTBUS bus by receiving OTA start command broadcast by control node, each OTA data packet broadcast by control node in sequence and OTA end command broadcast by control node. In the present application scheme, when the terminal node receives the command or data packet from control node, it does not need to respond to CN, so it is more suitable for AUTBUS bus that emphasizes high real-time data transmission.

[0011] As a possible implementation method of the first aspect, the OTA start command also includes the number of terminal nodes to be upgraded; the judgment that the terminal node identifiers to be upgraded include the own node identifier includes: traversing the terminal node identifiers to be upgraded, if the own node identifier is hit, it means that the terminal node identifiers to be upgraded include the own node identifier, and the traversal will no longer continue; if the number of terminal node identifiers to be upgraded reaches the number of terminal nodes to be upgraded and still does not hit the own identifier, the current OTA upgrade is terminated.

[0012] As a possible implementation method of the first aspect, it also includes: setting a local data packet sequence number, and the local data packet sequence number increases or decreases each time an OTA data packet is written to the storage area; each OTA data packet broadcasted in sequence by the control node also carries the sequence number of the OTA data packet; when the OTA data packet broadcasted by the control node is received, it is determined whether the sequence number of the OTA data packet carried by it matches the current local data packet sequence number, if so, the OTA data packet is written to the storage area, otherwise the current OTA upgrade is terminated.

[0013] From the above, the present application can match the local data packet sequence number with the received data packet sequence number, thereby ensuring that the data is written into the storage area in the correct order, thus avoiding upgrade failures caused by data disorder.

[0014] As a possible implementation method of the first aspect, it also includes: when it is determined that the terminal node identifiers to be upgraded include the node identifier of itself, setting an upgrade flag; when the OTA data packets broadcast by the control node are received in sequence and the set upgrade flag is checked for existence, the OTA data packet is written into the storage area, otherwise the current OTA upgrade is terminated.

[0015] From the above, this application sets an upgrade flag to mark whether the device is in the upgrade process, which helps to clarify the current status of the device and avoid upgrade operations under unexpected circumstances. By checking the upgrade flag, the device can be prevented from repeatedly entering the upgrade state when the upgrade process has already started, thereby avoiding unnecessary resource consumption and potential risks.

[0016] As a possible implementation manner of the first aspect, when ending the current OTA upgrade, it also includes: clearing the upgrade flag, and / or deleting the data in the storage area.

[0017] From the above, this application clears the upgrade flag after the upgrade is completed to release related resources, ensure that the device returns to normal working state, and avoid the flag occupying memory or other resources.

[0018] As a possible implementation method of the first aspect, the upgrade execution includes: performing a reset, and during the reset and restart process, copying the upgrade data stored in the storage area to the main program area and the backup area; starting from the main program area first, and if the main program area fails to start, starting from the backup area.

[0019] From the above, the present application copies the upgrade data to the main program area and the backup area during the reset and restart process, which can ensure the integrity and consistency of the data and avoid startup failures caused by incomplete data.

[0020] As a possible implementation manner of the first aspect, the resetting and restarting process further includes: verifying the correctness of the upgrade data stored in the storage area.

[0021] From the above, the present application verifies the correctness of the upgrade data in the FLASH during the reset and restart process, so as to confirm that the data has not been damaged or tampered with during the transmission process, thereby ensuring the success of the update process.

[0022] To achieve the above-mentioned object, the second aspect of the present application provides an OTA upgrade method based on AUTBUS bus, which is applied to a control node, comprising:

[0023] Receive an OTA start command sent by a host computer, and forward and broadcast the OTA start command, wherein the OTA start command includes the identifiers of each terminal node to be upgraded;

[0024] Receive each OTA data packet sent by the host computer in sequence, and forward and broadcast each OTA data packet in sequence;

[0025] Receive the OTA end command sent by the host computer, and forward and broadcast the OTA end command.

[0026] As a possible implementation manner of the second aspect, management time slot resources are used to broadcast the OTA start command, the OTA data message and / or the OTA end command.

[0027] To achieve the above-mentioned purpose, the third aspect of the present application provides an OTA upgrade method based on AUTBUS bus, which is applied to a terminal node, including:

[0028] An OTA startup command receiving module, used to receive an OTA startup command broadcast by a control node, wherein the OTA startup command includes an identifier of each terminal node to be upgraded;

[0029] A judgment module, configured to prepare a storage area when judging that the terminal node identifiers to be upgraded include the node identifier of the terminal node itself;

[0030] A data receiving module, used to sequentially receive the OTA data packets broadcasted by the control node in sequence, and write them into the storage area;

[0031] The OTA end command receiving module is used to perform the upgrade based on the upgrade data composed of each OTA data packet stored in the storage area after receiving the OTA end command broadcast by the control node.

[0032] To achieve the above-mentioned purpose, the fourth aspect of the present application provides an OTA upgrade method based on AUTBUS bus, which is applied to a control node, comprising:

[0033] A receiving broadcast module is used to receive an OTA start command sent by a host computer, and forward and broadcast the OTA start command, wherein the OTA start command includes the identifier of each terminal node to be upgraded; receive each OTA data packet sent by the host computer in sequence, and forward and broadcast each OTA data packet in sequence; receive an OTA end command sent by the host computer, and forward and broadcast the OTA end command.

[0034] A fifth aspect of the present application provides a computing device, including:

[0035] processor, and

[0036] A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes any of the methods described in the first aspect above.

[0037] In a sixth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer implements any of the methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 It is a flowchart of a first embodiment of an OTA upgrade method based on AUTBUS bus provided in an embodiment of the present application;

[0039] Figure 2 It is a flowchart of a second embodiment of an OTA upgrade method based on AUTBUS bus provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of time slot resources used for CN upgrade in an OTA upgrade method based on AUTBUS bus provided in this application;

[0041] Figure 4 A flowchart of a specific implementation of an OTA upgrade method based on AUTBUS bus provided in this application;

[0042] Figure 5 A first schematic diagram of an operation interface for OTA upgrade based on AUTBUS bus provided in this application;

[0043] Figure 6 A second schematic diagram of the operation interface of the OTA upgrade based on the AUTBUS bus provided in this application;

[0044] Figure 7 A third schematic diagram of the operation interface of the OTA upgrade based on the AUTBUS bus provided in this application;

[0045] Figure 8 A fourth schematic diagram of the operation interface of the OTA upgrade based on the AUTBUS bus provided by the present application;

[0046] Fig. 9 1 is a schematic structural diagram of a first embodiment of an OTA upgrade device based on an AUTBUS bus provided in an embodiment of the present application;

[0047] Fig.10 It is a structural schematic diagram of a computing device provided in an embodiment of the present application.

[0048] It should be understood that the size and shape of each block diagram in the above structural diagram are for reference only and should not constitute an exclusive interpretation of the embodiments of the present application. The relative positions and inclusion relationships between the blocks presented in the structural diagram are only schematic representations of the structural associations between the blocks, and do not limit the physical connection methods of the embodiments of the present application. DETAILED DESCRIPTION

[0049] The technical solution provided by the present application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of the present application are mainly to illustrate the possible implementation methods of the technical solution of the present application and should not be interpreted as the only limitation on the technical solution of the present application. It is known to those of ordinary skill in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by the present application is also applicable to similar technical problems.

[0050] It should be understood that the OTA upgrade solution based on the AUTBUS bus provided in the embodiments of the present application includes an OTA upgrade method and device based on the AUTBUS bus. Since the principles of solving the problems in these technical solutions are the same or similar, some repetitions may not be repeated in the introduction of the following specific embodiments, but it should be regarded as that these specific embodiments have been referenced to each other and can be combined with each other.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present application. In case of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0052] [First embodiment of the OTA upgrade method based on AUTBUS bus]

[0053] The first embodiment of the present application provides an OTA upgrade method based on AUTBUS bus, which is applied to terminal nodes, such as Figure 1 As shown, the method includes:

[0054] S110: receiving an OTA start command broadcasted by a control node, wherein the OTA start command includes identifiers of each terminal node to be upgraded;

[0055] S120: When it is determined that the terminal node identifiers to be upgraded include the own node identifier, prepare a storage area;

[0056] S130: receiving OTA data packets broadcasted by the control node in sequence, and writing them into the storage area;

[0057] S140: After receiving the OTA end command broadcast by the control node, perform the upgrade based on the upgrade data composed of each OTA data packet stored in the storage area.

[0058] In this embodiment, the AUTBUS bus belongs to a two-wire network. The two-wire network must have a control node (CN) and can have several terminal nodes (i.e., user nodes, Terminal Node, TN). There is only one CN, and TN can support up to 252. CN is responsible for the configuration and management of the entire network, including controlling TN to perform data upgrade management. TN performs corresponding upgrade operations based on the control of CN.

[0059] In some embodiments, the OTA start command also includes the number of terminal nodes to be upgraded, and the TN determines that the identifiers of the terminal nodes to be upgraded include its own node identifier, specifically including:

[0060] Traverse the terminal node identifiers to be upgraded. If a hit is found, it means that the terminal node identifiers to be upgraded include the TN's own node identifier, and the traversal will not continue. If the number of traversed terminal node identifiers reaches the number of terminal nodes to be upgraded and the TN's own identifier is still not hit, the TN ends the current upgrade process, indicating that the TN is not the TN to be upgraded this time.

[0061] In this embodiment, in S110, the TN receives the OTA start command broadcast by the CN, wherein the OTA start command includes the identifiers of each terminal node to be upgraded and the number of terminal nodes to be upgraded. The OTA start command may be specifically as shown in Table 1:

[0062] Table 1

[0063] Field Name type describe msg_type uint8 Message type OTA_START (0x11) ota_node_cnt uint8 The number of endpoints that need to be upgraded is 1-253. nodeid_list uint8

[252] nodeid list

[0064] Among them, when the msg_type field is 0x11, it means that the message is an OTA start command (OTA_START), and the ota_node_cnt field is filled in with the number of terminal nodes that need to be upgraded included in the OTA start command, so that CN and TN can clearly know how many nodes need to participate in this firmware update, which helps CN to better organize and manage the update process, and is convenient for TN to know the maximum number of nodes that can be traversed when traversing the nodeid list (nodeid_list). Of course, ota_node_cnt may not be included. The nodeid_list field is used to fill in the identifiers of each terminal node to be upgraded. Among them, the TN node identifier in the nodeid list can be filled in as needed, and the number of terminal nodes filled in can be single or multiple, or all TN node identifiers, so that it can be implemented as a single or multiple, or the entire network online TN nodes can be upgraded.

[0065] In this embodiment, in S120, after TN receives the OTA start command broadcast by CN, it will traverse all the terminal node identifiers (such as ID or address) to be upgraded included in the OTA start command, that is, traverse the nodeid_list in Table 1 to check whether its own identifier is included. When the terminal node identifiers to be upgraded include the identifier of the TN itself, it is considered that the TN is one of the targets of this update, and it is determined that the TN needs to be upgraded. At this time, a storage area is prepared, which is a part of the memory of the TN (usually flash memory FLASH) dedicated to storing new firmware. Before starting to receive the new firmware, this storage area will be cleared to ensure that the old data will not interfere with the writing of new data. When the number of node identifiers in the traversed nodeid_list of the TN reaches the number of terminal nodes to be upgraded (the value filled in ota_node_cnt in Table 2) and the TN's own identifier is not hit, it means that the TN itself does not need to be upgraded, so the TN ends its upgrade process.

[0066] In this embodiment, the CN broadcasts each OTA data packet in sequence, so in S130 the TN also receives each OTA data packet in sequence and writes it into the storage area after receiving it.

[0067] During the receiving and writing process, the TN needs to determine whether the received OTA data packet can be written into the storage area. Based on this, in some embodiments, such as Figure 2 As shown, it also includes:

[0068] Setting a local data packet sequence number, and increasing or decreasing the local data packet sequence number each time an OTA data packet is written into the storage area;

[0069] Each OTA data packet broadcasted in sequence by the control node also carries the sequence number of the OTA data packet;

[0070] When receiving the OTA data packet broadcasted by the control node, it is determined whether the sequence number of the OTA data packet carried by the control node matches the current local data packet sequence number. If so, the OTA data packet is written into the storage area, otherwise the current OTA upgrade is terminated.

[0071] In specific implementation, the OTA data packet is shown in Table 2:

[0072] Table 2

[0073]

[0074] Among them, when the msg_type field is 0x12, it means that the message is an OTA data packet (OTA_DATA). Before TN receives each OTA data packet broadcast by CN, it first needs to set a local data packet sequence number. The initial value can be set to 1. This is because the data packet sequence number starts from 1 and increases, so that the order of received data packets can be easily tracked. The initial value is set to 1, which means that this is the first expected data packet. When TN receives an OTA data packet, it is necessary to check the message sequence number recorded by the msg_seq_id field in Table 2. When the message sequence number in Table 2 is the same as the current local data packet sequence number, it means that TN has received the expected OTA data packet, and CN broadcasts the OTA data packet in sequence. There is no omission or misorder in the broadcast process. At this time, TN writes the specific data of the OTA data packet, that is, the data message recorded in the data field, into the storage area, and increments the local data packet sequence number by 1. If the message sequence number in Table 2 is different from the current local data packet sequence number, it means that the OTA data packet is omitted or misordered during the broadcast process. At this time, TN may end the upgrade.

[0075] For example, if the current local data packet sequence number is 1, it means that the OTA data packet has not been stored. When the sequence number of the received OTA data packet is 1, it means that it is the first OTA data packet sent by broadcast. At this time, the current local data packet sequence number is equal to the sequence number of the OTA data packet. The OTA data packet is written to the storage area, and the local data packet sequence number is incremented by 1 to 2. If the current local data packet sequence number is 1, when the sequence number of the received OTA data packet is 2, it means that it is the second OTA data packet sent by broadcast. At this time, the current local data packet sequence number is not equal to the sequence number of the OTA data packet, indicating that the first OTA data packet is omitted or the second OTA data packet is sent out of order. At this time, TN ends the upgrade. If the current local data packet sequence number is 2, when the sequence number of the received OTA data packet is 1, it means that the first OTA data packet is sent repeatedly. At this time, ignore this data packet and do not do any processing. At this time, TN ends the upgrade.

[0076] In other embodiments, if the sequence number of the data packet sent by the host computer to the CN is from large to small, such as (100-1), and the CN uses the same sequence (such as 100-1) to send the data packet to the TN, then the TN can set the initial value of the current local data packet sequence number to the maximum data packet sequence number (such as 100). When the data packet with the sequence number 100 broadcast by the CN is received, it is the same as the current local data packet sequence number, indicating that the TN has received the expected OTA data packet, and then the TN decrements the current local data packet sequence number by 1. The principle is basically the same as the increment of the sequence number of the above-mentioned data packets, and will not be repeated.

[0077] Adding the local data packet sequence number during the OTA upgrade process and matching it with the sequence number of the received OTA data packet can ensure that the data is written to the storage area in the correct order, avoiding upgrade failures caused by disordered data. If the received data packet sequence number does not match the local data packet sequence number, it indicates that one or some data packets may be lost. At this time, the current upgrade process can be stopped to prevent error accumulation, and the missing data packets can be requested to be retransmitted if necessary. This method effectively improves the reliability and success rate of OTA updates and ensures that the terminal device can successfully complete the firmware upgrade process.

[0078] In this embodiment, after confirming that an upgrade is required, the TN will set a mark in the memory or a certain status flag to indicate that it will be upgraded. Based on this, in some embodiments, it also includes:

[0079] When it is determined that the terminal node identifiers to be upgraded include the own node identifier, setting an upgrade flag;

[0080] When the OTA data packets broadcasted by the control node are received in sequence and the set upgrade flag is checked to exist, the OTA data packet is written into the storage area, otherwise the current OTA upgrade is terminated.

[0081] Specifically, the upgrade flag is a flag bit or variable used to indicate whether the TN is in the process of firmware update. This flag is set only when the TN determines that it needs to perform a firmware update. If the upgrade flag is not set, the TN will not continue to process the data packet. After the upgrade is successful, the TN can clear the saved upgrade flag to indicate that the firmware update is complete.

[0082] From the above, this application sets an upgrade flag to mark whether the device is in the upgrade process, which helps to clarify the current status of the device and avoid upgrade operations under unexpected circumstances. By checking the upgrade flag, the device can be prevented from repeatedly entering the upgrade state when the upgrade process has already started, thereby avoiding unnecessary resource consumption and potential risks.

[0083] In this embodiment, in S140, the TN performs the upgrade only after receiving the OTA end command broadcast by the CN, wherein the OTA end command is as shown in Table 3, and the msg_type field is filled with 0x13 to indicate an OAT end command:

[0084] Table 3

[0085] Field Name type describe msg_type uint8 Message type OTA_END (0x13)

[0086] In this application, CN uses broadcast messages to send OTA start commands, OTA data messages, and OTA end commands, so that each node can receive the broadcast message and obtain the upgrade data at the same time to achieve the upgrade at basically the same time. It is conducive to batch upgrades and unified control of the upgrade time. For example, the OTA upgrade method described in this application can be executed at night and early in the morning, broadcasting the above OTA start command, OTA data message, and OTA end command, so that the corresponding TN nodes are upgraded at the same time.

[0087] In some embodiments, performing the upgrade includes:

[0088] Perform a reset,

[0089] During the reset and restart process, the upgrade data stored in the storage area is copied to the main program area and the backup area;

[0090] The main program area is preferably used for startup. If the main program area fails to start, the backup area is used for startup.

[0091] In some embodiments, the reset and restart process further includes:

[0092] Verify the correctness of the upgrade data stored in the storage area.

[0093] Specifically, when the upgrade is performed in S140, after TN receives the end command, it will perform a software reset to ensure that the new firmware can be loaded and run correctly. Then the built-in boot code of TN (usually called BOOTROM) will run, and BOOTROM will check the code stored in the storage area. This process usually includes using CRC to verify the correctness of the upgrade data stored in the storage area to verify whether the upgrade data is intact. If the verification is successful, BOOTROM will copy the upgrade data from the storage area to the main program area and the backup area. The main program area is the program storage area used when the system is operating normally. The backup area exists to provide redundant protection when the main program area fails, ensuring that the system can still be started from the backup area. When the system starts, BOOTROM will prioritize loading the upgrade data from the main program area to start. If the firmware in the main program area is found to be damaged or cannot be started normally during the startup process, the system will automatically switch to the backup area to start. This ensures that the system can still operate normally even if there is a problem with the main program area.

[0094] From the above, this application copies the upgrade data to the main program area and the backup area during the reset and restart process, which can ensure the integrity and consistency of the data, avoid startup failures caused by incomplete data, and automatically recover when problems occur, thereby improving the stability and availability of the system. The correctness of the upgrade data in the storage area is verified during the reset and restart process, so that it can be confirmed that the data has not been damaged or tampered with during the transmission process, ensuring the success of the update process.

[0095] In some embodiments, when the current OTA upgrade is ended, the process further includes:

[0096] Clear the upgrade flag and / or delete the data in the storage area.

[0097] From the above, this application can release related resources by clearing the upgrade flag after the upgrade is completed, ensuring that the device returns to normal working state and avoiding the flag occupying memory or other resources. Deleting some or all of the data in the storage area can prevent residual data from being left due to unfinished upgrades, which may cause abnormal device behavior or problems with future upgrade operations. It helps to maintain the good state of the device, improve the stability and security of the system, and simplify the state management and troubleshooting process.

[0098] [Second embodiment of OTA upgrade method based on AUTBUS bus]

[0099] This application also proposes an OTA upgrade method based on AUTBUS bus, which is applied to control nodes, such as Figure 2 As shown, including:

[0100] S210: receiving an OTA start command sent by a host computer, and forwarding and broadcasting the OTA start command, wherein the OTA start command includes identifiers of each terminal node to be upgraded;

[0101] S220: receiving each OTA data packet sent by the host computer in sequence, and forwarding and broadcasting each OTA data packet in sequence;

[0102] S230: Receive the OTA end command sent by the host computer, and forward and broadcast the OTA end command.

[0103] In some embodiments, fixed time slot resources, such as management time slot resources, are used to broadcast the OTA start command, the OTA data message and / or the OTA end command.

[0104] Specifically, the smallest time unit in the AUTBUS bus network is a time slot, and 64 time slots form a frame. During the upgrade process, the CN forwards and broadcasts all OTA upgrade messages to the TN, and no TN response is required. The CN uses fixed time slot resources for OTA message broadcasting, for example, the 3rd and 4th symbols can be fixed, such as Figure 3 In this example, the two fixed time limit resources are used as management time slots. OTA messages are broadcasted through the management time slots, and each TN can receive them. In this way, there is no need to allocate additional time slots for the TNs.

[0105] In summary, the above method proposed in this application can achieve the following beneficial effects:

[0106] 1. Automated upgrade: OTA upgrade allows TN devices to be updated remotely and automatically without human intervention, reducing maintenance costs and complexity.

[0107] 2. Centralized management: Broadcasting is performed through the control node so that multiple TN devices can synchronously receive update commands and data packets, facilitating centralized management and coordination of upgrade operations for multiple devices.

[0108] 3. On-demand update: The control node can specify specific terminal nodes for update, which means that only the selected TN devices will perform the upgrade operation, avoiding unnecessary resource consumption.

[0109] 4. Data integrity assurance: TN receives data packets one by one and writes them into a temporary storage area. After all data packets are received, complete data verification can be performed to ensure the integrity and consistency of the upgraded data.

[0110] 5. Reduce downtime: TN performs the upgrade after receiving the end command, which can ensure that the update is carried out without affecting the normal operation of the TN equipment, reducing the downtime caused by the upgrade.

[0111] 6. Redundancy mechanism: After TN is upgraded, it can be started through the backup area if the main program area fails to start, further improving the system reliability and user experience.

[0112] [A specific implementation method of OTA upgrade method based on AUTBUS bus]

[0113] This application provides an OTA upgrade method based on AUTBUS bus, which describes in detail the interaction between CN and TN1, and the upgrade operation of TN1. Figure 4 As shown, including:

[0114] 1. Initialization phase, including each TN notifying the CN after coming online, and the CN allocating time slot resources for communication to each TN;

[0115] 2. OTA START phase, including the following steps:

[0116] CN receives the OTA start command from the host computer. The command contains the number of TN nodes that need to be upgraded and the nodeid of each TN that needs to be upgraded. All OTA messages are broadcast messages, forwarding the OTA start command to all TNs.

[0117] After receiving the OTA start command, TN uses the number of TN nodes that need to be upgraded in the OTA start command as the maximum number of node identifiers traversed, traverses the terminal node identifier nodeid that needs to be upgraded in the OTA start command, and determines whether it needs to be upgraded. When its own identifier exists in the terminal node identifier nodeid that needs to be upgraded (that is, it hits its own identifier), it determines that it needs to be upgraded, sets the upgrade flag to 1, and initializes the current local data packet sequence number to 1, erases the FLASH upgrade area, and prepares to write data. When the number of TN nodes traversed by the TN reaches the number of TN nodes that need to be upgraded (that is, all TN nodes have been traversed), and its own identifier is still not hit in the terminal node identifier nodeid that needs to be upgraded, the TN ends its upgrade process, indicating that the TN must be upgraded.

[0118] 3. OTA DATA loop broadcast phase until the file transfer is completed:

[0119] CN receives OTA data packets and data packet sequence numbers from the host computer, where all OTA messages are broadcast messages, and forwards OTA data packets to all TNs;

[0120] TN matches the data packet sequence number with the current local data packet sequence number and checks whether the set upgrade flag exists. If the data packet sequence number is the same as the current local data packet sequence number and the set upgrade flag exists, it means the match is successful, then the data is written to the FLASH upgrade area, and the local data packet sequence number is increased by 1. If the set upgrade flag does not exist or the data packet sequence number is different from the current local data packet sequence number, then the match fails, then the upgrade flag is cleared, and OTA ends.

[0121] 4. OTA END stage:

[0122] CN receives the OTA end command from the host computer, where all OTA messages are broadcast messages, and forwards the OTA end command to all TNs;

[0123] After the TN receives the end command, it performs a software reset so that the new firmware can be loaded and run.

[0124] 5. OTA COPY stage:

[0125] The BOOTROM in TN will check the FLASH upgrade area code. If the verification is successful, the upgrade data will be copied to the main program area and the backup area. The main program area will be started first to obtain the upgrade data for upgrading. If the main program area program is damaged, it will be started from the backup area.

[0126] The embodiment of the present application also provides an operation based on a graphical user interface (GUI) to implement the process of performing OTA firmware update on the TN through the CN, such as Figures 5 to 8 shown.

[0127] like Figure 5 As shown in the figure, on the user interface, all TN nodes that can be updated with firmware are listed. The user selects the terminal nodes (TN1 and TN2) that need to be updated with firmware on the GUI interface. Then, after selecting the terminal nodes that need to be updated, the user clicks the "Firmware Update" button.

[0128] The CN node will respond to the above operations of the user, such as Figure 6 As shown, a new dialog box or window will pop up. In the dialog box or window that pops up, the user can see a list of available firmware versions. The user selects a firmware version to upgrade from the list of firmware files provided. The file can be selected by browsing the file system, or from a predefined list of firmware versions. Then, after the user selects the firmware file, click the "Start" button, and the CN node will start the upgrade from the location of the firmware file (such as Figure 6 The location shown is a folder under the D drive, and it is not difficult to understand that it can also be an address of a server on the network) to download the selected firmware file to start the firmware update process.

[0129] Then, if Figure 7 As shown, in the pop-up dialog box or window, the firmware download progress will be displayed, and the progress bar or percentage will be updated in real time to let the user know the current download status. At this time, it means that the firmware file is being transmitted to the CN, wherein the firmware file is transmitted to the CN in turn in the form of individual data packets, and the CN immediately forwards the broadcast each time it receives a data packet, so that TN1 and TN2 in the figure receive the corresponding data packet. The process of TN receiving each data packet sent by CN can be referred to the description of the first embodiment, and will not be repeated here.

[0130] Finally, if Figure 8 As shown in the figure, when the firmware file is completely transferred to CN, the interface will display "Download Completed". This means that the firmware file has successfully arrived at CN, and it also means that CN has completed the forwarding and broadcasting of the last data packet corresponding to the firmware file. The CN node will update the status information after the download is completed to inform the user that the download is complete. The next step will be to wait for the TN side (TN1 and TN2) to verify and install the firmware formed by each received data packet. At this time, Figure 8 The interface shown shows "Firmware download complete, wait one minute to complete the upgrade" to prompt that the verification and installation process is currently waiting on the TN side. Of course, other information can also be used for prompting.

[0131] In the whole process, the CN node acts as the control center, responsible for communicating with the host computer or cloud server and broadcasting the firmware file to all selected TN nodes.

[0132] In this way, users can easily manage and monitor the entire OTA firmware update process to ensure the smooth progress of the update operation.

[0133] [The first embodiment of the OTA upgrade device based on AUTBUS bus of this application]

[0134] like Fig. 9 As shown, the embodiment of the present application provides an OTA upgrade device based on the AUTBUS bus, which is applied to the terminal node and can be used to implement the OTA upgrade method based on the AUTBUS bus in the above embodiment, such as Fig. 9 As shown, the OTA upgrade device based on the AUTBUS bus has an OTA start command receiving module 901, a judgment module 902, a data receiving module 903, and an OTA end command receiving module 904.

[0135] An OTA startup command receiving module, used to receive an OTA startup command broadcast by a control node, wherein the OTA startup command includes an identifier of each terminal node to be upgraded;

[0136] A judgment module, configured to prepare a storage area when judging that the terminal node identifiers to be upgraded include the node identifier of the terminal node itself;

[0137] A data receiving module, used to sequentially receive the OTA data packets broadcasted by the control node in sequence, and write them into the storage area;

[0138] The OTA end command receiving module is used to perform the upgrade based on the upgrade data composed of each OTA data packet stored in the storage area after receiving the OTA end command broadcast by the control node.

[0139] For details, please refer to the detailed description of the method in the first embodiment, which will not be repeated here.

[0140] [Second embodiment of the OTA upgrade device based on AUTBUS bus of this application]

[0141] The embodiment of the present application provides an OTA upgrade device based on AUTBUS bus, which is applied to the control node and can be used to implement the OTA upgrade method based on AUTBUS bus in the above embodiment. The OTA upgrade device based on AUTBUS bus has a receiving broadcast module for receiving the OTA start command sent by the host computer, and forwarding and broadcasting the OTA start command, wherein the OTA start command includes the identifiers of each terminal node to be upgraded; receiving each OTA data packet sent by the host computer in sequence, and forwarding and broadcasting each OTA data packet in sequence; receiving the OTA end command sent by the host computer, and forwarding and broadcasting the OTA end command. For details, please refer to the detailed description of the method in the second embodiment, which will not be repeated here.

[0142] [Embodiment of the computing device of the present application]

[0143] Fig.10 900 is a schematic structural diagram of a computing device 900 provided in an embodiment of the present application. The computing device can be used as an OTA upgrade device based on the AUTBUS bus to execute the optional embodiments of the above-mentioned OTA upgrade method based on the AUTBUS bus. The computing device can be a terminal or a chip or chip system inside the terminal. Fig.10 As shown, the computing device 900 includes: a processor 910 , a memory 920 , and a communication interface 930 .

[0144] It should be understood that Fig.10 The communication interface 930 in the computing device 900 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0145] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit inside the processor 910, or an external storage unit independent of the processor 910, or a component including a storage unit inside the processor 910 and an external storage unit independent of the processor 910.

[0146] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0147] It should be understood that in the embodiment of the present application, the processor 910 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 910 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0148] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a nonvolatile random access memory. For example, the processor 910 may also store information on the device type.

[0149] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform any operation step of the above method and any optional embodiment thereof.

[0150] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0151] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0152] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0153] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0154] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0155] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0156] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0157] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0158] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0159] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0160] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0161] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0162] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0163] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0164] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

[0165] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0166] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. An OTA upgrade method based on AUTBUS bus, applied to a terminal node, characterized in that: include: Receive an OTA start command broadcast by a control node, wherein the OTA start command includes an identifier of each terminal node to be upgraded; When it is determined that the terminal node identifiers to be upgraded include the own node identifier, preparing a storage area; receiving in sequence the OTA data packets broadcasted in sequence by the control node, and writing them into the storage area; After receiving the OTA end command broadcast by the control node, the upgrade is performed based on the upgrade data composed of each OTA data packet stored in the storage area.

2. The method according to claim 1, characterized in that The OTA start command also includes the number of terminal nodes to be upgraded; The determining whether the terminal node identifiers to be upgraded include the own node identifier includes: traversing the terminal node identifiers to be upgraded, and if the own node identifier is hit, it means that the terminal node identifiers to be upgraded include the own node identifier, and the traversal is no longer continued; if the number of terminal node identifiers to be upgraded that have been traversed reaches the number of terminal nodes to be upgraded and the own identifier is still not hit, the current OTA upgrade is terminated.

3. The method according to claim 1, characterized in that Also includes: Setting a local data packet sequence number, and increasing or decreasing the local data packet sequence number each time an OTA data packet is written into the storage area; Each OTA data packet broadcasted in sequence by the control node also carries the sequence number of the OTA data packet; When receiving the OTA data packet broadcasted by the control node, it is determined whether the sequence number of the OTA data packet carried by the control node matches the current local data packet sequence number. If so, the OTA data packet is written into the storage area, otherwise the current OTA upgrade is terminated.

4. The method according to any one of claims 1 to 3, characterized in that Also includes: When it is determined that the terminal node identifiers to be upgraded include the own node identifier, setting an upgrade flag; When the OTA data packets broadcasted by the control node are received in sequence and the set upgrade flag is checked to exist, the OTA data packet is written into the storage area, otherwise the current OTA upgrade is terminated.

5. The method according to claim 4, characterized in that The execution upgrade includes: Perform a reset, During the reset and restart process, the upgrade data stored in the storage area is copied to the main program area and the backup area; The main program area is preferably used for startup. If the main program area fails to start, the backup area is used for startup.

6. The method according to claim 5, characterized in that Also includes at least one of the following: When the current OTA upgrade is ended, the upgrade flag is cleared and / or the data in the storage area is deleted; During the reset and restart process, the correctness of the upgrade data stored in the storage area is also verified.

7. An OTA upgrade method based on AUTBUS bus, applied to a control node, characterized in that: include: Receive an OTA start command sent by a host computer, and forward and broadcast the OTA start command, wherein the OTA start command includes the identifiers of each terminal node to be upgraded; Receive each OTA data packet sent by the host computer in sequence, and forward and broadcast each OTA data packet in sequence; Receive the OTA end command sent by the host computer, and forward and broadcast the OTA end command.

8. The method according to claim 7, characterized in that The OTA start command, the OTA data message and / or the OTA end command are broadcasted using management time slot resources.

9. An OTA upgrade device based on AUTBUS bus, applied to a terminal node, characterized in that: include: An OTA startup command receiving module, used to receive an OTA startup command broadcast by a control node, wherein the OTA startup command includes an identifier of each terminal node to be upgraded; A judgment module, configured to prepare a storage area when judging that the terminal node identifiers to be upgraded include the node identifier of the terminal node itself; A data receiving module, used to sequentially receive the OTA data packets broadcasted by the control node in sequence, and write them into the storage area; The OTA end command receiving module is used to perform the upgrade based on the upgrade data composed of each OTA data packet stored in the storage area after receiving the OTA end command broadcast by the control node.

10. An OTA upgrade device based on AUTBUS bus, applied to a control node, characterized in that: include: A receiving broadcast module is used to receive an OTA start command sent by a host computer, and forward and broadcast the OTA start command, wherein the OTA start command includes the identifier of each terminal node to be upgraded; Receive each OTA data packet sent by the host computer in sequence, and forward and broadcast each OTA data packet in sequence; receive the OTA end command sent by the host computer, and forward and broadcast the OTA end command.

Images