Firmware self-diagnosis method for safety control system

Abstract

The invention discloses a firmware self-diagnosis method for a safety control system. The firmware self-diagnosis method comprises the following steps: step S1; analyzing the original firmware, extracting a block information table and a segment information table of the original firmware, adding a firmware head comprising a version number, compatibility information, generation time, a block verification value and a segment verification value, and generating target firmware containing verification information; s2, in the process of loading the target firmware into the memory, calculating check values of the current loading block and segment in real time, comparing the check values with corresponding values in the block check table and the segment check table, and if the check values are inconsistent, reporting an error; and S3, when the firmware runs, calculating check values of the read-only code segment and the read-only data segment in the memory in real time according to a preset block size. By performing multi-level verification in different stages, fine-grained error detection and quick positioning are realized, and exceptions can be quickly found and accurately positioned, so that debugging and repairing by developers are facilitated.

Description

Technical Field

[0001] The present application relates to the field of industrial automation control, and in particular to a method for self-diagnosis of firmware of a safety control system. Background Art

[0002] With the continuous improvement of industrial automation level, Safety Instrumented System (SIS) has been widely used in high-risk industries such as oil, gas, chemical, pharmaceutical and power generation. SIS system monitors potentially dangerous process status in real time and takes measures to keep it within the safe operating range, thereby ensuring the safety of personnel, assets and environment. In order to meet high safety requirements, such as SIL3 (Safety Integrity Level 3), SIS system needs to have high reliability and stability.

[0003] However, in practical applications, traditional control systems have some shortcomings in self-diagnosis of firmware. Usually, control systems use checksums such as cyclic redundancy check (CRC), MD5, or digital signatures to verify the correctness of the firmware, but this method is mainly limited to the power-on loading stage and cannot achieve real-time detection of firmware integrity during operation. In addition, these methods often cover the entire file, which may lead to a lower error detection probability for larger firmware and make it difficult to effectively identify errors. At the same time, since the checksum of the entire firmware needs to be calculated, the correctness of the firmware cannot be confirmed before the checksum calculation is completed, which reduces the timeliness of discovering firmware errors. If the firmware fails during operation and is not diagnosed in time, it may cause delays in fault isolation and even cause more serious accidents. This is an unacceptable safety hazard for high-risk industries and needs to be improved. Summary of the invention

[0004] In view of the deficiencies in the prior art, the present application provides a method for self-diagnosis of firmware of a safety control system, aiming to solve the above problems.

[0005] A method for self-diagnosis of firmware of a safety control system comprises the following steps: Step S1: parse the original firmware, extract its block information table and segment information table, and append the firmware header including version number, compatibility information, generation time, block check value and segment check value to generate target firmware containing check information; divide the original firmware into multiple blocks and segments according to the data length not exceeding the preset data length, generate the check value of each block and segment respectively, and form the block check table and segment check table; Step S2: When the target firmware is loaded into the memory, the checksum values ​​of the currently loaded blocks and segments are calculated in real time, and compared with the corresponding values ​​in the block check table and the segment check table. If they are inconsistent, an error is reported; Step S3: When the firmware is running, the check values ​​of the read-only code segment and the read-only data segment in the memory are calculated in real time according to the preset block size, and compared with the corresponding values ​​in the segment check table. If they are inconsistent, an error is reported.

[0006] By adopting the above technical solution and performing multi-level verification at different stages, fine-grained error detection and rapid location are achieved. Any anomaly can be quickly discovered and accurately located, whether during the generation process or at runtime, making it easier for developers to debug and repair. This approach helps improve the robustness and maintainability of the system and avoid the spread of potential risks. This automated protection mechanism can detect and prevent problems from occurring at the first opportunity, reducing system downtime and maintenance costs. Detailed block and segment information and real-time verification mechanisms provide developers with rich debugging information, which helps to quickly locate and solve problems.

[0007] Optionally, the target firmware includes a firmware header, a block information table, a segment information table, program data, a block data CRC table, and a segment data CRC table.

