Fault detection method and device based on PLC encryption and decryption operation

Abstract

The invention provides a fault detection method and device based on PLC encryption and decryption operation. The method comprises the steps that real-time data generated in the current period of a PLC and state data involved in the process of decrypting received data or encrypting sent data are acquired; matching the real-time data and the state data in the current period with a dynamic threshold range, wherein the dynamic threshold range is determined based on the real-time data and the state data generated in a normal state in a PLC historical period; and if the matching fails, generating a control instruction, fault alarm information and a data acquisition strategy based on the real-time data and / or the state data which fails in matching, so that the PLC adjusts an execution strategy based on the control instruction, and executes acquisition of the real-time data and the state data in the next period based on the data acquisition strategy. And the fault alarm information is encrypted and then transmitted to the safety monitoring platform. And the real-time performance, the reliability and the safety of the PLC system are enhanced on the whole.

Description

Technical Field

[0001] This application relates to the field of industrial control technology, and in particular to a fault detection method, a fault detection device, a computer device, a computer-readable storage medium, and a computer program product based on PLC encryption and decryption operation. Background Technology

[0002] A Programmable Logic Controller (PLC) is a digital computing electronic system designed specifically for industrial environments. It uses programmable memory to store instructions for performing logical operations, sequential control, timing, counting, and arithmetic operations, and controls various types of machinery or production processes through digital or analog input / output interfaces.

[0003] To detect and isolate potential faults in real time during production, preventing them from escalating into major incidents that lead to production line downtime, equipment damage, or safety accidents, PLC fault detection is necessary. Specifically, during PLC operation, the data acquisition module reads sensor or internal status data in real time. Then, the comparison logic unit compares each real-time value with a preset threshold. If any real-time value exceeds the threshold range, a fault determination is immediately triggered, and a preset response is executed. Furthermore, to defend against network eavesdropping, data tampering, and unauthorized control in an open and interconnected industrial environment, ensuring the confidentiality, integrity, and authenticity of production instructions and process data, and guaranteeing the physical security and continuous reliable operation of the industrial control system, the data sent / received by the PLC needs to be encrypted. Specifically, when sending data, the data is encrypted, an integrity digest and digital signature are generated, and a timestamp is added before transmission. Upon receiving data, the signature and integrity are verified first; if everything is correct, the data is decrypted and then executed by the control system.

[0004] In PLC systems, the independent, static fault detection mechanism and the high-overhead, coarse-grained encryption transmission mechanism create a conflict between functionality and performance under industrial real-time constraints. Delayed threshold detection cannot identify systemic anomalies caused by encryption delays or network attacks, while rigid encryption algorithms, in turn, increase the load on the Central Processing Unit (CPU), crowding out detection resources. Ultimately, when facing complex faults or coordinated attacks, the PLC system cannot guarantee real-time control performance, nor can it achieve effective security protection, thus reducing the reliability and security of the PLC system. Summary of the Invention

[0005] The purpose of this application is to provide a fault detection method, a fault detection device, a computer device, a computer-readable storage medium, and a computer program product based on PLC encryption and decryption operation, so as to improve the reliability and security of PLC systems.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a fault detection method based on PLC encryption and decryption during operation. The method is applied to a programmable logic controller (PLC) and includes: acquiring real-time data generated by the PLC in the current cycle and status data involved in decrypting received data or encrypting transmitted data; matching the real-time data and status data in the current cycle with a dynamic threshold range, the dynamic threshold range being determined based on real-time data and status data generated under normal conditions in historical cycles of the PLC; if the matching fails, generating control instructions, fault alarm information, and a data acquisition strategy based on the failed real-time data and / or status data, so that the PLC adjusts its execution strategy based on the control instructions, executes the acquisition of real-time data and status data in the next cycle based on the data acquisition strategy, and transmits the encrypted fault alarm information to a security monitoring platform.

[0007] Compared to existing technologies, the fault detection method based on PLC encryption / decryption operation provided in the first aspect of this application enables real-time comprehensive monitoring and rapid response to the PLC's operating status and safety conditions through dynamic threshold matching and collaborative analysis of encrypted status data. When a matching failure is detected, fault control instructions can be immediately generated and executed, and the data acquisition strategy adjusted, effectively shortening the time window for fault detection and handling, and significantly improving system reliability and response speed. Simultaneously, incorporating the status data of the encrypted transmission process into fault judgment allows for the timely identification of systemic problems caused by encryption anomalies or security attacks, achieving deep synergy between security mechanisms and fault detection mechanisms, thereby enhancing the real-time performance, reliability, and security of the PLC system as a whole.

[0008] In other embodiments provided in this application, before matching the real-time data and status data in the current period with the dynamic threshold range, the method further includes: establishing a dynamic threshold range based on the normal real-time data and status data in the historical period and the real-time data and status data in the current period, wherein the length of the historical period is fixed.

[0009] By dynamically establishing threshold ranges based on historical and current normal data, the fault detection mechanism possesses adaptive learning and adjustment capabilities. It can dynamically correct judgment criteria according to the actual operating conditions and changes in equipment, effectively avoiding false alarms caused by environmental fluctuations or slow equipment aging, while ensuring sensitive identification of genuine anomalies. The fixed historical period length ensures both real-time performance and computational efficiency of the algorithm while maintaining the stability of the learning process, thus enabling fault detection to achieve both high accuracy and strong robustness in complex and ever-changing industrial environments.

[0010] In other embodiments provided in this application, real-time data includes sensor data and PLC data, and the dynamic threshold range includes sensor threshold range, PLC threshold range, and communication status threshold range. Matching the real-time data and status data in the current period with the dynamic threshold range includes: matching the sensor data in the current period with the sensor threshold range; matching the PLC data in the current period with the PLC threshold range; and matching the status data in the current period with the communication status threshold range. The method further includes: if at least two of the above matching fails, then a final matching failure is determined; if only one of the above matching fails, then the corresponding alarm level is selected according to the anomaly type of the matching failure data, and if the matching failure data is PLC control data, then the previous valid data of the matching failure data is used for PLC control.

[0011] By subdividing thresholds into three categories—sensor, PLC internal, and communication status—and performing hierarchical matching, the system achieves multi-dimensional and accurate fault diagnosis. When only a single dimension is abnormal, the system can intelligently select the alarm level based on the anomaly type and automatically activate the previous valid data for fault-tolerant control when critical control data is abnormal, thus ensuring the continuity of the control process while avoiding erroneous actions. Only when multiple dimensions are abnormal simultaneously is a final fault determined. This multi-source information fusion judgment strategy significantly improves the accuracy of fault identification, effectively reduces false alarms caused by single-point interference or instantaneous fluctuations, and enhances the system's reliable operation capability under complex conditions.

[0012] In other embodiments provided in this application, the method further includes: adjusting the encryption strategy based on the real-time data and / or status data of the failed match, in order to balance the real-time performance and security of the PLC.

[0013] By dynamically adjusting the encryption strategy based on fault detection results, intelligent linkage between the security mechanism and the operating status is achieved. When a system performance bottleneck or specific fault is detected, the encryption strength can be automatically reduced to prioritize ensuring real-time control. Conversely, when a security threat is identified, the encryption level can be increased to strengthen protection. This adaptive adjustment breaks down the inherent contradiction between security and real-time performance, enabling the PLC system to dynamically optimize resource allocation under different operating conditions, thereby achieving the best balance between overall security and real-time performance.

[0014] In other embodiments provided in this application, the encryption strategy is adjusted based on the real-time data and / or status data that fail to match, including: when the fault level of the real-time data and / or status data that fails to match is the highest level, the adjusted encryption strategy is: only sign, skip encryption, and interrupt the transmission of data with a fault level lower than the highest level in the PLC, and transmit simultaneously through the main and backup channels; or, when the real-time data and / or status data that fails to match indicates that the PLC is in a critical operating state, the adjusted encryption strategy is: only sign, skip encryption, or use a key shorter than the current key; or, when the real-time data and / or status data that fails to match indicates that the PLC is under attack, the adjusted encryption strategy is: adopt a higher level encryption strategy.

