Industrial device firmware upgrade method and apparatus, and electronic device

Abstract

The application discloses an industrial equipment firmware upgrading method and device and electronic equipment. The method comprises the following steps: receiving a firmware upgrading package sent by a sender equipment, wherein the sender equipment is a mobile terminal or a previous industrial equipment, and the previous industrial equipment is an industrial equipment which has completed firmware upgrading for the last time among a plurality of industrial equipments closest to the current time; performing firmware upgrading on a target industrial equipment among the plurality of industrial equipments based on the firmware upgrading package; receiving device data corresponding to a plurality of to-be-upgraded equipments among the plurality of industrial equipments in the case that firmware upgrading of the target industrial equipment is completed; determining a next industrial equipment from the plurality of to-be-upgraded equipments based on the device data corresponding to the plurality of to-be-upgraded equipments; and sending the firmware upgrading package to the next industrial equipment for firmware upgrading of the next industrial equipment. The application solves the technical problem of low firmware upgrading efficiency and reliability in the related art in the industrial equipment cluster.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and more particularly to the field of wireless communication and firmware upgrade technology. Specifically, it relates to a firmware upgrade method, apparatus, and electronic device for industrial equipment. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), remote firmware upgrades for industrial equipment have become a critical operation to ensure complete equipment functionality, performance optimization, and timely application of security patches. However, related technologies have significant limitations in terms of efficiency and reliability for firmware upgrades in industrial equipment clusters, especially in applications such as large factories and remote facility monitoring. Firmware upgrade methods in these technologies often rely on manual on-site operation, connecting and activating the upgrade process for each piece of industrial equipment one by one. This not only consumes a large amount of human resources but also faces serious challenges in terms of timeliness and accuracy when the number of devices is large or geographically dispersed. More importantly, this method increases the risk to operators in harsh or hazardous environments, such as on energized production lines or in complex underground pipeline networks. Manual intervention may lead to unexpected shutdowns or safety accidents, affecting the continuity and stability of production. Furthermore, broadcast-based firmware distribution technology also reveals significant weaknesses in industrial environments. Strong electromagnetic interference and numerous obstacles between devices in industrial settings make frequent signal collisions and data packet loss almost inevitable, resulting in low efficiency and reliability of firmware upgrades in industrial equipment clusters.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method, apparatus, and electronic device for firmware upgrades of industrial equipment, which at least solves the technical problems of low firmware upgrade efficiency and reliability in industrial equipment clusters.

[0005] According to one aspect of the present invention, an industrial equipment firmware upgrade method is provided, comprising: receiving a firmware upgrade package sent by a sending device, wherein the sending device is a mobile terminal or a previous industrial device, and the previous industrial device is the industrial device among a plurality of industrial devices that most recently completed a firmware upgrade; performing a firmware upgrade on a target industrial device among the plurality of industrial devices based on the firmware upgrade package; receiving device data corresponding to each of the plurality of devices to be upgraded among the plurality of industrial devices when the firmware upgrade of the target industrial device is completed; determining a next industrial device from the plurality of devices to be upgraded based on the device data corresponding to each of the plurality of devices to be upgraded; and sending the firmware upgrade package to the next industrial device for firmware upgrade of the next industrial device.

[0006] According to another aspect of the present invention, an industrial equipment firmware upgrade apparatus is also provided, comprising: an upgrade package receiving module, configured to receive a firmware upgrade package sent by a sending device, wherein the sending device is a mobile terminal or a previous industrial device, and the previous industrial device is the industrial device among a plurality of industrial devices that most recently completed a firmware upgrade; a firmware upgrade module, configured to perform a firmware upgrade on a target industrial device among the plurality of industrial devices based on the firmware upgrade package; a data receiving module, configured to receive device data corresponding to each of the plurality of devices to be upgraded among the plurality of industrial devices when the firmware upgrade of the target industrial device is completed; a device selection module, configured to determine the next industrial device from the plurality of devices to be upgraded based on the device data corresponding to each of the plurality of devices to be upgraded; and an upgrade package sending module, configured to send the firmware upgrade package to the next industrial device for firmware upgrade of the next industrial device.

[0007] According to another aspect of the present invention, a non-volatile storage medium is also provided, which stores a plurality of instructions adapted for an industrial equipment firmware upgrade method, any one of which is loaded and executed by a processor.

[0008] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any one of the industrial equipment firmware upgrade methods.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of any one of the industrial equipment firmware upgrade methods.

[0010] In this embodiment of the invention, by receiving a firmware upgrade package sent by a sending device (either a mobile terminal or a previous industrial device, where the previous industrial device is the one that most recently completed a firmware upgrade among multiple industrial devices); performing a firmware upgrade on a target industrial device based on the firmware upgrade package; receiving device data corresponding to each of the multiple devices to be upgraded based on the device data of each device to be upgraded; determining the next industrial device from among the multiple devices to be upgraded based on the device data of each device to be upgraded; and sending the firmware upgrade package to the next industrial device for firmware upgrade, this invention achieves the goal of automatically receiving and processing the firmware upgrade package by constructing a relay-style decentralized upgrade process, and then intelligently selecting and connecting to the next device to be upgraded based on the device data to transmit the firmware upgrade package, thereby automatically performing the firmware upgrade of the next industrial device. This achieves the technical effect of efficiently and reliably performing automatic and continuous upgrades of cluster devices without manual intervention, improving the upgrade efficiency of large-scale device clusters, and solving the technical problem of low firmware upgrade efficiency and reliability in industrial device clusters. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0012] Figure 1 This is a flowchart of an industrial equipment firmware upgrade method according to an embodiment of the present invention;

[0013] Figure 2 This is a timing diagram of data transmission between an optional mobile terminal (such as a mobile phone) and a device based on the Ymodem protocol, according to an embodiment of the present invention.

[0014] Figure 3 This is a schematic diagram of an optional device master control state machine transition according to an embodiment of the present invention;

[0015] Figure 4 This is a flowchart of an optional industrial equipment firmware upgrade method according to an embodiment of the present invention;

[0016] Figure 5 This is a schematic diagram of an industrial equipment firmware upgrade device according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] First, to facilitate understanding of the embodiments of the present invention, some terms or nouns involved in the present invention will be explained below:

[0020] A Bluetooth dual-mode chip refers to an integrated circuit chip that can simultaneously support both Bluetooth Classic (Bluetooth Classic / BR / EDR) and Bluetooth Low Energy (BLE) communication standards. These two modes correspond to different stages of Bluetooth technology development and application scenarios. Bluetooth Classic (BR / EDR) is an early standard for Bluetooth technology, supporting various applications such as audio streaming (e.g., headphones, speakers), file transfer, and game controllers. It is typically used in scenarios requiring high data transfer rates and long transmission distances. Bluetooth Low Energy (BLE), on the other hand, focuses on low power consumption and intermittent data transmission. BLE is designed for devices that require long-term operation but have limited power, such as wearable devices, health monitors, and smart home sensors. Bluetooth chips in BLE mode consume extremely low power, especially in standby and broadcast modes, significantly extending device battery life. A Bluetooth dual-mode chip combines the advantages of both communication standards, allowing a single device to flexibly switch between different types of Bluetooth connections to meet diverse application needs.

[0021] A state machine is a programming concept used to describe the control logic of a device or system, especially for embedded systems or software systems with multiple possible states and transitions between states. A state machine can be viewed as a model that decomposes the behavior of a system into a series of states and rules governing the transitions from one state to another.

[0022] According to an embodiment of the present invention, a method for firmware upgrade of industrial equipment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0023] Figure 1 This is a flowchart of an industrial equipment firmware upgrade method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0024] Step S102: Receive the firmware upgrade package sent by the sending device, wherein the sending device is a mobile terminal or the previous industrial device, and the previous industrial device is the industrial device that has completed the firmware upgrade most recently among multiple industrial devices.

[0025] Optionally, the method of this embodiment can be applied to a scenario where firmware upgrades are performed on multiple industrial devices in an industrial equipment cluster based on a mobile terminal. The execution entity for steps S102 to S110 can be a target industrial device among the multiple industrial devices. This target industrial device is the industrial device among the multiple industrial devices that requires firmware upgrades (i.e., the device to be upgraded). Each industrial device is a smart Bluetooth device, including a Bluetooth dual-mode chip, a Flash memory, and a main control state machine program running on it. This program can implement the industrial device firmware upgrade method of this embodiment.

[0026] Optionally, each industrial device can be configured with a corresponding device role. In a firmware upgrade scenario, the device role of each industrial device can be dynamically adjusted as the firmware upgrade progresses. Depending on the firmware upgrade progress, the device role can be set as a slave device, master device, idle broadcast device, etc. For example, for the target industrial device in this embodiment, before the firmware upgrade process begins, i.e., before executing step S102, the device role of the target industrial device is an idle broadcast device. When the firmware upgrade process begins, such as when executing steps S102 to S104, the device role of the target industrial device switches from idle broadcast device to slave device. When the firmware upgrade of the target industrial device is completed, for example, when executing steps S106 to S110, the device role of the target industrial device switches from slave device to master device. Each industrial device can be given intelligent state machine and role switching capabilities, enabling it to autonomously switch between the three core states of slave device, master device, and idle broadcast device. Simultaneously, each industrial device can be configured to have specific device functions and adopt different operating states when in different device roles.

