Program backup and upgrade method of multi-level embedded industrial control system

Abstract

The invention discloses a program backup and upgrade method for a multi-level embedded industrial control system. The method comprises a backup process and an upgrade process. The backup process comprises the steps of generating a backup file, obtaining the length of storage information, reading data segments in sequence after judging whether the length of the storage information is 0 or not, encrypting the data segments and putting the encrypted data segments into the backup file until all the data segments are encrypted and put into the backup file, and completing the backup process; the upgrading process comprises the steps of obtaining upgrading data segments for verification, writing the upgrading data segments into an APP program area of the FLASH memory after verification is passed until all the upgrading data segments are written, and completing the upgrading process. According to the method, a unique encryption mode is adopted, the upgrading firmware of the program is encrypted and verified during use, and the confidentiality of the original upgrading firmware is guaranteed. Due to the design of the multilevel structure upgrading process and the encryption method, program upgrading is more efficient and convenient, and meanwhile the safety and stability of the system are ensured.

Description

Technical Field

[0001] The present invention relates to the field of embedded industrial control technology, and in particular to a program backup and upgrade method for a multi-level embedded industrial control system. Background Art

[0002] In the current booming embedded industrial control field, many devices require multiple modules to work together, and each module has independent program firmware. However, if the program upgrade is not carried out in an appropriate way, each program burning will take a lot of time and require the participation of professionals. In addition, some modules are installed inside the device and are difficult to remove, which significantly reduces the efficiency of device updates.

[0003] Currently, program upgrade methods in embedded systems are mainly divided into two categories: updates through boot loaders and software upgrades through applications. However, these methods also have some shortcomings. For example, updating the boot loader itself is dangerous because a failed update may damage the device and is usually not repairable by the end user, and may require a factory repair. In addition, using a package manager to update may not be very applicable in embedded systems because embedded systems usually use well-tested specific software, and package managers may cause the software to be split into multiple packages, which may complicate testing and version control.

[0004] For program backup, microcontroller embedded systems can generally use methods including hardware interface reading, Bootloader firmware upgrade, dual-zone backup, remote automatic update (OTA), file system backup, system image backup, etc. However, in the backup process, data faces security risks during transmission and is vulnerable to unauthorized access and tampering. Summary of the invention

[0005] The purpose of the present invention is to address the deficiencies of the prior art and to propose a program backup and upgrade method for a multi-level embedded industrial control system.

[0006] In order to solve the above technical problems, the technical solution of the present invention is: The present invention provides a program backup and upgrade method for a multi-level embedded industrial control system, wherein the multi-level embedded industrial control system comprises a display module, a core control module and a secondary control module, wherein the display module is connected in communication with the core control module and realizes the upgrade and backup of the core control module; the core control module is connected in communication with the secondary control module and uses the core control module as a transfer to realize the upgrade and backup of the secondary control module by the display module; The internal Flash of the chips of the display module, the core control module and the secondary control module is divided into a Bootloader program area and an APP program area; The program backup and upgrade method includes a backup process and an upgrade process; The backup process includes: Generate a backup file, obtain the storage information length of the APP program area, determine whether the storage information length is 0, and then read the data segments in the APP program area in order, encrypt the data segments and put them into the backup file, until all data segments are encrypted and put into the backup file, and the backup process is completed; The upgrade process includes: Erase the APP program area of ​​the FLASH inside the MCU (microcontroller unit), obtain the upgrade data segment for verification, and write the upgrade data segment into the APP program area of ​​the FLASH inside the MCU after the verification passes, until all the upgrade data segments are written into the APP program area of ​​the FLASH inside the MCU, completing the upgrade process.

[0007] Furthermore, in the upgrade process, the upgrade process of the display module is specifically: S11: The display module receives the upgrade instruction, obtains the file containing the upgrade data in the external memory, and erases the APP program area of ​​the MCU internal FLASH; S12: extract the upgrade data segments in the file in order, verify the current upgrade data segment, and identify whether the verification is passed. If so, enter S13; if not, the process ends and a "failed upgrade" signal is fed back to the display module; S13: Write the current upgrade data segment into the APP program area of ​​the MCU internal FLASH, and the Flash address is offset; the offset of the Flash address is the same as the size of the upgrade data segment; S14: Determine whether all the upgrade data segments in the file have been completely written into the APP program area of ​​the MCU internal FLASH. If so, a "successful upgrade" signal is fed back to the display module. If not, return to S12.

