Batch updating method and device, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of data processing, and provides a batch updating method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: scanning a local area network, and obtaining an online PLC equipment list; performing matching verification on the online PLC equipment list and a preset updating target list to obtain a to-be-updated target PLC set; sending the target firmware file to each PLC in the target PLC set; receiving a verification response message from each target PLC, wherein the verification response message is used for indicating a result of performing integrity verification on the received firmware file by the target PLC; and under the condition that verification is passed, a firmware updating instruction is sent to each target PLC, and the firmware updating instruction is used for instructing the target PLC to write the received firmware file into an internal storage area of the target PLC while the target PLC keeps running of the current control program of the target PLC.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a batch update method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Programmable Logic Controllers (PLCs), as the core control units of industrial automation systems, are widely used in key sectors such as manufacturing, energy, and transportation. Their reliability and maintainability directly affect the continuous operation and maintenance efficiency of production systems. With the rapid development of industrial internet and intelligent manufacturing technologies, higher demands are placed on the remote management, function iteration, and fault repair capabilities of PLC devices. Efficient and secure firmware updates have become a crucial aspect of ensuring the long-term stable operation of equipment.

[0003] Currently, PLC firmware update technology mainly relies on local physical operations. Common methods include updating using a dedicated programmer connected via cable, writing firmware on a standalone device using a general serial port tool, importing firmware files using a USB flash drive, or sending commands via dedicated software. These methods typically require on-site operation by professional engineers and suffer from problems such as highly specialized tools, cumbersome procedures, imperfect update feedback mechanisms, and difficulties in error handling.

[0004] In summary, existing PLC firmware update methods generally suffer from low update efficiency, which severely restricts the flexibility and response speed of equipment operation and maintenance. Summary of the Invention

[0005] In view of this, embodiments of this application provide a batch update method, apparatus, electronic device, and computer-readable storage medium to solve the problem of low update efficiency of existing PLC firmware in the prior art.

[0006] A first aspect of this application provides a batch update method, including: Scan the local area network to obtain a list of online PLC devices; The online PLC device list is matched and verified with the preset update target list to obtain the target PLC set to be updated; Send the target firmware file to each PLC in the target PLC set; Receive verification response messages from each target PLC. The verification response messages are used to indicate the result of the target PLC's integrity verification of the received firmware file. If the verification passes, a firmware update command is sent to each target PLC. The firmware update command instructs the target PLC to write the received firmware file to its internal storage area while keeping its current control program running.

[0007] A second aspect of this application provides a batch update apparatus, comprising: Module 301 is used to scan the local area network and obtain a list of online PLC devices; The matching module 302 is used to match and verify the online PLC device list with the preset update target list to obtain the target PLC set to be updated; The sending module 303 is used to send the target firmware file to each PLC in the target PLC set; The receiving module 304 is used to receive the verification response message from each target PLC. The verification response message is used to indicate the result of the target PLC's integrity verification of the received firmware file. The sending module 303 is also used to send a firmware update instruction to each target PLC when the verification is successful. The firmware update instruction is used to instruct the target PLC to write the received firmware file into its internal storage area while keeping its current control program running.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The beneficial effects of this application embodiment compared with the prior art are as follows: By scanning the local area network to obtain the list of online PLC devices, active network scanning replaces manual addressing, realizing the automatic discovery and listing of devices to be updated, laying an efficient foundation for batch operations. The online PLC device list is matched and verified with a preset update target list to obtain the set of target PLCs to be updated. This ensures the accuracy of the update target set at the source of operation, effectively preventing erroneous updates of non-target devices and omissions of target devices. The target firmware file is sent to each PLC in the target PLC set. A verification response message is received from each target PLC, indicating the result of the target PLC's integrity verification of the received firmware file. Through an end-to-end integrity verification mechanism, each target PLC is provided with independent data correctness proof, thereby ensuring that the firmware file written is reliable and error-free, eliminating the risk of equipment failure due to transmission errors at the data level. If the verification passes, a firmware update command is sent to each target PLC. The firmware update command instructs the target PLC to write the received firmware file into its internal storage area while keeping its current control program running. By instructing the PLC to perform background writing while maintaining the continuous operation of the main control task, the firmware data can be written into the equipment without interrupting the existing process flow. This enables batch updates of target PLCs, improves the efficiency of PLC firmware updates, and thus improves the flexibility and response speed of equipment operation and maintenance. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a batch update method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating another batch update method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a batch update device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] In industrial automated production lines, especially in scenarios with extremely high requirements for production continuity and environmental cleanliness, such as food, pharmaceutical or precision electronics assembly, the firmware maintenance of programmable logic controllers (PLCs), which serve as the core "brain" of the production line, has long faced a dilemma.