[0008] Optionally, a method for self-diagnosing the firmware in the storage medium during the firmware running process is also included, comprising the following steps: Step A1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step A2: Next, diagnose the firmware block information table to verify the integrity and correctness of each firmware block; Step A3: Finally, the storage area firmware is divided into blocks of preset sizes according to the block information table to calculate the check value, and compared with the block data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware.

[0009] By adopting the above technical solution, through the method of self-diagnosis of the firmware in the storage medium during the operation of the firmware, not only the integrity and correctness of the firmware header information are ensured, the accuracy and completeness of the block information table are enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience is improved, and the long-term stability and reliability of the system are enhanced, providing a strong guarantee for the effectiveness and reliability of the firmware self-diagnosis method.

[0010] Optionally, a method for self-diagnosing the firmware in the storage medium during the firmware running process is also included, comprising the following steps: Step B1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step B2: Next, diagnose the firmware segment information table to verify the integrity and correctness of each firmware segment; Step B3: Finally, the storage area firmware segments are segmented and the check values ​​are calculated according to the firmware segmentation information table, and compared with the segment data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware.

[0011] By adopting the above technical solution, through the method of self-diagnosis of the firmware in the storage medium during the operation of the firmware, not only the integrity and correctness of the firmware header information are ensured, the accuracy and completeness of the segment information table are enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and the long-term stability and reliability of the system are enhanced, providing a strong guarantee for the effectiveness and reliability of the firmware self-diagnosis method.

[0012] Optionally, the step S2 specifically includes the following steps: Step S2.1: Verify the integrity of the firmware header: Check whether the key fields in the firmware header are complete and have not been tampered with; Step S2.2: Verify the integrity of the block information table to ensure that the information of all blocks is accurate; Step S2.3: Verify the integrity of the segment information table to ensure that the information of all segments is accurate; Step S2.4: Load and verify each block according to the block information table. During the loading process, the verification value of each block is calculated in real time and compared with the pre-stored verification value. If inconsistency is found, an error is reported immediately and the loading process is stopped; Step S2.5: Load and verify segment by segment according to the segment information table. During the loading process, the verification value of each segment is calculated in real time and compared with the pre-stored verification value; if inconsistency is found, an error is reported immediately and the loading process is stopped.

[0013] By adopting the above technical solution, not only the integrity and correctness of the firmware header information is ensured, the accuracy of the block and segment information table is enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and strong guarantees are provided for the effectiveness and reliability of the firmware self-diagnosis method.

[0014] Optionally, step S3 specifically includes the following steps: Step S3.1: before loading the firmware into the memory, first check the integrity and correctness of the firmware segment information table and the segment data CRC table in the storage area; if correct, load it into the memory; Step 3.2: Select segments with initial values ​​and read-only attributes according to the firmware segment information table to ensure that these segments will not be modified during operation; Step 3.3: According to the memory loading address of each segment, the firmware in the memory is divided into blocks according to the preset data length to calculate the check value; Step 3.4: Compare the calculated checksum value with the corresponding value in the segment data CRC table to perform self-diagnosis and ensure the integrity and accuracy of the storage area firmware; if the segment checksum value is inconsistent, an error is reported immediately and the recovery mechanism is triggered to try to restore the damaged file from the backup.

[0015] By adopting the above technical solutions, not only the system startup security and integrity are improved, the security of key code segments and data segments is enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic recovery mechanisms are realized, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and strong guarantees are provided for the effectiveness and reliability of the firmware self-diagnosis method.

[0016] Optionally, the firmware header includes generation time, version number, compatibility information, burning location, program entry address, offset address, length and check code of the block information table and offset address, length and check code of the segment information table.

[0017] Optionally, the block information table includes multiple block information, each block corresponds to a table entry, including the attributes of the current block, the offset address, the address loaded into the memory, the current block size and the offset address of the corresponding CRC table; the segment information table includes multiple segment information, each segment corresponds to a table entry, including the attributes of the current segment, the offset address, the address loaded into the memory, the current segment size and the offset address of the corresponding CRC table.