[0008] Among them, the method for generating the file containing the upgrade data is: dividing the upgrade data into multiple upgrade data segments, sequentially concatenating each upgrade data segment with the module identifier and the custom identifier, and then using the MD5 algorithm to generate an encrypted ciphertext, inserting the encrypted ciphertext into the corresponding upgrade data segment, until the encryption of all upgrade data segments is completed, to obtain the file containing the upgrade data.

[0009] Furthermore, in the upgrade process, the upgrade process of the core control module or the secondary control module is specifically: S21: The core control module or the secondary control module receives the upgrade instruction sent by the display module and erases the APP program area of ​​the FLASH inside the MCU; S22: Acquire the upgrade data segment sent by the display module; S23: Verify the acquired upgrade data segment to identify whether the verification is passed. If so, proceed to S24; if not, feed back an "upgrade failure" signal to the display module; S24: writing the verified upgrade data segment into the buffer of the Bootloader program area of ​​the core control module or the secondary control module; the display module determines whether all upgrade data segments have been sent, if so, entering S25; if not, returning to S22; S25: Write all the upgrade data segments in the buffer into the APP program area of ​​the FLASH inside the core control module or the secondary control module MCU, and at the same time, the Flash address is offset, and an "upgrade success" signal is fed back to the display module; the offset of the Flash address is the same as the size of all the upgrade data segments.

[0010] Furthermore, in the above upgrade process, the verification method is: concatenate the current upgrade data segment with the module identifier and the custom identifier, and then use the MD5 algorithm to generate a verification ciphertext, and compare the encrypted ciphertext corresponding to the current upgrade data segment with the verification ciphertext. If they are the same, the verification passes.

[0011] Furthermore, in the backup process, the backup process of the display module is specifically: S31: The display module receives the backup instruction and generates a backup file in the external memory; S32: The display module obtains the storage information length of the APP program area from the MCU internal FLASH, and determines whether the storage information length is 0; if it is 0, enter S33; if not 0, enter S34; S33: The display module obtains the i-th data segment in the APP program area, and determines whether the current data segment is all 0xFF. If so, the process ends, and if not, the process executes S35; wherein i=1,...,n, and n is the total number of data segments; S34: The display module obtains the i-th data segment in the APP program area, records the total length of the obtained data segments, and determines whether the total length of the obtained data segments exceeds the storage information length obtained in S32. If so, the process ends; otherwise, the process executes S35; wherein i=1,...,n, and n is the total number of data segments; S35: Data segment After being concatenated with the module identifier and the custom identifier, the encrypted ciphertext is generated using the MD5 algorithm. After the encrypted ciphertext is inserted into the corresponding data segment, the encrypted data segment is obtained and placed in the backup file generated by the external storage device. Then, the following operations are performed: If the length of the stored information is 0, return to S33; if the length of the stored information is not 0, return to S34.

[0012] Furthermore, in the backup process, the backup process of the core control module or the secondary control module includes the following steps: S41: the core control module or the secondary control module receives the backup instruction sent by the display module, and the display module generates a backup file in the external memory; S42: The core control module or the secondary control module obtains the storage information length of the APP program area from the internal FLASH of the MCU, and determines whether the storage information length is 0; if it is 0, enter S43; if not 0, enter S44; S43: The core control module or the secondary control module obtains the data segment in the APP program area , determine whether the current data segment is all 0xFF, if so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends; if not, execute S45; S44: The core control module or the secondary control module obtains the data segment in the APP program area , record the total length of the acquired data segments, and determine whether the total length of the acquired data segments exceeds the length of the storage information acquired in S42. If so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends. If not, execute S45; S45: The display module displays the data segments sent by the core control module and the secondary control module. After being concatenated with the module identifier and the custom identifier, the encrypted ciphertext is generated using the MD5 algorithm and inserted into the data segment. After that, the encrypted data segment is obtained and placed in the external memory backup file, and then the following operations are performed: If the length of the storage information obtained by the core control module or the secondary control module is 0, return to S43, and make If the length of the storage information obtained by the core control module or the secondary control module is not 0, then return to S44, and .