[0015] Imagine a bottling production line controlled collaboratively by dozens of identical PLCs, each managing different stages such as filling, capping, labeling, and palletizing. One day, the equipment manufacturer issues an urgent notice pointing out a potential vulnerability in the firmware of this batch of PLCs. This vulnerability could cause brief anomalies in a specific output signal at certain times. While infrequent, it could lead to microgram-level deviations in single-batch filling or label misalignment. For food companies striving for zero defects, this risk must be eliminated.

[0016] However, traditional firmware update methods are virtually impossible to implement in this scenario. First, non-professionals cannot operate it: production line maintenance electricians are familiar with hardware wiring and program uploading, but they shy away from the firmware update process, which requires a dedicated programmer, connection to a specific debugging port, and execution of complex burning instructions. Second, the update operation is extremely risky; engineers must wire and operate each PLC individually. Any mistake in any step, such as poor communication cable contact, incorrect firmware file selection, or unexpected power outage during the update, could potentially brick a single PLC, completely paralyzing a link in the entire production line. More realistically, the entire production line must be shut down for the update. Every hour of downtime means a huge loss of production and delivery pressure. Simultaneously, engineers updating dozens of devices one by one is time-consuming, and each device must be manually verified for functionality after the update, resulting in a complete production halt during the entire window. At this point, the options are either to continue production despite the unknown risks, or to disassemble the entire batch of PLC modules and send them back to the manufacturer for processing. This not only incurs high logistics and repair costs but also leads to an unplanned and lengthy complete shutdown of the production line. In modern continuous production, the systematic deficiencies of traditional PLC firmware update methods in terms of operability, safety, and economy constitute a pressing pain point that urgently needs to be addressed.

[0017] A batch update method and apparatus according to embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0018] Figure 1This is a flowchart illustrating a batch update method provided in an embodiment of this application. Figure 1 The batch update method is applied to electronic devices where the electronic devices and multiple programmable logic controllers (PLCs) to be updated are located on the same local area network. For example... Figure 1 As shown, this batch update method includes: Step S101: Scan the local area network to obtain a list of online PLC devices; Step S102: Match and verify the online PLC device list with the preset update target list to obtain the target PLC set to be updated; Step S103: Send the target firmware file to each PLC in the target PLC set; Step S104: Receive a verification response message from each target PLC. The verification response message is used to indicate the result of the target PLC's integrity verification of the received firmware file. Step S105: If the verification passes, send a firmware update instruction to each target PLC. The firmware update instruction is used to instruct the target PLC to write the received firmware file into its internal storage area while keeping its current control program running.

[0019] This invention discloses a batch update control method applied in the field of industrial automation. The method is executed by an electronic device acting as a central control console, which is connected to multiple programmable logic controllers (PLCs) to be updated within a local area network (LAN). Here, LAN refers to a local communication network built on the Ethernet protocol. Firmware files are executable image files containing the PLC system's operating program and configuration data. The update target list is a pre-defined list containing identifiers of the PLC devices to be updated.

[0020] In step S101, the console scans the network by sending network probe packets to the local area network. These packets are based on specific industrial communication protocols or general network discovery protocols. All online PLC devices that support the protocol will return response packets to the console upon receiving the probe packets. The console collects these responses, parses out the device identification information contained within, such as device model, serial number, or MAC address, and generates a list of online PLC devices. This utilizes the network layer's active probe and response mechanism to achieve automatic device discovery, avoiding the tedious manual registration of each device's network address.

[0021] Step S102 involves target confirmation of the discovered devices. The control console compares and verifies the online PLC device list obtained in step S101 with the preset update target list. Verification can be done by checking if the number of online devices exactly matches the expected number in the list, or by comparing the unique identifiers of each online device to ensure they are all present in the list. For example, if the preset list contains the serial numbers of one hundred specific model PLCs across ten production lines, step S102 verifies that the online list contains exactly one hundred of these devices. This software logic comparison ensures that subsequent update operations accurately target the intended set of devices, preventing accidental updates to non-target devices or omissions of target devices—a prerequisite for reliable batch operations.