[0027] In one optional embodiment, if the target industrial device is the first device among a plurality of industrial devices, the sending device is a mobile terminal, wherein the first device is the first device to perform a firmware upgrade; if the target industrial device is not the first device, the sending device is the previous industrial device.

[0028] Optionally, when the target industrial device is the first device, the firmware upgrade process is initiated by an external mobile terminal. The mobile terminal (such as a smartphone or dedicated handheld device) acts as the starting node for the upgrade task, responsible for directly transmitting the firmware upgrade package to the first device. The first device can be selected by the mobile terminal based on the device data corresponding to each device to be upgraded in the industrial device cluster. The specific implementation process of the mobile terminal in selecting the target industrial device is the same as the selection process of the next industrial device in subsequent embodiments, and will not be repeated here. Through the initialization steps based on the mobile terminal, the firmware upgrade package can be imported into the device network, and this process is also the only manual trigger point in the entire upgrade chain. All subsequent upgrade activities can be automatically coordinated and completed within the industrial device cluster. When the target industrial device is not the first device, it means that the current target industrial device receives the firmware upgrade package within the cluster through inter-device relay. At this stage, the sending device refers to the previous industrial device that recently completed the firmware upgrade. After the previous industrial device is upgraded and restarted, its internal control logic will drive it to change from a slave device to a central device and automatically begin scanning for other industrial devices in the surrounding environment that need to be upgraded. Once a suitable next target is found, the firmware upgrade package is transmitted there, allowing the upgrade process to continue spreading throughout the industrial equipment cluster until all industrial equipment in the cluster has been upgraded. This device-to-device upgrade method greatly reduces the need for centralized control or cloud reliance, achieving self-organization and self-governance of firmware upgrades.

[0029] This embodiment constructs a flexible firmware upgrade system where a mobile terminal only needs to trigger a single industrial device, after which the entire upgrade task can automatically propagate throughout the industrial device cluster, forming a decentralized upgrade chain. After completing its own upgrade, each industrial device immediately participates in the industrial device cluster's upgrade network, acting as a sender of firmware upgrade packages to continue upgrading other industrial devices until all industrial devices in the cluster have completed the upgrade. This approach not only significantly improves the upgrade efficiency of large-scale industrial device clusters but also maintains the continuity and high reliability of upgrades in complex and ever-changing industrial environments.

[0030] As an optional embodiment, when the target industrial device is the first device among multiple industrial devices, before executing step S102, device initialization and broadcast information configuration are performed in the industrial device cluster. This process is the basis for the device to join the upgrade network, mainly enabling each industrial device to announce its identity, firmware version, and upgrade request status in a standardized manner under normal conditions. By configuring specific Bluetooth broadcast data packets and custom Generic Attribute Profile (GATT) services, the device establishes a standardized interface for discovery, connection, and control interaction with the outside world (mobile terminal applets or other industrial devices). This lays the communication foundation for subsequent intelligent discovery, reliable connection, and command interaction. The specific implementation process is as follows: State machine initialization: After the industrial device is powered on or restarted, its internal main control state machine is initialized to DEVICE_STATE_IDLE (idle broadcast state). Bluetooth Role and Broadcast Configuration: The device configures the Bluetooth protocol stack to operate in idle broadcast device mode, builds and starts a low-power broadcast (Advertising). In the Advertising Data packet, the following information is filled in sequentially in the "Manufacturer Specific Data (AD Type 0xFF)" field: Device ID: 4 bytes, unique across the network; Firmware Version: 2 bytes; Upgrade Flag: 1 byte. 0x00 indicates the firmware is up-to-date, 0x01 indicates an upgrade is needed; Broadcast Signal Strength Calibration Value (optional): 1 byte; Battery Status Field (Battery Percentage), allowing other industrial devices in the network to scan and obtain its battery information. GATT Service Definition: The device initializes a custom GATT service (e.g., UUID: 0000FFE0-0000-1000-8000-00805F9B34FB). Three characteristics are created under this service: upgrade control characteristic (UUID:0000FFE1-…): with the attribute of Write, used to receive control commands; upgrade data characteristic (UUID:0000FFE2-…): with the attributes of Write Without Response and Notify, serving as the Ymodem protocol data transmission channel; and upgrade status characteristic (UUID: 0000FFE3-…): with the attribute of Notify, used to proactively report progress and status.

[0031] In one optional embodiment, receiving a firmware upgrade package sent by the sending device includes: receiving a firmware upgrade package sent by the sending device based on the Yale modem protocol.

[0032] Optionally, the Ymodem protocol is a widely used communication protocol for transferring files in computer networks. It is characterized by its lightweight nature and ease of implementation, and incorporates Cyclic Redundancy Check (CRC) and automatic retransmission mechanisms to ensure accurate data transmission. In firmware upgrade scenarios, the Ymodem protocol is chosen as the primary method for receiving firmware upgrade packets by the receiving device because it effectively handles common packet loss and interference issues in wireless environments. When an industrial device in an industrial equipment cluster completes its own firmware upgrade (i.e., the receiving device) and prepares to upgrade the next industrial device, it acts as the Ymodem protocol receiver, waiting for firmware data transmission from another device (such as the target industrial device). The firmware data is divided into several small blocks according to the Ymodem protocol, and each block carries a CRC checksum before and after transmission. Upon receiving each block, the receiving device immediately performs a CRC check. If the check result is correct, it sends an acknowledgment (ACK) to the sending device; otherwise, it sends a negative acknowledgment (NAK) requesting retransmission of the data block. This mechanism ensures the integrity and accuracy of received firmware data blocks during transmission, preventing upgrade failures due to data errors. When receiving firmware upgrade packages using the Ymodem protocol, the receiving device (such as the target industrial equipment) can use Ymodem's CRC check mechanism to detect any errors that may occur during data transmission, ensuring that the received data blocks are completely correct. When a data block is transmitted incorrectly, Ymodem's NAK-ACK mechanism allows the receiving device to request retransmission of the erroneous data block until correct data is received, thereby improving the reliability of data transmission. By using the Ymodem protocol to receive firmware upgrade packages, the receiving device can ensure the complete reception of firmware data in an intelligent and efficient manner. This process not only improves the success rate of firmware upgrades but also reduces upgrade delays or failures caused by data errors, positively contributing to the stability and upgrade efficiency of the entire device network. Through this embodiment, the receiving device in the firmware upgrade process can utilize the Ymodem protocol to complete the reception of firmware upgrade packages with higher data transmission quality and efficiency.

[0033] Optionally, taking a mobile terminal as the sending device as an example, a reliable one-to-one connection is established between the mobile terminal (such as a mobile app) and the first device in the industrial equipment cluster (i.e., the first industrial device to undergo firmware upgrade). Using the mature Ymodem file transfer protocol, the complete firmware upgrade package is securely and completely injected into the device network composed of all industrial devices in the cluster. This ensures the absolute correctness of the initial firmware data, serving as a reliable starting point for the entire decentralized relay diffusion process and the sole manual trigger point and data source for the entire upgrade task. Figure 2 This is a timing diagram of data transmission between an optional mobile terminal (such as a mobile phone) and a device based on the Ymodem protocol, according to an embodiment of the present invention. Figure 2 As shown, the specific implementation process is as follows: Device discovery and connection: The mobile terminal applet initiates Bluetooth scanning, filters industrial devices with an "upgrade flag" of 0x01 in the broadcast data, selects and connects to the first device (such as Device A). Service discovery and command issuance: The applet discovers Device A's custom GATT service and feature value, and writes the start command 0x01 to its upgrade control feature value. Ymodem protocol handshake: After receiving the command, Device A continuously sends the ASCII character 'C' (0x43) to the mobile terminal through the Notify function of the upgrade data feature value notification, initiating transmission and requesting Cyclic Redundancy Check (CRC)-16 verification. File header transmission: After receiving 'C', the mobile terminal constructs and sends a Ymodem file header packet (starting with a Start Of Heading (SOH) frame header, packet number 0, containing metadata such as file name, size, and CRC-16 verification). Device A replies with an acknowledgment (ACK) (0x06) after successful verification. Data Block Transmission and Verification: The mobile terminal divides the firmware file into fixed 1024-byte blocks and sends Ymodem data frames sequentially (starting with the Start of Text (STX) character, containing the packet number, data block, and CRC-16). Device A performs CRC verification on each received data packet. If the verification passes, it replies with an ACK; otherwise, it replies with a Negative Acknowledgment (NAK) (0x15), triggering a retransmission. A maximum of 10 retries are allowed. End of Transmission and Firmware Writing: After all data blocks have been sent, the mobile terminal sends an End of Transmission (EOT) (0x04). Device A replies with an ACK, and the mobile terminal then sends an empty header packet to end the session. Device A writes the completely received firmware data to the spare area of ​​the external Flash memory.

[0034] Step S104: Based on the firmware upgrade package, perform firmware upgrade on the target industrial equipment among multiple industrial devices.

[0035] Optionally, once the firmware upgrade package is received, the target industrial device switches from the idle broadcast device state DEVICE_STATE_IDLE to the slave device state DEVICE_STATE_SLAVE, and initiates its internal upgrade process. Taking Device A, as defined in the aforementioned embodiment, as an example, after Device A writes the fully received firmware data (i.e., the firmware upgrade package) to the spare area of ​​the external Flash, Device A performs a software reboot, enters the bootloader (a piece of code in an embedded system responsible for starting the operating system or application), copies the new firmware from the spare area to the main program area, and completes its own upgrade. After Device A completes its firmware update and reboots, its bootloader or application initialization code detects that the currently running firmware has been updated to the new version. This process is the core of the device upgrade, ensuring the correct installation of the new firmware, thereby achieving functional enhancement or fixing security vulnerabilities.