[0013] Another object of the present invention is to provide a program backup and upgrade system for a multi-level embedded industrial control system that implements the above method, comprising: Upgrade module, which upgrades the programs of multi-level embedded industrial control systems; The backup module backs up the programs of the multi-level embedded industrial control system.

[0014] Another object of the present invention is to provide an electronic device comprising a processor and a memory, wherein the memory stores machine executable instructions that can be executed by the processor, and the processor executes the machine executable instructions to implement the above method.

[0015] Another object of the present invention is to provide a machine-readable storage medium, which stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the above method.

[0016] Compared with the prior art, the present invention has the following beneficial effects: The present invention provides a program backup and upgrade method for a multi-level embedded industrial control system. The upgrade and backup process is divided into operations of different modules, which is easy to manage and maintain, and at the same time improves the flexibility of operation; the data segment is encrypted during the process of program backup or upgrade, which increases the security, integrity and correctness of the data and reduces the risk of errors during the upgrade or backup process. In addition, when a file is created in the Bootloader program (the boot program before the system starts) after the upgrade or backup process starts, the program information contained in the APP program will be obtained into the file, and the device type and version information corresponding to the file can be known without decrypting the file, which is convenient for identifying the validity of the encrypted file; adding the storage information length in the program information can effectively avoid the situation in which the APP program cannot be started due to misjudgment that all data is 0xFF during the backup process, and effectively solves the problem of being unable to determine the end of the program. The method is applicable to multi-level systems and has good versatility and adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments, wherein: Figure 1 A schematic diagram of the overall framework provided by an embodiment of the present invention.

[0018] Figure 2 A schematic diagram of the upgrade process of the display module APP program provided in an embodiment of the present invention.

[0019] Figure 3 This is a diagram of the upgrade flow module verification process provided by an embodiment of the present invention.

[0020] Figure 4 Schematic diagram of the upgrade process of the core control module and secondary control module APP program provided in an embodiment of the present invention.

[0021] Figure 5 The following is a schematic diagram of the overall backup process provided by an embodiment of the present invention.

[0022] Figure 6 A schematic diagram of the backup process of the display module APP program provided in an embodiment of the present invention.

[0023] Figure 7A schematic diagram of the backup process of the core control module and the secondary control module APP program provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0025] The terms "including" and "having" and any variations thereof mentioned in the embodiments of the present invention are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0026] This embodiment is aimed at the program maintenance function requirements of the control system of a fully automatic jacquard glove machine. Taking the fully automatic jacquard glove machine control system with a multi-layer structure as an example, the steps of the program backup and upgrade method of the multi-layer embedded industrial control system provided by the present invention are described; specifically, Figure 1 As shown, the control system of the fully automatic jacquard glove machine adopts a three-layer structure, including: The first layer includes the display module, which is responsible for upgrading and backing up the APP program of the display module.

[0027] The second layer includes the core control module, specifically the main control module and the head module; it uses the CAN-FD bus to implement the upgrade and backup of the APP program of the core control module.

[0028] The third layer includes secondary control modules, specifically the whole beating machine module and the head rear bed module; it uses the CAN-FD bus to realize the communication between the display module and the core control module. The core control module acts as a data transfer and communicates with the secondary control module through the CAN bus to realize the upgrade and backup of the secondary control module APP program by the display module.

[0029] Each module in the system has its device ID to identify whether the received CAN-FD command controls the device.

[0030] Each module in the system includes a Bootloader program and an APP program, which are stored in the 0x8000000 and user program addresses in the internal Flash of the chip respectively. The user program address is determined according to the size of the Bootloader program and the size of the internal Flash sector, and is usually set to 0x8020000 or 0x8040000. This embodiment uses 0x8040000 as the user program address.