[0022] After confirming the target set, step S103 executes firmware file distribution. The console sends the target firmware file, either in parallel or sequentially, to each device in the target PLC set via the established network connection. Each PLC temporarily stores the file in a designated receive buffer of its internal non-volatile memory. This step, based on a reliable file transfer protocol, reliably transmits the single firmware copy stored at the central node through packet routing and reassembly technology. In step S104, after each target PLC fully receives the firmware file, it performs an integrity verification calculation, such as calculating the cyclic redundancy check (CRC) code or message digest hash value of the file, and sends the calculation result back to the console as a verification response message. By using a verification algorithm to perform deterministic mapping of the data, any bit error occurring during transmission will cause the verification value calculated by the receiving end to differ from the original value, thus effectively detecting data corruption caused by network interference and other reasons.

[0023] Step S105 triggers the firmware update process. Once the console confirms that the verification response message from a PLC has passed verification, it sends a firmware update command to that PLC. This command instructs the PLC to perform a critical operation: without interrupting its currently running main control program, write the verified and complete firmware file, temporarily stored in the receive buffer, to a specific non-volatile memory area called the spare storage area. The PLC's software architecture supports multi-tasking or background processing, allowing the firmware writing operation to be executed in a separate, low-priority background task through task scheduling, thus ensuring that real-time control tasks are unaffected. The spare storage area is physically or logically isolated from the active storage area where the currently running firmware resides; therefore, the write operation will not damage the running system.

[0024] The automatic scanning in step S101 solves the problem of low device discovery efficiency. The matching and verification in step S102 ensures the accuracy of the work objects through software logic, significantly reducing the risk of human error. The combination of steps S103 and S104, through file distribution and independent verification mechanisms, ensures that the firmware copy obtained by each device is complete and error-free, laying a data foundation for subsequent reliable updates. Step S105 allows firmware data to be written while the device is running, decoupling the update process from the production process and avoiding the device downtime required by traditional update methods, thereby greatly improving system availability and the flexibility of update operations. Through centralized scheduling and networked operation on the console, the originally scattered, manual, and high-risk firmware update work is transformed into a standardized operation and maintenance operation that can be remotely executed, batch-processed, and is controllable without affecting production.

[0025] In some embodiments, step S102 includes at least one of the following: Determine whether the number of devices in the online PLC device list matches the expected number specified in the preset update target list; Determine whether the unique identifier of each device in the online PLC device list exists in the preset update target list.

[0026] To ensure the accuracy and safety of the update operation and avoid misoperation of non-target equipment or omission of critical equipment, the matching verification in step S102 can be implemented through one or more of the following logical judgments. The first method is quantity consistency verification, where the console application compares the total number of devices actually found in the online PLC device list with the expected number of devices explicitly specified in the preset update target list to see if they are completely equal.

[0027] For example, a pre-set list may indicate that twenty PLCs numbered 001 to 020 on a certain production line need to be updated this time. If the online list after scanning contains exactly twenty devices, the quantity verification will pass; if only nineteen are found or twenty-one are found, the verification will fail and an alarm will be triggered.

[0028] The second method is identifier inclusion verification. The console extracts the unique identifier of each device in the online list, such as the device serial number, MAC address, or pre-programmed device code, and checks one by one whether all of these identifiers exist in the set of device identifiers recorded in the preset update target list.

[0029] For example, all device identifiers in the online list must have a corresponding entry in the preset list for verification to pass; if an unfamiliar device identifier appears in the online list that is not in the preset list, the verification fails. These two verification mechanisms can be used independently or in combination to form a dual verification.

[0030] By using a programmed comparison, the actual operating environment is required to be consistent with the predetermined plan in terms of equipment scale or specific identity, thereby building a solid defense against the spread of errors at the logical level and ensuring the accurate targeting of batch update operations from the source.

[0031] In some embodiments, the verification response message includes: a first verification value calculated by the target PLC based on the received firmware file; step S105 includes: For each target PLC, the first verification value is compared with the second verification value calculated locally based on the target firmware file; If the comparison matches, the verification is deemed successful, and a firmware update command is sent to the target PLC.

[0032] To establish a reliable end-to-end verification mechanism, the verification response message returned by the target PLC in step S104 specifically includes a key data item: a first verification value, such as an MD5 or SHA-256 hash value, generated by the target PLC based on the firmware file data it has received completely, through a specific cryptographic hash function.

[0033] Accordingly, in step S105, the console performs the following precise operations to determine whether the verification passes or fails: For each target PLC in the network, the console parses the first verification value reported by the PLC from the received verification response message. At the same time, the console itself uses the same hash algorithm to calculate a second verification value from the original data of the target firmware file initially stored locally as the distribution source.