[0036] Step S106: After the firmware upgrade of the target industrial equipment is completed, the device data corresponding to each of the multiple industrial equipment to be upgraded is received.

[0037] Optionally, once the target industrial device successfully completes its firmware upgrade, information (i.e., device data) will be collected from other devices in the industrial device cluster that have not yet been upgraded. Device data may include, but is not limited to, key indicators such as the corresponding industrial device's signal strength, remaining battery power, firmware version number, whether it is ready for an upgrade, and its distance from the target industrial device. By acquiring this information, the upgraded industrial device can assess the network status and prepare for the next step.

[0038] In one optional embodiment, when the firmware upgrade of the target industrial equipment is completed, receiving device data corresponding to each of the multiple industrial equipment to be upgraded includes: when the firmware upgrade of the target industrial equipment is completed, detecting whether the remaining power of the target industrial equipment is greater than a second power threshold; and when the remaining power of the target industrial equipment is greater than the second power threshold, receiving device data corresponding to each of the multiple industrial equipment to be upgraded.

[0039] Optionally, after the target industrial device completes its firmware upgrade and restarts to operational status, its control logic will first check its remaining battery level. This check can be performed by reading information provided by the device's built-in battery management system or by calling the power information service in the Bluetooth protocol stack. Checking the remaining battery level is to assess whether the target industrial device has sufficient energy reserves to support the subsequent firmware transmission task. The second battery threshold can be set based on the average energy consumption during firmware transmission and the minimum power reserve required for safe operation of the device. If the target industrial device's remaining battery level is greater than or equal to this threshold, it indicates that the device has the energy foundation to undertake the firmware upgrade package transmission task. Only when the target Bluetooth device's remaining battery level meets the above condition, i.e., is greater than the second battery threshold, will the Bluetooth scanning and connection process be initiated to collect data from other devices in the network environment to be upgraded. This conditional control ensures that the target Bluetooth device has assessed and confirmed that it has sufficient power support before engaging in power-intensive Bluetooth connections and data transmission, thereby avoiding situations where device functionality is degraded or the upgrade task is forced to be interrupted due to insufficient power.

[0040] In this embodiment, an intelligent power management mechanism is introduced at the device level during the firmware upgrade process, ensuring both the smooth progress of the upgrade task and the stable operation of the industrial equipment itself. This conditional check based on remaining power is part of the intelligent firmware upgrade process. Combined with other decision-making factors such as signal strength filtering and distance information considerations, it forms a comprehensive, flexible, and efficient firmware upgrade network. These methods help improve the operational efficiency of large-scale industrial equipment clusters, reduce maintenance costs caused by improper power management, and also help extend the service life of individual industrial devices and improve energy efficiency.

[0041] Optionally, after the target industrial equipment's firmware upgrade is complete, the target industrial equipment can autonomously switch its role and state. This process is a key turning point in achieving "decentralization" and "relay," primarily transforming the upgraded industrial equipment from a passive "upgrade target" into an active "upgrade initiator." Driven by its internal state machine, the target industrial equipment can automatically switch its role from slave to master and enter an active scanning state. This transformation endows ordinary equipment with intelligent relay capabilities and is the core mechanism for the automatic diffusion of upgrade tasks. The specific implementation process is as follows: State machine-driven transition: The target industrial equipment's internal master control state machine automatically switches its current state from slave (DEVICE_STATE_SLAVE) to master (DEVICE_STATE_MASTER_SCANNING) according to preset logic. It can be configured that after the master device completes its upgrade, before deciding whether to switch to DEVICE_STATE_MASTER_SCANNING (actively scanning to upgrade other devices), it checks its own battery level. If the battery level is below the set threshold (20%), you can choose to temporarily not switch to the master device, maintain DEVICE_STATE_IDLE, and only act as the slave device being upgraded, until it is charged or the battery level is restored before participating in the handover. In the DEVICE_STATE_MASTER_SCANNING state, the device firmware calls the fixed API provided by the Bluetooth chip software development kit (SDK) (for the Nordic nRF5 SDK, it calls the function sd_ble_gap_scan_start() to start Bluetooth gap scan and stops broadcasting before this) to switch its Bluetooth role from slave to master, preparing to actively scan for surrounding devices, identify multiple devices to be upgraded, and obtain the corresponding device data.

[0042] In an optional embodiment, the method further includes: when the remaining power of the target industrial device is less than or equal to a second power threshold, sending a power reminder message to the sending device to prompt the sending device to send the firmware upgrade package to other industrial devices to be upgraded among the multiple industrial devices besides the target industrial device.

[0043] Optionally, after completing its firmware upgrade, the target industrial device will first check its remaining battery power and compare it with a preset second battery power threshold. The purpose of setting this second battery power threshold is to ensure that the device will not interrupt its task or damage its functionality due to battery depletion during firmware transmission. If, during the comparison, the target industrial device's remaining battery power is found to be less than or equal to the second battery power threshold, then it no longer has sufficient energy to undertake the firmware transmission task. At this time, the target industrial device will send a battery power warning message to the sending device (such as a mobile terminal or the previous industrial device). This message is uploaded to the sending device via Bluetooth. Upon receiving the battery power warning message, the sending device (or the management program on the mobile terminal) will adjust its upgrade strategy based on this feedback, selecting another device in the network environment besides the target industrial device as the new firmware transmission target. This means that the upgrade task path, originally planned to relay through the target industrial device, now needs to bypass the industrial device with insufficient battery power and find a new transmission channel. This path redirection can avoid energy bottlenecks during the firmware upgrade process and ensure the smooth progress of the task. This intelligent adjustment of battery power warning and upgrade path is not only an emergency measure when battery power is insufficient, but also reflects the dynamic optimization capability of the firmware upgrade strategy. By monitoring the power status of devices in the network in real time, upgrade tasks can be intelligently allocated, avoiding wasting resources on industrial equipment with insufficient power. Instead, firmware transmission is redirected to industrial equipment with more abundant power, thereby accelerating the upgrade process of the entire cluster.

[0044] Optionally, if the remaining battery power of the target industrial equipment is less than or equal to the second battery power threshold, a battery power warning can be displayed on the mobile terminal to alert the user of low battery power. Specifically, if the sending device is a mobile terminal, the target industrial equipment can directly send the battery power warning to the mobile terminal; if the sending device is the previous industrial equipment, the battery power warning can be sent to the mobile terminal via the previous industrial equipment.

[0045] The method described in this embodiment introduces more refined and dynamic energy efficiency management at both the device and system levels during the firmware upgrade process, particularly for sensitive situations involving low battery power. This mechanism, through the transmission of battery power alerts and real-time adjustments to the upgrade path, ensures that firmware upgrade tasks can be completed efficiently and without disruption, even when some industrial equipment has insufficient power. This improves the operational efficiency and stability of the entire equipment cluster.

[0046] In one optional embodiment, upon completion of the firmware upgrade of the target industrial equipment, receiving device data corresponding to each of the multiple industrial equipment to be upgraded includes: upon completion of the firmware upgrade of the target industrial equipment, controlling the target industrial equipment to initiate Bluetooth scanning, wherein the Bluetooth scanning is used to identify devices among the multiple industrial equipment whose corresponding upgrade flag is a predetermined identifier; identifying the devices whose corresponding upgrade flag is a predetermined identifier as multiple upgrade devices; sending Bluetooth connection requests to the multiple upgrade devices; and upon successful establishment of Bluetooth connections with the multiple upgrade devices based on the Bluetooth connection requests, receiving device data corresponding to each of the multiple upgrade devices.

[0047] Optionally, after the target industrial device (i.e., the device that has just completed a firmware upgrade) restarts, its built-in control logic will automatically trigger the Bluetooth scanning function. The main purpose of Bluetooth scanning is to search for other devices in the network environment that have not yet been upgraded. By using the upgrade flag bit in the broadcast data packet (e.g., 0x01 represents the upgrade status, 0x00 represents the latest firmware status), industrial devices that still need firmware upgrades are filtered out. This step automates device discovery, identifying subsequent targets for upgrade tasks without external intervention. During Bluetooth scanning, the target industrial device records all industrial devices in the broadcast data whose upgrade flag bit is a predetermined identifier (e.g., 0x01 representing the upgrade status). These industrial devices constitute a candidate list for subsequent upgrade tasks, i.e., multiple devices to be upgraded. After identifying the list of devices to be upgraded, the target industrial device will actively send connection requests to these devices, attempting to establish a one-to-one Bluetooth connection. If the Bluetooth connection request is accepted, the target industrial device will successfully establish a Bluetooth connection with one of the candidate devices. At this time, it can obtain the other party's device data through this connection, including but not limited to signal strength, remaining battery power, device type, firmware version, etc. The collection of device data is a prerequisite for intelligently selecting the next upgrade target, providing a direct basis for subsequent decisions based on multi-dimensional parameters. If the Bluetooth connection still fails to be established after a predetermined number of retries, an alarm can be sent to the user via a mobile terminal.