[0015] By precisely linking fault levels with encryption strategies, intelligent scheduling of system resources and security levels is achieved under abnormal operating conditions. When facing the highest-level fault, a strategy of simplified signatures, interrupting secondary data, and enabling dual-channel transmission is adopted to maximize the real-time performance and delivery reliability of critical control commands. When the system is in a critical performance state, basic control functions are prioritized by dynamically reducing encryption overhead. When attacked, encryption strength is immediately increased to strengthen defense. This tiered response mechanism ensures that the PLC can make optimal decisions in various abnormal scenarios, thus maintaining core capabilities of safety and real-time control even under extreme conditions.

[0016] In other embodiments provided in this application, the method further includes: when the PLC resumes normal operation, forcibly initiating a new session key negotiation with the current communication peer to obtain a new set of session keys; for data in the transmission queue, the highest priority data is transmitted using the original session key, and the data in the transmission queue other than the highest priority data and the data newly added to the transmission queue are transmitted using the newly obtained session key.

[0017] By forcibly updating the session key after system recovery, the risk of key leakage during failures or attacks is effectively eliminated, thereby enhancing forward security of communication. Simultaneously, its transition strategy of using the original key for the highest priority data in the transmission queue avoids the loss or delay of high-priority control commands that may occur during key switching, ensuring the continuity of critical controls. This key management mechanism, which balances security updates with business continuity, enables the system to seamlessly and securely rebuild the security context during recovery from an abnormal state, ensuring smooth and reliable overall operation.

[0018] In other embodiments provided in this application, the method further includes: determining a suitable lightweight encryption algorithm based on the hardware architecture of the PLC system; integrating the lightweight encryption algorithm into the firmware of the PLC or Internet of Things (IoT) gateway, and configuring an application programming interface (API) compatible with a real-time operating system (RTOS); or, integrating the encryption module into an encryption coprocessor outside the CPU of the PLC, wherein the encryption coprocessor uses hardware acceleration circuitry.

[0019] By adapting lightweight encryption algorithms to different hardware architectures and deeply integrating them with the RTOS, the encryption function can operate efficiently and stably in resource-constrained embedded environments. Simultaneously, by employing a dedicated encryption coprocessor or hardware acceleration circuitry, the heavy encryption and decryption computation tasks are offloaded from the main CPU, significantly reducing the impact of encryption operations on the real-time performance of the PLC control cycle. This hardware-software co-optimization design fundamentally resolves the conflict between security and real-time performance in traditional solutions, enabling high-strength encrypted communication without sacrificing system response speed.

[0020] In other embodiments provided in this application, the method further includes: when the PLC establishes a communication connection with an external device, performing mutual authentication based on elliptic curve cryptography (ECC), and generating a shared session key in conjunction with the elliptic curve Diffie-Hellman ECDH key exchange protocol; controlling the delay of each complete authentication process to within 15 milliseconds through session recovery technology and a pre-computed temporary key caching mechanism; wherein, the session recovery technology includes: when the communication connection is abnormally interrupted and needs to be re-established, quickly rebuilding the secure channel within less than 5 milliseconds based on the previously cached secure session context, bypassing the complete key exchange and authentication process; wherein, the pre-computed temporary key caching mechanism includes: pre-compiling one or more elliptic curve temporary key pairs during idle or low-load periods of the PLC control cycle and storing them in a pre-cached queue; when a new secure session needs to be established, retrieving an available temporary key pair from the pre-cached queue, thereby eliminating the computational delay caused by on-site key generation.

[0021] By combining strong ECC authentication with ECDH key exchange and introducing session recovery and pre-computation caching mechanisms, the latency of secure connection establishment is significantly reduced while ensuring high security. Session recovery time is controlled within 5 milliseconds, enabling near-instantaneous communication recovery after temporary network interruptions, greatly improving system availability and robustness. Pre-computing key pairs during PLC idle periods transforms the high-latency field key generation process into background preprocessing, completely eliminating its interference with the real-time control cycle. These mechanisms work together to achieve ultimate optimization of the secure handshake process, enabling high-strength authentication and key negotiation to meet the stringent millisecond-level real-time requirements of industrial control systems.

[0022] In other embodiments provided in this application, the method further includes: identifying the industrial control protocol characteristics of the target data currently received / sent by the PLC; if the industrial control protocol characteristics of the target data are different from the standard protocol characteristics, the target data is converted into the standard protocol characteristics before further processing, wherein the standard protocol characteristics are an industrial control protocol preset for fault detection and encrypted transmission.

[0023] With built-in protocol recognition and conversion capabilities, it achieves compatibility and unified security processing for various heterogeneous industrial protocols. Regardless of the original protocol used by the PLC communication (such as Modbus, Profinet, etc.), it can be converted into internally preset standard security protocol features for processing. This seamlessly extends intelligent fault detection and high-strength encrypted transmission capabilities to existing, diverse industrial network environments. It avoids the complexity and high cost of developing security extensions separately for each protocol, significantly improving versatility and deployment convenience, making the security upgrade and transformation of traditional industrial systems simple and efficient.

[0024] The second aspect of this application provides a fault detection device based on PLC encryption and decryption during operation. The device is applied to a PLC and includes: a data acquisition module for acquiring real-time data generated by the PLC in the current cycle and status data involved in decrypting received data or encrypting transmitted data; a fault detection module for matching the real-time data and status data in the current cycle with a dynamic threshold range, the dynamic threshold range being determined based on real-time data and status data generated under normal conditions in historical cycles of the PLC; if the matching fails, generating control instructions, fault alarm information, and a data acquisition strategy based on the failed real-time data and / or status data; and a secure communication module for enabling the PLC to adjust its execution strategy based on control instructions, to acquire real-time data and status data for the next cycle based on the data acquisition strategy, and to encrypt and transmit the fault alarm information to a security monitoring platform.

[0025] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the first aspect.

[0026] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0027] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the first aspect.

[0028] The fault detection device based on PLC encryption / decryption operation provided in the second aspect of this application, the computer equipment provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the fault detection method based on PLC encryption / decryption operation provided in the first aspect. Attached Figure Description

[0029] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a flowchart illustrating the fault detection method based on PLC encryption / decryption in the embodiments of this application. Figure 1 ; Figure 2 This is a flowchart illustrating the fault detection method based on PLC encryption / decryption in the embodiments of this application. Figure 2 ; Figure 3This is a schematic diagram of the fault detection device based on PLC encryption / decryption operation in the embodiments of this application. Figure 1 ; Figure 4 This is a schematic diagram of the fault detection device based on PLC encryption / decryption operation in the embodiments of this application. Figure 2 ; Figure 5 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0030] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0031] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0032] Under the constraints of industrial real-time requirements, the independent and static fault detection mechanisms and the computationally expensive and rigid encryption transmission mechanisms in traditional PLC systems create a conflict between their functions and performance. As a result, when faced with complex faults or coordinated attacks, the system is unable to guarantee real-time control performance or achieve effective security protection, leading to a reduction in overall reliability and security.

[0033] In view of this, embodiments of this application provide a fault detection method, a fault detection device, a computer device, a computer-readable storage medium, and a computer program product based on PLC encryption and decryption operation. By synchronously acquiring real-time operation data and encryption / decryption process status data within the control cycle of the PLC, and matching them with dynamic thresholds established based on historical normal data, a comprehensive response including control instruction adjustment, data acquisition strategy update, and encryption alarm is immediately generated and executed when a matching failure is detected. This deeply couples intelligent fault detection, secure encrypted transmission, and real-time control execution, synergistically improving the system's reliability, security, and real-time response in a single process.

[0034] First, the fault detection method based on PLC encryption and decryption operation provided in the embodiments of this application will be described in detail.