[0034] The console compares the first checksum from the specific PLC bit-by-bit with the locally calculated second checksum. If they match perfectly, it proves that the firmware file copy received by the PLC has not experienced any data errors or tampering during the entire transmission process from the console to the PLC receiver, ensuring file integrity. In this case, the console determines that the verification of the PLC has passed and immediately sends a firmware update command to the PLC. If the comparison does not match, it indicates that there may be data corruption during the transmission process, the verification fails, the console will not send an update command to the PLC, and may trigger a retransmission or error reporting process. Utilizing the deterministic nature of cryptographic hash functions, firmware files of any size are mapped to a short and fixed "digital fingerprint."

[0035] By comparing the "fingerprints" calculated independently by the source and receiver, the integrity of large-scale data transmitted over unreliable networks can be verified efficiently and reliably. This ensures that only devices with intact files will proceed to the subsequent update execution stage, preventing device program malfunctions or even damage due to data errors.

[0036] In some embodiments, prior to step S101, the following is included: By deploying the Dynamic Host Configuration Protocol (DHCP) service in the local area network, each connected PLC is automatically assigned an Internet Protocol (IP) address, enabling electronic devices to communicate with each PLC via network based on their IP addresses.

[0037] To create a plug-and-play, networked batch update environment that requires no manual configuration, the system first performs automated network environment initialization before step S101. Specifically, a Dynamic Host Configuration Protocol (DHCP) service is deployed and run on the local area network (LAN). When multiple PLC devices to be updated are connected to the LAN via network cables, each PLC acts as a DHCP client and automatically sends an address request to the DHCP server.

[0038] The DHCP server dynamically assigns a unique Internet Protocol (IP) address to each requesting PLC from its pre-configured address pool, and simultaneously sends relevant network configuration parameters such as subnet mask and default gateway. After this process, all PLCs within the local area network obtain a valid IP address that can be used for network layer addressing. This allows electronic devices acting as control consoles to establish a precise network communication connection with the target PLC based on the standard IP protocol stack, enabling subsequent device discovery, command transmission, and data transmission and reception.

[0039] By leveraging the mature network protocol DHCP to automate the management of IP address resources, the tedious process of manually setting static IP addresses for each PLC is completely eliminated. This is especially suitable for temporary work scenarios with a large number of devices or frequent device replacements. It not only significantly improves deployment efficiency before batch updates and reduces the risk of network outages due to manual configuration errors, but also ensures that the entire update system has good scalability and environmental adaptability, laying a crucial network communication foundation for the automated execution of subsequent steps.

[0040] In some embodiments, the internal storage area is a backup firmware storage area isolated from the active storage area where the PLC's currently running firmware is located; the firmware update instruction is specifically used to instruct the target PLC to start a writing process independent of its main control task, and to write the firmware file to the backup firmware storage area through the writing process.

[0041] To achieve a silent update mechanism that does not interfere with the normal control function of the PLC during firmware updates, specific limitations were made to the key elements in step S105. Here, the internal storage area refers to a specific non-volatile storage area in the PLC hardware architecture that is physically or logically isolated from the active storage area where the currently running firmware resides; that is, the backup firmware storage area.

[0042] The active storage area holds the real-time control program currently being executed by the PLC, while the backup firmware storage area is dedicated to safely storing new firmware versions awaiting activation. Correspondingly, the firmware update command issued by the console in step S105 specifically instructs the target PLC receiving the command to perform the following precise operation: After parsing the command, the PLC's real-time operating system or firmware management module will dynamically create an independent, low-priority background write process, ensuring that its main control task—the core logic scanning and IO processing task that guarantees continuous production line operation—continues to enjoy the highest scheduling priority and is not interrupted.

[0043] The PLC initiates a separate write process to securely and block-by-block write the verified and complete firmware file data from a temporary receive buffer to a physically isolated backup firmware storage area. By combining a hardware-based dual-storage design with a software-based task isolation scheduling mechanism, the time-consuming and risky firmware write operation is constrained to execute within a dedicated background container. This ensures that the high real-time performance of the main control loop is unaffected by bus occupancy, storage access latency, or processor load fluctuations that may be caused by the write operation, thus achieving true "online" updates. This guarantees that the industrial control system can maintain continuous and stable operation during firmware upgrades, avoiding unplanned downtime.

[0044] In some embodiments, the method further includes: step 201, receiving and monitoring the status report returned by each target PLC after executing the firmware update instruction; Step 202: When the status report indicates that the update has failed, a rollback operation is triggered. The rollback operation is used to keep the firmware version in the current active storage area of ​​the corresponding target PLC unchanged.