[0018] Optionally, in step S1, when generating the target firmware, a heterogeneous generation method is adopted, and the target firmware is independently generated using at least two different programming languages, and the correctness of the generation of the target firmware is determined by comparison.

[0019] By adopting the above technical solutions, different programming languages ​​have different syntax and characteristics. By using multiple languages ​​to independently implement the same logic, errors caused by specific problems in a single language or tool chain can be reduced. Using multiple programming languages ​​for development can reduce the impact of specific language vulnerabilities or attack vectors on the system. Even if a certain language has undiscovered security vulnerabilities, the parts implemented in other languages ​​can still serve as a redundant mechanism to provide additional security. In addition, this approach can also help detect and avoid firmware errors caused by security issues in the compiler or tool chain.

[0020] Optionally, in step S1, the preset data length of the blocks and segments is 2KB, and the check value is generated using a CRC32 algorithm.

[0021] By adopting the above technical solution, selecting 2KB as the preset data length can avoid excessive computing overhead while maintaining a high error detection rate; CRC32 is a widely used cyclic redundancy check algorithm, which provides good error detection capabilities at a relatively low computing cost and is suitable for frequent real-time verification. Since each block or segment has a corresponding check value, selecting a smaller data block can improve the accuracy of error location, but it will also increase the size of the check table. A data block size of no more than 2KB can ensure a high error detection accuracy while reasonably controlling the size of the check table. In addition, a smaller data block means less additional space is required to process and store the check value in memory, which is particularly important for resource-constrained embedded systems. The 2KB data block size and CRC32 check value are commonly used configurations in many existing standards and protocols, which makes the solution easier to integrate with other systems or tools, improving compatibility and versatility.

[0022] In summary, the present application includes at least one of the following beneficial technical effects: 1. Through multi-level verification at different stages, fine-grained error detection and rapid location are achieved. Whether in the generation process or at runtime, any anomaly can be quickly discovered and accurately located, making it easier for developers to debug and repair. This approach helps improve the robustness and maintainability of the system and avoid the spread of potential risks. This automated protection mechanism can detect and prevent problems from occurring at the first opportunity, reducing system downtime and maintenance costs. Detailed block and segment information and real-time verification mechanisms provide developers with rich debugging information, which helps to quickly locate and solve problems.

[0023] 2. By performing self-diagnosis on the firmware in the storage medium during firmware operation, not only the integrity and correctness of the firmware header information is ensured, the accuracy and completeness of the block information table are enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and the long-term stability and reliability of the system are enhanced, providing strong guarantees for the effectiveness and reliability of the firmware self-diagnosis method.

[0024] 3. It not only ensures the integrity and correctness of the firmware header information, enhances the accuracy of the block and segment information table, but also refines the error detection and positioning capabilities, provides real-time monitoring and automatic protection mechanisms, optimizes resource utilization and performance, supports flexible update and maintenance strategies, improves debugging and maintenance convenience, and provides strong guarantees for the effectiveness and reliability of the firmware self-diagnosis method.

[0025] 4. Different programming languages ​​have different syntax and features. By using multiple languages ​​to independently implement the same logic, errors caused by specific problems in a single language or tool chain can be reduced. Using multiple programming languages ​​for development can reduce the impact of specific language vulnerabilities or attack vectors on the system. Even if a language has undiscovered security vulnerabilities, parts implemented in other languages ​​can still serve as redundant mechanisms to provide additional security. In addition, this approach can also help detect and avoid firmware errors caused by security issues in the compiler or tool chain.