[0035] Figure 1 This is a flowchart illustrating the fault detection method based on PLC encryption / decryption in the embodiments of this application. Figure 1 This method is applied to PLCs; see [link / reference]. Figure 1As shown, the method may include: S11: Obtain real-time data generated by the PLC in the current cycle, as well as status data involved in decrypting received data or encrypting transmitted data.

[0036] The current cycle refers to the fixed time interval between a complete control logic operation, I / O data refresh, and communication processing performed by the PLC control system. This includes, but is not limited to, a typical PLC scan cycle (e.g., 1ms to 100ms), a real-time operating system task scheduling cycle, or a specific security communication session processing cycle.

[0037] Real-time data refers to timely information collected, generated, or processed by the PLC system within the current control cycle to reflect the status of the controlled object and the operating status of the controller itself. This includes sensor measurements (such as temperature and pressure), actuator feedback status (such as valve opening), PLC internal variables (such as the current value of the timer), and intermediate calculation results.

[0038] Status data refers to the operational indicators that reflect the performance and security status of the PLC system during the execution of secure operations such as data encryption / decryption, authentication, and key management. These include the time consumed by encryption / decryption operations, CPU utilization, key exchange success or failure flags, remaining lifespan of session keys, security coprocessor load, and communication link latency and packet loss rate.

[0039] Real-time data can be obtained by directly reading the PLC's input image area, process image area, and internal memory.

[0040] Status data can be obtained by monitoring the interfaces of security coprocessors or software encryption modules, querying the timestamps of real-time operating system task execution, and analyzing feedback information from the network driver layer.

[0041] S12: Match the real-time data and status data within the current period with the dynamic threshold range.

[0042] The dynamic threshold range is determined based on real-time data and status data generated under normal conditions within the PLC's historical cycles. In other words, the dynamic threshold range is a set of values ​​that the PLC system automatically learns and continuously updates based on its historical normal operation data to determine whether the current data is within the normal range.

[0043] During the generation of the dynamic threshold range, the system collects and statistically analyzes the numerical distribution of various monitoring parameters (such as sensor readings, CPU utilization, and encryption latency) under normal operating conditions without faults or attacks during the initial stage or a specified learning period. An algorithm (such as calculating the moving average and standard deviation) is then used to form a baseline model and initial threshold. In subsequent operation, the system periodically updates the model and threshold using a fixed-length sliding window (such as the most recent 1000 cycles) based on newly collected normal data, allowing the judgment criteria to adapt to slow changes such as equipment aging and environmental alterations.

[0044] For example, for a temperature sensor, its dynamic threshold range may be initially set to [20°C, 30°C], and after the device continues to run and the baseline temperature slowly rises, this range may be adaptively adjusted to [22°C, 32°C].

[0045] During the matching process, each specific real-time data point (e.g., temperature value) and status data point (e.g., encryption time) collected in the current cycle is compared one by one with the corresponding predefined parameter categories and their threshold ranges (e.g., temperature threshold range, encryption time upper limit) within the dynamic threshold range. If the current data value falls within the threshold range of its corresponding parameter, the parameter is considered to have matched successfully. If the current data value exceeds the threshold range, the parameter is considered to have failed to match. The system records the matching results of all parameters and comprehensively evaluates the overall operating status of the current cycle based on preset decision logic (e.g., if sensor data matching fails but status data is normal, only a low-level alarm is triggered; if both fail simultaneously, a high-level fault determination is triggered).

[0046] S13: If the matching fails, control instructions, fault alarm information and data acquisition strategy are generated based on the real-time data and / or status data of the matching failure, so that the PLC can adjust the execution strategy based on the control instructions, execute the acquisition of real-time data and status data in the next cycle based on the data acquisition strategy, and transmit the fault alarm information to the safety monitoring platform after encryption.

[0047] A matching failure means that at least one monitoring parameter (real-time data or status data) in the current cycle has exceeded its dynamically determined normal range, indicating that the PLC system may have experienced equipment failure, abnormal performance, or is under security attack.

[0048] Upon a matching failure, the system analyzes which parameters are abnormal and their severity, and intelligently generates a response accordingly. Control commands are used to immediately adjust the PLC execution strategy (such as switching to safe mode or activating backup equipment). Fault alarm information records the anomaly type, time, and data in detail, and is encrypted before being reported to the safety monitoring platform in real time. The data acquisition strategy will then adjust the data acquisition frequency, accuracy, or key focus areas for the next cycle (e.g., high-frequency sampling of abnormal parameters), thus forming a closed-loop processing flow integrating real-time response, safety alarms, and proactive diagnosis.

[0049] When generating control commands, the system automatically selects and generates corresponding control commands based on the type of failed matching parameters and a preset fault-action mapping rule base. For example, if temperature sensor data continuously exceeds limits, a command to "shut down the heater and start the cooling fan" is generated; if an abnormal surge in encryption time indicates a possible flooding attack, a command to "limit the rate of receiving IP data packets from a specific source" is generated. These commands are immediately written to the output image area or directly sent to specific control modules for execution via the PLC's internal command execution interface.

[0050] When generating fault alarm information, the system extracts information such as the name of the parameter that failed to match, the current abnormal value, the timestamp of the occurrence, and the address of the PLC station to which it belongs. This information is then encapsulated according to a preset alarm information format template to generate structured fault alarm information. This information is appended with an integrity checksum generated by a specified algorithm and encrypted using the current session key or device private key. Finally, it is sent in real-time to the designated security monitoring platform via a secure transmission module.

[0051] When generating specific data acquisition strategies, the system dynamically adjusts subsequent data acquisition plans based on the severity and type of parameter anomalies. For example, for parameters with occasional minor anomalies, the strategy may halve their sampling period for close monitoring; for parameters indicating critical faults, the strategy will instruct the data acquisition module to sample them multiple times in the next cycle, while simultaneously improving the acquisition accuracy of other related parameters. It may also pause the acquisition of non-critical parameters to conserve resources, thereby achieving precise location and continuous tracking of the root cause of the anomaly.

[0052] S14: If the match is successful, it is determined that the PLC system is in normal operating status and safety condition within the current cycle.

[0053] A successful match means that all monitored operating parameters and safety indicators meet the normal standards obtained through adaptive learning, and the system has not detected any equipment failures, performance degradation, or security threats. In this case, the system does not need to trigger any corrective or alarm actions. It will continue to execute the predetermined control tasks and prepare for the next cycle's data acquisition according to the current cycle's data acquisition strategy (usually a standard frequency and range). Simultaneously, the secure transmission module will continue to use the current session key to perform routine encryption and integrity protection on subsequent communication data, maintaining the entire system in a steady-state, secure closed-loop operation.

[0054] As described above, the fault detection method based on PLC encryption / decryption operation provided in this application, through dynamic threshold matching and collaborative analysis of encrypted status data, enables real-time comprehensive monitoring and rapid response to the PLC's operating status and safety conditions. When a matching failure is detected, fault control instructions can be immediately generated and executed, and the data acquisition strategy adjusted, effectively shortening the time window for fault detection and handling, and significantly improving system reliability and response speed. Simultaneously, incorporating the status data of the encrypted transmission process into fault judgment allows for timely identification of systemic problems caused by encryption anomalies or security attacks, achieving deep synergy between security mechanisms and fault detection mechanisms, thereby enhancing the real-time performance, reliability, and security of the PLC system as a whole.

[0055] Furthermore, as a response to Figure 1 In a refinement and extension of the method shown, this application embodiment also provides a fault detection method based on PLC encryption and decryption operation.

[0056] Figure 2 This is a flowchart illustrating the fault detection method based on PLC encryption / decryption in the embodiments of this application. Figure 2 See Figure 2 As shown, the method may include: S21: Based on the PLC hardware architecture, select a suitable lightweight encryption algorithm for firmware integration or implement encryption acceleration through a dedicated hardware coprocessor.