[0045] To enhance the robustness of the batch update process and provide safe fault tolerance for update failures, after sending the firmware update command in step S105, the method also includes a status monitoring and automatic rollback mechanism. The console continuously receives and monitors the status report returned by each target PLC after executing the firmware update command. This status report is generated by the PLC's firmware management module, providing real-time feedback on the progress and final result of the writing process. Its content can clearly indicate the status such as update success, update in progress, or update failure, and may include specific error codes.

[0046] When the console detects a status report from a target PLC that explicitly indicates an update failure (e.g., a write verification error, insufficient spare storage space, or abnormal process termination), it immediately triggers a rollback operation for that specific PLC. The core purpose of this rollback operation is to ensure that the failed target PLC can safely maintain its original firmware version in its current active storage area and continue operating normally, through a series of predefined cleanup and recovery instructions.

[0047] Specifically, rollback operations may include instructing the PLC to clear partially written or incomplete data in its spare firmware storage area, and resetting boot flags associated with firmware switching, introducing a compensation mechanism driven by real-time monitoring and feedback of the operation results of individual nodes in distributed batch operations.

[0048] When an abnormal operation of a child node is detected, the system does not freeze or roll back entirely. Instead, it automatically performs a partial recovery for the faulty node, reverting its state to a known, stable working point. This effectively isolates single points of failure, preventing the risk of the entire batch job being interrupted or the devices becoming idle due to the failure of an individual device update, thereby improving the overall success rate and system reliability of large-scale firmware update tasks.

[0049] In some embodiments, a subset of PLCs whose status is "updated successfully" is selected based on the status report; In response to user operation or preset conditions, a restart command is sent to the devices in the PLC subset. The restart command is used to instruct the corresponding PLC to perform a restart operation and load and run the firmware file in its spare storage area during the restart process.

[0050] To complete the final steps of the firmware update and provide flexible control strategies, the method also includes a control restart phase after monitoring the status reports of all target PLCs. The console first filters out PLCs whose status is explicitly marked as successfully updated based on all collected status reports, forming a subset of successfully updated PLCs. This subset includes devices that have successfully written the complete firmware file to their internally isolated backup storage area.

[0051] The console will respond to explicit manual commands from the operator, or to a preset automation condition, such as the arrival of a preset maintenance time window or a successful device percentage reaching a threshold, by sending a restart command to each device in the PLC subset. This restart command instructs the target device to perform a system restart.

[0052] During the device reboot process, its bootloader detects a verified firmware file image in the backup storage area and switches program control to that firmware file, thereby enabling the device to load and start running the new version firmware program in the backup storage area, completing the final firmware upgrade and activation.

[0053] The console employs a status report filtering mechanism to ensure that reboot commands are only sent to devices that have successfully completed the update process, thus preventing system instability that might result from forcibly rebooting devices that failed to update. Simultaneously, delegating the final reboot trigger to the user or a preset strategy provides the possibility of flexibly scheduling system reboot windows based on actual production conditions. This enables precise, secure, and controllable management of when firmware updates take effect, making it a crucial step in seamlessly integrating batch update operations into continuous production processes.

[0054] In the embodiments of this application, by scanning the local area network to obtain a list of online PLC devices, proactive network scanning replaces manual addressing, realizing the automatic discovery and listing of devices to be updated, laying an efficient foundation for batch operations. The online PLC device list is matched and verified with a preset update target list to obtain a set of target PLCs to be updated. This ensures the accuracy of the update target set at the source of the operation, effectively preventing erroneous updates of non-target devices and the omission of target devices. A target firmware file is sent to each PLC in the target PLC set. A verification response message is received from each target PLC, instructing the target PLC on the result of integrity verification of the received firmware file. Through an end-to-end integrity verification mechanism, each target PLC is provided with independent proof of data correctness, thereby ensuring the reliability and accuracy of the firmware file written, eliminating the risk of device failure due to transmission errors at the data level. If the verification passes, a firmware update command is sent to each target PLC. The firmware update command instructs the target PLC to write the received firmware file into its internal storage area while keeping its current control program running. By instructing the PLC to perform background writing while maintaining the continuous operation of the main control task, the firmware data can be written into the equipment without interrupting the existing process flow, thereby improving the flexibility and response speed of equipment operation and maintenance.

[0055] This invention also provides a batch firmware update system for industrial equipment. This system aims to provide a standardized, efficient, and low-risk firmware update environment by using a dedicated centralized control application to host and automate all complex update logic.