[0048] Through the steps of this embodiment, the firmware upgrade process for an industrial equipment cluster achieves a series of automated operations, from automatic scanning and intelligent identification of the target industrial equipment after the upgrade is completed, to proactive connection to data collection. This not only reduces reliance on manual intervention but also significantly improves the speed and accuracy of firmware upgrade tasks propagating across the network. In particular, by dynamically establishing Bluetooth connections, the status changes of each industrial device can be captured in real time during the upgrade process, ensuring that each data transmission is based on the latest network conditions and device energy status, thereby increasing the success rate and efficiency of firmware upgrades.

[0049] In an optional embodiment, the method further includes: if any of the multiple devices to be upgraded fails to establish a Bluetooth connection, sending a new Bluetooth connection request to any of the devices to be upgraded, retrying the Bluetooth connection operation with any of the devices to be upgraded, and recording the cumulative number of retries; repeating the Bluetooth connection operation until a Bluetooth connection is successfully established with any of the devices to be upgraded, or the cumulative number of retries reaches a predetermined number of retries.

[0050] Optionally, during the firmware upgrade process, if the target industrial device fails to establish a Bluetooth connection with a device to be upgraded (e.g., connection request times out without response, Bluetooth signal suddenly interrupted), the target industrial device will not immediately give up. Instead, it will automatically send a new Bluetooth connection request to the same Bluetooth device to attempt to re-establish the connection. This retry request essentially provides an opportunity for occasional wireless communication failures, aiming to compensate for temporary communication interruptions caused by environmental noise, signal obstruction, etc., and ensure the smooth progress of the firmware upgrade task. To avoid indefinite retries that cause unnecessary resource waste and upgrade delays, a cumulative retry count can be recorded for each retry attempt. This counting mechanism allows the control logic to track the retry frequency, thereby determining when to continue trying and when to take other measures. When a connection failure occurs, the target industrial device will repeatedly execute the Bluetooth connection request until one of the following two termination conditions is met: a successful Bluetooth connection is established with the device to be upgraded, at which point the next step of the firmware upgrade can proceed normally. If the cumulative number of retries reaches the system's preset retry limit (i.e., the predetermined number of retries), and a connection is still not successfully established before the limit is reached, it means that the current wireless environment or device status may not be suitable for immediate upgrade. The system will then enter an abnormal handling process, which may include marking the device as "awaiting manual inspection" or skipping the current industrial equipment and attempting to connect to other devices to be upgraded.

[0051] This embodiment provides a retry-based fault tolerance mechanism, enabling the firmware upgrade process to self-correct minor communication obstacles to a certain extent. Furthermore, by setting a reasonable upper limit on the number of retries, excessive consumption of invalid attempts can be avoided, maintaining the efficiency and controllability of the upgrade process. In practical applications, especially in the complex wireless environments of industrial sites, the implementation of this mechanism can significantly improve the firmware upgrade success rate and reduce the probability of upgrade interruptions or failures caused by communication instability, thereby ensuring the stable operation and timely update capability of the entire industrial equipment cluster.

[0052] Step S108: Based on the equipment data corresponding to each of the multiple devices to be upgraded, determine the next industrial device from the multiple devices to be upgraded.

[0053] In this step, based on the collected device data, upgraded industrial equipment will use certain algorithms or rules to select the best next upgrade target from multiple devices to be upgraded. Selection criteria may include, but are not limited to, signal strength (to ensure stable data transmission), remaining battery power (to avoid interruptions to the upgrade process due to insufficient power), and firmware version number (to confirm whether an upgrade is necessary). This intelligent decision-making ensures the efficiency and continuity of the upgrade process.

[0054] Optionally, the device data may include, but is not limited to, signal strength and remaining battery power. Based on the device data corresponding to multiple devices to be upgraded, there are several ways to determine the next industrial device from among them. For example, the next industrial device can be selected in, but is not limited to, the following ways: When the target industrial device (i.e., the industrial device currently in the role of the master device) simultaneously scans multiple devices to be upgraded, the state machine makes a decision based on multiple factors to intelligently select the upgrade device. For example, it prioritizes selecting the device with high Received Signal Strength Indicator (RSSI) and sufficient remaining battery power as the next industrial device. This is equivalent to dynamically selecting the "optimal next hop" at each relay point, rather than pre-setting a fixed device, thus optimizing the propagation path and completion time of the entire upgrade task. Alternatively, when the target industrial device scans and selects a target, it prioritizes connecting to the upgrade device with lower but higher battery power than the safety threshold, ensuring that these devices complete the upgrade as soon as possible before their power runs out, avoiding them from permanently falling behind due to insufficient power. When there are multiple potential upgrade paths, the device with more abundant battery power is selected as the relay node to share the forwarding load in the network and achieve energy load balancing.

[0055] In one optional embodiment, when the device data includes signal strength and remaining power, determining the next industrial device from the multiple devices to be upgraded based on the device data corresponding to each of the multiple devices to be upgraded includes: determining multiple candidate devices from the multiple devices to be upgraded whose remaining power is greater than a first power threshold; determining a first weight corresponding to the signal strength and a second weight corresponding to the remaining power; performing a weighted summation operation on the first weight and the second weight based on the signal strength and remaining power corresponding to each of the multiple candidate devices to obtain a score value corresponding to each of the multiple candidate devices; and determining the next industrial device from the multiple candidate devices based on the score values ​​corresponding to each of the multiple candidate devices.

[0056] Optionally, before upgrading, a preliminary screening of the remaining power of all devices to be upgraded is performed to exclude those with power below a specific threshold (i.e., the first power threshold). This is a preventative measure to avoid upgrade failure due to sudden power depletion during the upgrade process. Only industrial devices whose remaining power meets the minimum standard are considered qualified candidate devices and included in the subsequent intelligent selection process. To reflect the different levels of importance of signal strength and remaining power in the firmware upgrade process, different weights are assigned to these two parameters. The first weight corresponding to signal strength reflects the impact of communication quality between devices, while the second weight corresponding to remaining power considers the energy guarantee for the device to successfully complete the upgrade process. These weight values ​​can be determined based on, but are not limited to, experimental data or predefined strategies, to balance the importance of both in the algorithm. Next, a comprehensive score is calculated for each candidate device. By multiplying the signal strength and remaining power of the candidate device by their respective weights (the first weight and the second weight), and then summing the results, the score value of the device can be obtained. The next industrial device is intelligently selected based on the calculated score value. For example, the score values ​​of various candidate devices can be compared, and the device with the highest score (or greater than a preset value) can be selected as the next upgrade target. This approach ensures that upgrade tasks are prioritized for devices with high communication quality and sufficient power, thereby improving the overall success rate and efficiency of firmware upgrades.

[0057] By implementing the above decision-making mechanism, this embodiment proposes a more intelligent and efficient firmware upgrade scheme. It considers not only the signal transmission quality at the physical layer but also the energy state of industrial equipment, ensuring the reliability of industrial equipment and the continuity of the upgrade task during the upgrade process. This intelligent decision-making method based on quantitative analysis is particularly suitable for firmware upgrade scenarios involving industrial equipment clusters, helping to overcome the challenges posed by complex environments and wide equipment distribution, and achieving automation and optimization of firmware upgrades.

[0058] Optionally, the acquisition of RSSI (Signal Strength Index) primarily relies on the underlying support of the Bluetooth protocol stack. When the target industrial device performs Bluetooth scanning, it provides the source address of the broadcast packet and the received RSSI value in the callback event whenever it receives a broadcast packet. This quality indicator can be obtained in real time without establishing a connection. For example, in Android development, it can be obtained by calling the onLeScan method of the BluetoothAdapter.LeScanCallback low-power scan callback during low-power scanning (different APIs correspond to different development platforms). After two devices (which can be two industrial devices or a mobile terminal and an industrial device) establish a GATT connection, the RSSI in the connection state can be actively read or monitored through specific APIs (such as Android's BluetoothGatt.readRemoteRssi() or the embedded chip's sd_ble_gap_rssi_get() to get the RSSI value of the Bluetooth connection gap), providing data for dynamic link evaluation. Battery information is primarily obtained through the standardized methods of the standard Bluetooth Battery Service. Devices supporting this service expose a standard Universally Unique Identifier (UUID) (0x180F) and a feature value (0x2A19). Once a GATT connection is established between devices, the central device can read this feature value to obtain an integer battery percentage between 0 and 100, just like reading other data.

[0059] As an optional embodiment, when the device data also includes distance information (i.e., the distance to the target industrial equipment), a third weight corresponding to the distance information is determined. Based on the signal strength, remaining power, and distance information of each of the multiple candidate devices, the first weight, second weight, and third weight are weighted and summed to obtain the score value corresponding to each of the multiple candidate devices. Based on the score values ​​corresponding to each of the multiple candidate devices, the next industrial equipment is determined from the multiple candidate devices. By further integrating the decision algorithm with distance information (i.e., the relative distance to the target industrial equipment) into the device data and introducing the third weight corresponding to the distance information, the firmware upgrade of the industrial equipment cluster can not only achieve intelligent selection based on signal strength and remaining power, but also take into account the relative position between industrial equipment, which can significantly enhance the comprehensiveness and effectiveness of the upgrade strategy, making the firmware upgrade selection mechanism more comprehensive and refined.

[0060] Step S110: Send the firmware upgrade package to the next industrial device for firmware upgrade.