[0031] Each module in the system has a Bootloader program and an APP program. The module operation mode is to enter the Bootloader program at startup. If specific conditions are not met, the Bootloader will directly jump to the address 0x8040000 to enter the APP program, thereby ensuring the normal operation of the module.

[0032] The specific conditions include the display module identifying whether the key on the matrix keyboard is long pressed before power-on, and other modules recording the RTC backup register flag and then performing a soft reset after receiving the display module command, entering the Bootloader program according to the identified flag, and clearing the flag after entering to ensure that it can directly enter the APP program when it starts normally next time.

[0033] The program information is stored at the address of the fixed offset 0x20000 of the APP program starting address, including the program type, program version and program size. The program type and program version can be modified in the APP program, while the program size needs to be generated in the .upi function and modified through the upgrade process, otherwise the program size is 0.

[0034] The program information is part of the APP program and will be added to the encrypted file. Its function is to allow the display module to know the device type and version information corresponding to the file without decryption, and quickly identify the validity of the encrypted file. The effective program size can also determine the accurate range of the program and improve the stability of program upload.

[0035] The system adopts a touch screen combined with a USB flash drive to perform human-computer interaction and file management.

[0036] The encryption method is as follows: Divide the data in the file into multiple data segments, sequentially concatenate each data segment with the module identifier and the custom identifier, and then use the MD5 algorithm to generate encrypted ciphertext. Insert the encrypted ciphertext into the corresponding data segment until all data segments are encrypted. In this embodiment, the data segment size is 30K, that is, the data in the file is divided into multiple 30K data segments for sequential segment encryption; the encrypted ciphertext length is 16 bytes; The module identifier is the CID (Component Identifier) ​​of each module. The CID generation satisfies the following formula: Generate CID by obtaining the chip's cpuid. CID is a 32-bit integer data.

[0037] The custom identifier is 12 bytes of user-definable data, which is written in the computer and the Bootloader program.

[0038] The file is generated by computer generation or backup function, wherein: The process of generating upi file by computer is as follows: The user provides the bin program file of the device.

[0039] The computer program obtains the size of the bin file and writes it to the location of the bin file offset 0x20000+16 bytes from the file header.

[0040] The position of the offset file header 0x20000+16 bytes is the 4-byte program size content stored in the program information of the APP program.

[0041] The computer program uses the file encryption method to obtain the bin file data content in segments, append the encrypted text, and write it into the upi file until the bin file is finished reading.

[0042] The process of the backup function is as follows: The backup function also uses the file encryption method to generate files. Compared with the computer-generated upi files, the display module backup includes a variety of situations: For the chip to be backed up, the program size value (storage information length) in the above program will be checked first. If it is 0, the end signal is determined by judging whether the Flash data content obtained this time is all 0xFF. If it is not 0, the size is obtained, and the end signal is determined by judging whether the Flash data content obtained this time exceeds the size. Determining the program size can prevent the situation where the obtained data is all 0xFF but is actually part of the APP program, causing the APP program to fail to start.

[0043] For the display module Bootloader program, the corresponding situations are as follows: Back up your own APP program. When the program size is 0, after generating the file, it will return to the starting address offset X of the APP program, re-acquire the data segment, write the determined program size to the corresponding buffer location, regenerate the verification code of the data segment, and write the modified file size to the 0x20000+16+16*n position after the file header offset, and re-write the verification code to the file header offset X+data segment+16*n. The purpose of using this method is to ensure that when the file is upgraded, not only the program size content in the program information can be modified, but also the verification part of the upgrade process can be passed. This method will also be used in the subsequent backup of lower-level programs.

[0044] The offset address X satisfies the following formula: The n in 16*n is because a 16-byte check code will be generated each time a data segment is obtained. Each time a data segment check code is generated, it needs to be offset by 16 bytes in the file. Therefore, the address that needs to modify the program size here needs to be offset by 16*n bytes. When the program size obtained is not 0, no other operation is required.