[0056] The system's core architecture is a centralized management framework of "single console + multiple devices." The entire process is uniformly scheduled by a single host acting as the control center. This host manages multiple programmable logic controller (PLC) devices awaiting updates across the network throughout their entire lifecycle through a dedicated console application. This framework achieves an integrated closed-loop operation, from automatic device discovery, reliable firmware distribution, update command execution, real-time progress monitoring, to result summary reporting. It transforms the previously scattered, multi-point operations reliant on manual intervention into a one-time, centralized task, significantly reducing manual intervention and the resulting risk of misoperation.

[0057] The system's infrastructure layer consists of three types of general-purpose products: a Dynamic Host Configuration Protocol (DHCP) server for automatically managing network address allocation; one or more standard network switches for providing wired network connectivity; and a host serving as the control center, typically running a common Windows operating system. All three utilize readily available commercial products, eliminating the need for custom development and significantly reducing system deployment costs and complexity. The core capabilities for intelligent updates are encapsulated in a separately developed control application, which is installed and runs on the aforementioned host.

[0058] This control application achieves end-to-end update automation through a series of collaborative functional modules. First, its network device scanning function automatically sends probe packets to the connected local area network after startup, actively identifying and listing all online programmable logic controller devices that conform to the protocol specifications and are awaiting updates, thus establishing an accurate device list for subsequent operations.

[0059] Once the operator manually selects a pre-compiled target firmware file via the graphical interface, the application's firmware file distribution function is activated. This function establishes a network connection with each device in the list to be updated and reliably transmits the selected firmware file to a predefined temporary storage directory or receive buffer within each device, preparing the data source for the update.

[0060] To ensure a flawless transmission process, firmware verification is then triggered. This function is based on cryptographic hash algorithms, such as calculating and comparing the MD5 value of the file. The application calculates the MD5 value of the original firmware file as a baseline and compares it with the MD5 value calculated for the received file on each device. Only devices where both values ​​match perfectly are considered to have successfully transmitted the file and are eligible to proceed to the next stage.

[0061] Subsequently, the automatic firmware flashing function takes over the process, automatically sending firmware flashing commands to all verified devices simultaneously, triggering the update routines within each device. Upon receiving the command, each device, in a background mode that ensures the continuous operation of its main control loop and does not affect existing production tasks, securely writes the temporarily stored firmware file into its internal non-volatile memory. This process is performed synchronously on all target devices, greatly reducing the overall operation time.

[0062] After the update command is executed, the application monitors the return status of each device. Once a device is detected as having successfully completed the flashing process, the automatic device restart function can be triggered according to a preset strategy, sending a restart command to the device to load and run the new firmware, thus making it effective. No abnormalities are ignored throughout the process; the error logging function records the operational status of each device in real time, especially the specific error codes and information of update failures, in a unified flashing log file, providing comprehensive data for subsequent problem tracing and root cause analysis.

[0063] To ensure flexibility in on-site operations, the application also provides granular restart control. Its partial restart function allows batch jobs to perform restarts only on a subset of devices whose updates have been confirmed successful, skipping those that failed or whose status is unclear, thus preventing accidental operation. Simultaneously, the manual restart function gives the operator the final decision-making power for restarts. After observing the system status, the operator can manually trigger a restart via an interface button at an appropriate time, or cancel the automatic restart plan. Finally, all operation steps, device status, and results are clearly and in real-time presented to the operator on the application interface through the update log display function, ensuring the entire process is transparent and controllable.

[0064] Once the target device set is determined, the console simultaneously sends the target firmware file to the designated receiving area on all target devices. Distribution is not a one-time event; the console continuously monitors the status of each distribution task and only allows the process to proceed to the next stage after ensuring that file transfers on all devices are marked as "successful." For devices that fail to transmit, the system can automatically retry or add them to an exception list, thus achieving controllable and traceable management of the entire distribution process.

[0065] To improve batch processing efficiency, the system employs a console-triggered parallel burning / update execution mechanism. After confirming that all target device files have passed verification, the console simultaneously sends firmware update commands to all devices, triggering a parallel background silent write process on each device. This parallel triggering and execution method ensures that the total time for processing N devices is approximately equal to the time for processing a single device, rather than N times that time, thus significantly reducing the overall job time for large-scale batch updates.

[0066] To adapt to complex on-site management needs, the system supports a configurable target equipment selection and group update mechanism. Operators can flexibly filter and specify the specific equipment or equipment groups to be updated based on equipment model, IP address range, asset number, or directly from the scan results on the console interface. This enables the system to support a phased update strategy, such as updating a small number of devices first for verification before rolling it out to all devices, or updating only equipment in a specific workshop, thus providing fine-grained operational control and further reducing the risk of misoperation.