[0026] 5. Selecting 2KB as the preset data length can avoid excessive computational overhead while maintaining a high error detection rate. CRC32 is a widely used cyclic redundancy check algorithm that provides good error detection capabilities at a relatively low computational cost and is suitable for frequent real-time verification. Since each block or segment has a corresponding check value, selecting a smaller data block can improve the accuracy of error location, but it will also increase the size of the check table. A data block size of no more than 2KB can ensure high error detection accuracy while reasonably controlling the size of the check table. In addition, a smaller data block means less additional space is required to process and store the check value in memory, which is particularly important for resource-constrained embedded systems. The 2KB data block size and CRC32 check value are commonly used configurations in many existing standards and protocols, which makes the solution easier to integrate with other systems or tools, improving compatibility and versatility. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a flowchart of an embodiment of the present application.

[0028] Figure 2 It is a schematic diagram of the composition of the original firmware in the embodiment of the present application.

[0029] Figure 3 It is a flowchart of generating target firmware in an embodiment of the present application.

[0030] Figure 4 It is a schematic diagram of the composition of the target firmware in the embodiment of the present application.

[0031] Figure 5 It is a flow chart of generating firmware by a heterogeneous method in an embodiment of the present application.

[0032] Figure 6 It is a flowchart of the self-diagnosis of the firmware during the loading process in the embodiment of the present application.

[0033] Figure 7 It is a flowchart of the firmware performing self-diagnosis by block when loading in an embodiment of the present application.

[0034] Figure 8 It is a flow chart of the self-diagnosis of the firmware by segment when loading in the embodiment of the present application.

[0035] Fig. 9 It is a flowchart of self-diagnosis of firmware in a storage medium during operation in an embodiment of the present application.

[0036] Fig.10 It is a flowchart of performing self-diagnosis on the firmware in the storage medium by block during operation in an embodiment of the present application.

[0037] Fig.11 It is a flow chart of performing segment-by-segment self-diagnosis on the firmware in the storage medium during operation in an embodiment of the present application.

[0038] Fig.12 It is a flowchart of the firmware in the memory performing self-diagnosis during operation in the embodiment of the present application.

[0039] Fig.13 It is a flow chart of the self-diagnosis of the firmware in the memory by segments during the runtime in the embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to facilitate the understanding of this application, Figure 1 To Attachment Fig.13 The present application is described in more detail with reference to the accompanying drawings and specific embodiments. It should be noted that when an element is described as being "fixed to" another element, it may be directly on the other element, or one or more centered elements may exist therebetween. When an element is described as being "connected to" another element, it may be directly connected to the other element, or one or more centered elements may exist therebetween. The terms "vertical", "horizontal", "left", "right" and similar expressions used in this specification are for illustrative purposes only.

[0041] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The term "and / or" used in this specification includes any and all combinations of one or more of the related listed items.

[0042] The embodiment of the present application discloses a method for self-diagnosis of firmware of a safety control system, comprising the following steps: step S1; parsing the original firmware, extracting its block information table and segment information table, and appending a firmware header including version number, compatibility information, generation time, block check value and segment check value, and generating a target firmware containing check information; dividing the original firmware into multiple blocks and segments according to a preset data length not exceeding, generating a check value for each block and segment respectively, and forming a block check table and a segment check table; step S2: in the process of loading the target firmware into the memory, calculating the check value of the current loaded block and segment in real time, and comparing it with the corresponding value in the block check table and the segment check table, and reporting an error if it is inconsistent; step S3: when the firmware is running, calculating the check value of the read-only code segment and the read-only data segment in the memory in real time according to the preset block size, and comparing it with the corresponding value in the segment check table, and reporting an error if it is inconsistent. By performing multi-level checks at different stages, fine-grained error detection and rapid positioning are achieved, and any abnormality can be quickly discovered and accurately located during the generation process or during operation, which is convenient for developers to debug and repair. This approach helps improve the robustness and maintainability of the system and avoid the spread of potential risks. This automated protection mechanism can detect and prevent problems from occurring in the first place, reducing system downtime and maintenance costs. Detailed block and segment information and real-time verification mechanisms provide developers with rich debugging information, helping to quickly locate and solve problems.