[0045] The backup core control module and the secondary control module, after generating the file, locate the file header to the file 0x20000 +16 + 16*n, the 16*n is as described above, obtain the program size content, if it is 0, modify the program size content, locate the file header to the file starting offset X, re-acquire the data segment, and generate a new checksum, write it to the file header offset X + data segment + 16 * n; if it is not 0, no other operation is required.

[0046] The naming method of the encrypted file in the file generation method specifically includes: The prefix of the file generated by the host computer is the CID of the corresponding chip and the date and time when the file is generated. Each part is separated by a hyphen. The file suffix is ​​.upi, such as 83030C00_20240325.upi.

[0047] The file prefix generated by the backup function is BK plus the module CID and the file generation sequence number, each part is separated by a hyphen, and the suffix is ​​.upi, such as BK_83030C00_001.upi. The ID number in the generated file name is called DID, which is an 8-bit hexadecimal string.

[0048] like Figure 2 , the display module APP upgrade process includes the following steps: S11: The display module receives the upgrade instruction, obtains the file containing the upgrade data in the external memory, erases the APP program in the MCU's internal FLASH (Flash memory), and enters S12.

[0049] The MCU internal FLASH of the specified area has a first address of 0x08040000, and the obtained file size is used as the memory area of ​​the range. The file size here is different from the program size in the program information described above, but is the file data size obtained through the file system.

[0050] S12: extract the upgrade data segments in the file in order, verify the current upgrade data segment, and identify whether the verification is passed. If so, enter S13; if not, the process ends and a "failed upgrade" signal is fed back to the display module; The process of obtaining and verifying file data in S12 is as follows: Figure 3 As shown in the figure, as the upgrade verification process of the display module APP program, the display module Bootloader concatenates the current upgrade data segment with the module identifier and the custom identifier, and then uses the MD5 algorithm to generate a 16-byte verification ciphertext, and compares the encrypted ciphertext corresponding to the current upgrade data segment with the verification ciphertext. If they are the same, the verification passes.

[0051] S13: Write the current 30K-byte upgrade data segment into the APP program area of ​​the MCU internal FLASH, and the Flash address is offset by 30K bytes; S14: Determine whether all the upgrade data segments in the file have been completely written into the APP program area of ​​the MCU internal FLASH. If so, a "successful upgrade" signal is fed back to the display module. If not, return to S12.

[0052] During the upgrade process, the display screen will feedback information about the upgrade process, including upgrade progress, whether the upgrade is successful or not, etc.

[0053] During the upgrade process of the core control module and the secondary control module APP program, the display module Bootloader uses the CAN-FD bus to send file data. Figure 4 The upgrade process of the core control module and the secondary control module APP program includes the following steps:

[0054] S21: confirm whether the core control module or the secondary control module receives the upgrade command. If so, erase the APP program area of ​​the FLASH inside the MCU and enter S22. If not, return to S21.

[0055] The upgrade command is used to notify the core control module and the secondary control module to prepare to receive data. The upgrade command includes the DID and CANID in the file name. The display module identifies the file DID to determine the CANID. The core control module confirms the sending path by identifying the CANID, and determines whether to enter the upgrade process through the DID in the upgrade command. If the DID in the upgrade command does not belong to the core control module, the core control module enters the data transfer mode and confirms the CANID of the sending command through the DID to ensure that the upgrade command can be accurately transmitted to the corresponding module. This method is also applicable to upgrade processes at more levels.

[0056] The data transfer mode is due to the fact that the display module and the core control module use the CAN-FD bus, which can use up to 64 bytes of data communication, while the core control module and the secondary control module use the CAN bus, which can only use up to 8 bytes of data communication. Therefore, the core control module is required to act as a data station to convert the content sent down by the display module or uploaded by the secondary control module.

[0057] Specifically, the work of the data transfer station includes: The data exceeding 8 bytes sent by the display module is converted into multiple 8-byte data and transmitted to the secondary control module.

[0058] The multiple 8-byte data uploaded in the secondary control module are merged into 64-byte data and uploaded to the display module; or, the 8-byte data are directly uploaded without merging.