[0061] In this step, after selecting the next industrial device, the target industrial device becomes the new, most recently upgraded device. It then acts as the new sender, transmitting the firmware upgrade package to the next industrial device via a reliable wireless communication protocol (such as using the Ymodem protocol combined with Bluetooth GATT service). This step restarts the firmware upgrade cycle until all industrial devices are updated to the latest firmware. This device-to-device firmware package delivery reduces reliance on fixed infrastructure (such as gateways or servers), enhancing the system's adaptability and robustness in complex industrial environments.

[0062] In one alternative embodiment, sending the firmware upgrade package to the next industrial device includes: sending the firmware upgrade package to the next industrial device based on the Ymodem protocol.

[0063] Optionally, Ymodem is a widely used communication protocol for file transfer, especially suitable for peer-to-peer (P2P) communication scenarios. It ensures data accuracy during transmission through built-in verification mechanisms (Cyclic Redundancy Check, CRC) and retransmission mechanisms (ACK / NAK-based acknowledgment / negative acknowledgment). Compared to broadcast or flooding transmission in related technologies, firmware transmission under the Ymodem protocol effectively addresses data packet loss issues in complex wireless environments, ensuring the integrity of the firmware upgrade package and thus improving the success rate of firmware upgrades and the stability of device clusters. Once the next industrial device is identified as the upgrade target, the sending device (which could be the initial mobile terminal or other industrial devices that have already been upgraded) will encapsulate and segment the firmware upgrade package according to the rules of the Ymodem protocol and send it to the target industrial device through the established GATT connection channel. The transmission of the firmware upgrade package follows a strict Ymodem process, including sending the header, transmitting data blocks one by one, CRC-based result confirmation, and finally, end-of-transmission confirmation (EOT). Each step of this transmission process has a corresponding acknowledgment or negative acknowledgment mechanism to ensure data integrity and controllability of the transmission process. During transmission, if the target industrial equipment detects a CRC check failure upon receiving data, indicating that the integrity of the data block is compromised, it will send a negative acknowledgment (NAK) signal to the sending equipment. Upon receiving the NAK signal, the sending equipment will retransmit the data block according to the protocol until the receiving equipment successfully receives and verifies the data, then sends an acknowledgment (ACK) signal. This fault-tolerant mechanism based on error detection and automatic retransmission effectively improves the reliability of data transmission, ensuring that firmware upgrade packages can be transmitted accurately even in environments with poor signal or severe interference. Data transmission under the Ymodem protocol, through point-to-point connections, avoids the "broadcast storm" problem that may be encountered in traditional broadcast upgrades, i.e., signal conflicts caused by multiple devices broadcasting at the same time. This one-to-one data transmission method not only improves transmission efficiency but also reduces the probability of data packet collisions and significantly reduces the consumption of network resources throughout the upgrade process, making OTA upgrades of device clusters more efficient and economical.

[0064] This embodiment introduces the highly reliable Ymodem data transmission protocol into the firmware upgrade process at the transmission layer. This ensures that the firmware upgrade package is accurately transmitted to each industrial device to be upgraded in complex and ever-changing wireless environments. The implementation of this mechanism not only improves the security and efficiency of data transmission but also reduces the firmware upgrade failure rate caused by data transmission errors, thereby enhancing the overall operational quality and stability of the device cluster.

[0065] Optionally, the target device can be designated as the master device, and a state machine-driven intelligent relay upgrade diffusion process can be implemented, enabling the self-organized propagation of upgrade tasks within the industrial equipment cluster. Its core function is to manage the dynamic switching of each device between the roles of master, slave, and idle broadcaster through a finely designed state machine that includes error handling; the establishment and maintenance of Bluetooth connections; and point-to-point firmware transmission based on the Ymodem protocol. This state machine ensures the reliability, fault tolerance, and efficiency of the upgrade process, allowing upgrade tasks to be automatically and orderly passed between devices like a relay baton.

[0066] Figure 3 This is a schematic diagram of an optional device master control state machine transition according to an embodiment of the present invention, such as... Figure 3As shown, the specific implementation process is as follows: In the master device scanning discovery state (DEVICE_STATE_MASTER_SCANNING): Devices in this state (such as Device A) initiate Bluetooth scanning, and their scanning filter is set to only receive signals from devices whose "upgrade flag" is 0x01 in the broadcast data. After discovering the target device (i.e., the next industrial device, such as Device B), its address is recorded, and the state transitions to the master device connection establishment state (DEVICE_STATE_MASTER_CONNECTING). When the master device simultaneously scans multiple devices to be upgraded, the state machine makes decisions based on a multi-factor intelligent selection of the upgrade device, comprehensively considering: signal strength (RSSI) and remaining device power (see the energy management section). This is equivalent to dynamically selecting the "optimal next hop" at each relay point, rather than pre-setting a fixed device, thus optimizing the propagation path and completion time of the entire upgrade task. Alternatively, when the master device scans and selects a target, it prioritizes connecting to upgrade devices with lower but higher power levels than the safety threshold, ensuring that these devices complete the upgrade as soon as possible before their power runs out, preventing them from permanently falling behind due to insufficient power. When multiple potential upgrade paths exist, the device with more power is selected as the relay node to share the forwarding load in the network and achieve energy load balancing. Master device connection establishment state (DEVICE_STATE_MASTER_CONNECTING): Device A initiates a Bluetooth connection request to Device B. If the connection is successful, it enters the master device GATT service discovery state (DEVICE_STATE_MASTER_GATT_DISCOVERY); if the connection fails (e.g., timeout), it enters the master device connection establishment failure state (DEVICE_STATE_MASTER_CONNECT_FAILED), waits for a random backoff time, and then returns to the scanning state to attempt to connect to other industrial devices. GATT service discovery state (DEVICE_STATE_MASTER_GATT_DISCOVERY): Device A discovers Device B's GATT service and obtains the handles of its upgrade control signature, upgrade data signature, and upgrade status signature. Upgrade command issuance and data transmission status (DEVICE_STATE_MASTER_SENDING): Device A writes a start command 0x01 to the upgrade control characteristic value of Device B. Subsequently, Device A reads the new firmware upgrade package stored in its own Flash and, as the Ymodem sender, sends data strictly according to the Ymodem protocol process (handshake, header, data block, end) in the aforementioned embodiment, based on the upgrade data characteristic value of Device B.During this process, Device A listens for ACK / NAK responses from Device B via Notify and executes the retransmission logic specified in the protocol. While waiting for the slave device to restart (DEVICE_STATE_WAIT_SLAVE_REBOOT): Device A confirms that Device B has received all data and is ready to restart by listening to the upgrade status characteristic value. After waiting for a preset time (e.g., 5 seconds), Device A actively disconnects from Device B, and the state machine transitions back to DEVICE_STATE_MASTER_SCANNING to search for the next target. When the upgrade control characteristic value of a device in DEVICE_STATE_IDLE (such as Device B) is written to 0x01, an event is triggered, and the state switches to DEVICE_STATE_SLAVE_RECEIVING. In this state, Device B, as the Ymodem receiver, receives data through the upgrade data characteristic value, verifies it, and responds with ACK / NAK. If consecutive verifications fail, it can enter the slave device CRC check error state DEVICE_STATE_SLAVE_CRC_ERROR for error counting and processing. After receiving the data, Device B's device state changes to DEVICE_STATE_SLAVE_UPGRADING, writes the firmware to Flash, and reboots. Upon reboot, its state machine logic is the same as Device A's, automatically entering DEVICE_STATE_MASTER_SCANNING and becoming the new master device.

[0067] As an optional embodiment, after sending the firmware upgrade package to the next industrial device, a receipt is received from the next industrial device. This receipt indicates that if the received firmware upgrade package is incomplete, it should be resent to the next industrial device until a new receipt from the next industrial device indicates that the received firmware upgrade package is complete, or a preset number of resending attempts is reached. If the preset number of resending attempts is reached, an alarm is issued to the user through the mobile terminal's display interface. Simultaneously, the target industrial device can select a new next industrial device and send the firmware upgrade package to it.

[0068] Optionally, after the firmware upgrade package is transmitted to the next industrial device, the receiving device (i.e., the next industrial device) will perform an integrity check on the received data. If the check result shows that the firmware package is incomplete, i.e., an error occurred or data packets were lost during data transmission, the receiving device will return a special acknowledgment result (such as a NAK message) indicating incomplete data to the sending device (i.e., the target industrial device). Upon receiving such an acknowledgment, the sending device will automatically initiate a retransmission mechanism to resend the firmware upgrade package to the receiving device until the receiving device confirms that the received firmware package is complete (via an ACK message), or the number of retransmissions reaches a pre-set limit. This acknowledgment-based retransmission mechanism ensures the integrity and accuracy of the firmware data during transmission. To avoid resource waste and indefinite delays in the upgrade process caused by infinite retransmissions, a reasonable maximum number of transmissions is preset. When the sending device continuously retransmits firmware packets to the next industrial device until the limit is reached, and the receiving device still cannot confirm data integrity, an alarm can be issued through the display interface of a mobile terminal (such as a smartphone app used by maintenance personnel). This alerts the user that the industrial device may have encountered a serious problem that is difficult to resolve automatically, such as hardware failure or severe network connectivity issues. This alarm function allows maintenance personnel to promptly notice potential problems and take appropriate manual intervention measures, avoiding risks arising from industrial devices remaining in an unupgraded state for extended periods. If the maximum retransmission limit is reached and firmware packet transmission still fails, the sending device can automatically execute intelligent selection for the next stage, choosing a new industrial device as the transmission target. This mechanism, based on real-time communication status between devices and preset device selection strategies (such as signal strength, communication quality, and device health status), can quickly identify and avoid problematic device nodes, selecting the most suitable industrial device to continue the transmission task. This dynamic device selection strategy not only improves the overall efficiency of firmware upgrade tasks but also enhances the robustness and flexibility of the device network, ensuring that the upgrade task can proceed smoothly even if a node experiences a problem.