[0043] Taking GCC compiling to generate an ELF format firmware file as an example, the process of generating firmware with verification information is described. The target firmware includes a firmware header, a block information table, a segment information table, program data, a block data CRC table, and a segment data CRC table. The firmware header includes the generation time, version number, compatibility information, burning location, program entry address, offset address, length and check code of the block information table, and offset address, length and check code of the segment information table. The block information table includes multiple block information, each block corresponds to a table entry, including the attributes of the current block, the offset address, the address loaded into the memory, the current block size, and the offset address of the corresponding CRC table; the segment information table includes multiple segment information, each segment corresponds to a table entry, including the attributes of the current segment, the offset address, the address loaded into the memory, the current segment size, and the offset address of the corresponding CRC table. Taking GCC compiling to generate an ELF format firmware file as an example, the process of generating firmware with verification information is described.

[0044] In step S1, the preset data length of the blocks and segments is 2KB, and the check value is generated using the CRC32 algorithm. Selecting 2KB as the preset data length can avoid excessive computational overhead while maintaining a high error detection rate; CRC32 is a widely used cyclic redundancy check algorithm that provides good error detection capabilities at a relatively low computational cost and is suitable for frequent real-time verification. Since each block or segment has a corresponding check value, selecting a smaller data block can improve the accuracy of error location, but it will also increase the size of the check table. A data block size of no more than 2KB can ensure a high error detection accuracy under the premise of reasonably controlling the size of the check table; in addition, a smaller data block means less additional space is required to process and store the check value in memory, which is particularly important for resource-constrained embedded systems. The 2KB data block size and CRC32 check value are commonly used configurations in many existing standards and protocols, which makes the solution easier to integrate with other systems or tools, improving compatibility and versatility.

[0045] The method for self-diagnosing the firmware in the storage medium by block during the firmware running process includes the following steps: Step A1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step A2: Then, diagnose the firmware block information table to verify the integrity and correctness of each firmware block; Step A3: Finally, according to the block information table, the storage area firmware is divided into blocks according to a preset size to calculate the check value, and compared with the block data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware. Through the method of self-diagnosing the firmware in the storage medium during the firmware running process, not only the integrity and correctness of the firmware header information is ensured, the accuracy and completeness of the block information table are enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and the long-term stability and reliability of the system are enhanced, providing a strong guarantee for the effectiveness and reliability of the firmware self-diagnosis method.

[0046] The method for self-diagnosing the firmware in the storage medium by segment during the firmware running process includes the following steps: Step B1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step B2: Then, diagnose the firmware segment information table to verify the integrity and correctness of each firmware segment; Step B3: Finally, calculate the check value of the storage area firmware segment according to the firmware segment information table, and compare it with the segment data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware. Through the method of self-diagnosing the firmware in the storage medium during the firmware running process, not only the integrity and correctness of the firmware header information is ensured, the accuracy and integrity of the segment information table are enhanced, but also the error detection and positioning capabilities are refined, real-time monitoring and automatic protection mechanisms are provided, resource utilization and performance are optimized, flexible update and maintenance strategies are supported, debugging and maintenance convenience are improved, and the long-term stability and reliability of the system are enhanced, providing a strong guarantee for the effectiveness and reliability of the firmware self-diagnosis method.

[0047] Step S2 specifically includes the following steps: Step S2.1: Verify the integrity of the firmware header: Check whether the key fields in the firmware header are complete and have not been tampered with; Step S2.2: Verify the integrity of the block information table to ensure that the information of all blocks is accurate; Step S2.3: Verify the integrity of the segment information table to ensure that the information of all segments is accurate; Step S2.4: Load and verify block by block according to the block information table, calculate the check value of each block in real time during the loading process and compare it with the pre-stored check value; if inconsistency is found, report an error immediately and stop the loading process; Step S2.5: Load and verify segment by segment according to the segment information table, calculate the check value of each segment in real time during the loading process and compare it with the pre-stored check value; if inconsistency is found, report an error immediately and stop the loading process. It not only ensures the integrity and correctness of the firmware header information and enhances the accuracy of the block and segment information tables, but also refines the error detection and positioning capabilities, provides real-time monitoring and automatic protection mechanisms, optimizes resource utilization and performance, supports flexible update and maintenance strategies, improves debugging and maintenance convenience, and provides strong guarantees for the effectiveness and reliability of the firmware self-diagnosis method.

