Fire pump controller driven by domestic chip with double-standard data encryption and man-machine cooperation method
Patent Information
- Application Number
- CN202611111993.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-10-13
AI Technical Summary
[0009]本发明还有一个目的是提供一种国产芯片驱动的消防泵控制器双标准数据加密与人机协同方法,其解决了现有消防泵控制器因加密方案与国产硬件平台及人机界面协同不足,导致在同时满足国密合规、国际认证数据防篡改及NFPA20参数监测规范时实时性较差、标准兼顾困难与部件依赖进口的问题
1、本发明通过在国产主控芯片内部集成双模式硬件加密单元对消防泵运行参数执行片上硬件加密运算,并将加密数据包写入芯片内部非易失性存储器形成本地备份,同时将完整性校验值随加密数据包一同发送以供接收端验证,实现了消防泵运行数据在单一国产芯片平台上兼顾国密算法与国际认证加密需求,无需依赖外接进口加密芯片,并保障了数据在传输链路中的完整性和可追溯性。
Abstract
Description
Technical Field
[0001] This invention relates to the field of data security transmission technology for fire pump control systems. More specifically, this invention relates to a dual-standard data encryption and human-machine collaboration method for a fire pump controller driven by a domestically produced chip. Background Technology
[0002] Fire pumps are the core equipment of building fire protection water supply systems, and their operating status directly affects the effectiveness of fire suppression during a fire. With the popularization of fire protection IoT technology, fire pump controllers need to upload operating parameters such as pump outlet pressure, pump speed, and running time to a remote monitoring platform in real time to achieve remote monitoring and data management. Against this backdrop, the security of fire pump operating data during collection, transmission, and storage is receiving increasing attention.
[0003] Domestic standards require that core fire protection data be encrypted using national cryptographic algorithms (such as SM4). International certifications such as FM (Factory Mutual) and UL (Underwriters Laboratories) have specific requirements for the tamper-proof capabilities of fire equipment data, requiring a data integrity verification pass rate of over 99.99%. NFPA 20 (US Fire Pump Installation Standard) requires that fire pump operating parameters be uploaded in real time and that the data be authentic and traceable. These standards together constitute a multi-layered system of requirements for the data security of fire pump controllers.
[0004] Existing fire pump controllers have the following problems in meeting the above requirements: First, the encryption schemes lack compatibility. Some schemes use imported encryption chips to achieve the data tamper-proof function required for FM / UL certification, but this approach relies on imported components, posing supply chain risks. Other schemes use domestically produced chips combined with software to implement Chinese cryptographic algorithms for encryption, in order to meet domestic compliance requirements. However, software encryption methods lag behind hardware encryption in terms of computational efficiency and security, and are difficult to simultaneously support encryption standards required for international certification. Both types of schemes can only meet the requirements of a single standard system, and no fire pump controller solution has yet been found that can simultaneously support both Chinese cryptographic algorithms and internationally certified encryption algorithms on the same hardware platform.
[0005] Secondly, there is insufficient coordination between data encryption and human-machine interface (HMI) display. Fire pump controllers are typically equipped with HMIs for on-site parameter display and operation. When operating parameters are transmitted to the HMI after encryption, they need to be decrypted before being displayed. In existing solutions, the decryption and display process of encrypted data on the HMI has a high delay, affecting the efficiency of on-site operators in obtaining real-time data. In addition, domestically produced HMIs are insufficient in adapting to the visualization display of encrypted data, making it difficult to clearly indicate the encryption status and integrity verification results of the data, and operators cannot intuitively determine whether the data they are viewing has been effectively encrypted.
[0006] Third, there is insufficient compatibility between data security protection and the NFPA 20 parameter monitoring standard. NFPA 20 requires the traceability of fire pump operating parameters. However, existing encrypted transmission schemes are prone to parameter loss or incomplete recording during data encryption, packaging, and transmission, affecting data integrity and traceability. Furthermore, without an effective integrity verification mechanism during encrypted transmission, data is at risk of being tampered with on the transmission link. Once tampered, it is difficult to detect in a timely manner and difficult to trace the original data.
[0007] The reasons for the above problems are as follows: the data security of fire pump controllers involves multiple aspects, including encryption algorithm selection, hardware implementation, data transmission, and human-machine interaction. Each aspect is constrained by different standards and specifications, while existing technical solutions are mostly designed for a single standard or a single aspect, lacking an architectural approach that systematically integrates national cryptographic compliance, international certification anti-tampering, and NFPA20 parameter monitoring specifications on a single domestically produced hardware platform. The main difficulties in solving these problems include: how to integrate hardware acceleration units for multiple encryption algorithms within the limited hardware resources of domestically produced chips; how to achieve low-latency collaborative processing of encrypted data between the chip and the human-machine interface without significantly increasing costs; and how to make the data encryption protection mechanism compatible with the real-time monitoring and traceability requirements of fire pump operating parameters. Summary of the Invention
[0008] One object of the present invention is to solve at least the above-mentioned problems and to provide at least the advantages that will be described later.
[0009] Another objective of this invention is to provide a dual-standard data encryption and human-machine collaboration method for fire pump controllers driven by domestically produced chips. This method addresses the problems of poor real-time performance, difficulty in achieving standard compliance, and reliance on imported components in existing fire pump controllers due to insufficient collaboration between encryption schemes and domestic hardware platforms and human-machine interfaces, while simultaneously meeting national cryptographic compliance, international certification data tamper-proofing, and NFPA20 parameter monitoring specifications. This method integrates a dual-mode hardware encryption unit and a hardware-level integrity verification module within the chip. It achieves on-chip low-latency encryption and local backup of operating parameters at the data acquisition source, with encryption latency not exceeding 50 microseconds and decryption latency not exceeding 80 microseconds, ensuring real-time collaboration between data transmission and display. Furthermore, the mechanism of sending verification values along with data packets and verifying them at the receiving end effectively guarantees the integrity and traceability of data in the transmission link. Based on the above scheme, this method takes into account both national cryptographic algorithms and international certification encryption requirements on a single domestic chip platform, without relying on external imported encryption chips. It also realizes rapid collaborative decryption and visualization of encrypted data on a domestic human-machine interface, thereby improving the adaptability of fire pump controllers under diverse standard systems, system response efficiency and the level of independent control of key components, while reducing the complexity and implementation cost of the overall system scheme.
[0010] To achieve these objectives and other advantages according to the present invention, a method for dual-standard data encryption and human-machine collaboration of a domestically produced chip-driven fire pump controller is provided, comprising the following steps: S1. Digital acquisition and input of physical sensor signals: Real-time acquisition of fire pump operating parameters through sensors and transmission to domestic main control chip. Fire pump operating parameters include at least pump outlet pressure, pump speed and running time. S2. Hardware Register Status Identification and Algorithm Kernel Retrieval for Encryption Mode: The domestic main control chip reads the working mode flag stored in its internal registers and matches the corresponding encryption algorithm based on the flag: when the flag is in the first state, the national cryptographic SM4 algorithm is selected; when the flag is in the second state, the AES-256 algorithm is selected. Specifically, the domestic main control chip reads the working mode flag (determining the algorithm family: SM4 or AES) and the encryption strength level register (determining the key length / operation rounds) stored in its internal registers, and matches the corresponding specific encryption configuration based on the combination of the above two: when the flag is in the first state and the strength level is high, the SM4 standard round is selected; when the flag is in the first state and the strength level is low, the SM4 simplified round is selected; when the flag is in the second state and the strength level is high, AES-256 is selected; when the flag is in the second state and the strength level is low, AES-128 is selected. S3. On-chip hardware arithmetic logic encryption operation: The dual-mode hardware encryption unit calls the selected encryption algorithm to perform on-chip hardware encryption operation on the fire pump operating parameters and generate encrypted data packets; S4. Backup and Cyclic Redundancy Check of Encrypted Data to Physical Storage Media: After the encrypted data packet is generated, the domestic main control chip writes it to the encrypted data backup area of the chip's internal non-volatile memory, forming a local physical backup. Simultaneously, the hardware-level data integrity verification module runs a cyclic redundancy check or hash check algorithm on the encrypted data packet and outputs an integrity verification value. Specifically, the hardware-level data integrity verification module defaults to running the CRC32 cyclic redundancy check algorithm on the encrypted data packet and outputs a 32-bit verification value. When the working mode is identified as domestic mode and the encryption strength level is high, the SM3 hash check algorithm is additionally enabled to output a 256-bit hash value. Both verification values are appended to the end of the encrypted data packet so that the receiving end can select the verification method according to its own security policy. The verification value is sent to the remote monitoring platform along with the encrypted data packet through the physical communication interface for the receiving end to perform integrity verification. S5. Collaborative Decryption and Visualization: After the encrypted data packet is transmitted to the domestically produced human-machine interface via the communication link, the domestically produced human-machine interface establishes a secure session with the domestic main control chip through a challenge-response two-way authentication mechanism based on a unique hardware identifier. Only after successful authentication can a hardware decryption request be sent to the domestic main control chip. After verifying the legitimacy of the request source and the validity of the session, the domestic main control chip performs decryption operations through the on-chip hardware decryption engine to restore the operating parameters of the fire pump. The domestically produced human-machine interface displays the decrypted parameters in real time through a dedicated display unit for encrypted data, and simultaneously marks the encryption status (displayed as a static icon with the algorithm name text in the upper right corner of the parameter area) and the integrity verification result (displayed as a green 'verification passed' text when verification is successful, and the parameter value is automatically hidden and a red warning box pops up when verification fails, until the operator manually confirms and the display is restored). S6. Abnormal Linkage Early Warning: When the remote monitoring platform or the domestic human-machine interface fails to perform integrity verification on the received encrypted data packet, or detects that the data has been tampered with during transmission, an alarm trigger signal is generated. After receiving the signal, the domestic main control chip simultaneously executes three alarms: sending alarm information to the remote monitoring platform, triggering the pop-up alarm on the domestic human-machine interface, and activating the audible and visual alarm.
[0011] Preferably, step S2 includes steps for configuring encryption strategies and managing key isolation, specifically: The domestically produced main control chip reads the data type of the fire pump operating parameters to be encrypted and matches the corresponding encryption strength level according to the security level requirements of the fire pump operating parameters; Based on the matched encryption strength level and the current working mode identifier, the domestically produced main control chip calls the corresponding encryption algorithm and key length from the dual-mode hardware encryption unit: when the working mode identifier is domestic mode and the encryption strength level is high, the SM4 algorithm is called; when the working mode identifier is domestic mode and the encryption strength level is low, the SM4 algorithm is called with a simplified operation round; when the working mode identifier is international mode and the encryption strength level is high, the AES-256 algorithm is called; when the working mode identifier is international mode and the encryption strength level is low, the AES-128 algorithm is called. The dual-mode hardware encryption unit is configured with independent key storage areas for different encryption strength levels. The key storage areas are isolated from each other through a hardware access isolation mechanism. Specifically, the chip's built-in memory management unit (MMU) configures independent read / write protection attributes for each key storage partition, and the cryptographic algorithm hardware acceleration engine reads key data through a dedicated key bus independent of the main data bus. External devices and ordinary user programs cannot access non-currently active key storage areas through the main data bus. When the working mode identifier in step S2 is switched, the domestic main control chip automatically disables the current key storage area and switches to the key storage area corresponding to the target mode.
[0012] Preferably, the method further includes a key periodic update and audit log generation step, which is executed in parallel with steps S4 to S6, specifically as follows: The timer built into the domestic main control chip records the elapsed time of the current encryption key. When the elapsed time reaches the preset key update cycle threshold, the key update process is automatically triggered. The dual-mode hardware encryption unit generates a new encryption key and replaces the current working key with the new key. After the replacement is completed, the old key is marked as invalid but is still retained in the key history storage area for decryption of historical data. After each key update, the domestically produced main control chip generates an audit record. The audit record includes at least the update timestamp, the key version identifier before the update, the key version identifier after the update, and the reason for the update. After the hardware-level data integrity verification module calculates the verification value of the audit record, it is written to the audit log area of the chip's internal non-volatile memory and uploaded to the remote monitoring platform for archiving through the communication interface. When the abnormal linkage warning in step S6 is triggered, the domestic main control chip packages all the audit records stored in the audit log area and reports them to the remote monitoring platform through the communication interface as evidence for tracing security incidents and determining responsibility.
[0013] Preferably, step S3, during the execution of the on-chip hardware encryption operation, also includes a step of monitoring and actively protecting against abnormal operating environments, specifically: The dual-mode hardware encryption unit has a built-in physical sensor group that monitors the chip's operating environment parameters in real time. The physical sensor group includes at least a voltage detection sensor, a temperature detection sensor, and a clock frequency detection sensor. Each sensor continuously collects environmental parameters at a sampling frequency of not less than 1kHz and transmits them to the chip's built-in security monitoring module. The safety monitoring module compares the environmental parameters collected by each sensor with the preset safety threshold range: when the voltage deviates from the preset voltage threshold range, or the temperature exceeds the preset temperature threshold range, or the clock frequency deviates from the preset frequency threshold range, the safety monitoring module determines that there is an abnormal risk in the current operating environment and immediately triggers a hardware-level protection response. After the hardware-level protection response is triggered, the dual-mode hardware encryption unit performs the following operations simultaneously: First, it marks the current encryption operation result as "generated under abnormal environment" and suspends the transmission of the encrypted data packet until the environment returns to normal and then re-encrypts it; Second, it sends an environmental abnormality alarm signal to the domestic main control chip, and after receiving it, the domestic main control chip reports the environmental abnormality event and abnormality type to the remote monitoring platform through the communication interface; Third, it switches the encrypted data packet transmission channel to secure transmission mode, allowing only the authenticated communication interface to access the chip's internal data.
[0014] Preferably, in step S4, when the encrypted data packet is sent to the remote monitoring platform through the physical communication interface, a step to ensure the quality of encrypted data communication is also included, specifically: The domestically produced main control chip monitors the communication quality status of the current communication link in real time. When the packet loss rate or bit error rate of the communication link exceeds the preset threshold, it automatically enables forward error correction coding to redundantly encode the encrypted data packet before sending it. After receiving the data packet encoded with forward error correction, the remote monitoring platform performs corresponding decoding and error correction operations to restore the complete encrypted data packet.
[0015] Preferably, it also includes an encrypted authentication step for remote parameter distribution, specifically: When the remote monitoring platform sends control parameters or operation instructions to the domestic main control chip, it first encrypts the control parameters using an encryption algorithm that matches the current encryption mode, and attaches a digital signature generated based on the unique hardware identifier of the domestic main control chip. After receiving the encrypted control parameters, the domestically produced main control chip first verifies the legality of the digital signature: it confirms whether the signature was issued by a legitimate remote monitoring platform through the built-in hardware identifier comparison module; after the signature verification is successful, it decrypts the control parameters using the decryption algorithm corresponding to the current working mode. After the decrypted control parameters are verified to be correct by the integrity verification module, the domestic main control chip executes the corresponding control operation; if the signature verification fails or the integrity verification fails, the domestic main control chip refuses to execute the control parameters and returns a refusal report to the remote monitoring platform through the communication interface.
[0016] Preferably, it also includes a multi-controller encryption policy negotiation and data interoperability step, specifically: When the first domestic main control chip needs to send encrypted data to the second domestic main control chip, the first domestic main control chip first sends an encryption configuration negotiation request to the second domestic main control chip through a secure handshake channel. The negotiation request includes at least the current working mode identifier, encryption strength level and key version number. After receiving the negotiation request, the second domestically produced main control chip compares its own encryption configuration with that of the first domestically produced main control chip: if the working mode identifier, encryption strength level and key version number of the two are consistent, then a direct encrypted data transmission channel is established directly; if there is a discrepancy, the two parties negotiate to select a commonly supported encryption configuration parameter. After the encrypted data transmission channel is established, the first domestic main control chip encrypts the data using the negotiated encryption configuration and transmits it to the second domestic main control chip; the second domestic main control chip decrypts the data using the same encryption configuration; after the data communication is completed, each controller automatically restores its original encryption configuration, and the temporary configuration parameters generated during the negotiation process are automatically cleared.
[0017] Preferably, after step S1 and before step S3, a local fault prediction step for operating parameters is also included, specifically: The domestically produced main control chip compares the collected fire pump operating parameters with the pre-stored normal operating parameter threshold range inside the chip: when the pump outlet pressure is lower than the lower limit pressure threshold or higher than the upper limit pressure threshold, or when the pump speed deviates from the rated speed range by more than the preset deviation value, it is determined that the operating parameters are abnormal. When the operating parameters are determined to be abnormal, the domestic main control chip generates a fault prediction mark and attaches it to the fire pump operating parameter data packet to be encrypted, and enters the encryption process of step S3 together with the fire pump operating parameters. The fault prediction indicator is transmitted along with the encrypted data packet to the domestic human-machine interface and remote monitoring platform. When displaying the decrypted parameters, the human-machine interface highlights the abnormal parameters with a specific color. After receiving the information, the remote monitoring platform triggers the corresponding fault maintenance work order.
[0018] Preferably, it also includes a step for monitoring the performance and status of encrypted hardware, specifically: The domestically produced main control chip initiates a hardware performance monitoring process at a fixed cycle: sending standard test data packets to the dual-mode hardware encryption unit and recording the actual completion time of the encryption operation; When the proportion of actual completion time of encryption operation exceeding the preset performance benchmark value in multiple consecutive monitoring reaches the preset alarm proportion, the domestic main control chip generates performance alarm information, uploads it to the remote monitoring platform through the communication interface, and displays performance prompts on the domestic human-machine interface. When the proportion of actual completion time of encryption operation exceeding the preset performance benchmark value in multiple consecutive monitoring reaches the preset emergency ratio, the domestic main control chip automatically performs computing resource allocation operation: switching the encryption task from the current encryption computing unit to the backup encryption computing unit, until the performance returns to normal and then switching back to the original configuration.
[0019] Preferably, it also includes steps for emergency export of encrypted data and external redundant backup, specifically: After each encrypted data packet is generated, the domestically produced main control chip, in addition to writing the encrypted data backup area into the chip's internal non-volatile memory, simultaneously sends the encrypted data packet to an external redundant storage device through an emergency data interface independent of the main communication interface (specifically, the chip's dedicated SPI bus interface, which is not used for remote network communication). After receiving the encrypted data packet, the external redundant storage device returns a reception confirmation signal to the domestic main control chip. When the domestic main control chip fails to receive the reception confirmation signal multiple times in a row, it determines that the external redundant storage device is offline or faulty, and temporarily stores the unconfirmed encrypted data packet in the chip's internal emergency buffer area, and resends it after the external redundant storage device is restored to online status. When the domestically produced main control chip detects a write failure or data read error in a specific storage area of the chip's internal non-volatile memory through its built-in self-diagnostic function, it automatically triggers an emergency data export process: the encrypted data packets that can still be read normally in the encrypted data backup area are exported to an external redundant storage device through the emergency data interface, and a data recovery log is generated and uploaded to the remote monitoring platform.
[0020] The present invention has at least the following beneficial effects: 1. This invention integrates a dual-mode hardware encryption unit within a domestically produced main control chip to perform on-chip hardware encryption calculations on the operating parameters of the fire pump. The encrypted data packets are written into the chip's internal non-volatile memory to form a local backup. Simultaneously, the integrity verification value is sent along with the encrypted data packets for verification by the receiving end. This enables the fire pump operating data to meet both national cryptographic algorithms and international certification encryption requirements on a single domestic chip platform, without relying on external imported encryption chips, and ensures the integrity and traceability of the data in the transmission link.
[0021] 2. This invention achieves hierarchical management of encryption strength and physical isolation of key storage areas by matching the corresponding encryption strength level according to the security level requirements of the fire pump operating parameters, configuring independent key storage areas for different levels and realizing hardware access isolation, and automatically deactivating the current storage area and switching to the storage area corresponding to the target mode when switching modes. This reduces the risk of key leakage between data of different security levels and avoids configuration errors that may be caused by manual intervention when switching working modes.
[0022] 3. This invention records the duration of key usage through a timer and automatically triggers the key update process when a preset threshold is reached. At the same time, the old key that has been replaced is marked as invalid but retained in the key history storage area for use in decrypting historical data. An audit record containing a timestamp and version identifier is generated and reported to the remote platform. This realizes the regular and proactive updating of encryption keys and the continuous decryptability of historical encrypted data, avoiding the problem of the old key becoming invalid immediately and causing historical data to be unreadable. At the same time, it provides a complete and traceable audit record for key operations.
[0023] 4. This invention monitors the chip's operating environment parameters, such as voltage, temperature, and clock frequency, in real time using a physical sensor group during the encryption operation. When the environmental parameters deviate from the preset threshold, the current encryption operation result is marked as "generated under abnormal environment" and transmission is paused. At the same time, the abnormal environment event is reported to the remote platform. This avoids the risk of system function interruption caused by aggressive erasure operations triggered by environmental fluctuations, and achieves the maintenance of system function continuity while ensuring chip security.
[0024] 5. This invention improves the reliability of data transmission in scenarios with poor communication quality by monitoring the packet loss rate or bit error rate of the communication link in real time and automatically enabling forward error correction coding to redundantly encode the encrypted data packets before sending them when the error rate exceeds a preset threshold. The receiving end performs decoding and error correction operations to restore the complete data packets. This also avoids the additional delay and logical complexity caused by data splitting and reassembly.
[0025] 6. This invention encrypts the control parameters issued by the remote monitoring platform and attaches a digital signature generated based on the chip's unique hardware identifier. The receiving end verifies the legality of the signature, and can only decrypt and execute it after the verification is successful. If the verification fails, execution is rejected and a rejection report is returned. This invention achieves trusted verification of the identity of remotely issued parameters and tamper-proof protection, effectively preventing illegal or forged instructions from intruding into the fire pump control system.
[0026] 7. This invention enables encrypted configuration negotiation between multiple controllers via a secure handshake channel. The two parties compare the working mode identifier, encryption strength level, and key version number. If there are inconsistencies, they negotiate to select mutually supported configuration parameters and establish a direct transmission channel for encrypted data transmission. After the transmission is completed, each controller restores its original encrypted configuration and automatically clears the temporary configuration parameters generated during the negotiation process. This achieves automatic adaptation of encrypted configuration when deploying multiple controllers, reduces the workload of manual configuration, and eliminates the security risks caused by temporary configuration residues.
[0027] 8. This invention compares the collected fire pump operating parameters with a pre-stored threshold range before encryption. When the parameters are determined to be abnormal, a fault prediction mark is generated and attached to the data packet to be encrypted and transmitted along with the encrypted data. The human-machine interface highlights or marks the abnormal parameters with a specific color, and the remote platform triggers the corresponding fault maintenance work order. This enables local early identification and rapid location of abnormal operating parameters. Moreover, the fault prediction mark is transmitted to the display terminal and remote platform with the encrypted data in an immutable manner, ensuring the credibility of the entire chain from discovery to presentation of abnormal information.
[0028] 9. This invention sends standard test data packets to the dual-mode hardware encryption unit at fixed intervals and records the actual completion time of encryption operations. When the proportion of completion times exceeding the preset performance benchmark value in multiple consecutive monitoring reaches the alarm threshold, performance alarm information is uploaded and a prompt is displayed. When the emergency threshold is reached, the encryption task is automatically switched to the backup encryption operation unit. After the performance returns to normal, it is switched back to the original configuration. This realizes active monitoring and abnormal early warning of encryption hardware performance, avoiding the passive decay of encryption performance to failure before it is discovered. At the same time, switching to the backup unit ensures the continuity of encryption function.
[0029] 10. This invention achieves dual data backup of internal chip storage and external redundant storage by simultaneously sending encrypted data packets to an external redundant storage device via an independent emergency data interface while writing them into the chip's internal non-volatile memory. If no confirmation signal is received, the unconfirmed data packets are temporarily stored in the internal emergency buffer and resent after recovery. When the chip's self-diagnosis detects a write failure or data read error in a specific storage area, it automatically exports the still readable encrypted data packets to the external redundant storage device and generates a data recovery log for reporting. This reduces the risk of encrypted data loss due to damage to the chip's storage area. Furthermore, the self-diagnosis judgment criteria are clear and specific, and the solution is operable.
[0030] Other advantages, objectives and features of the present invention will become apparent in part from the following description, and in part from those skilled in the art through study and practice of the invention. Detailed Implementation
[0031] The present invention will now be described in further detail so that those skilled in the art can implement it based on the description.
[0032] It should be understood that terms such as "having," "comprising," and "including" used in the embodiments of this application do not exclude the presence or addition of one or more other elements or combinations thereof. All directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationship and movement of components in a specific posture. If the specific posture changes, the directional indication will also change accordingly. When an element is referred to as "fixed to" or "set on" another element, it can be directly on the other element or may have an intervening element present. When an element is referred to as "connected to" another element, it can be directly connected to the other element or indirectly connected to the other element through an intervening element. Descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features.
[0033] It should be noted that, unless otherwise specified, the experimental methods described in the following implementation plan are all conventional methods, and the reagents and materials described are all commercially available unless otherwise specified.
[0034] It should be noted that the technical solutions of the various embodiments of this application can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by this application.
[0035] This invention provides a dual-standard data encryption and human-machine collaboration method for a fire pump controller driven by a domestically produced chip, which includes the following steps: S1. Digital Acquisition and Input of Physical Sensor Signals: A pressure sensor is installed on the outlet pipeline of the fire pump. The selected pressure sensor is the MD-G102 general-purpose pressure transmitter manufactured by Shanghai Mingkong Sensor Technology Co., Ltd. This pressure transmitter uses a diffused silicon sensor as the pressure-sensing element, with a range of 0 to 1.6 MPa, an output signal of 4 to 20 mA standard current, a response time of no more than 5 milliseconds, an accuracy class of 0.5% FS, a housing material of 304 stainless steel, and an IP65 protection rating. The pressure transmitter is installed on the pressure measuring pipe at the fire pump outlet flange, connected to the pipeline via an M20 x 1.5 pressure interface. The power supply voltage is DC 24V, and the output signal line is connected to the input pin of the analog-to-digital converter of a domestic main control chip. A speed sensor is installed on the output shaft of the fire pump's drive motor. The selected speed sensor is an HK-862 Hall effect speed sensor. The speed sensor housing is a stainless steel threaded structure, using an M16 x 1 external thread to be installed in a dedicated mounting hole on the motor end cover, and is internally sealed. Its operating voltage is DC 12 to 24 volts, the speed measurement range is 1 to 20,000 revolutions per minute, and the output signal is a square wave pulse signal. The signal line of the speed sensor is connected to the timer capture input pin of the domestic main control chip to measure the pulse frequency to calculate the real-time speed. The running time parameter is provided by the real-time clock counter integrated inside the domestic main control chip, which continuously accumulates the count starting from the power-on moment. The 4 to 20 mA current signal output by the pressure sensor is sampled by the 12-bit analog-to-digital converter integrated inside the domestic main control chip and converted into a digital quantity. The sampling rate of the analog-to-digital converter is set to 200 times per second, and the arithmetic mean of the 200 samples per second is taken as the pump outlet pressure value for that second (the fire pump outlet pressure is a slowly changing signal, and a sampling rate of 200Hz combined with moving average filtering can meet the monitoring accuracy requirements, while reducing the chip's computational load and power consumption). The square wave pulse signal output by the speed sensor is measured by the timer capture unit of the domestic main control chip to measure the pulse period, and the real-time speed value is calculated based on the number of teeth. The running time is directly read from the count value of the real-time clock counter. After being collected and digitized, the above three operating parameters are temporarily stored in the data cache area of the internal static random access memory of the domestic main control chip, waiting to enter the encryption process.
[0036] The domestically produced main control chip is the N32G455 series microcontroller manufactured by National Technology Co., Ltd., specifically model N32G455VEL7. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, and supports floating-point operations and DSP instructions. Internally, the chip integrates 512 kilobytes of embedded flash memory and 144 kilobytes of static random access memory. The chip incorporates a hardware acceleration engine for cryptographic algorithms, supporting Chinese cryptographic algorithms such as SM4, AES, SM3, SM1, and SM7, as well as internationally recognized algorithms such as DES and SHA. It also integrates a cyclic redundancy check (CRC) calculation unit, supporting CRC16 and CRC32 operations. The chip is available in an LQFP100 package and operates within a temperature range of -40 degrees Celsius to 105 degrees Celsius.
[0037] S2. Hardware Register Status Identification and Algorithm Kernel Retrieval for Encryption Mode: A specific address bit in the internal register of the domestically produced main control chip is defined as the working mode flag bit. This flag bit is a one-bit binary register. When the bit is logic 0, it represents the first state, selecting the national cryptographic SM4 algorithm; when the bit is logic 1, it represents the second state, selecting the AES-256 algorithm. The initial value of this flag bit is read from the configuration area of the chip's internal non-volatile memory and loaded into the register when the chip powers on. The user can modify this flag bit through the mode selection menu on the domestically produced human-machine interface. The modified value is simultaneously written to the configuration area to ensure that the same setting is maintained on the next power-on. After step S1 completes data acquisition, before the central processing unit of the domestically produced main control chip executes the encryption process, it first reads the current value of this working mode flag bit. If a logic 0 is read, the CPU writes the SM4 algorithm selection code 0x01 to the control register of the cryptographic algorithm hardware acceleration engine via the chip's internal high-performance bus, preparing the hardware acceleration engine to perform SM4 encryption operations; if a logic 1 is read, the CPU writes the AES-256 algorithm selection code 0x02 to the control register of the cryptographic algorithm hardware acceleration engine, preparing the hardware acceleration engine to perform AES-256 encryption operations.
[0038] S3. On-chip Hardware Arithmetic Logic Encryption Operation: The cryptographic algorithm hardware acceleration engine integrated within the domestically produced main control chip is a dual-mode hardware encryption unit. This hardware acceleration engine operates independently of the central processing unit (CPU) and has dedicated arithmetic logic circuits to implement encryption operations for both the SM4 and AES algorithms. After algorithm selection is completed in step S2, the CPU transmits the fire pump operating parameters temporarily stored in the static random access memory (SRAM) data buffer in step S1 to the input buffer of the hardware acceleration engine via the direct memory access channel. The hardware acceleration engine calls the corresponding encryption operation circuit to encrypt the input data according to the algorithm selection code written in the control register. For the SM4 algorithm, the hardware acceleration engine uses a 128-bit key length and performs 32 rounds of nonlinear iterative encryption according to the standard operation flow of the national standard SM4 block cipher algorithm. For the AES-256 algorithm, the hardware acceleration engine uses a 256-bit key length and performs 14 rounds of encryption transformation according to the standard operation flow of the AES algorithm. During the encryption operation, the hardware acceleration engine operates at a main frequency of 144 MHz. The actual time to complete a single encryption operation, as measured, is no more than 30 microseconds, lower than the method's required upper limit of 50 microseconds. After encryption, the hardware acceleration engine writes the generated encrypted data packet to the output buffer and sends a completion interrupt signal to the central processing unit (CPU). Upon responding to the interrupt, the CPU reads the encrypted data packet from the output buffer. This encrypted data packet contains the encrypted pump outlet pressure value, pump speed value, and runtime value, as well as the operating mode identifier and algorithm type flag used during encryption.
[0039] S4. Backup and Cyclic Redundancy Check of Encrypted Data to Physical Storage Media: After reading the encrypted data packet from the output buffer of the hardware acceleration engine, the CPU first writes the encrypted data packet to the encrypted data backup area of the embedded flash memory inside the chip via the chip's internal bus interface. This encrypted data backup area is designated as an independent storage partition in the flash memory, starting at address 0x08020000, with a size of 64 kilobytes, and is physically isolated from the main flash memory area storing program code. The write operation uses page programming, with each page being 2 kilobytes in size, and writes sequentially until all encrypted data packets are written. After the write is complete, the CPU reads the data just written in the flash memory and compares it byte by byte with the original encrypted data packet to confirm the correctness of the write operation. At the same time, the CPU calls the cyclic redundancy check calculation unit integrated inside the chip to calculate the integrity check value of the encrypted data packet. This check unit supports CRC32 polynomial 0x04C11DB7, with an initial value of 0xFFFFFFFF. The CPU configures the starting address of the check unit to be the starting address of the encrypted data packet in static random access memory, and the data length to be the actual byte length of the encrypted data packet, and then starts the check calculation. After completing the calculation within several clock cycles, the verification unit stores the generated 32-bit Cyclic Redundancy Check (CRC) value in the verification result register. The central processing unit (CPU) reads this check value and appends it to the end of the encrypted data packet, forming a complete data frame with the check value. Subsequently, the CPU sends this complete data frame to the physical communication interface via the chip's Universal Asynchronous Receiver / Transmitter (UART) interface or Ethernet Media Access Control (MAC) interface, and then uploads it to the remote monitoring platform. Upon receiving the data frame, the remote monitoring platform recalculates the CRC value for the encrypted data portion and compares it with the received check value to verify the integrity of the data during transmission. The aforementioned check value is sent along with the encrypted data packet, enabling the receiving end to have independent integrity verification capabilities.
[0040] S5. Collaborative Decryption and Visualization: The domestically produced human-machine interface (HMI) uses a 7-inch true-color thin-film transistor liquid crystal display with a resolution of 800×480 pixels, equipped with a capacitive touchscreen. This HMI connects to the domestically produced main control chip via a Serial Peripheral Interface (SPI) or a Universal Asynchronous Receiver / Transmitter (UART). After encrypted data packets are transmitted to the domestically produced HMI via the communication link, the central processing unit (CPU) of the HMI parses the data frame, extracting the encrypted data portion and the working mode identifier. The HMI first establishes a secure session with the domestically produced main control chip through a challenge-response two-way authentication mechanism based on the chip's unique hardware identifier. Only after successful authentication can the HMI send a hardware decryption request to the chip. This request includes the data frame header identifier of the data to be decrypted, the encrypted data length information, and a session token. Upon receiving the decryption request, the domestically produced main control chip first verifies the legitimacy of the request source and the validity of the session token. After successful verification, the CPU transmits the encrypted data to the input buffer of the cryptographic algorithm hardware acceleration engine via a direct memory access channel and writes the corresponding decryption algorithm selection code to the control register of the hardware acceleration engine according to the working mode identifier carried in the data frame. The hardware acceleration engine performs decryption operations, restoring the encrypted data to plaintext form of fire pump operating parameters, including pump outlet pressure, pump speed, and runtime. Upon decryption, it sends an interrupt signal to the central processing unit (CPU). The CPU reads the decrypted plaintext parameters and transmits them back to the domestically produced HMI (Human Machine Interface) via the communication interface. The actual measured time for the pure hardware decryption engine to perform the decryption operation is no more than 60 microseconds (this time specifically refers to the pure computation time of the main control chip's internal hardware acceleration engine from receiving input data to outputting the decryption result, excluding the time for the encrypted data packet to be transmitted between the HMI and the main control chip via the SPI / UART communication interface, and also excluding the time for two-way authentication and session negotiation), which is lower than the required 80 microsecond limit. After receiving the decrypted plaintext parameters, the domestically produced HMI displays them visually on a dedicated display unit for encrypted data. This display unit is a specific area on an LCD screen, displaying the pump outlet pressure, pump speed, and runtime in real-time in numerical and trend chart form. Meanwhile, the display unit marks the encryption status in the upper right corner of the parameter display area with a static icon and the algorithm name text, such as displaying "SM4 encryption" or "AES-256 encryption" and the corresponding algorithm icon; the lower right corner of the parameter display area marks the integrity verification result: when the verification is successful, it is displayed in green with the words "Verification successful"; when the verification fails, the parameter value is automatically hidden and a modal warning box with a red background pops up displaying "Integrity verification failed, data may have been tampered with", and the display can only be restored after the operator manually confirms.
[0041] S6. Abnormal Linkage Early Warning: When the remote monitoring platform or domestically produced HMI performs integrity verification on the received encrypted data packets, if the calculated cyclic redundancy check value is inconsistent with the check value carried at the end of the data frame, it is determined that the integrity verification has failed, indicating that the data may have been tampered with or has encountered errors during transmission. At this time, the remote monitoring platform or domestically produced HMI generates an alarm trigger signal and sends it to the domestically produced main control chip through the communication link. After receiving the alarm trigger signal, the central processing unit of the domestically produced main control chip simultaneously executes three alarm operations. First alarm: The central processing unit sends an alarm information data packet to the remote monitoring platform through the Ethernet interface. This data packet contains the alarm type code 0xE001 indicating integrity verification failure, the timestamp of the alarm occurrence, and the fire pump controller number of the alarm. Second alarm: The central processing unit sends a pop-up alarm command to the domestically produced HMI through the serial peripheral interface. After receiving it, the HMI pops up a modal alarm window in the center of the display screen. The window background is red, displaying the warning text "Data integrity verification failed, please check the communication link," accompanied by a continuous flashing effect, until the operator manually confirms and closes it. The third alarm channel: The central processing unit outputs a high-level signal through a general-purpose input / output pin, driving an external audible and visual alarm to activate. The audible and visual alarm is an industrial-grade device powered by 24V DC, installed on the top of the fire pump control cabinet. Upon receiving a high-level trigger signal, the alarm emits a buzzer sound of no less than 85 decibels (meeting the requirements of GB / T 3785 industrial environmental noise warnings, and avoiding discomfort to personnel on duty), and simultaneously flashes a red warning light. The alarm sound pressure level can be steplessly adjusted via a potentiometer according to the site environment until the alarm conditions are cleared or the operator manually resets it. The above three alarm channels execute synchronously and independently; a failure in any one channel does not affect the alarm function of the others.
[0042] Existing technologies include fire pump controller solutions that use imported encryption chips in conjunction with domestically produced main control chips to achieve data encryption, and solutions that use domestically produced chips to implement national cryptographic algorithms through software. Compared to these existing technologies, this invention directly integrates a dual-mode hardware encryption unit within the domestically produced main control chip. Encryption operations are performed by an on-chip hardware acceleration engine, avoiding the latency and increased power consumption issues caused by multiple data transfers between chips when using independent imported encryption chips. It also eliminates dependence on imported components. Regarding algorithm support, this invention simultaneously implements the SM4 and AES-256 algorithms within a single domestically produced chip, which can be switched using a working mode flag. This overcomes the limitations of existing software encryption schemes, such as excessive processor resources, limited processing speed, and the inability of a single chip to simultaneously support both national cryptographic and internationally certified encryption. The invention addresses several shortcomings. Regarding integrity verification, the verification value is generated by the chip's built-in cyclic redundancy check unit before the encrypted data packet is sent and sent along with the data packet. The receiving end can independently verify this, which is superior to existing technologies that only verify on the remote platform side and lack protection during transmission. In terms of decryption collaboration, the invention delegates the decryption operation to the hardware decryption engine of the domestically produced main control chip. The human-machine interface only needs to send a request and receive the result. The decryption delay is no more than 60 microseconds, significantly better than the high latency caused by software decryption performed by the human-machine interface's own processor in existing technologies. Furthermore, the decryption key is always stored inside the main control chip, reducing the risk of leakage.
[0043] In another technical solution, before executing step S2, the encryption strategy configuration and key isolation management steps are performed first. The domestically produced main control chip still uses the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip's built-in cryptographic algorithm hardware acceleration engine supports multiple symmetric encryption algorithms such as SM4 and AES, and its internal embedded flash memory supports multi-user partition management. After completing the acquisition and digital conversion of the fire pump operating parameters in step S1 and before proceeding to the algorithm selection in step S2, the domestically produced main control chip first reads the data type of the fire pump operating parameters to be encrypted. The fire pump operating parameters are assigned data type labels during data acquisition: pump outlet pressure parameters are labeled as the first data type, pump speed parameters are labeled as the first data type, and running time parameters are labeled as the second data type. The first data type represents the core operating parameters, and the second data type represents the auxiliary operating parameters. The central processing unit of the domestically produced main control chip matches the corresponding encryption strength level according to the data type label and a preset mapping rule: when the data type label is the first data type, a high encryption strength level is matched; when the data type label is the second data type, a low encryption strength level is matched.
[0044] After matching the encryption strength levels, the central processing unit of the domestically produced main control chip, based on the current operating mode flag, calls the corresponding encryption algorithm and key length from the dual-mode hardware encryption unit for subsequent encryption operations. Specifically, the operating mode flag stored in the internal register of the domestically produced main control chip is a one-bit binary register. When the flag is logic 0, it represents the domestic mode; when it is logic 1, it represents the international mode. When the operating mode flag is set to domestic mode and the encryption strength level is high, the CPU writes the SM4 algorithm selection code and a 256-bit key length configuration code to the control register of the cryptographic algorithm hardware acceleration engine. The hardware acceleration engine then performs encryption operations using the SM4 algorithm with a 256-bit key length. When the operating mode flag is set to domestic mode and the encryption strength level is low, the CPU writes the SM4 algorithm selection code and a 128-bit key length configuration code. The hardware acceleration engine then performs encryption operations using the SM4 algorithm with a 128-bit key length. When the operating mode flag is set to international mode and the encryption strength level is high, the CPU writes the AES-256 algorithm selection code. The hardware acceleration engine then performs encryption operations using the AES algorithm with a 256-bit key length. When the operating mode flag is set to international mode and the encryption strength level is low, the CPU writes the AES-128 algorithm selection code. The hardware acceleration engine then performs encryption operations using the AES algorithm with a 128-bit key length.
[0045] The dual-mode hardware encryption unit configures independent key storage areas for different encryption strength levels, and these key storage areas are physically isolated from each other through a hardware access isolation mechanism. In the embedded flash memory of the domestically produced main control chip, four independent key storage partitions are divided by the chip's built-in memory management unit: the first key storage area, starting at address 0x08030000 and with a size of 1 kilobyte, is used to store the 256-bit SM4 algorithm key at the high encryption strength level; the second key storage area, starting at address 0x08030400 and with a size of 1 kilobyte, is used to store the 128-bit SM4 algorithm key at the low encryption strength level; the third key storage area, starting at address 0x08030800 and with a size of 1 kilobyte, is used to store the 256-bit AES-256 algorithm key at the high encryption strength level; and the fourth key storage area, starting at address 0x08030C00 and with a size of 1 kilobyte, is used to store the 128-bit AES-128 algorithm key at the low encryption strength level. Access permissions for these four key storage areas are controlled by the chip's multi-user partition management unit. Each key store is configured with independent read and write protection attributes. Access permission registers for any key store can only be configured by the central processing unit (CPU) in a specific security mode; ordinary user programs have no right to directly read or write the contents of the key store. The address spaces of the key stores are not contiguous, with address gaps in between, achieving physical address isolation between the storage regions. When performing encryption or decryption operations, the cryptographic algorithm hardware acceleration engine reads key data from the currently active key store through an internal dedicated key bus. This key bus is independent of the chip's main data bus, and external devices cannot access the contents of the key stores through the main data bus.
[0046] When the working mode flag changes in step S2, the domestically produced main control chip automatically performs a key storage area switching operation. Assuming the current working mode flag is in domestic mode, the cryptographic algorithm hardware acceleration engine is using the SM4 algorithm key in either the first or second key storage area to perform encryption operations. When the user switches the working mode to international mode via the domestically produced human-machine interface, the central processing unit (CPU) of the domestically produced main control chip first sends a pause command to the cryptographic algorithm hardware acceleration engine, waits for the currently executing encryption operation to complete, and then sets the status register of the hardware acceleration engine to idle. Subsequently, the CPU, through the multi-user partition management unit, switches the access permission of the currently used key storage area from read-write mode to read-only mode, keeping it locked to prevent accidental modification during the switching process. The CPU reads the starting address and access permission configuration of the key storage area corresponding to the target mode, activates it as the currently available key storage area, and points the key source to the newly activated storage area through the control register of the hardware acceleration engine. After the switch is completed, the CPU sets the status register of the hardware acceleration engine to ready state and resumes the execution of encryption operations. During the aforementioned switchover process, the old mode key storage area enters a locked state upon receiving the switchover command, and remains locked until the new mode key storage area is fully activated and confirmed to be accessible. The entire switchover process is completed within the central processing unit, without involving any external data transmission. The actual switchover time, as measured, does not exceed 10 microseconds, and its impact on the continuity of encryption operations is negligible.
[0047] Compared with existing technologies, this invention automatically matches the corresponding encryption strength level based on the data type tag of the fire pump's operating parameters. Core parameters are matched with a high encryption strength level, and auxiliary parameters with a low encryption strength level. This overcomes the shortcomings of existing technologies where encryption strategies rely on manual settings, are fixed and singular, and cannot be dynamically adapted during operation. This invention simultaneously implements the SM4 and AES algorithms within a single domestically produced chip, with each algorithm supporting two key lengths. By matching the working mode identifier with the encryption strength level, four encryption configuration combinations can be automatically invoked: a high encryption strength domestic mode corresponding to the SM4 algorithm (using a standard 128-bit key length), a low encryption strength domestic mode corresponding to the SM4 algorithm (using a standard 128-bit key length), and so on. This invention addresses the shortcomings of existing software encryption schemes, which only support a single algorithm and a single key length and consume processor resources. It divides the embedded flash memory of the chip into four independent key storage partitions. Each partition has a non-contiguous address and independent access permissions. The key bus is independent of the main data bus, overcoming the lack of physical isolation protection in existing technologies where keys are stored in general flash memory areas or external memory. Furthermore, when switching working modes, the old mode key storage area is automatically locked and the new mode key storage area is automatically activated, eliminating the risk of key leakage during switching. The entire switching process is completed internally within the chip without external intervention.
[0048] In another technical solution, while performing steps S4 to S6 of claim 1, the domestically produced main control chip performs key cycle update and audit log generation steps in parallel. The domestically produced main control chip still uses the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. The chip's built-in real-time clock module is a set of continuously running counters, supporting leap year perpetual calendar functions. It can be powered via VDD or VBAT pins, and the timing is maintained by a backup battery when the chip's main power supply is interrupted. The chip's embedded flash memory has a capacity of 512 kilobytes, supports partition management and data protection, and the flash memory is divided into 256 pages, each page being 2 kilobytes in size.
[0049] The domestically produced main control chip integrates a 32-bit real-time clock counter, which continuously accumulates the count in seconds. During chip power-on initialization, the central processing unit (CPU) reads the current count value from the real-time clock module, using it as the starting reference for the key's elapsed time. Each time an encryption operation is performed, the CPU reads the current count value from the real-time clock module, calculates the difference between this count and the starting reference, and obtains the elapsed time of the current encryption key. The elapsed time is recorded in seconds and stored in the key management variable area of the chip's internal static random access memory (SRAM).
[0050] The preset key update cycle threshold is set by the user on the domestically produced human-machine interface. This threshold is in days and can be set to four levels: 30 days, 60 days, 90 days, or 180 days. The default value is 90 days. This value is based on the key lifecycle management recommendations in GM / T 0054 "Basic Requirements for Cryptographic Applications in Information Systems" and takes into account the practical engineering situation of fire pump controllers operating continuously for long periods and where key update operations should not be too frequent. The set value is transmitted to the domestically produced main control chip via the communication interface through the domestically produced human-machine interface and written into the configuration parameter area of the chip's embedded flash memory. Before the start of each encryption cycle, the central processing unit of the domestically produced main control chip compares the current key usage time with the preset key update cycle threshold. When the usage time reaches or exceeds the preset threshold, the central processing unit automatically triggers the key update process.
[0051] The key update process is executed in the following order: First, the CPU sends a key update preparation instruction to the cryptographic algorithm hardware acceleration engine, which saves the context state of the current working key to an internal temporary register. Second, the CPU calls the chip's built-in true random number generator to generate a new encryption key. The true random number generator is a hardware module built into the N32G455VEL7 chip, generating an unpredictable random number sequence based on circuit thermal noise. The CPU reads a 256-bit random number from the output register of the true random number generator as the new key; for SM4-128 or AES-128 modes, it reads the first 128 bits as the new key. Third, the CPU, through the chip's multi-user partition management unit, writes the newly generated key to the currently active key storage area, overwriting the original key data. The write operation uses flash page programming: first, all data of the page containing the target key storage area is read into a temporary buffer in the static random access memory, the flash page is erased, and then the complete data containing the new key is written back from the temporary buffer to the flash page. Fourth, after the write operation is complete, the central processing unit (CPU) reads the newly written key data back from the flash memory and compares it byte-by-byte with the original new key in the static random access memory (SRAM). Once the write is confirmed to be correct, the CPU updates the key cache register of the cryptographic algorithm hardware acceleration engine to the new key value. Fifth, the CPU marks the old key as invalid but retains it in the key history storage area. This key history storage area is also protected by hardware access isolation from the chip's multi-user partition management unit. Reading the contents of the key history storage area requires additional authorization (only allowed in maintenance mode by an administrator holding an authorized key). A maximum retention period is also set; when the number of key updates exceeds five, the oldest batch of old keys will be physically erased to balance the need for decryptable historical data with the risk of key leakage. The key history storage area is an independently partitioned storage area in the chip's embedded flash memory, starting at address 0x08031000, with a size of 4 kilobytes. It uses a circular queue to store the old keys generated from the last five updates, along with their corresponding version identifiers and timestamps. The purpose of storing old keys in the key history storage area is for subsequent decryption of historical encrypted data: when historical data needs to be decrypted, the domestically produced main control chip retrieves the corresponding old key from the key history storage area based on the key version number carried in the data packet header and performs the decryption operation. The entire key update process, from triggering to completion, takes no more than 15 milliseconds in actual testing.Since key updates are a low-frequency background task (with a cycle of up to 90 days), newly arriving encryption requests during this period can be temporarily stored in the input buffer and processed after the update is completed. This allows for transient fluctuations in encryption latency of no more than 15 milliseconds during this specific period. If the system has higher requirements for real-time performance, it can be configured to trigger key updates during system idle periods (such as gaps where no new data is collected) to minimize the impact on the real-time encryption stream. Encryption requests that have been received but not yet processed are temporarily stored in the input buffer and processed after the key update is completed.
[0052] After each key update, the domestically produced main control chip immediately generates an audit record. The audit record's data structure includes the following fields: an update timestamp field (4 bytes long), storing the count value from the real-time clock module at the moment the key update is completed; a key version identifier field (2 bytes long), storing the version number of the replaced old key; a key version identifier field (2 bytes long), storing the version number of the newly generated key, with the key version identifier numbered sequentially starting from 1 and automatically incrementing by 1 with each update; and an update trigger reason field (1 byte long), storing the reason code that triggered this key update: 0x01 indicates a cycle completion trigger, 0x02 indicates a user-manual trigger, and 0x03 indicates a security event trigger. After the audit record is generated, the central processing unit (CPU) first calls the chip's built-in cyclic redundancy check (CRC) calculation unit to calculate the CRC32 checksum for all fields of the audit record, and this checksum is appended to the end of the audit record. Subsequently, the CPU writes the complete audit record with the checksum to the audit log area of the chip's embedded flash memory. The audit log area starts at address 0x08032000, has a size of 8 kilobytes, and uses a sequential write method. Each audit record has a fixed length of 32 bytes, and the audit log area can store a maximum of 256 audit records. When the audit log area is full, the newest record overwrites the oldest record. After the audit records are written to flash memory, the central processing unit simultaneously packages and uploads the audit records to the remote monitoring platform for archiving via the chip's general asynchronous transceiver interface or Ethernet media access control interface. The remote monitoring platform receives and stores the audit records in its audit database for subsequent querying and tracing.
[0053] When the abnormal linkage warning in step S6 is triggered, i.e., when the remote monitoring platform or the domestically produced human-machine interface detects a data integrity verification failure or data tampering, the central processing unit of the domestically produced main control chip, while executing three-way alarms, reads all stored audit records from the audit log area of the chip's embedded flash memory. After reading each audit record, it verifies the CRC32 checksum appended to its end, discards records that fail the verification, and marks them as corrupt. All valid audit records are packaged into an audit data packet, which includes the total number of records, the complete content of each record, and the overall checksum. The central processing unit reports the audit data packet to the remote monitoring platform through the communication interface. After receiving the audit data packet, the remote monitoring platform archives it as evidence for security incident tracing and responsibility determination. This evidence packet can be used for post-event analysis of key update history, determining the key version used during the security incident, and investigating whether there were any abnormal operations in the key management process.
[0054] Compared with existing technologies, this invention continuously records the key usage time through a real-time clock module built into a domestically produced main control chip, and automatically triggers a key update process when a preset threshold is reached. After the key is updated, the old key is marked as invalid but is still retained in the key history storage area for use in decrypting historical data. This overcomes the shortcomings of existing technologies, such as the increased risk of leakage due to long-term unchanged keys and the inability to read historical encrypted data due to the immediate deletion of old keys after key updates. After each key update, an audit record containing an update timestamp, key version identifiers before and after the update, and the reason for the update is automatically generated. This record is written to an independent audit log area in the chip's internal flash memory after cyclic redundancy verification and uploaded to a remote monitoring platform for archiving. This overcomes the shortcomings of existing technologies, such as the lack of traceable records for key management operations and the difficulty in tracing key change history after a security incident. By packaging all audit records and reporting them to the remote monitoring platform as evidence when an abnormal linkage warning is triggered, the invention achieves the immediate and complete export of the key management history when a security incident occurs, providing reliable data support for subsequent responsibility determination and cause analysis.
[0055] In another technical solution, during the on-chip hardware encryption operation in step S3, the domestically produced main control chip simultaneously performs abnormal environment monitoring and active protection steps. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip has a built-in hardware acceleration engine for cryptographic algorithms, supports multiple symmetric encryption algorithms such as SM4 and AES, and also supports clock failure monitoring and anti-tampering monitoring functions. The chip operates at a voltage range of 1.8V to 3.6V and at a temperature range of -40°C to 105°C.
[0056] The dual-mode hardware encryption unit incorporates a set of physical sensors, including a voltage sensor, a temperature sensor, and a clock frequency sensor. All of these sensors are integrated hardware modules within the chip. The voltage sensor is a programmable low-voltage detection unit integrated within the chip. This unit continuously monitors the voltage value of the chip's power supply pins through a dedicated input channel of the chip's internal analog-to-digital converter. The temperature sensor is an integrated temperature sensing unit that measures temperature by utilizing the physical characteristic that the forward voltage drop of a semiconductor PN junction changes with temperature. The temperature value is read through another dedicated input channel of the chip's internal analog-to-digital converter. The clock frequency sensor is an integrated clock security monitoring unit that uses an internal low-speed RC oscillator as a reference clock and continuously monitors whether the operating frequency of an external high-speed crystal oscillator is within the normal range.
[0057] Each sensor continuously collects environmental parameters at a sampling frequency of at least 1 kHz. The voltage sensor collects the voltage value of the chip's power supply pin at a sampling rate of 2000 times per second, and after each sampling, the analog voltage signal is converted into a 12-bit digital value through an analog-to-digital converter. The temperature sensor collects the internal temperature value of the chip at a sampling rate of 1000 times per second, and after each sampling, the analog voltage signal corresponding to the temperature is converted into a 12-bit digital value through an analog-to-digital converter. The clock frequency sensor operates in a continuous monitoring mode, comparing and detecting the output frequency of the external high-speed crystal oscillator in each clock cycle. The detection frequency is equivalent to the chip's main frequency of 144 MHz, which means 144 million frequency comparisons are performed per second.
[0058] Environmental parameters collected by each sensor are transmitted in real time to the chip's built-in safety monitoring module. This module is an integrated hardware logic circuit that operates independently of the central processing unit. It contains three sets of preset safety threshold range registers: a voltage threshold range register with a preset value of 1.8V lower limit and 3.6V upper limit; a temperature threshold range register with a preset value of -40°C lower limit and 105°C upper limit; and a clock frequency threshold range register with a preset value of 4MHz lower limit and 32MHz upper limit. The safety monitoring module compares the environmental parameters collected by each sensor with their corresponding preset safety threshold ranges in real time. If the voltage value sampled by the voltage sensor is below 1.8V or above 3.6V, the voltage is determined to deviate from the preset voltage threshold range. If the temperature value sampled by the temperature sensor is below -40°C or above 105°C, the temperature is determined to exceed the preset temperature threshold range. If the clock frequency sensor detects an external crystal oscillator frequency below 4MHz or above 32MHz, the clock frequency is determined to deviate from the preset frequency threshold range. When any of the above conditions are met, the security monitoring module determines that there is an abnormal risk in the current operating environment and immediately triggers a hardware-level protection response.
[0059] Upon triggering of the hardware-level protection response, the dual-mode hardware encryption unit simultaneously performs the following three operations. The first operation: The dual-mode hardware encryption unit marks the current encryption operation result as "generated under abnormal environment" status. This mark is an 8-bit status code 0xFA, written into a specific field in the header of the encrypted data packet. After marking, the dual-mode hardware encryption unit pauses the transmission of the encrypted data packet, temporarily storing it in the pending-transmission buffer within the chip's internal static random access memory, without transmitting it externally through the physical communication interface. The security monitoring module continuously monitors environmental parameters. When the environmental parameters recover to within the preset security threshold range for 5 consecutive seconds, it determines that the environment has returned to normal. The dual-mode hardware encryption unit directly sends the previously encrypted data packet stored in the pending-transmission buffer (the header of this data packet still retains the "generated under abnormal environment" status mark as a traceability basis), without needing to re-execute the encryption operation, thus avoiding delays and resource consumption caused by repeated encryption operations. If the environmental parameters deviate from the threshold range again in subsequent encryption cycles, the newly generated encrypted data packet is also marked as "generated under abnormal environment" status and transmission is paused. The second operation: The dual-mode hardware encryption unit sends an environmental anomaly alarm interrupt signal to the central processing unit (CPU) of the domestically produced main control chip. Upon responding to the interrupt, the CPU reads the environmental anomaly type register recorded in the safety monitoring module. This register records the anomaly type in encoded form—0x01 indicates voltage anomaly, 0x02 indicates temperature anomaly, 0x03 indicates clock frequency anomaly, and 0x04 indicates multiple anomalies occurring simultaneously. The CPU packages the anomaly type code along with a timestamp of the anomaly occurrence and uploads it to the remote monitoring platform via the chip's Ethernet media access control interface or universal asynchronous transceiver interface. The third operation: The dual-mode hardware encryption unit switches the encrypted data packet transmission channel to secure transmission mode. In secure transmission mode, the chip's physical communication interface only responds to data requests from the certified local maintenance interface; all remote data requests are rejected. The certified local maintenance interface is identified by a hardware enable signal identified through the chip's general purpose input / output pins. This signal only takes effect when the fire pump control cabinet maintenance door is opened and activated by maintenance personnel using a key switch. Secure transmission mode remains in effect until environmental parameters return to the preset safety threshold range and maintenance personnel confirm the deactivation via the domestically produced human-machine interface.
[0060] Compared with existing technologies, this invention continuously monitors the chip's operating environment parameters at a sampling frequency of no less than 1 kHz using voltage, temperature, and clock frequency sensors integrated within the chip. A security monitoring module, operating independently of the central processing unit, performs real-time threshold comparisons, overcoming the lack of systematic monitoring of environmental anomalies and delayed anomaly detection in existing technologies. When environmental parameters deviate from preset thresholds, the current encryption result is marked as "generated under abnormal environment" and transmission is paused instead of immediately erasing all keys and sensitive data. Once the environment returns to normal, the encryption is automatically re-encrypted and transmitted, overcoming the shortcomings of existing aggressive protection schemes that suffer from system interruptions and permanent data loss due to accidental triggering by brief environmental fluctuations. Simultaneously, the invention reports environmental anomalies to a remote monitoring platform and switches the transmission channel to a secure mode that only allows access via the local maintenance interface, achieving timely notification of anomalies and proactive protection of the communication link, maintaining system function continuity while ensuring chip security.
[0061] In another technical solution, during the transmission of the encrypted data packet from step S4 to the remote monitoring platform via the physical communication interface, the domestically produced main control chip simultaneously performs encrypted data communication quality assurance steps. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip has a built-in hardware acceleration engine for cryptographic algorithms, supporting multiple symmetric encryption algorithms such as SM4 and AES. It also integrates multiple universal asynchronous transceiver interfaces and an Ethernet media access control interface for data communication with the remote monitoring platform. The physical communication interface is an Ethernet interface, and the physical layer transceiver chip is the YT8512 industrial-grade Ethernet physical layer transceiver manufactured by Yutai Microelectronics Co., Ltd. This transceiver supports two data rates: 10 Mbps and 100 Mbps, and operates in a temperature range of -40°C to 85°C. It connects to the Ethernet media access control interface of the domestically produced main control chip via a simplified gigabit media independent interface, and is connected to the Ethernet switch of the local area network where the fire pump controller is located via an RJ45 connector with a network transformer, thus connecting to the remote monitoring platform via a public or private network.
[0062] Before sending encrypted data packets through the physical communication interface, the central processing unit (CPU) of the domestically produced main control chip first performs communication link quality monitoring. The CPU reads the communication quality parameters of the current communication link through the statistics register of the Ethernet Media Access Control (MAC) interface inside the chip. The data recorded in the statistics register includes: the total number of data packets sent, the total number of data packets received, the number of cyclic redundancy check (CRC) error packets, the number of alignment error packets, and the number of lost packets. The CPU calculates the packet loss rate and bit error rate (BER) for each statistical period of 100 sent data packets. The packet loss rate is calculated as follows: the number of data packets actually sent within the statistical period is subtracted from the number of data packets confirmed as received by the remote monitoring platform; the difference is divided by the actual number of sent data packets, and then multiplied by 100%. The bit error rate is calculated as follows: the number of CRC error packets recorded in the Ethernet MAC interface statistics register within the statistical period is divided by the total number of received data packets within the statistical period, and then multiplied by 100%.
[0063] The central processing unit (CPU) compares the calculated packet loss rate and bit error rate with preset thresholds. The preset threshold for packet loss rate is set to 5%, and the preset threshold for bit error rate is set to 0.1%. When the packet loss rate does not exceed 5% and the bit error rate does not exceed 0.1%, the CPU determines that the current communication link quality is good, and encrypted data packets are sent directly through the physical communication interface in the normal manner without enabling forward error correction coding. When the packet loss rate exceeds 5% or the bit error rate exceeds 0.1%, the CPU determines that the current communication link quality has deteriorated and automatically enables forward error correction coding. The above statistics and comparison of packet loss rate and bit error rate are performed once before each encrypted data packet is sent. The communication quality judgment result is only valid for the currently to be sent encrypted data packet. The statistics and judgment are re-performed before the next data packet is sent, thereby realizing real-time dynamic tracking of communication link quality.
[0064] When forward error correction coding is enabled, the CPU performs forward error correction coding on the encrypted data packets. The forward error correction coding uses the Reed-Solomon coding algorithm, a widely used forward error correction coding method in digital communication and storage systems, which has good burst error correction capabilities. The CPU divides the encrypted data packets to be sent into blocks of 239 bytes each. For each data block, 16 bytes of redundant check data are generated using the Reed-Solomon coding algorithm. This redundant check data is appended to the original data block, forming a 255-byte encoded data block. This encoding parameter corresponds to the RS(255, 239) encoding scheme of the standard Reed-Solomon code, which can correct up to 8 bytes of errors, with a redundancy of approximately 6.69%. For the last data block that is less than 240 bytes long, the CPU pads the end of the data block with 0x00 bytes to a length of 240 bytes before encoding. After encoding, the actual data length is recorded in the data packet header, and the receiving end removes the padding bytes based on this length information. After forward error correction coding is completed, the central processing unit assembles the encoded data blocks into a complete encoded data packet in sequence and sends it to the remote monitoring platform through the physical communication interface. The enabled or disabled status of forward error correction coding is indicated by a status flag bit in the header of the encrypted data packet. A logic 1 indicates that forward error correction coding is enabled in the current data packet, and a logic 0 indicates that it is not enabled.
[0065] After receiving an encrypted data packet, the remote monitoring platform first parses the status flag bits in the packet header. When the status flag bit is logic 0, the remote monitoring platform directly extracts the encrypted data part according to the normal process and performs subsequent decryption and integrity verification operations. When the status flag bit is logic 1, the remote monitoring platform recognizes that the current data packet has enabled forward error correction encoding and performs the corresponding decoding and error correction operations. The remote monitoring platform first divides the received encoded data block into 256-byte segments and runs the Reed-Solomon decoding algorithm on each encoded data block. The decoding algorithm first checks whether there are erroneous bytes in the encoded data block and their positions. If errors are detected and the number of errors does not exceed 8, the decoding algorithm automatically restores the erroneous bytes to the correct values, restoring the original 240-byte data block. If the number of errors detected exceeds 8, the decoding algorithm determines that the data block cannot be corrected, marks the data block as an unrecoverable error, and sends an alarm message indicating a serious degradation in communication quality to the administrator of the remote monitoring platform. For each successfully decoded data block, the remote monitoring platform removes the padding 0x00 bytes, concatenates the data blocks in their original order, and restores the complete encrypted data packet. After restoration, the remote monitoring platform performs subsequent decryption and integrity verification operations on the encrypted data portion. The processing flow is exactly the same as for data packets without forward error correction coding. The entire process of enabling, encoding, sending, receiving, decoding, and restoring forward error correction coding is completed at the communication link layer, which is completely transparent to the upper-layer data decryption and display process and does not change the format and content of the encrypted data packets.
[0066] The existing technology is a solution where the fire pump controller uses a data retransmission mechanism to ensure the reliability of data transmission when the communication quality deteriorates. That is, when the remote monitoring platform detects that the data packet is lost or erroneous, it sends a retransmission request to the controller, and the controller retransmits the lost or erroneous data packet. Compared with existing technologies, this invention uses a domestically produced main control chip to monitor the packet loss rate and bit error rate of the communication link in real time. When the packet loss rate exceeds 5% or the bit error rate exceeds 0.1%, forward error correction coding is automatically activated. The encrypted data packet is then sent after Reed-Solomon coding to generate redundant check data. The receiving end performs decoding and error correction operations to restore the complete data packet. This overcomes the shortcomings of existing retransmission mechanisms, which suffer from significantly increased transmission delay and decreased real-time performance due to repeated retransmission requests when communication quality is unstable. Forward error correction coding is a one-way transmission method, so the receiving end can correct transmission errors on its own without sending a retransmission request to the sending end, resulting in higher real-time performance. It is especially suitable for monitoring data transmission scenarios with real-time requirements, such as fire pump operating parameters. At the same time, the activation and deactivation status of forward error correction coding is indicated by a flag bit in the data packet header. The receiving end automatically selects the decoding method accordingly, achieving seamless integration of the communication quality assurance mechanism and the encrypted transmission process. Moreover, the encoding and decoding process is completely transparent to the upper-layer encryption, decryption, and display processes, without changing the format and content of the data packet.
[0067] In another technical solution, while the encrypted data packet in step S4 is sent to the remote monitoring platform via the physical communication interface, the domestically produced main control chip simultaneously supports the encrypted authentication process of the remote monitoring platform issuing control parameters or operation commands to the domestically produced main control chip. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, integrating up to 512 kilobytes of embedded flash memory and 144 kilobytes of static random access memory. It has a built-in hardware acceleration engine for cryptographic algorithms, supporting multiple cryptographic algorithms such as AES, DES, TDES, SHA1 / 224 / 256, SM1, SM3, SM4, SM7, and MD5. The chip has a built-in true random number generator, supports secure boot, encrypted program download and secure updates, and supports clock failure detection and tamper detection. The chip has a built-in 96-bit unique identifier and a 128-bit unique customer identifier.
[0068] When the remote monitoring platform sends control parameters or operation commands to the domestically produced main control chip, it first performs encryption and signature operations. The remote monitoring platform is a server deployed in the fire control center, equipped with encryption management software paired with the domestically produced main control chip. This software has a built-in SM4 algorithm encryption module and a digital signature generation module. When operators input the control parameters to be sent on the human-machine interface of the remote monitoring platform, the control parameters include fire pump start commands, stop commands, speed setpoints, pressure setpoints, or operating mode switching commands. The remote monitoring platform first encrypts the control parameters using the encryption algorithm corresponding to the current operating mode. When the current operating mode identifier is domestic mode, the SM4 algorithm is used to encrypt the control parameters; when the current operating mode identifier is international mode, the AES-256 algorithm is used to encrypt the control parameters. The encrypted control parameters form a ciphertext data block.
[0069] After encryption, the remote monitoring platform attaches a digital signature to the encrypted control parameters. The digital signature is generated as follows: the remote monitoring platform reads the pre-stored unique hardware identifier of the domestically produced main control chip. This unique hardware identifier is a 96-bit unique identifier written into the chip at the factory. The remote monitoring platform concatenates the encrypted control parameter data block to be sent with the 96-bit unique identifier of the domestically produced main control chip into a single data string. It then performs an SM2 digital signature operation on this data string using its private key, generating a 64-byte digital signature value. This private key is the private key portion of an SM2 asymmetric key pair. The key pair is generated by the remote monitoring platform administrator during system initialization using key management software. The public key portion is pre-imported and stored securely in the public key storage area of the embedded flash memory within the domestically produced main control chip. After the digital signature is generated, the remote monitoring platform packages the encrypted control parameter ciphertext, the digital signature value, and its own identity identifier into a complete instruction data packet, which is then sent to the physical communication interface of the domestically produced main control chip via a public or private network.
[0070] After receiving the instruction data packet through the physical communication interface of the domestically produced main control chip, the central processing unit (CPU) first parses the data packet, extracting the encrypted control parameter ciphertext, digital signature value, and remote monitoring platform identification. The CPU then performs a verification of the digital signature's legitimacy. The verification process is as follows: The CPU reads the pre-stored public key of the remote monitoring platform from the public key storage area of the embedded flash memory within the chip. This public key is an SM2 public key paired with the remote monitoring platform's private key. The public key storage area starts at address 0x08033000, has a size of 1 kilobyte, and is set to read-only mode by the chip's multi-user partition management unit to prevent tampering. The CPU uses this public key to perform SM2 signature verification on the received digital signature value. The verification operation works as follows: The CPU concatenates the received encrypted control parameter ciphertext with a 96-bit unique identifier stored within the chip to form a data string. It uses the public key to decrypt the digital signature value to obtain the original digest value, and simultaneously uses the SM3 hash algorithm to calculate the hash value of the concatenated data string. The decrypted digest value is compared with the calculated hash value. If they match, the signature verification passes; otherwise, it fails. A successful signature verification indicates that the instruction data packet was indeed issued by a legitimate remote monitoring platform holding the corresponding private key, and that the data has not been tampered with during transmission. A failed signature verification indicates that the instruction may have originated from an illegal source or been tampered with during transmission.
[0071] After successful signature verification, the central processing unit (CPU) decrypts the ciphertext of the encrypted control parameters using the decryption algorithm corresponding to the current operating mode. When the current operating mode flag is set to domestic mode, the CPU invokes the SM4 decryption function of the cryptographic algorithm hardware acceleration engine, using the currently active SM4 key to decrypt the ciphertext. When the current operating mode flag is set to international mode, the CPU invokes the AES-256 decryption function, using the currently active AES-256 key to decrypt the ciphertext. Upon decryption, the CPU obtains the plaintext control parameters or operation instructions.
[0072] Before being executed, the decrypted control parameters must be verified by the integrity verification module. The central processing unit sends the decrypted plaintext control parameters to the chip's built-in cyclic redundancy check (CRC32) calculation unit to calculate the CRC32 check value. This check value is then compared with the check value carried in the instruction data packet. If they match, the integrity verification passes; otherwise, it fails.
[0073] After integrity verification is passed, the central processing unit (CPU) executes the corresponding control operation. For example, if the control parameter is a fire pump start command, the CPU outputs a high-level signal to the AC contactor control coil of the fire pump through a general-purpose input / output pin, causing the fire pump to start running; if the control parameter is a speed setpoint, the CPU outputs a pulse signal with the corresponding duty cycle to the analog input terminal of the frequency converter through a pulse width modulation output pin, adjusting the operating speed of the fire pump motor; if the control parameter is a pressure setpoint, the CPU writes the setpoint into the pressure control variable area in the chip's internal static random access memory, using it as the target value for closed-loop control in subsequent PID regulation calculations.
[0074] When signature verification fails or integrity verification fails, the domestically produced main control chip refuses to execute the control parameter. The central processing unit (CPU) generates a refusal report, which includes a refusal reason code: 0x01 indicates signature verification failure, 0x02 indicates integrity verification failure, and 0x03 indicates both failures, as well as a timestamp of the refusal and a summary of the received instruction data packet. The CPU returns the refusal report to the remote monitoring platform via the physical communication interface. Upon receiving the refusal report, the remote monitoring platform displays a failure message on its interface and records the event in its operation log for subsequent review by operators.
[0075] The existing technology is that the fire pump controller uses a simple password verification or fixed key authentication method to realize the remote parameter distribution scheme. That is, when the remote monitoring platform distributes control parameters, it only attaches a preset fixed password or uses a fixed key to encrypt the data. The controller only verifies whether the password matches or executes the data after decryption using the same fixed key. Compared with existing technologies, this invention first encrypts the control parameters issued by the remote monitoring platform using an encryption algorithm that matches the current encryption mode. Then, it uses the private key of the remote monitoring platform to generate a digital signature based on the unique hardware identifier of the domestic main control chip and attaches it to the instruction data packet. After receiving the digital signature, the domestic main control chip first verifies its legitimacy using the pre-stored public key of the remote monitoring platform. Only after the signature verification is successful can the control parameters be decrypted. This overcomes the security risks of existing technologies, such as the ease with which fixed passwords can be intercepted and cracked, and the lack of an identity binding mechanism for fixed keys, which makes it impossible to confirm whether the instruction comes from a legitimate source. The decrypted control parameters can only be executed after being verified by the integrity verification module. If the signature verification fails or the integrity verification fails, execution is refused and a refusal report is returned. This achieves trusted identity verification of remotely issued parameters, anti-tampering protection, and traceable feedback of execution results, effectively preventing illegal or forged instructions from intruding into the fire pump control system.
[0076] In another technical solution, within the fire pump control system, when the first domestically produced main control chip needs to send encrypted data to the second domestically produced main control chip, both chips perform multi-controller encryption configuration negotiation and data interoperability steps. Both the first and second domestically produced main control chips are N32G455VEL7 microcontrollers manufactured by National Technology Co., Ltd. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, integrating up to 512 kilobytes of embedded flash memory and 144 kilobytes of static random access memory. It has a built-in hardware acceleration engine for cryptographic algorithms, supporting multiple symmetric encryption algorithms such as SM4 and AES. The chip internally integrates multiple universal asynchronous transceiver interfaces, serial peripheral interfaces, and controller area network bus interfaces for inter-chip communication.
[0077] The first and second domestically produced main control chips establish a physical connection via a Controller Area Network (CLAN) bus or a Universal Asynchronous Receiver / Transmitter (UART) interface. The CLAN bus uses shielded twisted-pair cable as the transmission medium, with a communication rate set to 250 kilobits per second. A 120-ohm terminating resistor is connected to each end of the bus to eliminate signal reflection. When the first domestically produced main control chip needs to send encrypted data to the second domestically produced main control chip, the central processing unit of the first domestically produced main control chip first sends an encryption configuration negotiation request to the second domestically produced main control chip through the aforementioned physical connection. The negotiation request is a data frame with a fixed format. The data frame header contains a frame type identifier 0xA5, indicating a negotiation request frame. The payload of the data frame contains three fields: the first field is the working mode identifier, which is 1 byte long and stores the current working mode identifier status of the first domestic main control chip. 0x00 indicates domestic mode and 0x01 indicates international mode. The second field is the encryption strength level, which is 1 byte long and stores the encryption strength level currently used by the first domestic main control chip. 0x01 indicates high encryption strength level and 0x02 indicates low encryption strength level. The third field is the key version number, which is 2 bytes long and stores the key version identifier currently used by the first domestic main control chip. This version number is an unsigned integer that increments sequentially from 1.
[0078] After receiving the negotiation request data frame, the central processing unit (CPU) of the second domestically produced main control chip parses three fields in the data frame payload to extract the operating mode identifier, encryption strength level, and key version number of the first domestically produced main control chip. The CPU of the second domestically produced main control chip then reads the current operating mode identifier, the currently used encryption strength level, and the currently used key version number stored in its internal registers, and compares these three encryption configuration parameters one by one with the corresponding parameters received from the first domestically produced main control chip.
[0079] There are two scenarios for the comparison results. Scenario 1: If both chips have the same operating mode identifier, encryption strength level, and key version number, the second domestically produced main control chip returns an acknowledgment frame to the first. The frame header includes a frame type identifier (0xA6) indicating successful negotiation, and the payload includes a status code field (0x00) indicating consistent configuration. Upon receiving the acknowledgment frame, the first domestically produced main control chip establishes a direct encrypted data transmission channel. This channel uses both chips' current working keys for encryption and decryption. The first domestically produced main control chip encrypts the data using its own current working key and sends it via the physical connection. The second domestically produced main control chip decrypts the received data using its own current working key. Since both chips have identical operating mode identifiers, encryption strength levels, and key version numbers, and their current working keys are also identical, encryption and decryption can proceed normally.
[0080] In the second scenario: if any one of the two domestically produced main control chips is inconsistent in terms of operating mode identifier, encryption strength level, or key version number, the second domestically produced main control chip returns a negotiation response frame to the first domestically produced main control chip. The header of the response frame contains a frame type identifier 0xA7 indicating that negotiation is in progress, and the payload contains all three encryption configuration parameters of the second domestically produced main control chip itself. After receiving the negotiation response frame, the first domestically produced main control chip and the two parties enter the configuration negotiation phase. During the configuration negotiation phase, the commonly supported encryption configuration parameters are determined according to the following priority rules: The first priority is the working mode identifier. If the working mode identifiers of the two chips are inconsistent, the working mode identifier of the first domestically produced main control chip will be used as the negotiation result. The second domestically produced main control chip will temporarily switch to the same working mode as the first domestically produced main control chip during this data interoperability period. The second priority is the encryption strength level. After the working mode identifier is determined, if the encryption strength levels of the two chips are inconsistent, the highest common encryption strength level supported by both parties and capable of meeting the requirement of encryption latency not exceeding 50 microseconds under their respective performance loads will be negotiated and selected. If a higher strength level causes the encryption latency of one party to exceed the limit, it will automatically downgrade to a lower level. The third priority is the key version number. After both the working mode identifier and the encryption strength level are determined, if the key version numbers of the two chips are inconsistent, both parties agree to use the key corresponding to the one with the newer version number for encryption and decryption. After the negotiation is completed, both parties will temporarily store the negotiated encryption configuration parameters in the negotiation cache area of their respective chip's internal static random access memory. The negotiation buffer is a temporary storage area designated in static random access memory, starting at address 0x20003000 and having a size of 64 bytes.
[0081] After the encrypted data transmission channel is established, the first domestically produced main control chip encrypts the data to be sent using the negotiated encryption configuration parameters. Specifically, the central processing unit (CPU) of the first domestically produced main control chip writes the corresponding algorithm selection code and key length configuration code to the control register of the cryptographic algorithm hardware acceleration engine according to the negotiated working mode identifier and encryption strength level. It then reads the key corresponding to the negotiated key version number from the corresponding key storage area and performs encryption operations to generate encrypted data packets. After encryption, the first domestically produced main control chip transmits the encrypted data packets to the second domestically produced main control chip via the controller area network bus or a universal asynchronous transceiver interface. Upon receiving the encrypted data packets, the second domestically produced main control chip decrypts them using the same negotiated encryption configuration parameters. The CPU of the second domestically produced main control chip configures the decryption mode of the cryptographic algorithm hardware acceleration engine according to the negotiated working mode identifier and encryption strength level. It then reads the key corresponding to the negotiated key version number from the corresponding key storage area and performs decryption operations to restore the plaintext data.
[0082] After data interoperability is completed, both the first and second domestically produced main control chips automatically restore their original encryption configurations. The specific restoration process is as follows: The central processing unit (CPU) of the first domestically produced main control chip reads its own operating mode identifier, encryption strength level, and key version number from the configuration parameter area of its embedded flash memory before data interoperability. It then rewrites these original configuration parameters into the corresponding registers and key storage area activation register, restoring the cryptographic algorithm hardware acceleration engine to its state before data interoperability. The second domestically produced main control chip performs the same restoration operation. After restoration, both CPUs clear all temporary configuration parameters temporarily stored in the negotiation cache by writing 64 bytes of 0x00 consecutively starting from the beginning address of the negotiation cache, completely clearing the temporary configuration parameters and eliminating security risks caused by residual temporary configurations. The entire negotiation, transmission, and restoration process, from initiating the negotiation request to restoring the original configuration, takes no more than 50 milliseconds in actual testing.
[0083] The existing technology is a scheme in which each controller in a multi-controller system uses the same encryption parameters that are pre-configured manually for data communication. That is, during system integration, technicians use a programmer to write the same encryption algorithm, key and key version number into each controller. Each controller uses this fixed configuration to exchange encrypted data. When the encryption configuration of a controller needs to be changed, all related controllers need to be reconfigured one by one. Compared with existing technologies, this invention sends a negotiation request containing a working mode identifier, encryption strength level, and key version number to a second domestically produced main control chip via a first domestically produced main control chip. After receiving the request, the second domestically produced main control chip compares its own encryption configuration with that of the first domestically produced main control chip. If they match, a direct encrypted data transmission channel is established. If they do not match, they negotiate to select a commonly supported encryption configuration parameter. This overcomes the shortcomings of existing technologies, such as the need for manual pre-configuration of encryption configurations for each controller, the need for complete re-burning when configurations change, low engineering implementation efficiency, and susceptibility to configuration inconsistencies due to human error. After data interoperability is completed, each controller automatically restores its original encryption configuration, and temporary configuration parameters in the negotiation cache are automatically cleared. This ensures automatic adaptation and flexible switching when multiple controllers exchange encrypted data, and eliminates security risks caused by residual temporary configurations.
[0084] In another technical solution, after the acquisition and digital conversion of the fire pump operating parameters are completed in step S1 and before the on-chip hardware encryption operation in step S3, the domestically produced main control chip performs a local fault prediction step for the operating parameters. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, and integrates up to 512 kilobytes of embedded flash memory and 144 kilobytes of static random access memory. The configuration parameter area of the embedded flash memory inside the chip pre-stores the threshold range of the fire pump's normal operating parameters. This configuration parameter area starts at address 0x08034000 and has a size of 4 kilobytes, and is written by technicians through the maintenance interface before the chip leaves the factory or during system debugging.
[0085] The normal operating parameter threshold range includes the lower and upper limits of the pump outlet pressure, as well as the rated speed range and preset deviation value of the pump speed. Taking a certain type of fire pump as an example, its normal operating pressure range is a lower limit of 0.2 MPa and an upper limit of 1.4 MPa, the rated speed is 1450 rpm, and the preset deviation value is 5% of the rated speed, that is, the deviation range is 1377.5 rpm to 1522.5 rpm. The above threshold parameters are stored in the configuration parameter area of the embedded flash memory in floating-point format, with each parameter occupying 4 bytes.
[0086] After completing data acquisition in step S1, the central processing unit (CPU) of the domestically produced main control chip reads the currently acquired pump outlet pressure, pump speed, and runtime from the data cache of the static random access memory. The CPU then reads the pre-stored lower pressure threshold (0.2 MPa), upper pressure threshold (1.4 MPa), rated speed (1450 rpm), and a preset deviation value of 5% from the configuration parameter area of the embedded flash memory. The CPU compares the current pump outlet pressure with the lower and upper pressure thresholds respectively, and simultaneously compares the current pump speed with the lower limit (rated speed multiplied by 1 minus 5%) and the upper limit (rated speed multiplied by 1 plus 5%) respectively.
[0087] The comparison results fall into three scenarios. Scenario 1: When the pump outlet pressure is greater than or equal to 0.2 MPa and less than or equal to 1.4 MPa, and the pump speed is greater than or equal to 1377.5 rpm and less than or equal to 1522.5 rpm, the central processing unit (CPU) determines that the current fire pump operating parameters are normal, does not generate a fault prediction flag, and the collected fire pump operating parameters proceed to step S3 for encryption calculation according to the normal process. Scenario 2: When the pump outlet pressure is less than 0.2 MPa or greater than 1.4 MPa, the CPU determines that the pump outlet pressure is abnormal. Scenario 3: When the pump speed is less than 1377.5 rpm or greater than 1522.5 rpm, the CPU determines that the pump speed is abnormal. When either the pump outlet pressure or the pump speed is abnormal, the CPU determines that the operating parameters are abnormal.
[0088] When an abnormal operating parameter is detected, the central processing unit (CPU) of the domestically produced main control chip generates a fault prediction flag. The fault prediction flag is a 1-byte status code, encoded as follows: 0x01 indicates pump outlet pressure is below the lower limit, 0x02 indicates pump outlet pressure is above the upper limit, 0x03 indicates pump speed is below the lower limit, 0x04 indicates pump speed is above the upper limit, and 0x05 indicates both abnormal pump outlet pressure and abnormal pump speed occur simultaneously. The CPU appends the fault prediction flag to a specific field in the header of the fire pump operating parameter data packet to be encrypted; this field is located in the first byte of the data packet. After appending, the format of the fire pump operating parameter data packet is: the first byte is the fault prediction flag, and subsequent bytes are the original data of the pump outlet pressure value, pump speed value, and running time value, respectively. The CPU sends the data packet with the fault prediction flag to the encryption process in step S3. The dual-mode hardware encryption unit performs on-chip hardware encryption on the entire data packet. The fault prediction flag and the fire pump operating parameters are encrypted together, ensuring that the fault prediction flag cannot be tampered with during subsequent transmission and storage.
[0089] The encrypted data packet is transmitted to the remote monitoring platform via the physical communication interface in step S4, and simultaneously transmitted to the domestically produced human-machine interface (HMI) after decryption in step S5. Upon receiving the encrypted data packet, the HMI first executes the decryption process in step S5 to restore the entire data packet to plaintext, and then parses the first byte of the plaintext data packet to obtain the fault prediction identifier. When displaying the decrypted fire pump operating parameters, the HMI's dedicated encrypted data display unit highlights or marks the corresponding parameters with a specific color based on the value of the fault prediction identifier. The specific labeling method is as follows: When the fault prediction indicator is 0x01, the pump outlet pressure value is displayed in red font with a downward arrow icon to the right of the value, indicating that the pressure is below the lower limit; when the fault prediction indicator is 0x02, the pump outlet pressure value is displayed in red font with an upward arrow icon to the right of the value, indicating that the pressure is above the upper limit; when the fault prediction indicator is 0x03, the pump speed value is displayed in red font with a downward arrow icon to the right of the value, indicating that the speed is below the lower limit; when the fault prediction indicator is 0x04, the pump speed value is displayed in red font with an upward arrow icon to the right of the value, indicating that the speed is above the upper limit; when the fault prediction indicator is 0x05, both the pump outlet pressure value and the pump speed value are displayed in red font and each is labeled with a corresponding arrow icon. Running time parameters are not involved in fault prediction and are always displayed normally in white font. Simultaneously, a "Abnormal Operating Parameters" warning banner is displayed at the top of the HMI display area with a yellow background to alert on-site operators.
[0090] After receiving and decrypting the encrypted data packet sent in step S4, the remote monitoring platform also parses the fault prediction identifier. Based on the value of the fault prediction identifier, the remote monitoring platform automatically triggers the corresponding fault maintenance work order. The generation logic for the fault maintenance work order is as follows: the remote monitoring platform fills in the fault prediction identifier, the timestamp of the abnormality, the fire pump controller number, and the current abnormal pump outlet pressure and pump speed values into a preset work order template, automatically generating an electronic maintenance work order. After the work order is generated, the remote monitoring platform sends the work order information to the preset maintenance personnel's terminals via SMS or application push notification. The maintenance work orders are displayed in a list format in the management interface of the remote monitoring platform, marked with a status of "Pending Processing," and sorted according to the severity of the abnormality—work orders marked with 0x05 have the highest priority, followed by work orders marked with 0x01 and 0x02, and then work orders marked with 0x03 and 0x04.
[0091] The existing technology involves fire pump controllers only collecting and uploading data. Whether the operating parameters are abnormal is determined entirely by the remote monitoring platform after receiving the data and comparing thresholds through software. The controller does not perform any fault prediction locally. Compared with existing technologies, this invention compares the collected fire pump operating parameters with the pre-stored normal operating parameter threshold ranges of the domestically produced main control chip before encryption. When the pump outlet pressure is lower than the lower limit or higher than the upper limit, or the pump speed deviates from the rated speed range by more than a preset deviation value, it is determined that the operating parameters are abnormal and a fault prediction mark is generated. This mark is attached to the data packet to be encrypted and transmitted together with the operating parameters. This overcomes the shortcomings of existing technologies, which rely entirely on remote platforms for anomaly judgment and cannot detect and mark anomalies locally when communication is interrupted. The fault prediction mark is transmitted to the domestically produced human-machine interface and remote monitoring platform along with the encrypted data packet. When displaying decrypted parameters, the human-machine interface highlights or marks abnormal parameters with a specific color so that on-site operators can immediately and intuitively identify abnormal states. After receiving the data, the remote monitoring platform automatically triggers the corresponding fault maintenance work order to realize closed-loop management of anomalies from discovery to handling. Moreover, the fault prediction mark is encrypted together with the operating parameters to ensure the credibility and immutability of the entire chain of anomaly information from local prediction to remote presentation.
[0092] In another technical solution, during the daily operation of the fire pump controller, the domestically produced main control chip initiates a hardware performance monitoring process at fixed intervals. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, and a built-in cryptographic algorithm hardware acceleration engine, supporting multiple symmetric encryption algorithms such as SM4 and AES. The chip integrates two independent cryptographic algorithm hardware acceleration channels, which are completely symmetrical in hardware and serve as backups for each other. By default, the first cryptographic algorithm hardware acceleration channel is in operation as the current encryption operation unit, while the second cryptographic algorithm hardware acceleration channel is in sleep mode as a backup encryption operation unit, consuming only extremely low standby power. The two channels are connected to the input and output buffers via an internal multiplexer controlled by the central processing unit through a dedicated channel selection register.
[0093] The central processing unit (CPU) of the domestically produced main control chip has an internal 24-hour timer. This timer uses the chip's internal real-time clock module as its clock source and continuously increments from the moment of power-on. When the timer's count reaches the number of seconds corresponding to 24 hours (86,400 seconds), it generates an overflow interrupt signal, triggering the CPU to initiate a hardware performance monitoring process. After the performance monitoring process starts, the timer automatically resets to zero and restarts, preparing for the next trigger.
[0094] At the start of each performance monitoring process, the CPU first reads 64 bytes of random data from the chip's internal true random number generator, using this random data as the plaintext portion of the standard test data packet. The true random number generator is a hardware module built into the N32G455VEL7 chip, generating unpredictable random number sequences based on circuit thermal noise. Simultaneously, the CPU pre-calculates the expected encryption result of this standard test data packet under normal performance conditions: during chip factory calibration or system initialization, the CPU performs an encryption operation using the standard test data packet under standard conditions of a chip temperature of 25 degrees Celsius, a supply voltage of 3.3 volts, and a clock frequency of 144 MHz. The result is stored as the expected encryption result in the calibration parameter area of the chip's embedded flash memory, starting at address 0x08035000, with a length of 64 bytes. The CPU then sends the standard test data packet to the input buffer of the current encryption operation unit, i.e., the first cryptographic algorithm hardware acceleration channel, and records the start time of the encryption operation using a hardware timer integrated within the chip. This hardware timer is a 32-bit microsecond-level timer with a resolution of 1 microsecond. After the hardware acceleration channel completes the encryption operation, it sends a completion interrupt signal to the central processing unit. When responding to the interrupt, the central processing unit immediately reads the current value of the hardware timer, calculates the difference between the current value and the starting time, and obtains the actual completion time of the encryption operation.
[0095] The central processing unit (CPU) compares the measured actual completion time with a preset performance benchmark. The preset benchmark is set at 35 microseconds, derived from the average completion time of multiple measured encryption operations under standard conditions, plus a certain margin. This margin leaves a 15-microsecond safety margin compared to the system's required encryption latency of no more than 50 microseconds. A completion time of 35 microseconds or less is considered normal; a completion time greater than 35 microseconds is considered a timeout.
[0096] The central processing unit (CPU) maintains a sliding window of 50 monitoring results, stored in the chip's internal static random access memory (SRAM) starting at address 0x20004000. Each monitoring result occupies 1 byte, with 0x00 indicating normal operation and 0x01 indicating timeout. After each new performance monitoring cycle, the CPU writes the current result to the end of the sliding window and removes the oldest result from the beginning, always maintaining the window containing only the most recent 50 monitoring results. The CPU counts the number of timeout results within the sliding window and calculates the timeout ratio by dividing the number of timeouts by 50. When the timeout ratio reaches or exceeds 30% in multiple consecutive monitoring cycles, the CPU determines that a preset alarm ratio has been reached and generates a performance alarm message. The performance alarm message includes an alarm type code (0xE002) indicating encryption performance degradation, the current timeout ratio, the alarm trigger timestamp, and the current chip temperature. The central processing unit uploads performance alarm information to the remote monitoring platform through the chip's Ethernet media access control interface or universal asynchronous transceiver interface. At the same time, it sends the performance alarm information to the domestically produced human-machine interface. The human-machine interface displays the message "Encryption performance degraded, maintenance recommended" in yellow background in the status bar at the top of the display screen.
[0097] When the timeout rate reaches or exceeds 60% during multiple consecutive monitoring sessions, the CPU determines that a preset emergency ratio has been reached and automatically executes a computing resource allocation operation. The specific process of the computing resource allocation operation is as follows: First, the CPU sends a pause command to the current encryption computing unit, i.e., the first cryptographic algorithm hardware acceleration channel. This channel enters a paused state after completing the currently executing encryption operation. Second, the CPU switches the data paths of the input and output buffers from the first channel to the second channel through the channel selection register of the multiplexer. Third, the CPU sends a wake-up command and an initialization command to the second cryptographic algorithm hardware acceleration channel, which serves as a backup encryption computing unit, configuring the control register of this channel with the same algorithm selection and key configuration as the first channel. Fourth, the CPU sends a standard test data packet to the second channel to perform a verification encryption operation. After confirming that the output result of the second channel is completely consistent with the expected encryption result, the second channel is officially put into use as the current encryption computing unit, responsible for all subsequent encryption computing tasks. The first channel then switches to a dormant state, serving as a new backup encryption computing unit. The entire computing resource allocation operation, from triggering to completion, took no more than 5 milliseconds according to actual testing. During this period, encryption operations were paused, but received but unprocessed encryption requests were temporarily stored in the input buffer and will be processed by the second channel after the switch is completed.
[0098] The backup relationship between the first and second channels remains unchanged after the reallocation is completed; that is, the second channel is currently in operation, and the first channel serves as a backup. In subsequent performance monitoring, the CPU continues to monitor the performance of the currently operating encryption unit. When the timeout rate of the currently operating encryption unit recovers to below 30% after multiple consecutive monitoring sessions, the CPU determines that performance has returned to normal and automatically performs a reverse switchover operation, switching the encryption task from the currently operating second channel back to its original configuration. That is, the first channel resumes its role as the current encryption unit, and the second channel reverts to its backup encryption unit, restoring the system to its factory default hardware resource configuration.
[0099] Existing technologies lack proactive monitoring mechanisms for encryption hardware performance in fire pump controllers. Problems are only passively detected when encryption operations experience significant failures or data transmission anomalies, by which time the encryption function may have partially or completely failed, affecting secure data transmission. In contrast, this invention overcomes the shortcomings of existing technologies by sending standard test data packets to the dual-mode hardware encryption unit at fixed intervals and recording the actual completion time of encryption operations. It compares the actual completion time with a preset performance benchmark value and maintains a sliding window of the most recent monitoring results. Furthermore, when the proportion of encryption operation completion times exceeding the preset performance benchmark value in consecutive monitoring reaches a preset alarm ratio, performance alarm information is uploaded and a performance prompt is displayed on the human-machine interface, providing early warning of encryption performance degradation. When the timeout ratio reaches a preset emergency ratio, the encryption task is automatically switched from the current encryption unit to a backup encryption unit. After performance returns to normal, it switches back to the original configuration, ensuring the continuity of encryption function when encryption hardware performance deteriorates and avoiding the risk of the entire encryption link failing due to the performance degradation of a single encryption unit.
[0100] In another technical solution, after the encrypted data packet is generated in step S4, the domestically produced main control chip performs emergency export of encrypted data and external redundancy backup steps. The domestically produced main control chip is the N32G455VEL7 microcontroller manufactured by National Technology Co., Ltd. This chip uses a 32-bit ARM Cortex-M4F core, with a maximum operating frequency of 144 MHz, and integrates up to 512 kilobytes of embedded flash memory and 144 kilobytes of static random access memory. The embedded flash memory supports partition management and data protection, and supports hardware ECC verification. The chip integrates multiple universal asynchronous transceiver interfaces, serial peripheral interfaces, controller area network bus interfaces, and SDIO interfaces for communication with external devices.
[0101] After each encrypted data packet generation, the domestically produced main control chip, in addition to writing the encrypted data packet to the encrypted data backup area of the chip's internal non-volatile memory according to step S4, simultaneously sends the encrypted data packet to an external redundant storage device through an emergency data interface independent of the main communication interface. The emergency data interface uses the chip's serial peripheral interface, which is independent of the Ethernet interface and universal asynchronous transceiver interface used for remote communication. The serial peripheral interface is configured in master mode, with a clock frequency of 10 MHz and a data format of mode 0 (clock polarity 0, clock phase 0, and data length 8 bits). The four pins of the serial peripheral interface—serial clock pin, master output / slave input pin, master input / slave output pin, and chip select pin—are connected to the corresponding pins of the external redundant storage device. The external redundant storage device is a W25Q64JV serial flash memory manufactured by Winbond Electronics Co., Ltd. This chip is a 64-megabit serial flash memory (8 megabytes), packaged in an 8-pin small outline integrated circuit. It operates from 2.7V to 3.6V and supports standard serial peripheral interfaces, dual-channel serial peripheral interfaces, and quad-channel serial peripheral interfaces. The maximum clock frequency is 133 MHz, with at least 100,000 write / erase cycles, a data retention period of at least 20 years, and an operating temperature range of -40°C to 85°C. The chip select pin of the W25Q64JV serial flash memory is connected to the chip select pin of the serial peripheral interface of the domestically produced host control chip. The serial clock pin is connected to the serial clock pin of the serial peripheral interface of the domestically produced host control chip. The master input / slave output pin is connected to the master input / slave output pin of the serial peripheral interface of the domestically produced host control chip, and the master output / slave input pin is connected to the master output / slave input pin of the serial peripheral interface of the domestically produced host control chip. The power supply pin of the W25Q64JV serial flash memory is connected to a 3.3V DC power supply, and the ground pin is connected to system ground. The external redundant storage device is installed in a dedicated slot inside the fire pump control cabinet and is connected to the serial peripheral interface pins of the domestic main control chip via a four-core shielded cable.
[0102] When the central processing unit (CPU) of the domestically produced main control chip sends encrypted data packets to the W25Q64JV serial flash memory via the serial peripheral interface, it first sends a 0x06 command to the write enable command register of the memory to enable the write operation, then sends a page programming command 0x02, followed by the 24-bit target memory address, and finally sends each byte of the encrypted data packet consecutively. Each encrypted data packet has a fixed length of 256 bytes, with the write target address starting from 0x000000, each data packet occupying 256 bytes, and offsetting sequentially. After each write operation is completed, the CPU sends a read status register command 0x05 via the serial peripheral interface to read the W25Q64JV's status register, checking if the busy flag is 0. If the busy flag is 0, the write operation is complete; if the busy flag is 1, the write operation is still in progress, and the CPU continues to wait until the busy flag becomes 0.
[0103] After receiving the encrypted data packet, the external redundant storage device returns a reception confirmation signal to the domestically produced main control chip. The reception confirmation signal is implemented as follows: after the W25Q64JV serial flash memory completes the page programming operation, the busy flag bit of its status register changes from 1 to 0. When the central processing unit of the domestically produced main control chip detects that the busy flag bit has changed to 0 by reading the status register, it considers that a reception confirmation signal has been received.
[0104] When the domestically produced main control chip fails to receive a reception acknowledgment signal three times consecutively, the central processing unit (CPU) determines that the external redundant storage device is offline or faulty. The specific logic for determining this is as follows: After each encrypted data packet is sent, the CPU starts a timeout counter. This counter uses the chip's internal real-time clock module as its clock source, with an initial value of 0, incrementing by 1 every millisecond. When the timeout counter reaches 1000 (1000 milliseconds), the CPU determines that the transmission has timed out and no reception acknowledgment signal has been received. If all three transmissions time out, the CPU determines that the external redundant storage device is offline or faulty. At this point, the CPU temporarily stores the unacknowledged encrypted data packets in the chip's internal emergency buffer. The emergency buffer is a dedicated storage area within the chip's internal static random access memory (SRAM), starting at address 0x20005000, with a size of 16 kilobytes. It uses a circular queue for storage, with each encrypted data packet having a fixed length of 256 bytes, and can store up to 64 unacknowledged encrypted data packets. The CPU stores the unacknowledged encrypted data packets along with their corresponding write destination address and timestamp in the emergency buffer. Once the external redundant storage device is back online, the CPU reads the unacknowledged encrypted data packets from the emergency buffer and resends them to the original destination address. The determination of whether the external redundant storage device is back online is as follows: the CPU sends a read device identifier command (0x90) to the W25Q64JV every 30 seconds. If the device identifier (0xEF17) is correctly read, the device is considered back online.
[0105] When a domestically produced main control chip detects a write failure or data read error in a specific storage area of its internal non-volatile memory through its built-in self-diagnostic function, it automatically triggers an emergency data export process. The specific implementation of the built-in self-diagnostic function is as follows: the embedded flash memory controller within the domestically produced main control chip integrates hardware ECC verification. Each time data is read from the flash memory, the hardware ECC verification logic automatically verifies the read data. When a single-bit error is detected, the ECC verification logic automatically corrects the error and sets a correctable error flag; when a double-bit error is detected, the ECC verification logic cannot correct it, sets an uncorrectable error flag, and triggers a flash memory error interrupt. After responding to the flash memory error interrupt, the central processing unit (CPU) reads the error status register. If the uncorrectable error flag is set, it determines that a write failure or data read error has occurred in that storage area. At this time, the CPU automatically triggers the emergency data export process: starting from address 0x08020000 in the encrypted data backup area of the chip's internal non-volatile memory, the CPU reads the still readable encrypted data packets page by page from the encrypted data backup area. For each page, the CPU first attempts to read all the data on that page. If the ECC check passes or only a correctable error occurs, the page is considered readable. The data is then sent to the W25Q64JV serial flash memory via the emergency data interface (serial peripheral interface). If the ECC check detects an uncorrectable error, the page is skipped, and a specific placeholder 0xDEAD and error flag 0xEF are written to the corresponding location in the external redundant storage device. Simultaneously, the logical address of the page is recorded in the data recovery log so that the cause of the missing data can be clearly identified during subsequent data analysis. After all readable data has been exported, the CPU generates a data recovery log. The data recovery log includes the timestamp of the export operation, the number of successfully exported data packets, a list of skipped corrupted page addresses, and the identifier of the export target device. The CPU uploads the data recovery log to a remote monitoring platform via the Ethernet media access control interface, allowing administrators to understand the damage status of the chip's internal memory and the data recovery progress.
[0106] The existing technology is that the fire pump controller only stores the operating data in the non-volatile memory inside the chip and does not have an external redundant storage device. When the internal memory of the chip is physically damaged, the historical data is permanently lost and cannot be recovered. Compared with the prior art, this invention, after each encrypted data packet is generated, in addition to writing it to the encrypted data backup area of the chip's internal non-volatile memory, simultaneously sends the encrypted data packet to an external redundant storage device through an emergency data interface independent of the main communication interface. This achieves dual data backup of the chip's internal storage and external redundant storage, overcoming the defect of permanent data loss caused by a single storage medium failure in the prior art. After receiving the data, the external redundant storage device returns a reception confirmation signal. If no confirmation signal is received three times consecutively, the unconfirmed encrypted data packet is temporarily stored in the chip's internal emergency buffer area and resent after the device recovers, avoiding data loss due to temporary offline of the external storage device. When the chip detects an uncorrectable error in the internal non-volatile memory through built-in ECC self-diagnosis, it automatically exports all readable encrypted data packets in the encrypted data backup area to the external redundant storage device and generates a data recovery log, which is then uploaded to a remote platform. This achieves emergency data rescue and traceable reporting of the fault status in the event of storage medium failure. Furthermore, as a built-in hardware function of the chip, the ECC verification has clear and specific judgment criteria, and the solution is operable.
[0107] Regarding the data integrity verification pass rate required by FM / UL, which is over 99.99%, this invention passes CRC32 verification (collision probability of 2). -32 ≈ 2.33 × 10 -10 With a failure rate far below 0.01%, the SM3 hash verification, which is additionally enabled under a high security level, can theoretically meet the pass rate requirement. In actual engineering implementation, this can be confirmed by continuously monitoring the verification failure rate and periodically performing statistical verification of data integrity.
[0108] Although the technical solutions of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and embodiments shown and described herein.
Claims
1. A method for dual-standard data encryption and human-machine collaboration in a fire pump controller driven by a domestically produced chip, characterized in that, Includes the following steps: S1. Digital acquisition and input of physical sensor signals: Real-time acquisition of fire pump operating parameters through sensors and transmission to domestic main control chip. Fire pump operating parameters include at least pump outlet pressure, pump speed and running time. S2. Hardware register status identification and algorithm kernel retrieval for encryption mode: The domestic main control chip reads the working mode flag bit stored in the internal register and matches the corresponding encryption algorithm according to the flag bit: when the flag bit is in the first state, the national cryptographic SM4 algorithm is selected; when the flag bit is in the second state, the AES-256 algorithm is selected. S3. On-chip hardware arithmetic logic encryption operation: The dual-mode hardware encryption unit calls the selected encryption algorithm to perform on-chip hardware encryption operation on the fire pump operating parameters and generate encrypted data packets; S4. Backup and Cyclic Redundancy Check of Encrypted Data to Physical Storage Medium: After the encrypted data packet is generated, the domestic main control chip writes it into the encrypted data backup area of the non-volatile memory inside the chip to form a local physical backup; at the same time, the hardware-level data integrity verification module runs a cyclic redundancy check or hash check algorithm on the encrypted data packet and outputs an integrity verification value; the verification value is sent to the remote monitoring platform along with the encrypted data packet through the physical communication interface for the receiving end to perform integrity verification. S5. Collaborative Decryption and Visualization: After the encrypted data packet is transmitted to the domestically produced human-machine interface via the communication link, the domestically produced human-machine interface establishes a secure session with the domestically produced main control chip through a challenge-response two-way authentication mechanism based on a unique hardware identifier. Only after successful authentication can it send a hardware decryption request to the domestically produced main control chip. After verifying the legitimacy of the request source and the validity of the session, the domestically produced main control chip performs decryption operations through the on-chip hardware decryption engine to restore the operating parameters of the fire pump. The domestically produced human-machine interface displays the decrypted parameters in real time through a dedicated encrypted data display unit, and simultaneously marks the encryption status and integrity verification results. S6. Abnormal Linkage Early Warning: When the remote monitoring platform or the domestic human-machine interface fails to perform integrity verification on the received encrypted data packet, or detects that the data has been tampered with during transmission, an alarm trigger signal is generated. After receiving the signal, the domestic main control chip simultaneously executes three alarms: sending alarm information to the remote monitoring platform, triggering the pop-up alarm on the domestic human-machine interface, and activating the audible and visual alarm.
2. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, Before step S2, there are also steps for configuring encryption policies and managing key isolation, specifically: The domestically produced main control chip reads the data type of the fire pump operating parameters to be encrypted and matches the corresponding encryption strength level according to the security level requirements of the fire pump operating parameters; Based on the matched encryption strength level and the current working mode identifier, the domestically produced main control chip calls the corresponding encryption algorithm and key length from the dual-mode hardware encryption unit: when the working mode identifier is domestic mode and the encryption strength level is high, the SM4 algorithm is called; when the working mode identifier is domestic mode and the encryption strength level is low, the SM4 algorithm is called with a simplified operation round; when the working mode identifier is international mode and the encryption strength level is high, the AES-256 algorithm is called; when the working mode identifier is international mode and the encryption strength level is low, the AES-128 algorithm is called. The dual-mode hardware encryption unit is configured with independent key storage areas for different encryption strength levels, and the key storage areas are isolated from each other through a hardware access isolation mechanism. When the working mode identifier in step S2 is switched, the domestic main control chip automatically disables the current key storage area and switches to the key storage area corresponding to the target mode.
3. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, It also includes the key cycle update and audit log generation steps, which are executed in parallel with steps S4 to S6, specifically as follows: The timer built into the domestic main control chip records the elapsed time of the current encryption key. When the elapsed time reaches the preset key update cycle threshold, the key update process is automatically triggered. The dual-mode hardware encryption unit generates a new encryption key and replaces the current working key with the new key. After the replacement is completed, the old key is marked as invalid but is still retained in the key history storage area for decryption of historical data. After each key update, the domestically produced main control chip generates an audit record. The audit record includes at least the update timestamp, the key version identifier before the update, the key version identifier after the update, and the reason for the update. After the hardware-level data integrity verification module calculates the verification value of the audit record, it is written to the audit log area of the chip's internal non-volatile memory and uploaded to the remote monitoring platform for archiving through the communication interface. When the abnormal linkage warning in step S6 is triggered, the domestic main control chip packages all the audit records stored in the audit log area and reports them to the remote monitoring platform through the communication interface as evidence for tracing security incidents and determining responsibility.
4. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, In step S3, the on-chip hardware encryption operation also includes anomaly monitoring and proactive protection steps, specifically: The dual-mode hardware encryption unit has a built-in physical sensor group that monitors the chip's operating environment parameters in real time. The physical sensor group includes at least a voltage detection sensor, a temperature detection sensor, and a clock frequency detection sensor. Each sensor continuously collects environmental parameters at a sampling frequency of not less than 1kHz and transmits them to the chip's built-in security monitoring module. The safety monitoring module compares the environmental parameters collected by each sensor with the preset safety threshold range: when the voltage deviates from the preset voltage threshold range, or the temperature exceeds the preset temperature threshold range, or the clock frequency deviates from the preset frequency threshold range, the safety monitoring module determines that there is an abnormal risk in the current operating environment and immediately triggers a hardware-level protection response. After the hardware-level protection response is triggered, the dual-mode hardware encryption unit performs the following operations simultaneously: First, it marks the current encryption operation result as "generated under abnormal environment" and suspends the transmission of the encrypted data packet until the environment returns to normal and then re-encrypts it; Second, it sends an environmental abnormality alarm signal to the domestic main control chip, and after receiving it, the domestic main control chip reports the environmental abnormality event and abnormality type to the remote monitoring platform through the communication interface; Third, it switches the encrypted data packet transmission channel to secure transmission mode, allowing only the authenticated communication interface to access the chip's internal data.
5. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, In step S4, when the encrypted data packet is sent to the remote monitoring platform through the physical communication interface, a step to ensure the quality of encrypted data communication is also included, specifically: The domestically produced main control chip monitors the communication quality status of the current communication link in real time. When the packet loss rate or bit error rate of the communication link exceeds the preset threshold, it automatically enables forward error correction coding to redundantly encode the encrypted data packet before sending it. After receiving the data packet encoded with forward error correction, the remote monitoring platform performs corresponding decoding and error correction operations to restore the complete encrypted data packet.
6. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, It also includes the encrypted authentication steps for remote parameter distribution, specifically: When the remote monitoring platform sends control parameters or operation instructions to the domestic main control chip, it first encrypts the control parameters using an encryption algorithm that matches the current encryption mode, and attaches a digital signature generated based on the unique hardware identifier of the domestic main control chip. After receiving the encrypted control parameters, the domestically produced main control chip first verifies the legality of the digital signature: it confirms whether the signature was issued by a legitimate remote monitoring platform through the built-in hardware identifier comparison module; after the signature verification is successful, it decrypts the control parameters using the decryption algorithm corresponding to the current working mode. After the decrypted control parameters are verified to be correct by the integrity verification module, the domestic main control chip executes the corresponding control operation; if the signature verification fails or the integrity verification fails, the domestic main control chip refuses to execute the control parameters and returns a refusal report to the remote monitoring platform through the communication interface.
7. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, It also includes steps for multi-controller encryption policy negotiation and data interoperability, specifically: When the first domestic main control chip needs to send encrypted data to the second domestic main control chip, the first domestic main control chip first sends an encryption configuration negotiation request to the second domestic main control chip through a secure handshake channel. The negotiation request includes at least the current working mode identifier, encryption strength level and key version number. After receiving the negotiation request, the second domestically produced main control chip compares its own encryption configuration with that of the first domestically produced main control chip: if the working mode identifier, encryption strength level and key version number of the two are consistent, then a direct encrypted data transmission channel is established directly. If there is any inconsistency, the two parties shall negotiate and select a mutually supported encryption configuration parameter; After the encrypted data direct transmission channel is established, the first domestic main control chip uses the negotiated encryption configuration to encrypt the data and transmit it to the second domestic main control chip. The second domestically produced main control chip uses the same encryption configuration for decryption; after data communication is completed, each controller automatically restores its original encryption configuration, and temporary configuration parameters generated during the negotiation process are automatically cleared.
8. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, After step S1 and before step S3, there is also a step for local fault prediction of running parameters, which is as follows: The domestically produced main control chip compares the collected fire pump operating parameters with the pre-stored normal operating parameter threshold range inside the chip: when the pump outlet pressure is lower than the lower limit pressure threshold or higher than the upper limit pressure threshold, or when the pump speed deviates from the rated speed range by more than the preset deviation value, it is determined that the operating parameters are abnormal. When the operating parameters are determined to be abnormal, the domestic main control chip generates a fault prediction mark and attaches it to the fire pump operating parameter data packet to be encrypted, and enters the encryption process of step S3 together with the fire pump operating parameters. The fault prediction indicator is transmitted along with the encrypted data packet to the domestic human-machine interface and remote monitoring platform. When displaying the decrypted parameters, the human-machine interface highlights the abnormal parameters with a specific color. After receiving the information, the remote monitoring platform triggers the corresponding fault maintenance work order.
9. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, It also includes steps for monitoring and reporting the performance of encrypted hardware, specifically: The domestically produced main control chip initiates a hardware performance monitoring process at a fixed cycle: sending standard test data packets to the dual-mode hardware encryption unit and recording the actual completion time of the encryption operation; When the proportion of actual completion time of encryption operation exceeding the preset performance benchmark value in multiple consecutive monitoring reaches the preset alarm proportion, the domestic main control chip generates performance alarm information, uploads it to the remote monitoring platform through the communication interface, and displays performance prompts on the domestic human-machine interface. When the proportion of actual completion time of encryption operation exceeding the preset performance benchmark value in multiple consecutive monitoring reaches the preset emergency ratio, the domestic main control chip automatically performs computing resource allocation operation: switching the encryption task from the current encryption computing unit to the backup encryption computing unit, until the performance returns to normal and then switching back to the original configuration.
10. The method for dual-standard data encryption and human-machine collaboration of a fire pump controller driven by a domestically produced chip as described in claim 1, characterized in that, It also includes steps for emergency export of encrypted data and external redundant backup, specifically: After each encrypted data packet is generated, the domestically produced main control chip, in addition to writing the encrypted data backup area into the chip's internal non-volatile memory, simultaneously sends the encrypted data packet to an external redundant storage device through an emergency data interface independent of the main communication interface. After receiving the encrypted data packet, the external redundant storage device returns a reception confirmation signal to the domestically produced main control chip; When the domestic main control chip fails to receive a reception confirmation signal multiple times in a row, it determines that the external redundant storage device is offline or malfunctioning, and temporarily stores the unconfirmed encrypted data packets in the chip's internal emergency buffer area, and resends them after the external redundant storage device is restored to online status; When the domestically produced main control chip detects a write failure or data read error in a specific storage area of the chip's internal non-volatile memory through its built-in self-diagnostic function, it automatically triggers an emergency data export process: the encrypted data packets that can still be read normally in the encrypted data backup area are exported to an external redundant storage device through the emergency data interface, and a data recovery log is generated and uploaded to the remote monitoring platform.