[0069] By employing strategies such as data retransmission, alarm notifications, and intelligent device reselection in the above embodiments, not only is the data transmission reliability during firmware upgrades enhanced, but the dynamic optimization and adjustment capabilities of the upgrade strategy are also demonstrated. This ensures that the cluster can self-recover and continue executing upgrade tasks in the face of various complex and unexpected situations. Implementing this method can significantly improve the experience of maintenance personnel during industrial equipment upgrades. The immediacy of alarm notifications allows maintenance personnel to quickly locate and handle problematic devices, avoiding prolonged unproductive waiting and resource waste. Simultaneously, the intelligent reselection mechanism can accelerate the entire upgrade process. Even in the face of industrial equipment failures or network interference, it can automatically adjust to find the optimal upgrade path, significantly improving maintenance efficiency and reducing the need for manual intervention.

[0070] This embodiment provides a comprehensive firmware upgrade package transmission optimization and anomaly handling scheme. It not only improves the reliability of transmission through a data retransmission mechanism, but also enhances the cluster's self-adjustment and recovery capabilities in the face of complex situations through preset transmission counts, alarm functions, and intelligent reselection of the next industrial device. This ensures the smooth progress of the device cluster OTA upgrade process and significantly improves the operation and maintenance efficiency and user experience in industrial sites.

[0071] In an optional embodiment, the method further includes: before receiving the firmware upgrade package, controlling the target industrial equipment to operate at a first energy consumption; during the firmware upgrade process, controlling the target industrial equipment to operate at a second energy consumption, wherein the first energy consumption is less than the second energy consumption; from the completion of the firmware upgrade of the target industrial equipment to the sending of the firmware upgrade package to the next industrial equipment, controlling the target industrial equipment to operate at a third energy consumption, wherein the second energy consumption is less than the third energy consumption; and after the firmware upgrade package is sent to the next industrial equipment, controlling the target industrial equipment to operate at the first energy consumption.

[0072] Optionally, to better manage the energy consumption of industrial equipment during firmware upgrades, this embodiment proposes adjusting the Bluetooth operating mode of the industrial equipment according to different stages. Different operating modes correspond to different energy consumption strategies, specifically divided into three levels: first energy consumption, second energy consumption, and third energy consumption. First energy consumption represents the normal low-energy operating state of the industrial equipment outside of firmware upgrade stages, mainly used for daily operation and standby mode. At this time, the industrial equipment mainly maintains its visibility in the network through methods such as low-power Bluetooth broadcasting. Second energy consumption is the higher energy consumption state during firmware upgrades when the device receives firmware data. Because receiving the firmware upgrade package requires establishing a stable Bluetooth connection and high-speed data transmission, the industrial equipment consumes more power than in the first energy consumption stage. Third energy consumption is the highest energy consumption state after the industrial equipment completes its own firmware upgrade and is preparing to send a firmware upgrade package to the next industrial equipment. This stage involves high-speed Bluetooth scanning, connection, and large file transfer, thus reaching peak energy consumption.

[0073] By dynamically adjusting the operating energy consumption of industrial equipment at different stages of firmware upgrades, refined energy management can be achieved, minimizing energy waste. For each industrial device in a cluster, during the non-upgrade phase, it is configured to operate with minimum energy consumption to maintain network connectivity and ensure continuous operation. During the firmware receiving phase, energy consumption is moderately increased to ensure data transmission integrity and reliability, preventing upgrade failures due to signal instability. In preparation for sending the firmware upgrade package to the next device, it enters a third energy consumption state—the necessary energy input to complete file transfer tasks quickly. Once the firmware upgrade package is sent, the industrial device returns to the low-energy first energy consumption state, completing a full energy optimization cycle. Each industrial device in the cluster can be configured to switch states according to a preset energy consumption strategy at each stage of the firmware upgrade. Specifically: First energy consumption operation: Before receiving the firmware upgrade package, it operates in the lowest power consumption state, primarily performing advertising broadcasts and monitoring scans, maintaining network connectivity while maximizing energy savings. Second Power Consumption Operation: When receiving firmware upgrade packages, the device automatically switches to the second power consumption state. In this state, the device increases power consumption to support high-speed GATT connections and data transmission, while the Ymodem protocol's verification and retransmission mechanism ensures correct firmware data reception. Third Power Consumption Operation: When the firmware upgrade is complete and the device is ready to send the upgrade package to the next device, it briefly enters the third power consumption state, the highest power consumption state, to support active scanning, connection, and file transfer. After this phase, the device returns to the first power consumption state, resuming low-power operation. Different Bluetooth operating modes can be configured for different device roles. For example, when the device role is an idle broadcast device, the Bluetooth operating mode is determined to be the first power consumption mode; when the device role is a slave device, the Bluetooth operating mode is determined to be the second power consumption mode; and when the device role is a master device, the Bluetooth operating mode is determined to be the third power consumption mode.

[0074] This embodiment not only ensures the efficiency and reliability of the firmware upgrade process, but also enables the rational use of energy by industrial equipment through optimized control of energy consumption, thereby extending the service life of industrial equipment. In large-scale industrial equipment clusters, this dynamic energy consumption adjustment mechanism helps reduce the overall network's energy burden, decrease maintenance costs caused by improper energy management, and ensure the smooth completion of equipment firmware upgrades.

[0075] As an optional embodiment, the method further includes: sending the current status of the target industrial equipment to the mobile terminal. The current status may include, but is not limited to, statuses such as: pending upgrade, upgrading in progress, upgrade completed, slave device scanning, slave device upgrading, slave device CRC check error, and master device connection establishment failure. The master device refers to the target industrial equipment, and the slave device refers to the next industrial equipment. The mobile terminal receives and continuously monitors the current status of each device in the industrial equipment cluster and displays the current status of each device on its interface. Furthermore, when every device in the cluster has completed its upgrade, the mobile terminal can aggregate the current status of all devices and display the successful completion of the upgrade task to the user. If the current status reported by the target industrial equipment is an error (such as slave device CRC check error, master device connection establishment failure, etc.), a detailed error log is recorded, and an alarm is issued via the mobile terminal. Through real-time status synchronization and error handling mechanisms, not only can the upgrade process be visualized and monitored, enhancing system robustness and user experience, but also ensuring that even in complex network conditions or equipment failures, problems can be detected and remedial measures taken in a timely manner, thereby improving the success rate and efficiency of OTA upgrades for the entire cluster.

[0076] Specifically, each industrial device in the industrial equipment cluster can send its current status (including but not limited to pending upgrade, upgrading in progress, upgrade complete, and various error states) to the mobile terminal in real time, allowing maintenance personnel to intuitively understand the upgrade progress of the entire cluster through the mobile terminal's display interface. Once any device is detected to enter an error state, such as a CRC check failure or connection establishment failure, the mobile terminal not only records detailed error logs but also immediately sends an alarm to the user, facilitating rapid problem location and decision-making by maintenance personnel regarding manual intervention. When all industrial devices in the cluster have successfully upgraded, the mobile terminal summarizes and displays this result, informing the user that the upgrade task was successfully completed and providing immediate feedback on the upgrade outcome. This comprehensive status monitoring and error handling mechanism greatly enhances the system's responsiveness and upgrade success rate in the face of various uncertainties.

[0077] As an optional implementation, further upgrade progress synchronization, anomaly handling, and task completion can be performed within the industrial equipment cluster. The core function of this process is to achieve global visualization of the upgrade status, handle various anomalies during the upgrade process, and ensure system recoverability after upgrade failure. By defining status reporting characteristic values, the progress of each industrial device can be monitored in real time. Mechanisms such as automatic retry and safe rollback are designed to improve system robustness. Logs and data from the entire process can also provide a basis for subsequent system optimization. The specific implementation process is as follows: Progress Synchronization and Visualization: During the entire upgrade process, the slave device currently being upgraded reports its status (e.g., "Receiving 40%", "Verification Successful", "Installing") to the master device connected to it in real time via Notify, using its upgrade status characteristic value. This status information can be ultimately transmitted back to the mobile terminal app along the device chain, achieving global progress visualization. Anomaly Handling and Retry: Multiple error states can be defined (e.g., connection failure, CRC error, upgrade timeout). In states such as DEVICE_STATE_MASTER_CONNECT_FAILED and DEVICE_STATE_SLAVE_CRC_ERROR, each industrial device will execute a preset retry strategy (such as waiting for a random time before reconnecting or requesting a retransmission of data packets). If the retries fail after a certain number of attempts, a detailed error log is recorded, and the industrial device can be marked as "requiring manual intervention" through a status reporting mechanism. Security rollback mechanism: Before receiving new firmware, each industrial device can back up its currently running firmware in an independent area of ​​Flash. If the verification fails after installing the new firmware (e.g., startup fails), the device's bootloader can automatically trigger a rollback mechanism to restore the previous stable version, ensuring the basic functions of the system are available. Task completion determination: When the "upgrade flag" in the Bluetooth broadcast data of all industrial devices in the network changes to 0x00, it indicates that the upgrade task for the entire cluster has been completed. The mobile terminal app can summarize this information and show the user that the upgrade task has been successfully completed.