[0048] Step S3 specifically includes the following steps: Step S3.1: Before the firmware is loaded into the memory, first check the integrity and correctness of the firmware segmentation information table and the segmentation data CRC table in the storage area; if correct, load it into the memory; Step 3.2: Select segments with initial values ​​and read-only attributes according to the firmware segmentation information table to ensure that these segments will not be modified during operation; Step 3.3: According to the memory loading address of each segment, calculate the check value of the firmware in the memory according to the preset data length; Step 3.4: Compare the calculated check value with the corresponding value in the segmentation data CRC table to perform self-diagnosis and ensure the integrity and accuracy of the firmware in the storage area; if the check values ​​of the segments are inconsistent, report the error immediately, trigger the recovery mechanism, and try to restore the damaged file from the backup. It not only improves the system's startup security and integrity and enhances the security of key code segments and data segments, but also refines error detection and location capabilities, implements real-time monitoring and automatic recovery mechanisms, optimizes resource utilization and performance, supports flexible update and maintenance strategies, improves debugging and maintenance convenience, and provides strong guarantees for the effectiveness and reliability of firmware self-diagnosis methods.

[0049] In step S1, when generating the target firmware, a heterogeneous generation method is adopted, and the target firmware is independently generated using C language and Python, and the correctness of the target firmware generation is judged by comparison. Different programming languages ​​have different syntax and characteristics. By using multiple languages ​​to independently implement the same logic, errors caused by specific problems in a single language or tool chain can be reduced. Using multiple programming languages ​​for development can reduce the impact of specific language vulnerabilities or attack vectors on the system. Even if a certain language has undiscovered security vulnerabilities, the parts implemented in other languages ​​can still be used as a redundant mechanism to provide additional security. In addition, this method can also help detect and avoid firmware errors caused by security issues in the compiler or tool chain.

[0050] It also includes the self-diagnosis of the running area of ​​the firmware program, and the firmware in the memory is checked during the running time. The self-diagnosis of the running firmware usually cannot follow the program segmentation information table, because the memory block contains multiple segments, some of which have no initial values, while others are data segments, which will change dynamically during the running time. We can only diagnose the read-only code segment and data segment. Other segments need to adopt defensive programming, static testing and dynamic testing in the coding stage to ensure safety. We use the program segmentation information table for diagnosis, and its attributes include whether the current segment has an initial value and whether it is read-only. Only the segments with initial values ​​and read-only attributes are diagnosed, which just correspond to the code segment and read-only data segment of the program. First, the firmware segmentation information table and segmentation data CRC table in the storage area are checked, and if there is no error, they are loaded into the memory; then, the segment with initial value and read-only attribute is selected according to the firmware segmentation information table; then, according to the memory loading address of each segment, the check value is calculated for the firmware in the memory according to the maximum 2K block; finally, the calculated check value is compared with the value in the segmentation data CRC table for self-diagnosis.

[0051] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for self-diagnosis of security control system firmware, characterized in that: The following steps are involved: Step S1: parse the original firmware, extract its block information table and segment information table, and append the firmware header including version number, compatibility information, generation time, block check value and segment check value to generate target firmware containing check information; divide the original firmware into multiple blocks and segments according to the data length not exceeding the preset data length, generate the check value of each block and segment respectively, and form the block check table and segment check table; Step S2: When the target firmware is loaded into the memory, the checksum values ​​of the currently loaded blocks and segments are calculated in real time, and compared with the corresponding values ​​in the block check table and the segment check table. If they are inconsistent, an error is reported; Step S3: When the firmware is running, the check values ​​of the read-only code segment and the read-only data segment in the memory are calculated in real time according to the preset block size, and compared with the corresponding values ​​in the segment check table. If they are inconsistent, an error is reported.

