Gas supply and use double-end communication method, computer device and readable storage medium
By dynamically adjusting the lengths of fixed and redundant fields in the gas supply and demand dual-end communication, and combining priority identification and verification rules, the problem of coordination between safety redundancy, low overhead, and low latency in gas safety management is solved, achieving highly reliable transmission in weak network environments. It is suitable for gas safety management in all scenarios and dual-end communication in the industrial Internet of Things.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGDONG SENEASY INTELLIGENT TECH CO LTD
- Filing Date
- 2026-03-30
- Publication Date
- 2026-07-14
Smart Images
Figure CN122394739A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of gas safety management technology, and in particular to a communication method, computer equipment and readable storage medium for two ends of gas supply. Background Technology
[0002] In the field of gas safety management and control technology, the current mainstream technical solution is an end-to-cloud-to-end communication system based on a general Internet of Things communication protocol. Through the communication module between the gas station and the user terminal, in conjunction with the cloud server, data encapsulation, forwarding and parsing are realized, which can meet the basic requirements for instruction issuance and data reporting.
[0003] However, the gas supply and consumption safety management scenarios face inherently contradictory core technologies: emergency valve shut-off and leak warning commands require extremely low latency and high reliability (zero packet loss in weak network conditions), while the daily monitoring data reporting from millions of user terminals demands extremely low overhead. Furthermore, the deployment of numerous terminals in remote, weak network environments necessitates compatibility with multiple communication links. Existing general protocols, designed to ensure universality, incorporate numerous redundant fields and multi-step handshake confirmation mechanisms. Protocol overhead accounts for as much as 87% when transmitting small volumes of gas data, and the fixed request-confirmation-forward-confirmation four-step interaction results in persistently high end-to-end latency. Conventional industry improvement approaches are limited to single-point optimizations within the general protocol framework, such as simplifying handshake steps, removing redundant fields, or dynamically adjusting frame lengths. However, these approaches fail to break through the traditional logic of optimizing transmission at the communication layer. Any reduction in confirmation mechanisms to lower overhead and latency inevitably sacrifices the reliability of emergency commands, while adding redundancy checks and retransmission mechanisms to improve reliability inevitably increases overhead and latency. Therefore, achieving the optimal balance between safety redundancy, low overhead, and low latency remains elusive. Summary of the Invention
[0004] This application provides a communication method, computer equipment, and readable storage medium for both gas supply and consumption ends, in order to solve the technical problem that existing gas safety management and control cannot achieve optimal coordination of safety redundancy, low overhead, and low latency.
[0005] To address the aforementioned technical problems, in a first aspect, this application provides a communication method for two ends of a gas supply system, applied to a first terminal, wherein the first terminal is communicatively connected to a cloud server, and the cloud server is communicatively connected to a second terminal, the method comprising: Obtain the data type of the service data to be transmitted and the current link signal strength; The data security level and the fixed business field length of the business data to be transmitted are determined based on the data type. The length of the dynamic redundancy field of the service data to be transmitted is determined based on the current link signal strength and the data security level. Wherein, when the data security level is the same, the lower the current link signal strength, the longer the dynamic redundancy field is; and when the current link signal strength is the same, the higher the data security level, the longer the dynamic redundancy field is. A first service frame is generated based on the fixed service field length and the dynamic redundancy field length. The first service frame is sent to the cloud server, which then sends the first service frame to the second terminal. The first service frame includes a priority identifier. The first terminal is a user terminal and the second terminal is a gas station terminal, or the first terminal is a gas station terminal and the second terminal is a user terminal.
[0006] The aforementioned gas supply dual-end communication method determines the fixed business field length of the data to be transmitted based on its data type, and determines the dynamic redundancy field length based on the current link signal strength and data security level. This breaks through conventional adaptation logic in the field, using security level as the core driver to adjust the security redundancy length, rather than passively adapting to data size and network status. While maintaining compatibility with communication links across all scenarios, it achieves highly reliable transmission of emergency commands under weak network conditions. This gas supply dual-end communication method addresses the industry pain point of the inherent contradiction between security redundancy, low overhead, and low latency in gas supply dual-end scenarios. It is specifically adapted to the unique transmission characteristics of gas scenarios, such as short commands, small size, distinct security levels, and numerous remote and weak network environments. It can be directly applied to the safety management of gas in all scenarios, including residential outdoor gas cylinders, industrial gas stations, and gas monitoring of special equipment. It can also be extended to other industrial IoT dual-end communication scenarios with stringent requirements for security level, transmission latency, and communication overhead.
[0007] In one implementation, determining the data security level and the fixed service field length of the service data to be transmitted based on the data type includes: The data security level is determined based on the data type and the preset security level mapping relationship; Based on the data security level and the preset field length mapping relationship, the fixed business field length of the business data to be transmitted is determined.
[0008] In one implementation, determining the dynamic redundancy field length of the service data to be transmitted based on the current link signal strength and the data security level includes: The target length set of the redundant fields of the service data to be transmitted is determined according to the data security level, and the target length set includes multiple preset redundant field lengths; The length of the dynamic redundancy field of the service data to be transmitted is determined based on the current link signal strength and the target length set.
[0009] In one embodiment, after sending the first service frame to the cloud server, the method further includes: Whether the first service frame needs to be retransmitted is determined based on the data security level. If it is determined that the first service frame needs to be retransmitted, the first service frame is retransmitted to the cloud server according to the preset retransmission rules.
[0010] Secondly, this application provides a communication method for two ends of gas supply, applied to a cloud server, the method comprising: Obtain the first service frame sent by the first terminal, the first service frame being generated according to the above-mentioned communication method between the gas supply and consumption ends; The data security level of the service data to be transmitted is determined based on the priority identifier of the first service frame, and the verification rules of the service data to be transmitted are determined based on the data security level. The first service frame is verified according to the verification rules. If the verification passes, the first service frame is sent to the second terminal; if the verification fails, the first service frame is discarded.
[0011] In one implementation, the data security level includes a first security level, a second security level, a third security level, and a fourth security level, and the step of sending the first service frame to the second terminal if the verification passes includes: If the verification passes and the data security level is the first security level or the second security level, the first service frame is sent to the second terminal through a dedicated narrowband transmission channel. If the verification passes and the data security level is the third or fourth security level, the first service frame is sent to the second terminal through the shared broadband transmission channel.
[0012] Thirdly, this application provides a communication method for two ends of gas supply, applied to a second terminal, the method comprising: Obtain the first service frame sent by the cloud server, which is generated according to the above-mentioned communication method between the gas supply and consumption ends; The data security level of the transmitted service data is determined based on the priority identifier of the first service frame, and the verification rules of the transmitted service data are determined based on the data security level. The first service frame is verified according to the verification rules. If the verification passes, the corresponding business operation is executed according to the core data fields of the first business frame, wherein the core data fields include fixed business fields and dynamic redundancy fields.
[0013] In one embodiment, the method further includes: If the data security level is the first security level, a feedback frame is generated based on the execution status of the first service frame; within a preset time range after the first service frame is acquired, the feedback frame is sent to the cloud server, so that the cloud server sends the feedback frame to the first terminal, causing the first terminal to stop retransmitting the first service frame; And / or, if the data security level is the second security level, an execution identifier is generated based on the execution status of the first service frame; the execution identifier is embedded in the second service frame, and the second service frame is sent to the cloud server, so that the cloud server can send the second service frame to the first terminal.
[0014] Fourthly, this application provides a computer device including a processor and a memory, wherein the memory is used to store a computer program, and the computer program, when executed by the processor, implements the above-described communication method between the two ends of the gas supply.
[0015] Fifthly, this application provides a computer-readable storage medium, characterized in that it stores a computer program, which, when executed by a processor, implements the above-described communication method between the two ends of the gas supply. Attached Figure Description
[0016] Figure 1 This is a schematic flowchart illustrating a communication method between two ends of a gas supply system, as shown in an embodiment of this application. Figure 2 This is another schematic flowchart illustrating the communication method between two ends of gas supply in an embodiment of this application; Figure 3 This is another schematic flowchart illustrating the communication method between two ends of gas supply in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device shown in an embodiment of this application. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0018] Please refer to Figure 1, Figure 1 This is a flowchart illustrating a communication method for a two-way gas supply system provided in an embodiment of this application. The method is applied to a first terminal, which is connected to a cloud server, and the cloud server is connected to a second terminal. Figure 1 As shown, the communication method between the two ends of the gas supply in this embodiment includes steps S11 to S14, which are described in detail below: Step S11: Obtain the data type of the service data to be transmitted and the current link signal strength.
[0019] In this step, the user terminal can collect the gas concentration and gas consumption in the user's environment and send these data to the gas station for data statistics and risk warning. The gas station can generate emergency valve shut-off commands and leakage warning commands based on the data reported by the user terminal. When the gas concentration in the user's environment exceeds the standard value, a leakage warning command is generated for the user terminal to conduct risk assessment. When the gas concentration in the user's environment exceeds the risk value, an emergency valve shut-off command is generated for the user terminal to perform an emergency valve shut-off action to ensure safety. Preferably, the data types of the service data to be transmitted include gas concentration, gas consumption, leakage warning commands, and emergency valve shut-off commands. The current link signal strength reflects the current network quality and can be categorized into four levels: strong, medium, weak, and extremely weak.
[0020] Step S12: Determine the data security level and the fixed business field length of the business data to be transmitted based on the data type.
[0021] In this step, the data security level and the fixed business field length of the data to be transmitted can be uniquely determined based on the data type. When executing step S12, the data security level is first determined according to the data type and the preset security level mapping relationship; then, the fixed business field length of the data to be transmitted is determined according to the data security level and the preset field length mapping relationship. For example, the data security levels include first security level, second security level, third security level, and fourth security level. Gas consumption corresponds to the fourth security level, gas concentration corresponds to the third security level, leakage warning command corresponds to the second security level, and emergency valve shut-off command corresponds to the first security level. The fixed business field length corresponding to the first security level is 5 bytes, the fixed business field length corresponding to the second security level is 3 bytes, the fixed business field length corresponding to the third security level is 4 bytes, and the fixed business field length corresponding to the fourth security level is 4 bytes.
[0022] It should be noted that the length of the fixed business field is determined by the length of the core content of the business data to be transmitted. For example, the emergency valve closing instruction needs to include the command code and terminal ID, and its corresponding fixed business field length is 5 bytes; the leakage warning instruction only needs to include the warning code, and its corresponding fixed business field length is 3 bytes.
[0023] Step S13: Determine the length of the dynamic redundancy field of the service data to be transmitted based on the current link signal strength and the data security level. Wherein, when the data security level is the same, the lower the current link signal strength, the longer the dynamic redundancy field. And when the current link signal strength is the same, the higher the data security level, the longer the dynamic redundancy field.
[0024] In this step, the length of the dynamic redundancy field and the verification rules of the service data to be transmitted can be uniquely determined based on the current link signal strength and data security level. When executing step S13, firstly, the target length set of the redundant fields of the service data to be transmitted is determined based on the data security level. The target length set includes multiple preset redundant field lengths. Then, the length of the dynamic redundancy field of the service data to be transmitted is determined based on the current link signal strength and the target length set.
[0025] When the data security level is the first security level, if the current link signal strength is strong, the dynamic redundancy field length is determined to be 0 bytes, and the fixed service field length is 5 bytes, making the total length of the core data field of the first service frame 5 bytes; if the current link signal strength is medium, the dynamic redundancy field length is determined to be 1 byte, and the fixed service field length is 5 bytes, making the total length of the core data field of the first service frame 6 bytes; if the current link signal strength is weak / very weak, the dynamic redundancy field length is determined to be 3 bytes, and the fixed service field length is 5 bytes, making the total length of the core data field of the first service frame 8 bytes. In this case, the dynamic redundancy field is, for example, three repeated backups of the valve closing command, so that data error correction can be achieved within a single frame without retransmission.
[0026] When the data security level is the second security level, if the current link signal strength is strong / medium, the dynamic redundancy field length is determined to be 0 bytes, and the fixed service field length is 3 bytes, so that the total length of the core data field of the first service frame is 3 bytes; if the current link signal strength is weak / very weak, the dynamic redundancy field length is determined to be 1 byte, and the fixed service field length is 3 bytes, so that the total length of the core data field of the first service frame is 4 bytes.
[0027] When the data security level is level three, the dynamic redundancy field length is set to 0 bytes for all current link signal strength levels, and the fixed service field length is 4 bytes, making the total length of the core data field in the first service frame 4 bytes. When the data security level is level four, the dynamic redundancy field length is set to 0 bytes for all current link signal strength levels, and the fixed service field length is 4 bytes, making the total length of the core data field in the first service frame 4 bytes. It should be noted that the total length of the core data field in the first service frame is equal to the sum of the fixed service field length and the dynamic redundancy field length.
[0028] It should be noted that security levels three and four are low security levels. The business data corresponding to these levels is reported periodically. Even if a single packet loss occurs, subsequent reported business data will directly overwrite the lost data, without affecting the periodic closed-loop operation of the business. Therefore, when the data security level is three or four, setting the dynamic redundancy field length to 0 bytes, and not adjusting it based on the current link signal strength, can completely replace redundant acknowledgment messages at the communication layer, significantly reducing feedback overhead.
[0029] As can be seen, this step reverses the conventional adaptation logic by determining the length of the dynamic redundancy field and the verification rules of the data to be transmitted based on the current link signal strength and data security level. Driven by the gas safety level, it dynamically adjusts the length of the safety redundancy segment within the first service frame, rather than the length of the effective data. The adaptation logic is rigidly linked to the safety level matrix, frame structure, and interaction process. Under conventional adaptation logic, the worse the network, the shorter the frame length. By splitting the effective data, the transmission success rate is improved, adapting to the effective data length, which inevitably leads to retransmission overhead and increased latency. However, under the adaptation logic of this application embodiment, the higher the security level and the worse the network condition, the longer the safety redundancy segment within the first service frame. The effective data length is completely fixed. Through instruction redundancy backup within a single frame, the transmission success rate under weak network conditions is improved without increasing retransmission or latency. This solves the mutual exclusion problem of low latency and high reliability for emergency instructions in gas scenarios with weak networks.
[0030] Step S14: Generate a first service frame according to the fixed service field length and the dynamic redundancy field length, and send the first service frame to the cloud server, so that the cloud server sends the first service frame to the second terminal. The first service frame includes a priority identifier, and the first terminal is a user terminal and the second terminal is a gas station terminal, or the first terminal is a gas station terminal and the second terminal is a user terminal.
[0031] In this step, after determining the fixed business field length and the dynamic redundancy field length, the first business frame can be encapsulated and generated. Preferably, the first business frame includes a frame header field, a data type and security level field, a core data field, a checksum field, and a frame trailer field.
[0032] The frame header field is 1 byte in size. The high 4 bits are a fixed value of 0x01, indicating the start of the first service frame. The low 4 bits are real-time link status flags, which are used to synchronously collect the current link signal strength when encapsulating the first service frame. This provides a basis for dynamic redundancy adaptation and achieves rigid linkage between the frame header flag and the adaptation mechanism, unlike the conventional frame header which only serves as a start flag. For example, if the current link signal strength is strong, the low 4 bits of the frame header field are 0x3; if the current link signal strength is medium, the low 4 bits are 0x2; if the current link signal strength is weak, the low 4 bits are 0x1; and if the current link signal strength is extremely weak, the low 4 bits are 0x0.
[0033] The data type and security level field is 1 byte in size, with the high 4 bits representing the data type and the low 4 bits representing the data security level. These two bits are rigidly interlocked, corresponding to one of four data types. Once determined, they directly lock the verification rules for the checksum field, the fixed business field length, and the feedback rules for the frame tail field. The data type and security level field are directly associated with the checksum field's verification rules, the cloud server's link scheduling priority, and the feedback mechanism of the interaction process, achieving integrated binding of business type, security level, transmission scheduling, and reliability assurance. This differs from the generalized design of conventional frame structures where priorities can be flexibly configured. It should be noted that the data security level bit is the priority identifier for the first business frame.
[0034] The core data fields consist of two parts: fixed business fields and dynamic redundancy fields. The length of the fixed business fields is rigidly determined by the data type bits and cannot be modified, ensuring the consistent transmission of valid data. The length of the dynamic redundancy fields is driven and adjusted by the data security level bits and the real-time link status flag bits. The higher the security level and the worse the link status, the longer the dynamic redundancy fields become. This is used to repeatedly back up core instructions, achieving highly reliable transmission under weak network conditions, unlike the conventional frame structure which only transmits valid data. The checksum field is 1 byte long and carries the CRC check result of the first terminal on the first business frame, which is used for verification and comparison by the cloud server and the second terminal.
[0035] The frame tail field is 1 byte in size. The lower 4 bits are a fixed value of 0x02, indicating the end of the first service frame. The higher 4 bits are embedded feedback bits for transmission status, used to carry execution status feedback to the second terminal. For example, 00 indicates no execution, 01 indicates successful execution, 10 indicates execution failure, and 11 indicates warning is lifted. The feedback information is directly embedded in the frame tail of subsequent transmissions, realizing a rigid linkage between the frame tail identifier and interactive feedback, which is different from the single function of the conventional frame tail, which only serves as an end indicator.
[0036] The following is an example illustrating the typical frame structure of the first service frame. In the scenario where the user sends the gas consumption data to the gas station, the data security level is the fourth security level. If the current link signal strength is strong, the structure of the first service frame is as follows: Frame header field 1 byte (frame header value is 0x13, where the high 4 bits are 0x1, indicating the start of the frame, and the low 4 bits are 0x3, indicating the strong link status) → Data type bit 0x0 → Data security level bit 0x0 → Fixed service field 4 bytes (0x00 0x00 0x00 0x64, corresponding to 100L) → Dynamic redundancy field 0 bytes → Checksum field 1 byte (0xDE) → Frame tail field 1 byte (0x02). That is, the total length of the core data field is 4 bytes, the total length of the frame is 8 bytes, and the complete message is 0x13 0x000x00 0x00 0x00 0x64 0xDE 0x02. The effective data ratio is 50%, which is 4 times higher than that of the existing technology. In a scenario where an emergency valve shut-off command is sent from the gas station to the user terminal, the data security level is Level 1. If the current link signal strength is extremely weak, the structure of the first service frame is as follows: Frame header field 1 byte (frame header value is 0x10, where the high 4 bits are 0x1, indicating the start of the frame, and the low 4 bits are 0x0, indicating an extremely weak link status) → Data type bit 0x3 → Data security level bit 0x3 → Fixed service field 5 bytes (0xAA 0x00 0x00 0x00 0x01, where 0xAA is the valve shut-off command, and the last 4 bytes are the terminal ID) → Dynamic redundancy field 3 bytes (0xAA 0xAA 0xAA, valve shut-off command backup) → Checksum field 1 byte (0x8B) → Frame tail field 1 byte (0x02), that is, the total length of the core data field is 8 bytes, the total frame length is 12 bytes, and the complete message is 0x10 0x33 0xAA 0x00 0x00 0x00 The first service frame (0x01 0xAA 0xAA 0xAA 0x8B 0x02) achieves a 98% higher transmission success rate under weak network conditions compared to conventional short frame designs, while maintaining an end-to-end latency of ≤80ms. It can be seen that this first service frame rigidly interlocks the four types of core gas services with four safety levels and transmission rules, forming a closed, proprietary coding system. There is no redundant space for general configurations, completely eliminating the inherent overhead defects of general protocols. Fields form an inseparable interlocking relationship through safety levels; the function, value, and length of each field are rigidly determined by the safety level. Simultaneously, it integrates link status identifiers and embedded feedback bits to achieve precise allocation of safety redundancy.
[0037] In a preferred embodiment, after executing step S14, the first terminal can further determine whether the first service frame needs to be retransmitted based on the data security level. If it is determined that the first service frame needs to be retransmitted, the first service frame is resent to the cloud server according to the preset retransmission rules. Further, when the data security level is the first security level, the first terminal retransmits the first service frame twice, with an interval of 100ms between each retransmission; when the data security level is the second security level, the first terminal retransmits the first service frame once; when the data security level is the third or fourth security level, the first terminal does not retransmit the first service frame, and session management using a general protocol is not required.
[0038] The aforementioned gas supply dual-end communication method determines the fixed business field length of the data to be transmitted based on its data type, and determines the dynamic redundancy field length based on the current link signal strength and data security level. This breaks through conventional adaptation logic in the field, using security level as the core driver to adjust the security redundancy length, rather than passively adapting to data size and network status. While maintaining compatibility with communication links across all scenarios, it achieves highly reliable transmission of emergency commands under weak network conditions. This gas supply dual-end communication method addresses the industry pain point of the inherent contradiction between security redundancy, low overhead, and low latency in gas supply dual-end scenarios. It is specifically adapted to the unique transmission characteristics of gas scenarios, such as short commands, small size, distinct security levels, and numerous remote and weak network environments. It can be directly applied to the safety management of gas in all scenarios, including residential outdoor gas cylinders, industrial gas stations, and gas monitoring of special equipment. It can also be extended to other industrial IoT dual-end communication scenarios with stringent requirements for security level, transmission latency, and communication overhead.
[0039] Please refer to Figure 2 , Figure 2 This is another schematic flowchart illustrating a communication method for two ends of a gas supply system provided in an embodiment of this application. This communication method for two ends of a gas supply system is applied to a cloud server. For example... Figure 2 As shown, the communication method between the two ends of the gas supply in this embodiment includes steps S21 to S24, which are described in detail below: Step S21: Obtain the first service frame sent by the first terminal. The first service frame is generated according to the above-mentioned communication method between the gas supply and consumption ends.
[0040] In this step, the cloud server adopts an unacknowledged forwarding strategy, completely eliminating the redundant mechanism of receiving and forwarding acknowledgments in the general protocol.
[0041] Step S22: Determine the data security level of the service data to be transmitted based on the priority identifier of the first service frame, and determine the verification rules of the service data to be transmitted based on the data security level.
[0042] In this step, after receiving the first service frame, the cloud server first parses the data type, security level field, and checksum field based on the first service frame. The data security level is determined based on the data type and security level fields, and the verification rules for the service data to be transmitted are determined based on the data security level. The verification rules include the verification algorithm and verification range. The checksum field includes the CRC check result of the first service frame calculated by the first terminal.
[0043] Step S23: Verify the first service frame according to the verification rules.
[0044] In this step, the cloud server can perform frame verification according to the verification rules. During verification, the cloud server regenerates the checksum according to the verification rules, and then compares the regenerated checksum with the checksum in the checksum field. If they match, the verification passes; otherwise, the verification fails.
[0045] Preferably, the verification algorithm corresponding to the first security level is dual CRC-8 verification. When performing dual CRC-8 verification, the first verification checks all fields of the first service frame except for the checksum field and the frame tail field; the second verification checks the fixed service fields of the first service frame. The final checksum is the XOR value of the two verification results. The verification algorithm corresponding to the second security level is standard CRC-8 verification, and the verification scope includes the frame header field, data type and security level field, and core data field of the first service frame. The verification algorithms for the third and fourth security levels are simplified CRC-8 verification, which only checks the core data fields of the first service frame. It can be seen that by setting different verification algorithms according to different data security levels, unlike the design of fixed verification rules for conventional frame structures, a precise balance between security redundancy and overhead can be achieved. Furthermore, the target length set corresponding to the first security level is {3 bytes, 1 byte, 0 bytes}, the target length set corresponding to the second security level is {1 byte, 0 bytes}, the target length set corresponding to the third security level is {0 bytes}, and the target length set corresponding to the fourth security level is {0 bytes}.
[0046] Step S24: If the verification passes, the first service frame is sent to the second terminal; if the verification fails, the first service frame is discarded.
[0047] In this step, the cloud server adopts a security level priority scheduling strategy. After the cloud server verifies the data, it does not need to send any confirmation information to the first terminal and forwards it directly to the second terminal; if the verification fails, it is discarded directly without sending any error information.
[0048] In a preferred embodiment, the data security level includes a first security level, a second security level, a third security level, and a fourth security level. When executing step S24, if the verification passes and the data security level is the first security level or the second security level, the first service frame is sent to the second terminal through a dedicated narrowband transmission channel; if the verification passes and the data security level is the third security level or the fourth security level, the first service frame is sent to the second terminal through a shared broadband transmission channel, thereby achieving precise allocation of link resources.
[0049] Please refer to Figure 3 , Figure 3 This is another schematic flowchart illustrating a gas supply dual-end communication method provided in an embodiment of this application, which is applied to a second terminal. For example... Figure 3 As shown, the communication method between the two ends of the gas supply in this embodiment includes steps S31 to S34, which are described in detail below: Step S31: Obtain the first service frame sent by the cloud server. The first service frame is generated according to the above-mentioned communication method between the gas supply and demand ends.
[0050] In this step, the second terminal can obtain the first service frame through the cloud server.
[0051] Step S32: Determine the data security level of the transmitted service data based on the priority identifier of the first service frame, and determine the verification rules of the transmitted service data based on the data security level.
[0052] In this step, the second terminal first parses the data type, security level field, and check code field of the first service frame, and determines the verification rules for the transmitted service data based on the data type and security level field, and determines the verification algorithm and verification range based on the verification rules.
[0053] Step S33: Verify the first service frame according to the verification rules.
[0054] In this step, the second terminal regenerates the verification code according to the verification algorithm and verification range, and compares the regenerated verification code with the verification code in the verification code field. If the two are the same, the verification passes; if they are different, the verification fails.
[0055] Step S34: If the verification passes, the corresponding business operation is executed according to the core data fields of the first business frame, wherein the core data fields include fixed business fields and dynamic redundancy fields.
[0056] If the verification passes, the corresponding business operation is executed. For example, if the data security level is Level 1, and the verification passes, an emergency valve closure operation is executed.
[0057] In a preferred embodiment, if the data security level is the first security level, a feedback frame is generated based on the execution status of the first service frame. Within a preset time range after acquiring the first service frame, the feedback frame is sent to the cloud server, which then sends the feedback frame to the first terminal, causing the first terminal to stop retransmitting the first service frame. For example, in a scenario where an emergency valve closure command is issued at the gas station, the user terminal must reply with an execution status feedback message within 100ms, using the same frame format as the first service frame. Upon receiving the feedback, the gas station immediately stops the preset retransmission, ensuring that the gas station can monitor the valve closure status in real time and guaranteeing safety.
[0058] If the data security level is level two, an execution identifier is generated based on the execution status of the first service frame. This execution identifier is embedded in the second service frame, which is then sent to the cloud server. The cloud server then forwards the second service frame to the first terminal. For example, in a scenario where a leak warning command is issued at a gas station, the user terminal does not need to immediately provide separate feedback. Only after the warning is lifted is the warning handling completion identifier embedded in the feedback bit of the next regular data report at level three / four security, eliminating the need to send a separate feedback message and removing additional overhead. It should be noted that the second service frame has the same frame structure as the first service frame.
[0059] If the data security level is level three, no feedback is required by default. Only when the data exceeds the security threshold will the data anomaly identifier be embedded in the feedback bit at the end of the next warning command frame at the gas station, without requiring separate feedback. If the data security level is level four, no feedback is required by default. Since the usage data is reported periodically, if the data is lost this time, the latest data reported next time will directly overwrite it. The periodic closed loop of the business itself completely replaces the redundant confirmation messages at the communication layer, eliminating more than 90% of the feedback overhead.
[0060] The communication method for gas supply and demand at both ends provided in this application is not a simplified version of the handshake steps of a general protocol. Its core is to overturn the underlying logic of the general protocol, which requires end-to-end confirmation of all transmissions at the communication layer. It replaces the redundant confirmation at the communication layer with the closed-loop characteristics of the gas service itself, and achieves differentiated interaction by combining a security level matrix. It is rigidly linked with the frame structure throughout the process and reconstructed into a two-step simplified process of end-side initiation, cloud-based collaborative forwarding, and target-side parsing and execution. This eliminates the latency and overhead caused by redundant interaction from the root, while ensuring the absolute reliability of high-security-level commands.
[0061] The first and second service frames in this embodiment have a very simple structure and no additional adaptation modules. They are directly compatible with all types of communication links, including narrowband and broadband, such as IoT, 4G, and 5G. The adaptation process is completed entirely by the protocol itself without manual intervention. In narrowband weak network scenarios, redundant expansion of high-security instructions is automatically triggered while maintaining the minimum frame length of regular data, balancing high reliability and low overhead. In broadband strong network scenarios, the length of redundant segments is automatically compressed to maintain the minimum frame length for transmission, minimizing latency. Furthermore, the second terminal can use the transmission status feedback bit at the end of the frame to report link interference and verification failures during the reception process to the initiating end. Based on the feedback information, the initiating end dynamically optimizes the length of redundant segments for the next transmission at the same security level, forming a closed loop of prediction adaptation, feedback, and optimization, further improving adaptation accuracy.
[0062] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 4 As shown, the computer device 40 of this embodiment includes: at least one processor 41 ( Figure 4 (Only one is shown in the diagram), memory 42, and computer program 43 stored in the memory 42 and executable on the at least one processor 41, wherein the processor 41 executes the computer program 43 to implement the steps in any of the above method embodiments.
[0063] The computer device 40 may be a desktop computer or a cloud server, among other computing devices. The computer device 40 may include, but is not limited to, a processor 41 and a memory 42. Those skilled in the art will understand that... Figure 4 The computer device 40 is merely an example and does not constitute a limitation on the computer device 40. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.
[0064] The processor 41 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0065] In some embodiments, the memory 42 may be an internal storage unit of the computer device 40, such as a hard disk or memory of the computer device 40. In other embodiments, the memory 42 may be an external storage device of the computer device 40, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 40. Furthermore, the memory 42 may include both internal and external storage units of the computer device 40. The memory 42 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 42 can also be used to temporarily store data that has been output or will be output.
[0066] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above method embodiments.
[0067] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.
[0068] In the several embodiments provided in this application, it will be understood that each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.
[0069] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0070] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.
Claims
1. A communication method for two-way gas supply, characterized in that, The method is applied to a first terminal, which is communicatively connected to a cloud server, and the cloud server is communicatively connected to a second terminal. The method includes: Obtain the data type of the service data to be transmitted and the current link signal strength; The data security level and the fixed business field length of the business data to be transmitted are determined based on the data type. The length of the dynamic redundancy field of the service data to be transmitted is determined based on the current link signal strength and the data security level. Wherein, when the data security level is the same, the lower the current link signal strength, the longer the dynamic redundancy field is; and when the current link signal strength is the same, the higher the data security level, the longer the dynamic redundancy field is. A first service frame is generated based on the fixed service field length and the dynamic redundancy field length. The first service frame is sent to the cloud server, which then sends the first service frame to the second terminal. The first service frame includes a priority identifier. The first terminal is a user terminal and the second terminal is a gas station terminal, or the first terminal is a gas station terminal and the second terminal is a user terminal.
2. The communication method for two ends of gas supply as described in claim 1, characterized in that, The process of determining the data security level and the fixed service field length of the service data to be transmitted based on the data type includes: The data security level is determined based on the data type and the preset security level mapping relationship; Based on the data security level and the preset field length mapping relationship, the fixed business field length of the business data to be transmitted is determined.
3. The communication method for two ends of gas supply as described in claim 1, characterized in that, Determining the dynamic redundancy field length of the service data to be transmitted based on the current link signal strength and the data security level includes: The target length set of the redundant fields of the service data to be transmitted is determined according to the data security level, and the target length set includes multiple preset redundant field lengths; The length of the dynamic redundancy field of the service data to be transmitted is determined based on the current link signal strength and the target length set.
4. The communication method for two ends of gas supply as described in claim 1, characterized in that, After sending the first service frame to the cloud server, the method further includes: Whether the first service frame needs to be retransmitted is determined based on the data security level. If it is determined that the first service frame needs to be retransmitted, the first service frame is retransmitted to the cloud server according to the preset retransmission rules.
5. A communication method for two-way gas supply, characterized in that, Applied to a cloud server, the method includes: Obtain a first service frame sent by a first terminal, wherein the first service frame is generated by the gas supply and consumption dual-end communication method according to any one of claims 1 to 4; The data security level of the service data to be transmitted is determined based on the priority identifier of the first service frame, and the verification rules of the service data to be transmitted are determined based on the data security level. The first service frame is verified according to the verification rules. If the verification passes, the first service frame is sent to the second terminal; if the verification fails, the first service frame is discarded.
6. The gas supply dual-end communication method as described in claim 5, characterized in that, The data security levels include a first security level, a second security level, a third security level, and a fourth security level. The step of sending the first service frame to the second terminal if the verification passes includes: If the verification passes and the data security level is the first security level or the second security level, the first service frame is sent to the second terminal through a dedicated narrowband transmission channel. If the verification passes and the data security level is the third or fourth security level, the first service frame is sent to the second terminal through the shared broadband transmission channel.
7. A two-way communication method for gas supply, characterized in that, Applied to a second terminal, the method includes: Obtain the first service frame sent by the cloud server, wherein the first service frame is generated by the communication method of the gas supply and consumption ends according to any one of claims 1 to 4; The data security level of the transmitted service data is determined based on the priority identifier of the first service frame, and the verification rules of the transmitted service data are determined based on the data security level. The first service frame is verified according to the verification rules. If the verification passes, the corresponding business operation is executed according to the core data fields of the first business frame, wherein the core data fields include fixed business fields and dynamic redundancy fields.
8. The communication method for two ends of gas supply as described in claim 7, characterized in that, The method further includes: If the data security level is the first security level, a feedback frame is generated based on the execution status of the first service frame; within a preset time range after the first service frame is acquired, the feedback frame is sent to the cloud server, so that the cloud server sends the feedback frame to the first terminal, causing the first terminal to stop retransmitting the first service frame; And / or, if the data security level is the second security level, an execution identifier is generated based on the execution status of the first service frame; the execution identifier is embedded in the second service frame, and the second service frame is sent to the cloud server, so that the cloud server can send the second service frame to the first terminal.
9. A computer device, characterized in that, It includes a processor and a memory, the memory being used to store a computer program, which, when executed by the processor, implements the communication method for two gas supply terminals as described in any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the communication method between the gas supply and demand ends as described in any one of claims 1 to 8.