[0059] S22: Acquire the upgrade data segment sent by the display module; S23: Verify the acquired upgrade data segment to identify whether the verification is passed. If so, proceed to S24; if not, feed back an "upgrade failure" signal to the display module; The verification process is as follows Figure 3 As the upgrade verification process of the core control module and the secondary control module, the core control module and the secondary control module receive 30K bytes of data in the buffer, generate 16 bytes of ciphertext through the above encryption method, and compare it with the 16 bytes of ciphertext after the bytes obtained in the segment in the file to determine whether the file data is correct.

[0060] The function of returning the verification failure information is to notify the display module Bootloader program to exit the upgrade process and to notify the user of the upgrade failure information.

[0061] S24: writing the verified upgrade data segment into the buffer of the Bootloader program area of ​​the core control module or the secondary control module; the display module determines whether all upgrade data segments have been sent, if so, entering S25; if not, returning to S22; S25: Write all the upgrade data segments in the buffer into the APP program area of ​​the FLASH inside the core control module or the secondary control module MCU, and at the same time, the Flash address is offset, and an "upgrade success" signal is fed back to the display module; the offset of the Flash address is the same as the size of all the upgrade data segments.

[0062] like Figure 5 In the method of the present invention, the overall process of the backup process is as follows: Back up the APP program of the display module, then back up the APP program of the core control module, and finally back up the APP program of the secondary control module.

[0063] The backup function of the APP program will perform file backup operations on the programs of all system modules and save the newly generated backup files to the U disk according to the naming method of the backup files mentioned above.

[0064] After the backup process is completed, the Bootloader program of the display module rescans the USB disk file and refreshes the screen to display the newly generated backup file.

[0065] Specifically, Figure 6 The backup process of the display module APP program is as follows: The backup procedure of the display module APP program includes the following steps: S31: The display module receives the backup instruction and generates a backup file in the external memory; S32: The display module obtains the storage information length of the APP program area from the MCU internal FLASH, and determines whether the storage information length is 0; if it is 0, enter S33; if not 0, enter S34; S33: Display module obtains the data segment in the APP program area , determine whether the current data segment is all 0xFF, if so, end, if not, execute S35; S34: Display module obtains data segment in APP program area , record the total length of the acquired data segments, and determine whether the total length of the acquired data segments exceeds the length of the storage information acquired in S32, if so, end, if not, execute S35; S35: Data segment After being concatenated with the module identifier and the custom identifier, the encrypted ciphertext is generated using the MD5 algorithm and inserted into the data segment. After that, the encrypted data segment is obtained and placed into the backup file generated by the external storage device, and then the following operations are performed: If the length of the stored information is 0, return to S33, and ; If the length of the stored information is not 0, return to S34 and make .

[0066] The method for determining whether the APP program has been acquired is as described in the above file generation method for the backup function to generate the file, and the acquisition end method is confirmed by confirming the program size in the program information.

[0067] In the backup process of the display module, the file generation operation is as described in the above backup function file generation. If the program size in the acquired program information is 0, the program size content in the file is modified and the verification code of the segment data is modified. Here, the segment data in this embodiment is 30K bytes, which includes the content of the program information.

[0068] like Figure 7 In the backup process, the backup process of the core control module or the secondary control module APP program includes the following steps: S41: Waiting to check whether a backup command is received. If received, the display module generates a backup file in the external memory and enters S42. If not, the display module returns to S41.

[0069] The backup command, if similar to the upgrade command described in S21 above, is used to notify the core control module and the secondary control module to prepare to upload data, and the command includes the DID and CANID of the module to be backed up. The situations include:

[0070] For the backup of the core control module APP program, the display module confirms the DID of the corresponding module and connects the corresponding module in the core control module mainly by modifying the CANID.

[0071] For the backup of the secondary control module APP program, the display module confirms the CANID of one of the core control modules and connects to the corresponding module of the secondary control module mainly by modifying the DID.

[0072] When the core control module receives the CANID and recognizes that the DID does not belong to itself, it enters the data transfer mode.

[0073] The data transfer module is as described in S21 above.