[0078] Through the above steps S102 to S110, a relay-style decentralized upgrade process can be constructed, enabling the target industrial equipment that has completed the upgrade to automatically receive and process the firmware upgrade package. Then, based on the equipment data, it can intelligently select and connect to the next device to be upgraded to transmit the firmware upgrade package and automatically upgrade the firmware of the next industrial equipment. This achieves the technical effect of efficiently and reliably upgrading industrial cluster equipment without human intervention, improving the upgrade efficiency of large-scale industrial equipment clusters, and solving the technical problem of low firmware upgrade efficiency and reliability in industrial equipment clusters.

[0079] With the popularization of Internet of Things (IoT) technology, a large number of embedded devices are deployed in various environments, such as smart lighting, environmental monitoring, and industrial sensor networks. Upgrading firmware for these industrial devices to fix vulnerabilities, add functionality, or optimize performance has become a routine maintenance requirement. Bluetooth OTA upgrade methods in related technologies mainly suffer from the following pain points: 1) Low efficiency and high labor costs: Bluetooth OTA upgrade solutions in related technologies primarily involve maintenance personnel using mobile applications or dedicated handheld devices to approach and connect to each device to be upgraded. In scenarios with a large number of devices (such as a tunnel lighting system several kilometers long) or complex deployment environments (such as large warehouses or already-operated tunnels), this method is time-consuming, labor-intensive, and poses personal safety risks. 2) Poor reliability of broadcast upgrade solutions: Some improved solutions in related technologies attempt to distribute firmware using Bluetooth advertising or Bluetooth Mesh network broadcasting. However, Bluetooth broadcast channels have limited bandwidth, are unreliable, and lack an acknowledgment mechanism. In complex wireless environments, they are prone to upgrade failure due to packet collisions ("broadcast storms") or packet loss. While mesh networks can extend their range through relays, their firmware distribution process is typically based on flooding or controlled flooding, resulting in high network traffic and reliance on fixed gateways or relay nodes, leading to poor topology flexibility. 3) Insufficient intelligence in related technical solutions: Some related technologies propose broadcasting upgrade packages between devices via "hop-through" in linear scenarios such as tunnels, initiated by the ingress relay node. However, this solution is essentially still broadcasting, and the device roles (relay nodes) are fixed, unable to dynamically adjust based on network conditions. Devices passively forward messages, lacking the ability to intelligently decide whether to become relays based on their own status (such as battery level and signal strength), and unable to autonomously find alternative paths when point-to-point connections fail. 4) Resource consumption and upgrade interruption issues: Some related technologies require reserving significant space in the device's Flash memory for storing the complete upgrade package or as a backup, increasing hardware costs. Other solutions require restarting from scratch if the upgrade process is interrupted (e.g., the device is used), resulting in a poor user experience. In summary, related technologies suffer from low firmware upgrade efficiency and reliability in industrial equipment clusters.

[0080] To address the aforementioned problems, and in conjunction with the above embodiments and optional embodiments, the present invention proposes an optional implementation method. Figure 4 This is a flowchart of an optional industrial equipment firmware upgrade method according to an embodiment of the present invention, such as... Figure 4 As shown, the method includes:

[0081] S1, Device Initialization and Broadcast Information Configuration: This step is fundamental for industrial devices to join the upgrade network. It primarily enables each industrial device to publicly announce its identity, firmware version, and upgrade request status in a standardized manner under normal conditions. By configuring specific Bluetooth broadcast data packets and a custom Generic Attribute Profile (GATT) service, industrial devices establish standardized interfaces for discovery, connection, and control interaction with external parties (mobile terminal apps or other industrial devices). This lays the communication foundation for subsequent intelligent discovery, reliable connection, and command interaction.

[0082] S2, the mobile terminal triggers the first device upgrade and reliable file transfer. The core function of this step is to establish a one-to-one reliable connection between the mobile terminal (such as a mobile app) and the first device in the industrial equipment cluster (i.e., the first industrial device to undergo firmware upgrade). Through the mature Ymodem file transfer protocol, the complete firmware upgrade package is securely and completely injected into the device network composed of various industrial devices in the industrial equipment cluster. This can be initiated via a mobile app, connecting to and upgrading the first device, Device A. Device A restarts after the upgrade is complete. The specific implementation process is the same as in the previous embodiment and will not be repeated here. This ensures the absolute correctness of the initial firmware data, serving as a reliable starting point for the entire decentralized relay diffusion process and the only manual trigger point and data source for the entire upgrade task.

[0083] S3, the autonomous switching and state transition of the primary device role, is a crucial turning point for achieving "decentralization" and "relay." Its main function is to transform the industrial equipment that has completed its upgrade from a passive "upgrade target" to an active "upgrade initiator." Driven by its internal state machine, the industrial equipment automatically switches Device A's Bluetooth working mode from slave to master and enters the active scanning state DEVICE_STATE_MASTER_SCANNING. Device A initiates its Bluetooth scanning function to check if the device to be upgraded has been detected. If no device is detected or the scan times out, it returns to the scanning state and continues scanning. Based on the device data (such as signal strength (RSSI) and remaining battery power) of the scanned industrial equipment, it determines the next device to be upgraded (such as Device B). If Device B is detected, a Bluetooth connection is established, and the firmware upgrade package is sent to Device B for its upgrade. The specific implementation process is the same as in the previous embodiment and will not be repeated here. This transformation endows ordinary devices with the ability to relay information intelligently, which is the core mechanism that enables upgrade tasks to spread automatically.

[0084] S4, a state machine-driven intelligent relay upgrade diffusion, switches Device B to the master state after it completes the upgrade and restarts. Device B then scans and controls the upgrade of the next device to be upgraded (such as Device C), continuing the chain-like firmware upgrade process until the last device in the industrial equipment cluster has been upgraded. This step is the core execution loop of the entire solution, enabling the self-organized propagation of upgrade tasks within the industrial equipment cluster. Its core function is to manage the dynamic switching of each industrial device between the three roles of master, slave, and idle broadcast device, the establishment and maintenance of Bluetooth connections, and point-to-point firmware transmission based on the Ymodem protocol through a finely designed state machine that includes error handling. This state machine ensures the reliability, fault tolerance, and efficiency of the upgrade process, allowing upgrade tasks to be automatically and orderly passed between industrial devices like a relay baton.

[0085] S5, Upgrade Progress Synchronization, Anomaly Handling, and Task Completion, is the monitoring, assurance, and optimization phase of the upgrade process. Its core functions are to achieve global visualization of the upgrade status, handle various anomalies that occur during the upgrade process, and ensure system recoverability after upgrade failure. The specific implementation process is the same as in the aforementioned embodiments and will not be repeated here. By defining status reporting characteristic values, the progress of each industrial device can be monitored in real time. Mechanisms such as automatic retry and safe rollback are designed to improve system robustness. The logs and data throughout the process also provide a basis for subsequent system optimization.

[0086] This embodiment of the method can achieve at least one of the following effects: 1) Highly efficient decentralized upgrade: Completely eliminates dependence on fixed gateways, relay nodes, or cloud platforms. Upgrade tasks are automatically propagated through intelligent relay between industrial devices. Maintenance personnel only need to initiate the upgrade once, greatly improving the upgrade efficiency of large-scale industrial device clusters and reducing labor costs and operational risks in hazardous environments (such as tunnels already in operation). 2) Highly reliable data transmission: Abandoning unreliable broadcast methods, it adopts point-to-point (P2P) Bluetooth GATT connections combined with the mature Ymodem protocol for data transmission. The Ymodem protocol's built-in cyclic redundancy check (CRC) and ACK / NAK retransmission mechanisms ensure the integrity and reliability of data transmission in complex wireless environments, effectively solving the data packet loss problem in existing broadcast schemes. 3) Adaptive network and strong robustness: The state machine-based design enables each industrial device to make autonomous decisions. Connection failures will automatically retry or find new targets; device failures or offline status will not affect the overall propagation process; new industrial devices can be automatically discovered and upgraded after joining the network. The system has self-healing capabilities and does not depend on a fixed topology. 4) Optimized resource utilization and power consumption: Industrial devices establish high-speed data connections only when upgrading neighbors and disconnect immediately afterward. Most of the time, they operate in low-power scanning or idle broadcasting states, which is beneficial for energy management of the entire device network. Simultaneously, the solution eliminates the need to reserve a complete firmware backup area on the device side, saving Flash resources. 5) Clear global status visibility: By defining upgrade status characteristic values, the upgrade status of each industrial device can be reported to a mobile app in real time, providing maintenance personnel with global visual monitoring of the entire upgrade process, facilitating problem localization and progress management.

[0087] According to an embodiment of the present invention, an industrial equipment firmware upgrade system is also provided. The system includes: a mobile terminal; and multiple industrial devices, wherein one of the multiple industrial devices is connected to the mobile terminal via Bluetooth, and the multiple industrial devices are respectively used to execute any one of the above-described industrial equipment firmware upgrade methods.