[0057] In order to balance the requirements of high-strength encryption and real-time performance in resource-constrained industrial embedded environments, a method of integrating lightweight algorithms in firmware or accelerating with hardware coprocessors is adopted to achieve efficient and low-latency secure operation, depending on the specific hardware capabilities of the PLC.

[0058] Specifically, step S21 above may include: S21a: Determine the appropriate lightweight encryption algorithm based on the hardware architecture of the PLC system; integrate the lightweight encryption algorithm into the firmware of the PLC or IoT gateway, and configure an RTOS-compatible API.

[0059] When determining the specific algorithm, one can first analyze the key hardware architecture indicators of the target PLC or IoT gateway, including main CPU performance (such as clock speed and bit width), memory capacity, and whether it has a hardware encryption instruction set (such as AES-NI) or a dedicated security chip. Then, based on these resource constraints and security level requirements, select an algorithm from recognized lightweight cryptographic algorithm libraries (such as SPECK, LEA, ChaCha20, or the Chinese national cryptographic algorithm SM4) that has low computational complexity, low memory consumption, and has been proven in practice. For example, for a low-performance 8-bit MCU, SPECK might be chosen; for ARM Cortex-M series with certain performance, SM4 or LEA can be selected.

[0060] During integration and configuration, the source code or target library file of the selected lightweight encryption algorithm can be embedded into the firmware project of the PLC or IoT gateway, typically placed in a separate security function module directory. Subsequently, a set of standard, non-blocking calling interfaces (such as encrypt_data(), decrypt_data()) are encapsulated around the algorithm, ensuring these interfaces are fully compatible with the target RTOS's (such as FreeRTOS, VxWorks) task scheduling, interrupt management, and memory management mechanisms. Finally, these APIs are securely exposed to upper-layer applications through services provided by the RTOS (such as message queues and semaphores), and the RTOS's priority settings may be utilized to ensure that encryption tasks do not block high-priority real-time control tasks.

[0061] S21b: The encryption module is integrated into the encryption coprocessor outside the PLC's CPU.

[0062] The cryptographic coprocessor employs hardware acceleration circuitry. A cryptographic coprocessor is a chip or IP core independent of the main CPU, with built-in hardware acceleration circuitry (such as a dedicated arithmetic logic unit), specifically designed for efficient cryptographic computation.

[0063] Here, CPU refers to the main processor in a PLC that performs general logic and control tasks.

[0064] The encryption module here refers to a functional unit in the system architecture that is dedicated to secure operations such as encryption / decryption and digital signatures.

[0065] In practical integration, during the hardware design phase, the selected encryption coprocessor (such as a dedicated security chip or FPGA IP core with SM2 / SM4 / SM3 hardware acceleration capabilities) is connected to the PLC's main CPU via a high-speed bus (such as SPI, PCIe, or AXI). At the software level, a dedicated low-level driver is developed for this coprocessor, and the standardized API provided by this driver is called within the secure transmission module. This allows all encryption, decryption, signing, and verification computation tasks to be directly offloaded and forwarded to the coprocessor for execution, achieving hardware-level acceleration.

[0066] S22: When establishing a secure connection, perform ECC-based mutual authentication and ECDH key exchange, and use session recovery and pre-computed key caching mechanisms to control authentication latency to the millisecond level to meet real-time requirements.

[0067] In order to overcome the drawback of long computation time in traditional public-key cryptography while meeting the requirements of high-strength identity authentication and key security in industrial communication, the ECC / ECDH algorithm is adopted and supplemented by optimization mechanisms such as session recovery and pre-computation caching to compress the complete secure handshake process to the millisecond level.

[0068] Specifically, step S22 above may include: S22a: When the PLC establishes a communication connection with an external device, it performs mutual authentication based on elliptic curve cryptography (ECC) and generates a shared session key in conjunction with the elliptic curve Diffie-Hellman ECDH key exchange protocol.

[0069] In the specific process of identity authentication and key generation, firstly, the two communicating parties (such as the PLC and the host computer) exchange and verify their respective ECC public key certificates to confirm each other's legitimacy. Then, each party generates a temporary ECC key pair and exchanges temporary public keys. Next, each party uses its own temporary private key and the other party's temporary public key to independently calculate the same shared secret value using the ECDH protocol. Finally, based on this shared secret value, both parties use an agreed-upon Key Derivation Function (KDF) to derive a session key for subsequent communication, thereby establishing a secure channel with forward confidentiality while completing two-way identity authentication.

[0070] S22b: Through session recovery technology and a pre-computed temporary key caching mechanism, the latency of each complete authentication process is controlled to within 15 milliseconds.

[0071] The session recovery technology includes: when a communication connection is abnormally interrupted and needs to be re-established, the secure channel is quickly rebuilt in less than 5 milliseconds based on the previously cached secure session context, bypassing the complete key exchange and authentication process.

[0072] In other words, by securely storing the key materials and session identifiers of previous successful sessions in memory, when the connection is interrupted due to non-security reasons such as network fluctuations, both parties can resume communication in a very short time (such as 5 milliseconds) using this secure snapshot, skipping the time-consuming full key negotiation and certificate verification process, and achieving a seamless secure recovery similar to disconnection and reconnection.

[0073] The pre-computed temporary key caching mechanism includes: during idle or low-load periods of the PLC control cycle, one or more elliptic curve temporary key pairs are pre-computed and stored in a pre-cached queue. When a new security session needs to be established, an available temporary key pair is retrieved from the pre-cached queue, thereby eliminating the computational delay caused by on-site key generation.

[0074] In other words, by utilizing time fragments in the PLC control loop, the computationally intensive ECC temporary key pair generation work is completed in advance and in batches and stored in the cache pool. This allows the keys to be retrieved and used directly when a new session needs to be established, reducing the tens of milliseconds of computational delay required for on-site key generation to zero and achieving a zero-wait experience for establishing secure connections.

[0075] The complete authentication process refers to the entire workflow from the PLC and external device initiating a connection request to both parties completing mutual authentication of their identities based on digital certificates (ECC), performing ECDH key exchange to generate a shared session key, and finally establishing an encrypted channel usable by the application layer. This process includes several computationally intensive steps such as certificate parsing and verification, temporary key pair generation, public key exchange, shared secret computation, and session key derivation. By applying session recovery technology (avoiding duplicate verification) and a pre-computed temporary key caching mechanism (eliminating temporary key generation delays), the system can optimize and strictly control the total time of this series of steps to within 15 milliseconds, thereby meeting the stringent real-time requirements of industrial control systems for communication establishment.

[0076] S23: Identify the industrial control protocol type of the communication data. If it is not an internal standard security protocol, convert it into a unified standard protocol format before further processing.

[0077] In order to be compatible with and protect existing systems running on various heterogeneous industrial protocols (such as Modbus and Profinet), a protocol identification and conversion layer is used to uniformly convert different external protocol data into the internally preset standard security protocol format for processing.

[0078] Specifically, step S23 above may include: S23a: Identifies the industrial control protocol characteristics of the target data currently received / sent by the PLC.

[0079] Target data refers to the data unit that the PLC needs to receive or send in the current communication transaction, carrying specific industrial control information (such as read / write commands, process variable values, and equipment status). For example, a request message in a Modbus TCP frame requesting to read a holding register, or output module status data in a Profinet IO cycle.

[0080] Industrial control protocol characteristics refer to the specific structure, fields, encoding rules, or communication modes of data packets used to uniquely identify and distinguish different industrial communication protocols. For example, the characteristics of the Modbus / TCP protocol include its fixed MBAP header, specific function codes (such as 0x03 representing reading holding registers), and register-based data model; while the characteristics of Profinet IO include the Ethernet type field (0x8892) in its Ethernet frames, real-time loop communication mechanism, and specific device identifiers and data object structures.