[0074] S42: The core control module or the secondary control module obtains the storage information length of the APP program area from the internal FLASH of the MCU, and determines whether the storage information length is 0; if it is 0, enter S43; if not 0, enter S44; S43: The core control module or the secondary control module obtains the data segment in the APP program area , determine whether the current data segment is all 0xFF, if so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends; if not, execute S45; S44: The core control module or the secondary control module obtains the data segment in the APP program area , record the total length of the acquired data segments, and determine whether the total length of the acquired data segments exceeds the length of the storage information acquired in S42. If so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends. If not, execute S45; S45: The display module sends the 30K byte data segment sent by the core control module and the secondary control module After being concatenated with the 4-byte module identifier and the 12-byte custom identifier, the MD5 algorithm is used to generate a 16-byte encrypted ciphertext, which is then inserted into the data segment. After that, the encrypted data segment is obtained and placed in the external memory backup file, and then the following operations are performed: If the length of the storage information obtained by the core control module or the secondary control module is 0, return to S43, and make If the length of the storage information obtained by the core control module or the secondary control module is not 0, then return to S44, and .

Claims

1. A program backup and upgrade method for a multi-level embedded industrial control system, the multi-level embedded industrial control system comprising a display module, a core control module and a secondary control module; the display module is connected to the core control module for communication and realizes the upgrade and backup of the core control module; the core control module is connected to the secondary control module for communication and realizes the upgrade and backup of the secondary control module by the display module using the core control module as a transfer; The internal FLASH of the chip MCU of the display module, core control module and secondary control module is divided into a Bootloader program area and an APP program area; It is characterized in that The program backup and upgrade method includes a backup process and an upgrade process; The backup process includes: Generate a backup file, obtain the storage information length of the APP program area, determine whether the storage information length is 0, and then obtain the data segments in the APP program area in order, encrypt the current data segment and put it into the backup file until all data segments are encrypted; The upgrade process includes: Erase the APP program area of ​​the MCU's internal FLASH, obtain the upgrade data segment for verification, and write the upgrade data segment into the APP program area of ​​the MCU's internal FLASH after the verification passes, until all upgrade data segments are written into the APP program area of ​​the MCU's internal FLASH, completing the upgrade process.

2. The program backup and upgrade method of a multi-level embedded industrial control system according to claim 1, characterized in that: In the upgrade process, the upgrade process of the display module is specifically as follows: S11: The display module receives the upgrade instruction, obtains the storage file containing the upgrade data from the external memory, and erases the APP program area of ​​the MCU internal FLASH; S12: extract the upgrade data segments in the storage file in order, verify the current upgrade data segment, and identify whether the verification is passed. If so, enter S13; if not, feed back an "upgrade failure" signal to the display module; S13: Write the current upgrade data segment into the APP program area of ​​the MCU internal FLASH, and the Flash address is offset; the offset of the Flash address is the same as the size of the upgrade data segment; S14: Determine whether all the upgrade data segments in the storage file have been completely written into the APP program area of ​​the MCU internal FLASH. If so, feedback is given to the display module with an "upgrade success" signal; otherwise, return to S12.

3. The program backup and upgrade method of the multi-level embedded industrial control system according to claim 2, characterized in that: The upgrade data is divided into multiple upgrade data segments, each upgrade data segment is sequentially concatenated with the module identifier and the custom identifier, and then an encrypted ciphertext is generated using the MD5 algorithm. The encrypted ciphertext is inserted into the corresponding upgrade data segment until the encryption of all upgrade data segments is completed, thereby obtaining the storage file containing the upgrade data.

4. The program backup and upgrade method of a multi-level embedded industrial control system according to claim 1, characterized in that: In the upgrade process, the upgrade process of the core control module or the secondary control module is specifically as follows: S21: The core control module or the secondary control module receives the upgrade instruction sent by the display module and erases the APP program area of ​​the FLASH inside the MCU; S22: Acquire the upgrade data segment sent by the display module; S23: Verify the acquired upgrade data segment to identify whether the verification is passed. If so, proceed to S24; if not, feed back an "upgrade failure" signal to the display module; S24: writing the verified upgrade data segment into the buffer of the Bootloader program area of ​​the core control module or the secondary control module; the display module determines whether all upgrade data segments have been sent, if so, entering S25; if not, returning to S22; S25: Write all the upgrade data segments in the buffer into the APP program area of ​​the FLASH inside the core control module or the secondary control module MCU, and at the same time, the Flash address is offset, and an "upgrade success" signal is fed back to the display module; the offset of the Flash address is the same as the size of all the upgrade data segments.