[0067] The system provides automatic one-click reboot and a "partial reboot / cancel reboot" strategy as the final step in the process. Once the silent write operation is complete for all devices, the console can automatically send reboot commands to all successfully updated devices according to a preset strategy, enabling the new firmware to take effect in batches at once. Simultaneously, the system also grants operators significant control: they can cancel automatic reboot and manually trigger it in a subsequent maintenance window; or they can select only the devices that have successfully been written to perform the reboot, excluding those that failed or have questionable status. This flexible reboot strategy facilitates the handling of various abnormal situations during field operations.

[0068] The system constructed in this embodiment achieves a paradigm shift by combining general-purpose infrastructure with dedicated intelligent software. Firmware updates are transformed from an expert-level maintenance task that relies on dedicated hardware, complex manual operations, high risks, and requires downtime, into a standardized process that can be completed simply by clicking an interface and selecting a file on a general-purpose computer. The system eliminates manual addressing through automatic scanning, ensures data security through automatic verification, improves batch efficiency through parallel burning, and decouples the update process from production operations through a silent update mechanism—background writing and controllable restart. Ultimately, this improves the reliability, security, and efficiency of update operations while ensuring the continuity and availability of industrial production lines.

[0069] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0070] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0071] Figure 3 This is a schematic diagram of a batch update device provided in an embodiment of this application. Figure 3 As shown, the batch update device includes: Module 301 is used to scan the local area network and obtain a list of online PLC devices; The matching module 302 is used to match and verify the online PLC device list with the preset update target list to obtain the target PLC set to be updated; The sending module 303 is used to send the target firmware file to each PLC in the target PLC set; The receiving module 304 is used to receive the verification response message from each target PLC. The verification response message is used to indicate the result of the target PLC's integrity verification of the received firmware file. The sending module 303 is also used to send a firmware update instruction to each target PLC when the verification is successful. The firmware update instruction is used to instruct the target PLC to write the received firmware file into its internal storage area while keeping its current control program running.

[0072] According to the technical solution provided in this application, by scanning the local area network, an online PLC device list is obtained. Active network scanning replaces manual addressing, achieving automatic discovery and listing of devices to be updated, laying an efficient foundation for batch operations. The online PLC device list is matched and verified with a preset update target list to obtain a set of target PLCs to be updated. This ensures the accuracy of the update target set at the operation source, effectively preventing erroneous updates of non-target devices and omissions of target devices. A target firmware file is sent to each PLC in the target PLC set. A verification response message is received from each target PLC, indicating the result of the target PLC's integrity verification of the received firmware file. Through an end-to-end integrity verification mechanism, an independent data correctness certificate is provided for each target PLC, ensuring the reliability and accuracy of the firmware file written, thus eliminating the risk of device failure due to transmission errors at the data level. If the verification passes, a firmware update command is sent to each target PLC. The firmware update command instructs the target PLC to write the received firmware file into its internal storage area while keeping its current control program running. By instructing the PLC to perform background writing while maintaining the continuous operation of the main control task, the firmware data can be written into the equipment without interrupting the existing process flow, thereby improving the flexibility and response speed of equipment operation and maintenance.

[0073] In some embodiments, the matching module 302 is specifically used for at least one of the following: Determine whether the number of devices in the online PLC device list matches the expected number specified in the preset update target list; Determine whether the unique identifier of each device in the online PLC device list exists in the preset update target list.

[0074] In some embodiments, the verification response message includes: a first verification value calculated by the target PLC based on the received firmware file; The sending module 303 is specifically used for: For each target PLC, the first verification value is compared with the second verification value calculated locally based on the target firmware file; If the comparison matches, the verification is deemed successful, and a firmware update command is sent to the target PLC.

[0075] In some embodiments, the batch update device further includes: The allocation module is used to automatically assign Internet Protocol (IP) addresses to each connected PLC through the Dynamic Host Configuration Protocol (DHCP) service deployed in the local area network, so that electronic devices can communicate with each PLC over the network based on IP addresses.

[0076] In some embodiments, the internal storage area is a spare firmware storage area that is isolated from the active storage area where the PLC's currently running firmware is located; The firmware update command is specifically used to instruct the target PLC to start a write process independent of its main control task, and to write the firmware file to the backup firmware storage area through the write process.

[0077] In some embodiments, the receiving module 304 is further configured to receive and monitor the status report returned by each target PLC after executing the firmware update instruction; The batch update device also includes: The trigger module is used to trigger a rollback operation when the status report indicates that the update has failed. The rollback operation is used to keep the firmware version in the current active storage area of ​​the corresponding target PLC unchanged.