[0081] S23b: If the industrial control protocol characteristics of the target data are different from those of the standard protocol, the target data shall be converted into the standard protocol characteristics before proceeding to the next step.

[0082] Among them, the standard protocol feature is an industrial control protocol pre-designed for fault detection and encrypted transmission. Generally speaking, the standard protocol feature is an internal protocol specifically designed for the core functions of fault detection and encrypted transmission. It defines a unified data encapsulation format, security fields (such as signatures and encryption identifiers), and metadata fields extended for status monitoring.

[0083] The difference in characteristics means that the data currently being transmitted follows external or existing industrial communication protocols (such as Modbus), and its data format and field definitions do not have the ability to embed security and diagnostic information as required by the current system. Therefore, it cannot be directly understood and processed by the fault detection and secure transmission module.

[0084] During the specific conversion, the target data is first parsed to extract its original payload and control semantics. Then, according to the format specifications of the standard protocol features, this information is re-encapsulated and the required unified security headers (such as encryption identifiers and hash values) and extended diagnostic fields are added.

[0085] S23c: If the industrial control protocol characteristics of the target data are the same as those of the standard protocol, proceed directly to the next step of processing.

[0086] The identical characteristics mean that the data itself is encapsulated and transmitted according to a preset standard security protocol format, and has naturally integrated the necessary security fields and diagnostic information. Therefore, it can be directly processed by the subsequent fault detection and encryption verification modules without additional conversion.

[0087] S24: Obtain real-time data generated by the PLC in the current cycle, as well as status data involved in decrypting received data or encrypting transmitted data.

[0088] Step S24 here is implemented in the same way as step S11 in the previous embodiment. Please refer to the relevant description in the previous embodiment. It will not be repeated here.

[0089] S25: Establish a dynamic threshold range based on normal real-time data and status data within the historical period and real-time data and status data within the current period.

[0090] The length of the historical period is fixed. That is, when the system establishes and updates the dynamic threshold range, the historical data time window or the number of data points it uses is preset and remains unchanged. For example, the system may always use only the normal data from the most recent 1000 control periods to calculate the threshold. When new period data is added, the oldest period data is removed from the window, thus ensuring that the size of the dataset used for learning remains constant. This avoids the computational burden and model update lag caused by the infinite accumulation of data, and also ensures that the threshold can reflect the recent (rather than all historical) normal operating characteristics of the system in a timely manner, enhancing the algorithm's ability to respond to recent changes.

[0091] When establishing a dynamic threshold range, a fixed-length (e.g., N periods) historical data sequence marked as normal is collected and stored during the initialization or learning phase. For each monitored parameter (e.g., temperature, CPU load), based on these N historical normal values, its initial threshold range (e.g., [μ-2σ, μ+2σ]) is calculated using statistical methods (e.g., calculating its moving average μ and standard deviation σ). During subsequent continuous operation, whenever new periodic data is determined to be normal, it is added to the historical data sequence, while the oldest data point is removed, thus forming a first-in-first-out sliding window. The system periodically (e.g., every M periods) or whenever new normal data is added, it recalculates the statistical characteristics of each parameter based on all data within the current sliding window and dynamically updates its threshold range, enabling the threshold to adapt to changes in the system's operating state.

[0092] If the current period's data has not yet been determined to be normal, a conservative learning strategy is employed. This period's data, along with historical normal data, is still included in the threshold calculation pool, but with a lower confidence weight or a more robust statistical method (such as median and interquartile range) to reduce the impact of potential outliers on the threshold calculation results. Subsequently, the system performs a trial match on the current period's data based on this preliminary calculation result. If the match is successful, the data is officially marked as normal and included in the historical sequence. If the match fails, this threshold update is considered invalid and rolled back; the historical sequence remains unchanged, awaiting subsequent normal period data for further updates.

[0093] In practical applications, real-time data includes sensor data and PLC data.

[0094] Sensor data refers to the digital or analog signal values ​​collected and converted by various physical quantity sensors (such as temperature, pressure, flow, and position sensors) connected to the PLC input module, and then sent to the PLC to reflect the state of the controlled object or environment. Examples include: the current temperature value output by a temperature sensor (e.g., 25.6°C), the pipeline pressure reading from a pressure transmitter (e.g., 0.8 MPa), and the presence or absence of a signal detected by a photoelectric switch (1 indicates presence, 0 indicates absence).

[0095] PLC data refers to the variables and status information generated, processed, or stored within the PLC system for controlling logic execution and system status management. Examples include: the current value of internal timers (such as the elapsed time of the TON instruction), the cumulative value of counters, program execution flags (such as the motor start-up completion flag), intermediate calculation results (such as the output value of the PID controller), and system performance parameters such as CPU load rate and memory usage.

[0096] The dynamic threshold range includes the sensor threshold range, the PLC threshold range, and the communication status threshold range.

[0097] The sensor threshold range refers to the dynamic normal value range set for various types of sensor data. For example, the dynamic threshold range of a temperature sensor may be [20.0°C, 30.5°C].

[0098] PLC threshold range refers to the dynamic normal value range set for PLC internal data (such as CPU load, memory usage, and internal variables). For example, the dynamic threshold range for CPU utilization may be [0%, 75%].

[0099] The communication status threshold range refers to a dynamic normal value range set for status data (such as encryption time, network latency, and packet loss rate) during secure communication processes such as data encryption / decryption and network transmission. For example, the dynamic threshold range for the time taken of a single SM4 encryption operation may be [50μs, 200μs].

[0100] In complex industrial environments, a single parameter anomaly may be a transient disturbance or a local fault, while a simultaneous anomaly of multiple parameters is more likely to indicate a systemic fault or attack. In order to accurately identify serious faults and maintain control continuity while reducing false alarms, a multi-dimensional matching strategy is adopted. Only when multiple parameters are abnormal is it determined as a final fault and comprehensive measures are taken. For single parameter anomalies, alarms are issued according to their types, and the previous valid value is used for fault-tolerant control when critical control data is abnormal.

[0101] S26: Match the sensor data in the current cycle with the sensor threshold range; match the PLC data in the current cycle with the PLC threshold range; match the status data in the current cycle with the communication status threshold range.

[0102] The matching here refers to comparing the values ​​of each specific monitoring parameter in the three types of data (sensor data, PLC internal data, and communication status data) with the dynamic threshold range calculated and maintained separately for that parameter in its respective category, in order to determine whether the current value of the parameter is within the normal range, rather than comparing the three types of data together or as a whole.

[0103] S27: If at least two of the above matches fail, then the final match is determined to be a failure.

[0104] If at least two of the above matching fails, it means that at least two of the three key dimensions of the system—sensor, PLC internal status, and secure communication—are experiencing parameter anomalies simultaneously. This strongly indicates that the system may be experiencing serious problems such as complex equipment failure, overall performance degradation, or coordinated network attacks.

[0105] Next, the system will immediately determine that the final match has failed at the highest level, triggering the preset highest-level fault response process, including but not limited to performing an emergency shutdown or switching to safe mode, starting all redundant backup devices, fully encrypting and reporting the highest priority alarm containing all anomaly details, and may proactively disconnect some non-critical external connections for isolation, in order to contain the impact of the fault to the greatest extent and ensure the safety of personnel and equipment.

[0106] S28: If only one of the above matching fails, select the corresponding alarm level according to the anomaly type of the failed data, and if the failed data is PLC control data, use the previous valid data of the failed data for PLC control.

[0107] If only one of the above matching fails, it means that the system only detected parameter abnormalities in a single dimension (sensor, PLC internal or communication status), which may be a local fault, transient interference or initial attack indication.

[0108] For single-parameter anomalies, the system assigns alarm levels according to rules and reports them. If the abnormal data directly affects the control output, it automatically switches to the valid value of the previous cycle for fault-tolerant control to ensure continuous execution.