2. A method for self-diagnosis of security control system firmware according to claim 1, characterized in that: The target firmware includes a firmware header, a block information table, a segment information table, program data, a block data CRC table, and a segment data CRC table.

3. A method for self-diagnosis of security control system firmware according to claim 1, characterized in that: Also included is a method for self-diagnosing firmware in a storage medium during firmware operation, comprising the following steps: Step A1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step A2: Next, diagnose the firmware block information table to verify the integrity and correctness of each firmware block; Step A3: Finally, the storage area firmware is divided into blocks of preset sizes according to the block information table to calculate the check value, and compared with the block data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware.

4. A method for self-diagnosis of security control system firmware according to claim 1, characterized in that: Also included is a method for self-diagnosing firmware in a storage medium during firmware operation, comprising the following steps: Step B1: First, diagnose the firmware header information to ensure the integrity and correctness of the firmware file header; Step B2: Next, diagnose the firmware segment information table to verify the integrity and correctness of each firmware segment; Step B3: Finally, the storage area firmware segments are segmented and the check values ​​are calculated according to the firmware segmentation information table, and compared with the segment data CRC table to perform self-diagnosis to ensure the integrity and accuracy of the storage area firmware.

5. The method for self-diagnosis of security control system firmware according to claim 1, characterized in that: The step S2 specifically includes the following steps: Step S2.1: Verify the integrity of the firmware header: Check whether the key fields in the firmware header are complete and have not been tampered with; Step S2.2: Verify the integrity of the block information table to ensure that the information of all blocks is accurate; Step S2.3: Verify the integrity of the segment information table to ensure that the information of all segments is accurate; Step S2.4: Load and verify each block according to the block information table. During the loading process, the verification value of each block is calculated in real time and compared with the pre-stored verification value. If inconsistency is found, an error is reported immediately and the loading process is stopped; Step S2.5: Load and verify segment by segment according to the segment information table. During the loading process, the verification value of each segment is calculated in real time and compared with the pre-stored verification value; if inconsistency is found, an error is reported immediately and the loading process is stopped.

6. A method for self-diagnosis of security control system firmware according to claim 1, characterized in that: Step S3 specifically includes the following steps: Step S3.1: before loading the firmware into the memory, first check the integrity and correctness of the firmware segment information table and the segment data CRC table in the storage area; if correct, load it into the memory; Step 3.2: Select segments with initial values ​​and read-only attributes according to the firmware segment information table to ensure that these segments will not be modified during operation; Step 3.3: According to the memory loading address of each segment, the firmware in the memory is divided into blocks according to the preset data length to calculate the check value; Step 3.4: Compare the calculated checksum value with the corresponding value in the segment data CRC table to perform self-diagnosis and ensure the integrity and accuracy of the storage area firmware; if the segment checksum value is inconsistent, an error is reported immediately and the recovery mechanism is triggered to try to restore the damaged file from the backup.

7. The method for self-diagnosis of security control system firmware according to claim 1, characterized in that: The firmware header includes the generation time, version number, compatibility information, burning location, program entry address, offset address, length and check value of the block information table and offset address, length and check value of the segment information table.

8. The method for self-diagnosis of security control system firmware according to claim 1, characterized in that: The block information table includes multiple block information, each block corresponds to a table entry, including the attributes of the current block, the offset address, the address loaded into the memory, the current block size and the offset address of the corresponding CRC table; the segment information table includes multiple segment information, each segment corresponds to a table entry, including the attributes of the current segment, the offset address, the address loaded into the memory, the current segment size and the offset address of the corresponding CRC table.

9. A method for self-diagnosis of security control system firmware according to claim 1, characterized in that: In the step S1, when generating the target firmware, a heterogeneous generation method is adopted, and the target firmware is independently generated using at least two different programming languages, and the correctness of the target firmware is determined by comparison.

10. The method for self-diagnosis of security control system firmware according to claim 1, characterized in that: In the step S1, the preset data length of the blocks and segments is 2KB, and the check value is generated using the CRC32 algorithm.

Images