5. The program backup and upgrade method of a multi-level embedded industrial control system according to any one of claims 1 to 4, characterized in that: The verification method in the upgrade process is: concatenate the current upgrade data segment with the module identifier and the custom identifier, and then use the MD5 algorithm to generate the verification ciphertext. Compare the encrypted ciphertext and the verification ciphertext corresponding to the current upgrade data segment. If they are the same, the verification passes.

6. The program backup and upgrade method of a multi-level embedded industrial control system according to claim 1, characterized in that: In the backup process, the backup process of the display module is specifically as follows: S31: The display module receives the backup instruction and generates a backup file in the external memory; S32: The display module obtains the storage information length of the APP program area from the MCU internal FLASH, and determines whether the storage information length is 0; if it is 0, enter S33; if not 0, enter S34; S33: Display module obtains the data segment in the APP program area , determine whether the current data segment is all 0xFF, if so, end, if not, execute S35; where i=1,...,n, n is the total number of data segments; S34: Display module obtains data segment in APP program area , record the total length of the acquired data segments, and determine whether the total length of the acquired data segments exceeds the length of the storage information acquired in S32. If so, the process ends, and if not, the process executes S35; wherein i=1,...,n, and n is the total number of data segments; S35: Data segment After being concatenated with the module identifier and the custom identifier, the encrypted ciphertext is generated using the MD5 algorithm and inserted into the data segment. After that, the encrypted data segment is obtained and put into the backup file generated by the external storage, and then the following operations are performed: If the length of the stored information is 0, return to S33; if the length of the stored information is not 0, return to S34.

7. The program backup and upgrade method of a multi-level embedded industrial control system according to claim 1, characterized in that: In the backup process, the backup process of the core control module or the secondary control module includes the following steps: S41: the core control module or the secondary control module receives the backup instruction sent by the display module, and the display module generates a backup file in the external memory; S42: The core control module or the secondary control module obtains the storage information length of the APP program area from the internal FLASH of the MCU, and determines whether the storage information length is 0; if it is 0, enter S43; if not 0, enter S44; S43: The core control module or the secondary control module obtains the data segment in the APP program area , determine whether the current data segment is all 0xFF, if so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends; if not, execute S45; where i=1,...,n, n is the total number of data segments; S44: The core control module or the secondary control module obtains the data segment in the APP program area , record the total length of the acquired data segments, and determine whether the total length of the acquired data segments exceeds the storage information length acquired in S42. If so, the core control module or the secondary control module sends an end frame to notify the display module, and the backup process ends. If not, execute S45; wherein i=1,...,n, n is the total number of data segments; S45: The display module displays the data segments sent by the core control module and the secondary control module. After being concatenated with the module identifier and the custom identifier, the encrypted ciphertext is generated using the MD5 algorithm and inserted into the data segment. After that, the encrypted data segment is obtained and put into the external storage backup file, and then the following operations are performed: If the length of the storage information obtained by the core control module or the secondary control module is 0, return to S43; if the length of the storage information obtained by the core control module or the secondary control module is not 0, return to S44.

8. A program backup and upgrade system for a multi-level embedded industrial control system implementing the method described in any one of claims 1 to 7, characterized in that: include: Upgrade modules to upgrade modules in multi-level embedded industrial control systems; The backup module backs up the modules in the multi-level embedded industrial control system.

9. An electronic device, characterized in that: The invention comprises a processor and a memory, wherein the memory stores machine executable instructions that can be executed by the processor, and the processor executes the machine executable instructions to implement the method according to any one of claims 1 to 7.

10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the method described in any one of claims 1 to 7.

Images