[0109] When selecting an alarm level, the system maintains a predefined rule base for mapping anomaly types to alarm levels. When a single parameter matching fails, the system first identifies the anomaly type to which the parameter belongs (e.g., temperature sensor over-limit is a process parameter anomaly, encryption timeout is a security performance anomaly, and CPU overload is a system resource anomaly). Then, the system comprehensively evaluates the anomaly based on the severity coefficient preset for each anomaly type in the rule base, historical occurrence frequency, and the deviation of the current parameter, ultimately determining a specific alarm level (e.g., "Warning," "Severe," "Urgent"). For example, a minor initial temperature over-limit might trigger a "Warning," while a sustained and significant encryption timeout might directly trigger a "Severe" alarm.

[0110] When the system identifies a parameter that failed to match as data directly used to generate PLC control outputs (e.g., valve opening setpoints derived from PID calculations), it immediately retrieves the value of that parameter from a dedicated safety buffer that was verified as normal (i.e., successfully matched) at the end of the previous control cycle. The system then uses this "previous valid data" to overwrite the abnormal value of the current cycle and performs the control logic calculations and output refresh for the current cycle based on this value.

[0111] Simultaneously, the abnormal event, the replaced abnormal value, and the previous valid value used are all recorded in the fault log and reported as part of the alarm information. This process is completed automatically within a single control cycle, is transparent to the control task, and achieves seamless switching.

[0112] S29: If the matching fails, control instructions, fault alarm information and data acquisition strategy are generated based on the real-time data and / or status data of the matching failure, so that the PLC can adjust the execution strategy based on the control instructions, execute the acquisition of real-time data and status data in the next cycle based on the data acquisition strategy, and transmit the fault alarm information to the safety monitoring platform after encryption.

[0113] Step S29 here is implemented in the same way as step S13 in the previous embodiment. Please refer to the relevant description in the previous embodiment. It will not be repeated here.

[0114] While generating and executing immediate control and alarm responses to faults, the system further recognizes that faults or anomalies may originate from or be accompanied by security threats, and may also impact the system's real-time processing capabilities. Therefore, in order to conduct collaborative defense and resource optimization from a communication security perspective, the system then needs to adjust its own encryption strategy.

[0115] S210: Adjust the encryption strategy based on real-time data and / or status data of failed matches to balance the real-time performance and security of the PLC.

[0116] In other words, the system dynamically adjusts its encryption strategy based on the nature and severity of anomalies revealed by the failed matching data. When facing the highest level of failure, to ensure the ultimate real-time performance and reliable delivery of critical commands, the strategy is simplified to signing only and enabling dual-channel transmission. When the system is in a resource-constrained critical state, basic control functions are prioritized by reducing encryption overhead (such as signing only or using short keys). And when clear signs of an attack are detected, the encryption strength is immediately increased to build a stronger defense.

[0117] Through this hierarchical and adaptive adjustment, the system can dynamically and optimally allocate limited computing and communication resources under different abnormal scenarios, thereby achieving a balance between security and real-time performance as a whole.

[0118] Specifically, step S210 above may include: S210a: When the fault level of the real-time data and / or status data that failed to match is the highest level, the adjusted encryption strategy is: only sign, skip encryption, and interrupt the transmission of data with a fault level lower than the highest level in the PLC, and transmit it through the main and backup channels at the same time.

[0119] The fault level here refers to the quantitative classification of detected faults or anomalies by the system based on the potential or actual harm they pose to equipment safety, personnel safety, production continuity, and system integrity. For example: the highest level (such as level 3) refers to faults that may cause serious equipment damage, personnel injury, complete production interruption, or complete control of the system, such as simultaneous failure of multiple modules of the main controller, safety loop breakage, or detection of a confirmed remote code execution attack; the medium level (level 2) refers to faults that may affect part of production or equipment performance, such as continuous abnormality of a single sensor or partial network congestion; the low level (level 1) refers to minor anomalies that are temporary, self-recoverable, or only generate alarms, such as momentary communication jitter or slight parameter over-limit.

[0120] Signature-only, skipping encryption means that data packets sent outwards only have a digital signature attached (for verifying origin and integrity) without further symmetric or asymmetric encryption of the entire data payload, minimizing processing latency. Interrupting the transmission of data with a fault level lower than the highest in the PLC means the system will suspend the transmission of all non-urgent data (such as routine status reports and non-critical logs) related to medium and low-level faults, concentrating communication bandwidth and CPU resources on handling the highest-level faults. Simultaneous transmission via primary and backup channels means that for critical instructions or alarms related to the highest-level fault, the system will synchronously transmit the same data through two independent physical or logical network paths (e.g., primary Ethernet and backup wireless link) to ensure reliable delivery even if one channel fails.

[0121] S210b: When real-time data and / or status data that fail to match indicate that the PLC is in a critical operating state, the adjusted encryption strategy is: sign only, skip encryption, or use a key shorter than the current key.

[0122] Critical operating state refers to a situation where the computing, communication, or storage resources of a PLC system (such as CPU utilization, memory availability, and network bandwidth) have reached or are close to their design limits, resulting in a significant increase in overall system response latency. The system is on the verge of barely maintaining basic control functions but could become unstable at any time due to additional load. Examples include: CPU utilization consistently exceeding 90%, available memory below 5% of total capacity, and control cycle execution time jitter exceeding 50% of normal values.

[0123] When the data that fails to match contains abnormal resource indicators (such as CPU load and memory utilization), and their values ​​continue to exceed the critical state threshold (which is usually set at a safety margin slightly below the design limit, such as 85% CPU utilization), the system determines that the PLC is in a critical operating state.

[0124] When a critical operating state is determined, the system first assesses the severity of the current load. If time delay is the primary concern, a signature-only, encryption-skipped strategy is activated, calculating and appending only SM3 hashes and SM2 signatures to all outgoing data to minimize CPU overhead. If a certain level of confidentiality is required but encryption delay is still too high, a short-key strategy is adopted, such as temporarily switching the currently used SM4 symmetric key from 256 bits to 128 bits to reduce the computational load of encryption and decryption. The specific strategy selection can be automatically executed based on a predefined critical state level subclass (such as delay criticality or computational criticality).

[0125] S210c: When real-time data and / or status data that fail to match indicate that the PLC is under attack, the adjusted encryption strategy is to adopt a higher level of encryption.

[0126] When the status data of a failed match contains clearly abnormal attack characteristics, the system determines that it has been attacked. These indicators include, but are not limited to: abnormally high frequency of connection requests from the same source IP, identification of specific network port scanning behavior, a sharp increase in the number of decryption failures or signature verification failures within a short period of time, and alarms triggered by security modules (such as intrusion detection rules) for known attack patterns. In addition, if multiple communication status parameters (such as latency, packet loss rate, and encryption error rate) are simultaneously and drastically abnormal, and after ruling out device hardware failures, it also strongly indicates that a distributed denial-of-service (DDoS) or man-in-the-middle attack may have occurred.

[0127] At this point, the system first upgrades the currently used encryption algorithm to a higher strength version (for example, switching from 128-bit SM4 to 256-bit SM4, or upgrading from SM2 signature to a combination of SM2 signature and SM9 identifier encryption).

[0128] Simultaneously, all session keys are forced to be replaced immediately, and more frequent key update cycles may be enabled. Furthermore, the strategy may include attaching an additional Authentication Code (MAC) layer to critical packets, enabling stringent sequence number checks to resist replay attacks, or even temporarily switching to a backup, more sophisticated hybrid encryption suite. All adjustments are designed to increase the difficulty for attackers to crack or interfere with the encryption.

[0129] After successfully adjusting the encryption strategy under abnormal conditions and responding to faults or attacks, the system needs to safely and smoothly transition back to normal operation from the emergency state. Therefore, once the system confirms that the PLC has returned to normal operation, it initiates the following key update and transition process.

[0130] S211: When the PLC resumes normal operation, a new session key is forcibly negotiated to ensure forward security, and a smooth transition is performed on the data in the transmission queue to distribute the old and new keys.