[0088] Optionally, the multiple industrial devices are multiple smart Bluetooth devices: each device includes a Bluetooth dual-mode chip, Flash memory, and a main control state machine program running on it. This program can implement any of the aforementioned industrial device firmware upgrade methods, namely, it can implement state machine logic, dynamic Bluetooth role switching, GATT service response and initiation, and Ymodem protocol parsing and execution functions. A management program runs on the mobile terminal; this program is a WeChat mini-program or a native application (APP) installed on the mobile terminal (such as a smartphone). It serves as the sole trigger point for the entire upgrade task, responsible for connecting the first device among the multiple industrial devices, sending the firmware upgrade package via the Ymodem protocol, and receiving and displaying the global upgrade progress.

[0089] This embodiment also provides an industrial equipment firmware upgrade device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0090] According to an embodiment of the present invention, an apparatus embodiment for implementing the above-described industrial equipment firmware upgrade method is also provided. Figure 5 This is a schematic diagram of the structure of an industrial equipment firmware upgrade device according to an embodiment of the present invention, as shown below. Figure 5 As shown, the aforementioned industrial equipment firmware upgrade device includes: an upgrade package receiving module 500, a firmware upgrade module 502, a data receiving module 504, a device selection module 506, and an upgrade package sending module 508, wherein:

[0091] The upgrade package receiving module 500 is used to receive the firmware upgrade package sent by the sending device, wherein the sending device is a mobile terminal or the previous industrial device, and the previous industrial device is the industrial device that has completed the firmware upgrade most recently among multiple industrial devices.

[0092] Firmware upgrade module 502, connected to upgrade package receiving module 500, is used to upgrade the firmware of target industrial equipment among multiple industrial devices based on firmware upgrade package;

[0093] The data receiving module 504 is connected to the firmware upgrade module 502 and is used to receive the device data corresponding to each of the multiple industrial devices to be upgraded when the firmware upgrade of the target industrial device is completed.

[0094] The equipment selection module 506 is connected to the data receiving module 504 and is used to determine the next industrial equipment from the multiple equipment to be upgraded based on the equipment data corresponding to each of the multiple equipment to be upgraded.

[0095] The upgrade package sending module 508 is connected to the device selection module 506 and is used to send the firmware upgrade package to the next industrial device for firmware upgrade of the next industrial device.

[0096] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0097] It should be noted that the upgrade package receiving module 500, firmware upgrade module 502, data receiving module 504, device selection module 506, and upgrade package sending module 508 mentioned above correspond to steps S102 to S110 in the embodiments. The instances and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run in a computer terminal.

[0098] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0099] The aforementioned industrial equipment firmware upgrade device may also include a processor and a memory. The upgrade package receiving module 500, firmware upgrade module 502, data receiving module 504, device selection module 506, upgrade package sending module 508, etc., are all stored in the memory as program modules, and the processor executes the aforementioned program modules stored in the memory to realize the corresponding functions.

[0100] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0101] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the aforementioned industrial equipment firmware upgrade methods.

[0102] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0103] Optionally, a program that controls the device containing the non-volatile storage medium to execute any of the above-mentioned industrial equipment firmware upgrade method steps during program execution.

[0104] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the above-described industrial equipment firmware upgrade methods.

[0105] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is adapted to execute a program that initializes the industrial equipment firmware upgrade method steps described above.

[0106] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of any of the above-described industrial equipment firmware upgrade methods.

[0107] The order of the above embodiments of the present invention is merely for description and does not represent the superiority or inferiority of the embodiments.

[0108] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of modules described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between modules, and may be electrical or other forms.

[0110] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0111] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0112] If the aforementioned integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0113] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A firmware upgrade method for industrial equipment, characterized in that, include: The firmware upgrade package sent by the sending device is received. The sending device is a mobile terminal or a previous industrial device. The previous industrial device is the industrial device that has completed the firmware upgrade most recently among multiple industrial devices. Based on the firmware upgrade package, the target industrial equipment among the plurality of industrial devices is upgraded with firmware. Upon completion of the firmware upgrade of the target industrial equipment, device data corresponding to each of the multiple industrial equipment to be upgraded is received. Based on the equipment data corresponding to each of the plurality of devices to be upgraded, the next industrial device is determined from the plurality of devices to be upgraded; The firmware upgrade package is sent to the next industrial device for firmware upgrade.

2. The method according to claim 1, characterized in that, When the target industrial device is the first device among the plurality of industrial devices, the sending device is the mobile terminal, wherein the first device is the first device to perform a firmware upgrade; If the target industrial equipment is not the first equipment, the sending equipment is the previous industrial equipment.

3. The method according to claim 1, characterized in that, When the device data includes signal strength and remaining battery power, the step of determining the next industrial device from the plurality of devices to be upgraded based on the device data corresponding to each of the plurality of devices to be upgraded includes: From the plurality of devices to be upgraded, determine a plurality of candidate devices whose remaining power is greater than a first power threshold; Determine the first weight corresponding to the signal strength and the second weight corresponding to the remaining battery power; Based on the signal strength and remaining power of each of the multiple candidate devices, the first weight and the second weight are weighted and summed to obtain the score value of each of the multiple candidate devices. Based on the score values ​​corresponding to each of the multiple candidate devices, the next industrial device is determined from the multiple candidate devices.

4. The method according to claim 1, characterized in that, When the firmware upgrade of the target industrial equipment is completed, the system receives device data corresponding to each of the multiple industrial devices to be upgraded, including: When the firmware upgrade of the target industrial equipment is completed, the target industrial equipment is controlled to start Bluetooth scanning, wherein the Bluetooth scanning is used to identify the device among the plurality of industrial devices whose corresponding upgrade flag bit is a predetermined identifier; The devices whose corresponding upgrade flag is a predetermined identifier are designated as the plurality of upgrade-needed devices; Send Bluetooth connection requests to the plurality of devices to be upgraded; If a Bluetooth connection is successfully established with the plurality of devices to be upgraded based on the Bluetooth connection request, device data corresponding to each of the plurality of devices to be upgraded is received.

5. The method according to claim 1, characterized in that, The method further includes: If any of the multiple devices to be upgraded fails to establish a Bluetooth connection, a new Bluetooth connection request is sent to the device to be upgraded to retry the Bluetooth connection operation with the device to be upgraded, and the cumulative number of retries is recorded. Repeat the Bluetooth connection operation until a successful Bluetooth connection is established with any of the devices to be upgraded, or until the cumulative number of retries reaches the predetermined number of retries.

6. The method according to claim 1, characterized in that, When the firmware upgrade of the target industrial equipment is completed, the system receives device data corresponding to each of the multiple industrial devices to be upgraded, including: After the firmware upgrade of the target industrial equipment is completed, it is detected whether the remaining power of the target industrial equipment is greater than the second power threshold. When the remaining power of the target industrial equipment is greater than the second power threshold, the equipment data corresponding to each of the plurality of equipment to be upgraded is received.

7. The method according to any one of claims 6, characterized in that, The method further includes: If the remaining power of the target industrial equipment is less than or equal to the second power threshold, a power reminder message is sent to the sending device to prompt the sending device to send the firmware upgrade package to other industrial equipment to be upgraded, excluding the target industrial equipment.

8. The method according to any one of claims 1 to 7, characterized in that, The receipt of the firmware upgrade package sent by the sending device includes: receiving the firmware upgrade package sent by the sending device based on the Yale modem protocol; Sending the firmware upgrade package to the next industrial device includes: sending the firmware upgrade package to the next industrial device based on the Ymodem protocol.

9. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Before receiving the firmware upgrade package, the target industrial equipment is controlled to operate according to the first energy consumption level; During the firmware upgrade process, the target industrial equipment is controlled to operate according to a second energy consumption, wherein the first energy consumption is less than the second energy consumption. From the completion of the firmware upgrade of the target industrial equipment to the sending of the firmware upgrade package to the next industrial equipment, the target industrial equipment is controlled to operate according to the third energy consumption, wherein the second energy consumption is less than the third energy consumption; After the firmware upgrade package is sent to the next industrial device, the target industrial device is controlled to operate according to the first energy consumption.

10. An industrial equipment firmware upgrade device, characterized in that, include: The upgrade package receiving module is used to receive the firmware upgrade package sent by the sending device, wherein the sending device is a mobile terminal or the previous industrial equipment, and the previous industrial equipment is the industrial equipment that has completed the firmware upgrade most recently among multiple industrial equipment. A firmware upgrade module is used to perform firmware upgrades on target industrial equipment among the plurality of industrial devices based on the firmware upgrade package. The data receiving module is used to receive the device data corresponding to each of the multiple industrial devices to be upgraded when the firmware upgrade of the target industrial device is completed. The equipment selection module is used to determine the next industrial equipment from the plurality of equipment to be upgraded based on the equipment data corresponding to each of the plurality of equipment to be upgraded. The upgrade package sending module is used to send the firmware upgrade package to the next industrial device for firmware upgrade of the next industrial device.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the industrial equipment firmware upgrade method according to any one of claims 1 to 9.

12. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores multiple instructions, which are adapted to be loaded by a processor and executed by the industrial equipment firmware upgrade method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the industrial equipment firmware upgrade method according to any one of claims 1 to 9.

Images