[0078] In some embodiments, the batch update device further includes: The filtering module is used to filter out a subset of PLCs whose status has been successfully updated based on the status report; The sending module 303 is also used to send a restart command to the devices in the PLC subset in response to user operation or preset conditions. The restart command is used to instruct the corresponding PLC to perform a restart operation and load and run the firmware file in its spare storage area during the restart process.

[0079] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0080] Figure 4 This is a schematic diagram of the electronic device 6 provided in an embodiment of this application. Figure 4 As shown, the electronic device 6 of this embodiment includes a processor 601, a memory 602, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the steps in the various method embodiments described above. Alternatively, when the processor 601 executes the computer program 603, it implements the functions of each module / unit in the various device embodiments described above.

[0081] Electronic device 6 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 6 may include, but is not limited to, processor 601 and memory 602. Those skilled in the art will understand that... Figure 4 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or different components.

[0082] The processor 601 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0083] The memory 602 can be an internal storage unit of the electronic device 6, such as a hard disk or RAM of the electronic device 6. The memory 602 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 6. The memory 602 can also include both internal and external storage units of the electronic device 6. The memory 602 is used to store computer programs and other programs and data required by the electronic device.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0085] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0086] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A batch update method, characterized in that, Applied to electronic devices, where the electronic devices and multiple programmable logic controllers (PLCs) to be updated are located on the same local area network, the method includes: Scan the local area network to obtain a list of online PLC devices; The list of online PLC devices is matched and verified with the preset list of update targets to obtain the set of target PLCs to be updated; Send the target firmware file to each PLC in the target PLC set; Receive a verification response message from each of the target PLCs, the verification response message being used to indicate the result of the integrity verification of the received firmware file by the target PLC; If the verification passes, a firmware update instruction is sent to each of the target PLCs. The firmware update instruction is used to instruct the target PLC to write the received firmware file into its internal storage area while keeping its current control program running.

2. The method according to claim 1, characterized in that, The process of matching and verifying the online PLC device list with the preset update target list includes at least one of the following: Determine whether the number of devices in the online PLC device list is consistent with the expected number specified in the preset update target list; Determine whether the unique identifier of each device in the online PLC device list exists in the preset update target list.

3. The method according to claim 1, characterized in that, The verification response message includes: a first verification value calculated by the target PLC based on the received firmware file; If the verification passes, the step of sending a firmware update command to each of the target PLCs includes: For each target PLC, the first verification value is compared with a second verification value calculated locally based on the target firmware file; If the comparison matches, the verification is deemed successful, and the firmware update command is sent to the target PLC.

4. The method according to claim 1, characterized in that, Before scanning the local area network to obtain the list of online PLC devices, the method further includes: By deploying the Dynamic Host Configuration Protocol (DHCP) service in the local area network, each connected PLC is automatically assigned an Internet Protocol (IP) address, enabling the electronic device to communicate with each PLC via the IP address.

5. The method according to claim 1, characterized in that, The internal storage area is a spare firmware storage area that is isolated from the active storage area where the PLC's currently running firmware is located; The firmware update instruction is specifically used to instruct the target PLC to start a writing process independent of its main control task, and to write the firmware file to the backup firmware storage area through the writing process.

6. The method according to claim 1 or 5, characterized in that, The method further includes: Receive and monitor the status report returned by each of the target PLCs after executing the firmware update instruction; When the status report indicates that the update has failed, a rollback operation is triggered. The rollback operation is used to keep the firmware version in the current active storage area of ​​the corresponding target PLC unchanged.

7. The method according to claim 6, characterized in that, The method further includes: Based on the status report, a subset of PLCs with a status of "updated successfully" is selected; In response to user operation or preset conditions, a restart command is sent to the devices in the PLC subset. The restart command is used to instruct the corresponding PLC to perform a restart operation and load and run the firmware file in its spare storage area during the restart process.

8. A batch update device, characterized in that, This is applied to electronic devices, where the electronic devices and multiple programmable logic controllers (PLCs) to be updated are located on the same local area network, including: The acquisition module is used to scan the local area network and obtain a list of online PLC devices; The matching module is used to match and verify the online PLC device list with the preset update target list to obtain the target PLC set to be updated; The sending module is used to send the target firmware file to each PLC in the target PLC set; A receiving module is configured to receive a verification response message from each of the target PLCs, wherein the verification response message is used to indicate the result of the integrity verification of the received firmware file by the target PLC; The sending module is further configured to send a firmware update instruction to each of the target PLCs if the verification passes. The firmware update instruction is used to instruct the target PLC to write the received firmware file into its internal storage area while maintaining the operation of its current control program.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images