[0131] Specifically, step S211 above may include: S211a: When the PLC resumes normal operation, it forcibly initiates a new session key negotiation with the current communication peer to obtain a new set of session keys.

[0132] Determining whether a PLC has resumed normal operation is a complex decision-making process based on continuous monitoring of multiple indicators. The system requires that within a continuous monitoring window (e.g., 10 consecutive control cycles), all real-time data and status data successfully pass dynamic threshold matching, and the fault detection module does not generate any new control commands, alarm messages, or data acquisition strategy adjustment requests. Simultaneously, the abnormal indicators that previously triggered encryption strategy adjustments (such as high CPU load or attack characteristics) must have fallen back and stabilized within the normal range of their respective dynamic thresholds. Only when all these conditions are met does the system comprehensively determine that the PLC has resumed normal operation and trigger the subsequent security context update process.

[0133] During key updates, the system sends a key update request command with proof of timeliness and freshness (such as a timestamp-based challenge value) to all currently active communication partners (such as the host computer and other PLCs) via the secure transmission module. The receiving partner must sign the request using its long-term private key. Subsequently, based on this interaction, both parties re-execute a complete key exchange process with forward secrecy (such as based on the ECDH protocol) to generate a completely new set of session keys.

[0134] This process is mandatory, even if the current session has not expired, to ensure forward security of communication after recovery.

[0135] S211b: For data in the transmission queue, the highest priority data is transmitted using the original session key, and the data in the transmission queue other than the highest priority data and the data newly added to the transmission queue are transmitted using the newly obtained session key.

[0136] The transmission queue here refers to the set of data packets that already exist in the PLC's transmit buffer, waiting to be sent by the network but not yet sent, at the moment the system determines that it has resumed normal operation and begins negotiating a new key. The highest priority data refers to the data in this queue that is marked as needing to be sent with the lowest latency and highest reliability; this is typically real-time control commands or the highest level of security heartbeats. Using the original session key for transmission means that when this data is retrieved from the queue and sent, it is still encrypted and signed using the old session key from before the negotiation, ensuring that its transmission process is not delayed by the key switch, thus maintaining control continuity. All other data in the queue, as well as all newly generated data thereafter, are processed using the newly negotiated session key.

[0137] In this way, the risk of key leakage during abnormal operation is completely eliminated by forcibly updating the key, which enhances forward security. At the same time, the smooth transition strategy between the old and new keys ensures the continuous and delay-free transmission of the highest priority control commands at the moment of key switching, thus guaranteeing the real-time performance and reliability of critical controls.

[0138] After this, the PLC will enter a stable, normal operating phase. It will continue to execute routine control logic, use a new session key to encrypt and protect the integrity of all new communication data, and continue to monitor real-time and status data in a dynamic matching manner.

[0139] Simultaneously, the system will clear the temporary encryption policy set due to the abnormal event, restore the standard security configuration, and maintain moderate attention to historical abnormal parameters (such as a slightly higher sampling frequency) until the system is confirmed to be completely stable. The entire protocol stack will maintain this integrated intelligent detection and secure communication loop until the next abnormal event is triggered.

[0140] After completing multi-dimensional independent matching of sensor, PLC internal, and communication status data, the system summarizes the matching results. When all parameter matching results are successful, it means that the PLC system's operating status and safety condition are within the normal range for the current cycle.

[0141] S212: If the match is successful, it is determined that the PLC system is in normal operating status and safety condition within the current cycle.

[0142] In this situation, the PLC will maintain the current control execution strategy and data acquisition frequency, continue to execute the predetermined control tasks, and use the current session key to perform routine encryption and integrity protection on subsequent communication data. The entire system will remain in a steady-state, safe closed-loop operation until the next control cycle begins a new round of monitoring and matching processes.

[0143] This concludes the description of the fault detection method based on PLC encryption and decryption provided in this application embodiment.

[0144] Based on the same inventive concept, this application also provides a fault detection device based on PLC encryption and decryption operation.

[0145] The fault detection device based on PLC encryption and decryption is applied to PLC.

[0146] In practical applications, this device can be a functional system integrated into or attached to the PLC. It acquires data and executes control by accessing the PLC's input / output image area, internal memory, network interface, and security hardware (such as encryption coprocessor). Ultimately, it applies the generated control commands, acquisition strategies, and secure communication behaviors to the PLC itself and its connected external network, thereby achieving intelligent monitoring of the PLC's operating status, autonomous fault diagnosis and response, and enhanced security. It is a core functional unit for improving the reliability, security, and real-time performance of the PLC itself.

[0147] Figure 3This is a schematic diagram of the fault detection device based on PLC encryption / decryption operation in the embodiments of this application. Figure 1 See Figure 3 As shown, the device may include: The data acquisition module 31 is used to acquire real-time data generated by the PLC in the current cycle, as well as status data involved in decrypting received data or encrypting sent data.

[0148] The fault detection module 32 is used to match the real-time data and status data in the current cycle with the dynamic threshold range, which is determined based on the real-time data and status data generated under normal conditions in the PLC's historical cycles. If the matching fails, control instructions, fault alarm information and data acquisition strategies are generated based on the real-time data and / or status data that failed to match.

[0149] The safety communication module 33 is used to enable the PLC to adjust the execution strategy based on control instructions, to collect real-time data and status data for the next cycle based on the data acquisition strategy, and to transmit the fault alarm information to the safety monitoring platform after encryption.

[0150] Furthermore, as a response to Figure 3 In addition to the refinement and expansion of the illustrated device, this application embodiment also provides a fault detection device based on PLC encryption and decryption operation.

[0151] Figure 4 This is a schematic diagram of the fault detection device based on PLC encryption / decryption operation in the embodiments of this application. Figure 2 See Figure 4 As shown, the device may include: Configuration module 41 is used to determine the appropriate lightweight encryption algorithm based on the hardware architecture of the PLC system; integrate the lightweight encryption algorithm into the firmware of the PLC or IoT gateway, and configure the application programming interface (API) compatible with the real-time operating system (RTOS); or, the encryption module is integrated into the encryption coprocessor outside the CPU of the PLC, and the encryption coprocessor adopts hardware acceleration circuitry.

[0152] An optimization module 42 is established to perform mutual authentication based on elliptic curve cryptography (ECC) when the PLC establishes a communication connection with an external device, and to generate a shared session key in conjunction with the elliptic curve Diffie-Hellman ECDH key exchange protocol. Through session recovery technology and a pre-computed temporary key caching mechanism, the latency of each complete authentication process is controlled within 15 milliseconds. The session recovery technology includes: when the communication connection is abnormally interrupted and needs to be re-established, the secure channel is quickly rebuilt within less than 5 milliseconds based on the previously cached secure session context, bypassing the complete key exchange and authentication process. The pre-computed temporary key caching mechanism includes: during the idle or low-load period of the PLC control cycle, one or more elliptic curve temporary key pairs are pre-computed and stored in a pre-cached queue. When a new secure session needs to be established, an available temporary key pair is retrieved from the pre-cached queue, thereby eliminating the computational latency caused by on-site key generation.

[0153] The identification and conversion module 43 is used to identify the industrial control protocol characteristics of the target data received / sent by the current PLC; if the industrial control protocol characteristics of the target data are different from the standard protocol characteristics, the target data is converted into the standard protocol characteristics before further processing. The standard protocol characteristics are an industrial control protocol preset for fault detection and encrypted transmission.

[0154] The data acquisition module 44 is used to acquire real-time data generated by the PLC in the current cycle, as well as status data involved in decrypting received data or encrypting sent data.

[0155] The threshold adjustment module 45 is used to establish a dynamic threshold range based on normal real-time data and status data in the historical period and real-time data and status data in the current period, wherein the length of the historical period is fixed.

[0156] When real-time data includes sensor data and PLC data, and dynamic threshold ranges include sensor threshold ranges, PLC threshold ranges, and communication status threshold ranges, the fault detection module 46 is used to match the sensor data in the current period with the sensor threshold ranges; match the PLC data in the current period with the PLC threshold ranges; and match the status data in the current period with the communication status threshold ranges. If at least two of the above matches fail, a final match failure is determined. If only one of the above matches fails, the corresponding alarm level is selected according to the anomaly type of the failed data, and if the failed data is PLC control data, the previous valid data of the failed data is used for PLC control. If a final match failure occurs, control instructions, fault alarm information, and data acquisition strategies are generated based on the failed real-time data and / or status data.

[0157] The safety communication module 47 is used to enable the PLC to adjust the execution strategy based on control instructions, to collect real-time data and status data for the next cycle based on the data acquisition strategy, and to transmit the fault alarm information to the safety monitoring platform after encryption.

[0158] The encryption adjustment module 48 is used to adjust the encryption strategy based on the real-time data and / or status data of the failed match, so as to balance the real-time performance and security of the PLC.

[0159] The encryption adjustment module 48 is specifically used to adjust the encryption strategy as follows when the fault level of the failed real-time data and / or status data is the highest level: only sign, skip encryption, and interrupt the transmission of data with a fault level lower than the highest level in the PLC, and transmit it through the main and backup channels simultaneously; or, when the failed real-time data and / or status data indicates that the PLC is in a critical operating state, the adjusted encryption strategy is to only sign, skip encryption, or use a key shorter than the current key; or, when the failed real-time data and / or status data indicates that the PLC has been attacked, the adjusted encryption strategy is to adopt a higher level encryption strategy.

[0160] The recovery transition module 49 is used to force a new session key negotiation with the current communication peer when the PLC resumes normal operation, and obtain a new set of session keys. For data in the transmission queue, the highest priority data is transmitted using the original session key, and the data in the transmission queue other than the highest priority data and the data newly added to the transmission queue are transmitted using the newly obtained session key.

[0161] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0162] Based on the same inventive concept, this application also provides a computer device.

[0163] Figure 5 This is a schematic diagram of the structure of the computer device in an embodiment of this application. See also... Figure 5 As shown, the computer device may include: a memory 51, a processor 52, and a computer program stored on the memory 51, wherein the processor 52 executes the computer program to implement the methods described in the foregoing embodiments.

[0164] It should be noted that the description of the above computer device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0165] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in the foregoing embodiments.

[0166] It should be noted that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0167] Based on the same inventive concept, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described in the foregoing embodiments.

[0168] It should be noted that the descriptions of the above computer program product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the computer program product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0169] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A fault detection method based on PLC encryption / decryption operation, characterized in that, The method is applied to a programmable logic controller (PLC), and the method includes: Acquire the real-time data generated by the PLC in the current cycle, as well as the status data involved in decrypting the received data or encrypting the sent data; The real-time data and status data within the current cycle are matched with a dynamic threshold range, which is determined based on the real-time data and status data generated under normal conditions within the PLC's historical cycles. If the matching fails, control instructions, fault alarm information and data acquisition strategies are generated based on the real-time data and / or status data of the failed matching, so that the PLC adjusts the execution strategy based on the control instructions, executes the acquisition of real-time data and status data for the next cycle based on the data acquisition strategy, and transmits the fault alarm information to the safety monitoring platform after encryption.

2. The method according to claim 1, characterized in that, Before matching the real-time data and status data within the current period with the dynamic threshold range, the method further includes: The dynamic threshold range is established based on normal real-time data and status data within the historical period and real-time data and status data within the current period, wherein the length of the historical period is fixed.

3. The method according to claim 1, characterized in that, The real-time data includes sensor data and PLC data, and the dynamic threshold range includes sensor threshold range, PLC threshold range, and communication status threshold range; matching the real-time data and status data within the current period with the dynamic threshold range includes: Match the sensor data within the current period with the sensor threshold range; Match the PLC data within the current cycle with the PLC threshold range; Match the status data within the current period with the communication status threshold range; The method further includes: If at least two of the above matches fail, then the final match is determined to be a failure. If only one of the above matching fails, the corresponding alarm level is selected according to the anomaly type of the failed data. If the failed data is PLC control data, the previous valid data of the failed data is used for PLC control.

4. The method according to claim 1, characterized in that, The method further includes: Based on the real-time data and / or status data of the failed matches, the encryption strategy is adjusted to balance the real-time performance and security of the PLC.

5. The method according to claim 4, characterized in that, The step of adjusting the encryption strategy based on the real-time data and / or status data of the failed match includes: When the fault level of the failed real-time data and / or status data is the highest level, the adjusted encryption strategy is: only sign, skip encryption, and interrupt the transmission of data with a fault level lower than the highest level in the PLC, and transmit simultaneously through the main and backup channels; or, When the real-time data and / or status data indicating a failed match indicate that the PLC is in a critical operating state, the adjusted encryption strategy is: sign only, skip encryption, or use a key shorter than the current key; or, When the real-time data and / or status data indicating that the PLC has been attacked due to the failed matching, the adjusted encryption strategy is to adopt a higher level of encryption.

6. The method according to claim 1, characterized in that, The method further includes: When the PLC resumes normal operation, it forcibly initiates a new session key negotiation with the current communication peer to obtain a new set of session keys; For data in the transmission queue, the highest priority data is transmitted using the original session key, and the data in the transmission queue other than the highest priority data and the data newly added to the transmission queue are transmitted using the newly obtained session key.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Determine a suitable lightweight encryption algorithm based on the hardware architecture of the PLC system; integrate the lightweight encryption algorithm into the firmware of the PLC or IoT gateway, and configure an application programming interface (API) compatible with a real-time operating system (RTOS); or, The encryption module is integrated into an encryption coprocessor outside the central processing unit (CPU) of the PLC, and the encryption coprocessor uses hardware acceleration circuitry.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: When the PLC establishes a communication connection with an external device, mutual authentication based on elliptic curve cryptography (ECC) is performed, and a shared session key is generated in conjunction with the elliptic curve Diffie-Hellman ECDH key exchange protocol. By using session recovery technology and a pre-computed temporary key caching mechanism, the latency of each complete identity authentication process is controlled to within 15 milliseconds; The session recovery technology includes: when a communication connection is abnormally interrupted and needs to be re-established, the secure channel is quickly rebuilt within less than 5 milliseconds based on the previously cached secure session context, bypassing the complete key exchange and authentication process; The pre-computed temporary key caching mechanism includes: pre-compiling one or more elliptic curve temporary key pairs during the idle or low-load period of the PLC control cycle and storing them in a pre-cached queue; when a new security session needs to be established, an available temporary key pair is retrieved from the pre-cached queue, thereby eliminating the computational delay caused by on-site key generation.

9. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Identify the industrial control protocol characteristics of the target data currently being received / sent by the PLC; If the industrial control protocol characteristics of the target data are different from the standard protocol characteristics, the target data will be converted into the standard protocol characteristics before further processing. The standard protocol characteristics are an industrial control protocol preset for fault detection and encrypted transmission.

10. A fault detection device based on PLC encryption / decryption operation, characterized in that, The device is used in a programmable logic controller (PLC), and the device includes: The data acquisition module is used to acquire real-time data generated by the PLC in the current cycle, as well as status data involved in decrypting received data or encrypting sent data. The fault detection module is used to match the real-time data and status data in the current cycle with a dynamic threshold range, which is determined based on the real-time data and status data generated under normal conditions in the PLC's historical cycles. If the matching fails, control instructions, fault alarm information and data acquisition strategies are generated based on the real-time data and / or status data that failed to match. The safety communication module is used to enable the PLC to adjust its execution strategy based on the control instructions, to collect real-time data and status data for the next cycle based on the data acquisition strategy, and to encrypt and transmit the fault alarm information to the safety monitoring platform.

Images