Multi-protocol data interaction method and system integrating cloud management and host computer control

Abstract

The present application relates to the technical field of intelligent communication control, in particular to a multi-protocol data interaction method and system integrated with cloud management and host computer control. The system comprises a mainboard, a cloud background management system and a host computer management system. The mainboard is provided with multiple independent serial ports, forming multiple RS485 ports and at least one RS232 port. The mainboard receiving port is configured with a proposal and generates a shadow configuration. An original frame ring buffer area is established according to the port, and the original byte sequence and the receiving time and frame interval are stored. The shadow configuration is verified based on the buffered frame playback, and a verification report, a shadow digest value and a verification digest value are generated. When the digest is consistent and meets the safety switching window, the atomic switching is switched to the effective configuration. After taking effect, the multi-protocol is parsed and converted into a unified format for uploading, and the control instruction is mapped to the target protocol frame for issuing, thereby improving the configuration online reliability.

Description

Technical Field

[0001] This invention relates to the field of intelligent communication control technology, specifically to a multi-protocol data interaction method and system that integrates cloud management and host computer control. Background Technology

[0002] The informatization and automation of gas stations has evolved from single-machine metering to centralized station-level monitoring, and then to remote operation and maintenance across stations. Early fuel dispensers mostly used local independent control and simple serial communication, with data collection and transaction aggregation between the station and the station control unit via RS232 or RS485. With the increasing demands of chain operations and regulatory requirements, the need for centralized management of equipment status, transaction data, alarms, and maintenance records in the cloud has grown significantly. The on-site host computer now undertakes responsibilities such as installation and commissioning, protocol adaptation, fault location, and offline support. Simultaneously, the brands and models of gas station equipment have become increasingly diverse, with domestic and international manufacturers using the same protocols and experiencing frequent version iterations. On-site access has gradually evolved from a single protocol link to a multi-port, multi-protocol parallel access model. The motherboard typically needs to have multiple serial port resources, isolation, and level conversion capabilities, and complete protocol parsing, data aggregation, and control distribution under cloud or host computer configuration to adapt to the differentiated deployment and large-scale operation and maintenance of different stations.

[0003] Existing multi-protocol access solutions still have significant shortcomings in engineering applications: First, port protocol and communication parameter configurations often directly affect online links. Incorrect configurations or mismatched protocol selections can easily lead to port communication interruptions, resulting in unreadable device status, lost transaction data, or control failures. Second, with cloud-based maintenance and on-site host computers existing in parallel, configuration sources may compete for or overwrite each other. The lack of reliable consistency verification and conflict resolution mechanisms easily leads to instability phenomena such as "downtime after modification" and "repeated switching." Third, most solutions lack verifiable means to assess the effectiveness of new configurations, making it difficult to evaluate configuration usability without interrupting business operations. Furthermore, if switching is not timed to avoid high-frequency interaction periods, it may interfere with ongoing business processes. These problems result in high costs, significant risks, and difficulty in guaranteeing stability for multi-protocol expansion and on-site maintenance. Therefore, a multi-protocol data interaction method and system integrating cloud management and host computer control is needed to solve these problems. Summary of the Invention

[0004] (a) Technical problem to be solved: In view of the shortcomings of the existing technology, the present invention provides a multi-protocol data interaction method and system that integrates cloud management and host computer control, thus solving the above-mentioned problems.

[0005] (II) Technical Solution: To achieve the above objectives, the present invention provides the following technical solution: a multi-protocol data interaction method integrating cloud management and host computer control, applied to an intelligent communication control system. The system includes a motherboard and a management system, wherein the management system is a cloud backend management system or a host computer management system. The motherboard includes a processor and multiple independent serial ports, each independent serial port corresponding to multiple RS485 ports and at least one RS232 port. The RS485 port is connected to the fuel dispenser, and the RS232 port is communicatively connected to the management system. The method includes: Step S1: The motherboard establishes management communication with the management system and reports port information and a set of supported protocols. Step S2: The motherboard receives a port configuration proposal sent by the management system. The port configuration proposal includes at least a port identifier and a protocol identifier. The motherboard generates a shadow configuration while keeping the effective configuration unchanged, and establishes an original frame buffer for the port corresponding to the port identifier. The original frame buffer stores a preset number of segmented original byte sequences in chronological order and records reception time information and frame interval information for each original byte sequence. Step S3: The motherboard performs playback verification of the shadow configuration based on the segmented original byte sequences in the original frame buffer and generates... The verification report generates a shadow digest value and a verification digest value. The playback verification includes at least parsing and verifying the original byte sequence of the segmented frames according to the protocol corresponding to the shadow configuration, and determining verification indicators based at least on the verification pass rate and frame length consistency rate. The verification report is used to characterize whether the verification indicators meet a preset threshold. Step S4: The motherboard receives a configuration submission instruction according to preset arbitration rules. The configuration submission instruction carries a shadow digest value and a verification digest value. When the shadow digest value carried by the configuration submission instruction is consistent with the current shadow digest value, and the verification digest value carried by the configuration submission instruction is consistent with the current verification digest value... When the certificate digest values ​​are consistent and the secure switching window conditions are met, the motherboard atomically switches the shadow configuration to the effective configuration; wherein the secure switching window conditions include at least one of the following: the target port has not received the segmented original byte sequence within a continuous preset idle time, or the frame interval of the most recent preset number of segmented original byte sequences of the target port is greater than the preset interval threshold; Step S5: Under the effective configuration, the motherboard parses each port according to the corresponding protocol and converts it into unified format data and sends it to the management system, and maps the control instructions of the management system into target protocol frames and sends them down through the target port to realize multi-protocol bidirectional data interaction.

[0006] Furthermore, the port configuration proposal also includes a set of communication parameters and device addresses corresponding to the port identifier. The communication parameters include at least one or more of baud rate, parity check, data bits, and stop bits. The motherboard sets different protocol identifiers and corresponding communication parameters for different RS485 ports according to the port configuration proposal to achieve parallel access of multiple protocols.

[0007] Furthermore, the original frame buffer is a circular buffer. When the number of stored frames reaches the preset number, the earliest stored original frame byte sequence is overwritten by the newly received original frame byte sequence.

[0008] Furthermore, the replay verification is supplemented by at least one of address matching rate and field rationality pass rate, and the verification report includes the verification indicators and their comparison results with the preset threshold.

[0009] Furthermore, the shadow digest value is a digest value obtained by performing a digest operation on the parameter set of the shadow configuration, and the verification digest value is a digest value obtained by performing a digest operation on the verification indicators in the verification report; the motherboard only allows the atomic switch to be performed when the shadow digest value and verification digest value carried by the configuration submission command are consistent with the shadow digest value and verification digest value stored by the motherboard, and the switch is refused when either is inconsistent.

[0010] Furthermore, when the management system includes a cloud backend management system and a host computer management system, the preset arbitration rule includes: when the motherboard receives configuration submission instructions from the cloud backend management system and the host computer management system within a preset time window and the shadow digest values ​​carried by the two are inconsistent, the motherboard refuses to perform the atomic switch and returns conflict prompt information to the cloud backend management system and the host computer management system.

[0011] Furthermore, when the security switching window conditions are met, the motherboard suspends the target port's transmission and reception and clears the framing state associated with the old effective configuration before performing the atomic switch.

[0012] Furthermore, the unified format data includes a logical device identifier, a message type, and a service data field. The logical device identifier is generated by combining a port identifier, a device address, and a protocol identifier. The motherboard determines the target port and target protocol based on the logical device identifier to complete the mapping and distribution of the control command to the target protocol frame.

[0013] This invention also provides a multi-protocol data interaction system integrating cloud management and host computer control, including a motherboard and a management system, wherein the management system is a cloud backend management system or a host computer management system; the motherboard includes a processor and multiple independent serial ports, each corresponding to multiple RS485 ports and at least one RS232 port, the RS485 ports being used to connect to the fuel dispenser, and the RS232 ports being used for communication with the management system; the motherboard also includes a memory and program instructions executed by the processor, the program instructions being used to enable the motherboard to: establish management communication with the management system and report port information and the set of supported protocols; receive port configuration proposals sent by the management system, generate shadow configurations while keeping the effective configuration unchanged, and establish a raw frame buffer for the port corresponding to the port identifier in the port configuration proposal, the raw frame buffer storing a preset number of pre-divided raw frames in chronological order. The system generates a byte sequence and records the reception time and frame interval information for each original byte sequence. Based on the original frame buffer, it performs replay verification of the shadow configuration, generates a verification report, and generates a shadow digest value and a verification digest value. The replay verification is based at least on the verification pass rate and frame length consistency rate to determine the verification indicators. The system receives a configuration submission command according to preset arbitration rules. When the shadow digest value and verification digest value carried by the configuration submission command are consistent with the current shadow digest value and the current verification digest value, respectively, and the secure switching window condition is met, the shadow configuration is atomically switched to the effective configuration. The secure switching window condition includes at least a continuous preset idle time determination condition or a frame interval threshold determination condition. Under the effective configuration, each port is parsed according to the corresponding protocol and converted into unified format data, which is then sent to the management system. The control commands of the management system are mapped to target protocol frames and sent through the target ports to achieve multi-protocol bidirectional data interaction.

[0014] (III) Beneficial Effects: Compared with the prior art, the present invention provides a multi-protocol data interaction method and system that integrates cloud management and host computer control, which has the following beneficial effects: 1. The multi-protocol data interaction method and system that integrates cloud management and host computer control introduces shadow configuration while keeping the effective configuration unchanged, and performs caching and playback verification on the original frames of port communication. Before the new configuration officially takes effect, the protocol matching and communication parameter validity can be determined based on the real field frames, avoiding configuration errors or protocol mismatches from directly affecting the online link and causing communication interruption, thereby reducing the risk of unreadable device status, missing transaction data or control failure.

[0015] 2. The integrated cloud management and host computer control multi-protocol data interaction method and system generates shadow digest values ​​and verification digest values ​​and requires configuration submission commands to carry the digest values. The motherboard only allows switching when the digests are consistent. Furthermore, under preset arbitration rules, it performs consistency verification and conflict handling on submissions from the cloud backend management system and the host computer management system, which can effectively prevent repeated switching and unstable states caused by configuration competition, overwriting, or incorrect version submissions from different sources.

[0016] 3. This integrated cloud management and host computer control multi-protocol data interaction method and system sets a safe switching window condition based on port idle time or frame interval threshold, and performs atomic switching and necessary frame state cleanup when the safe switching window is met. This allows configuration switching to avoid high-frequency interaction phases, reduces disturbance to ongoing business processes and communication rhythms, improves the smoothness and reliability of the switching process, and thus reduces the probability of "downtime after modification" and business interference caused by switching. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the multi-protocol data interaction method for integrated cloud management and host computer control provided by the present invention.

[0018] Figure 2 A schematic diagram of the framework of the multi-protocol data interaction system for integrated cloud management and host computer control provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Please see Figure 1 , Figure 1This invention provides a flowchart illustrating a multi-protocol data interaction method integrating cloud management and host computer control. The method, applied to an intelligent communication control system, includes a motherboard and a management system, which is either a cloud-based backend management system or a host computer management system. The motherboard includes a processor and multiple independent serial ports, each corresponding to multiple RS485 ports and at least one RS232 port. The RS485 ports are connected to a fuel dispenser, and the RS232 ports are communicatively connected to the management system. The method includes: Step S1: The motherboard establishes management communication with the management system and reports port information and a set of supported protocols; Step S2: The motherboard receives a port configuration proposal from the management system, the proposal including at least a port identifier and a protocol identifier; The motherboard generates a shadow configuration while maintaining the effective configuration, and establishes an original frame buffer for the port corresponding to the port identifier. The original frame buffer stores a preset number of segmented original byte sequences in chronological order and records reception time information and frame interval information for each original byte sequence; Step S3: The motherboard performs playback verification on the shadow configuration based on the segmented original byte sequences in the original frame buffer. The process involves verifying and generating a verification report, as well as a shadow digest value and a verification digest value. The playback verification includes at least parsing and verifying the original byte sequence of the segmented frames according to the protocol corresponding to the shadow configuration, and determining verification indicators based at least on the verification pass rate and frame length consistency rate. The verification report is used to characterize whether the verification indicators meet a preset threshold. Step S4: The motherboard receives a configuration submission instruction according to preset arbitration rules. The configuration submission instruction carries a shadow digest value and a verification digest value. When the shadow digest value carried by the configuration submission instruction is consistent with the current shadow digest value, and the verification digest value carried by the configuration submission instruction is consistent with the current... When the previous verification digest values ​​are consistent and the secure switching window conditions are met, the motherboard atomically switches the shadow configuration to the effective configuration; wherein the secure switching window conditions include at least one of the following: the target port has not received the segmented original byte sequence within a continuous preset idle time, or the frame interval of the most recent preset number of segmented original byte sequences of the target port is greater than the preset interval threshold; Step S5: Under the effective configuration, the motherboard parses each port according to the corresponding protocol and converts it into unified format data and sends it to the management system, and maps the control instructions of the management system into target protocol frames and sends them down through the target port to realize multi-protocol bidirectional data interaction.

[0022] In this embodiment, the intelligent communication control system is designed for scenarios involving parallel access and centralized operation and maintenance of multi-manufacturer fuel dispensers at gas stations. The system consists of a motherboard, a cloud-based backend management system, and a host computer management system. The motherboard is centered around a processor, which employs a control chip with multiple hardware serial ports. The motherboard provides multiple independent serial port resources, each corresponding to multiple RS485 ports and at least one RS232 port. Each RS485 port connects to the fuel dispenser's side bus, and the RS232 port connects to the host computer management system via serial communication. The host computer management system and the cloud-based backend management system establish a data link through the station control network.

[0023] In step S1, after the motherboard powers on, it completes serial port initialization, establishes a management communication session with the host computer management system, and the host computer management system synchronizes the motherboard information to the cloud backend management system. The motherboard reports port information and the set of supported protocols. The port information includes at least the port identifier set PortID, port type, current port status, and port communication parameter range. The set of supported protocols includes at least the motherboard's fixed protocol identifier set ProtoID and the corresponding protocol version number. Through this reporting, the cloud backend management system and the host computer management system can constrain the port configuration interface, avoiding the distribution of configurations for non-existent ports or unsupported protocols.

[0024] In step S2, the cloud backend management system generates a port configuration proposal (ConfigProposal) and distributes it to the motherboard via the host computer management system. The ConfigProposal includes at least a port identifier (port_id) and a protocol identifier (proto_id), as well as a set of communication parameters and a set of device addresses corresponding to the port identifier. After receiving the ConfigProposal, the motherboard keeps the currently active configuration (ActiveConfig) unchanged and generates a shadow configuration (ShadowConfig) in memory. The shadow configuration is independent of the active configuration and is only used for candidate verification. The motherboard establishes a raw frame buffer (RawFrameBuffer) for the port corresponding to the port_id. The RawFrameBuffer stores a preset number of frames in chronological order. The original byte sequence of the frame Simultaneously, the reception time information is recorded for each frame. With frame interval information ,in The pre-framed raw byte sequence is formed using a timeout frame-breaking mechanism, with a frame-breaking threshold T_gap set. When no new bytes are received within the T_gap time, the received byte sequence is frozen into a frame and written to the RawFrameBuffer. The RawFrameBuffer is implemented using a circular queue, and is set... A new frame is written and overwrites the oldest frame to ensure that the cache continuously reflects the current communication rhythm and noise characteristics in the field.

[0025] In step S3, the motherboard performs replay verification on ShadowConfig based on the segmented raw byte sequence in RawFrameBuffer. The technical principle of replay verification is to call the parsing and verification rules of the corresponding protocol of ShadowConfig without changing ActiveConfig. Offline parsing and verification are performed, using CRC checksum set to CRC-16. The motherboard counts the number of replay sample frames. Count the number of frames that pass CRC check. The pass rate of the verification was obtained. Simultaneously, the frame length consistency is determined according to the shadow protocol rules, and the number of frames with consistent length is counted. Resulting in frame length consistency rate The verification metrics are... and Composition, motherboard setting threshold and The thresholds are set as follows: , ,when and The shadow configuration is then determined to have passed replay verification. The motherboard generates a ValidationReport, which includes at least port_id, proto_id, and , , The threshold parameters and the pass / fail judgment results are as follows. To achieve configuration version binding, the motherboard generates a ShadowDigest value and a VerifyDigest value. ShadowDigest is obtained by encoding the parameter set of the shadow configuration in a fixed order and then performing a digest operation. The fixed order includes port_id, proto_id, baud rate, parity mode, data bits, stop bits, and device address set. The digest operation uses SHA-256. VerifyDigest is obtained by encoding the key verification indicators in the verification report in a fixed order and then performing SHA-256. The key verification indicators include... , , Threshold parameters and judgment results. The motherboard sends ValidationReport, ShadowDigest, and VerifyDigest to the host computer management system, which then synchronizes them to the cloud backend management system, enabling verifiable confirmation of the configuration before it goes live.

[0026] In step S4, after the host computer management system confirms the configuration submission through the cloud backend management system, it sends a configuration submission command, CommitCmd, to the mainboard. CommitCmd carries ShadowDigest and VerifyDigest. The mainboard processes the submission command according to preset arbitration rules. The arbitration rules are set as follows: when the same port receives submission requests from both the cloud backend management system and the host computer management system within a preset time window and the ShadowDigest is inconsistent, the switchover is rejected and a conflict warning is returned; when the submission command originates from a single source and carries a ShadowDigest that matches the current ShadowDigest and a VerifyDigest that matches the current VerifyDigest, the switchover process begins. The mainboard employs a secure switchover window condition to reduce service disruption. The secure switchover window condition simultaneously satisfies the following two conditions: the target port's continuous idle time is not less than... The target port is recently The frame interval of all frames is greater than ;in Set to 800ms Set to 5. Set to 120ms. After the safe handover window conditions are met, the motherboard performs an atomic handover, replacing ShadowConfig with ActiveConfig in one go. During the handover process, the target port's send and receive operations are paused for a fixed short interval. , Set to 20ms and clear the residual frame state and protocol parsing state machine related to the old effective configuration, then resume transmission and reception to ensure that parsing starts from the synchronization point of the new protocol after the switch, avoiding misjudgments and anomalies caused by half-frame residue.

[0027] In step S5, the motherboard, under the ActiveConfig configuration, performs online parsing of each RS485 port and converts the parsing results into a unified format data UDM, which is then sent to the host computer management system. The host computer management system synchronizes this data with the cloud backend management system. The UDM includes at least a logical device identifier. Message type Business data field payload Generated by a combination of port identifier, device address, and protocol identifier, it is used to uniquely identify logical entities with multiple ports, multiple devices, and multiple protocols. When the management system issues control commands, the control commands adopt a unified command semantic structure, and the motherboard... The process involves determining the target port and target protocol, executing command mapping and frame encapsulation, generating a target protocol frame, and sending it to the corresponding fuel dispenser via the target port. Simultaneously, it receives response frames and converts them into UDM (Unified Device Management) frames for backhaul. In a field example, Ports 1 to 4 within the station connect to fuel dispensers from manufacturers A and B respectively, while Port 5 newly connects to a fuel dispenser from manufacturer C. After the cloud backend issues a Port 5 protocol configuration proposal, the mainboard first caches the original Port 5 communication frames and performs replay verification. Upon successful verification, an atomic switch is completed within a safe window that meets the idle and frame interval conditions. Subsequently, the manufacturer C protocol frame is parsed into a unified format for transaction status and metering data, which is then uploaded. Cloud query, reset, and other control commands are mapped to manufacturer C target protocol frames and sent down, thereby achieving stable parallel access and consistent operation and maintenance control for multiple manufacturers' devices.

[0028] Furthermore, the port configuration proposal also includes a set of communication parameters and device addresses corresponding to the port identifier. The communication parameters include at least one or more of baud rate, parity check, data bits, and stop bits. The motherboard sets different protocol identifiers and corresponding communication parameters for different RS485 ports according to the port configuration proposal to achieve parallel access of multiple protocols.

[0029] In this embodiment, the port configuration proposal ConfigProposal, in addition to including the port identifier port_id and the protocol identifier proto_id, further carries the communication parameter CommParam corresponding to port_id and the device address set AddrSet. This is used to configure different RS485 ports on the same motherboard to the communication modes required by different manufacturers' fuel dispensers, thereby achieving parallel access of multiple protocols. The communication parameter CommParam includes at least one or more of the following: baud rate (Baud), parity, data bits (DataBits), and stop bits (StopBits). In this embodiment, CommParam is represented by a four-tuple. Parity uses one of three parity types: no parity, odd parity, or even parity. DataBits is set to 8 bits, and StopBits is set to 1 or 2 bits. The device address set AddrSet is used to limit the range or list of device addresses that can communicate on the same port. AddrSet is represented as a discrete set. It can also be represented in interval form. The motherboard uses this information to address and route multiple devices within the port.

[0030] In terms of application, the cloud backend management system generates and distributes multi-port configuration proposals based on the list of devices accessed within the site, for example, configuring Port1 as the ProtoA protocol. , Connect three fuel dispensers from manufacturer A; configure Port2 to use the ProtoB protocol. , Connect two fuel dispensers from manufacturer B; configure Port3 as Protocol ProtoC. , The system connects to a fuel dispenser from manufacturer C. Upon receiving the data, the motherboard writes the protocol identifier and communication parameters for each port into its corresponding configuration item based on the port_id. It also independently sets the underlying serial port parameters for each RS485 port, allowing different ports to operate simultaneously at different baud rates and parity methods, avoiding protocol conflicts caused by traditional single-bus, single-parameter configurations. Simultaneously, the motherboard binds the AddrSet to the protocol parsing logic to filter frames outside the port's address range and select the correct target address when control commands are issued.

[0031] Furthermore, the original frame buffer is a circular buffer. When the number of stored frames reaches the preset number, the earliest stored original frame byte sequence is overwritten by the newly received original frame byte sequence.

[0032] In this embodiment, the RawFrameBuffer established for each port is implemented using a circular buffer structure to continuously retain the latest communication samples under limited storage resources, thereby supporting the playback verification and handover determination of the shadow configuration. The circular buffer consists of a length of... The storage units are composed of In this embodiment, the preset quantity is used. The configuration value should be between 256 and 1024, depending on the motherboard's memory capacity and the port's frame rate. Each memory unit is used to store one frame of raw byte sequence. and its receiving time information and frame interval information .

[0033] Setting write pointers in a circular buffer With read pointer Write pointer Indicates the position for writing the next frame. After port framing is complete, the motherboard writes the newly received original byte sequence of the already framed data into the memory. Simultaneously write the corresponding and and will according to Update. When the storage quantity reaches the preset quantity. back, Wrapping back to the starting position, the newly written frame will overwrite the oldest stored frame, thus ensuring that the buffer always retains the original communication samples of the most recent N frames. To avoid read anomalies caused by overwriting, this embodiment marks the current valid frame range of the buffer with a snapshot when playback verification is triggered. Playback verification reads sample frames within the snapshot range, and the write pointer continues to write new frames according to the above rules, ensuring that online transmission and reception are not blocked.

[0034] The advantages of using a circular buffer are: firstly, the buffer content is dynamically updated according to the on-site communication status, reflecting the latest protocol frame structure and link noise characteristics, thus improving the representativeness of replay verification; secondly, the storage space is fixed and controllable, avoiding buffer bloat due to long-term operation; and thirdly, the strategy of covering the earliest frames ensures that the system maintains real-time performance even in high-frame-rate port scenarios. Those skilled in the art can select the appropriate buffer based on the upper limit of port frame length, the number of ports, and the memory capacity. The specific values ​​are determined, and a circular buffer is implemented according to the write pointer wrap-around mechanism.

[0035] Furthermore, the replay verification is supplemented by at least one of address matching rate and field rationality pass rate, and the verification report includes the verification indicators and their comparison results with the preset threshold.

[0036] In this embodiment, the pass rate is used as the benchmark. Consistency with frame length Assuming the basic verification metrics are met, replay verification further incorporates address matching rate. With field reasonableness pass rate At least one of the above supplements the verification conclusion, thereby improving the ability to identify boundary cases such as "correct protocol selection but inconsistent parameters or addressing" and "parsing is successful but semantic fields are abnormal," and reducing the probability of misjudging a configuration as usable. When the motherboard performs offline parsing of the original frame buffer sample, it extracts the address field from the parsing result. With key field set And perform matching and reasonableness judgment respectively.

[0037] Address matching rate This is used to characterize the consistency between the address field of the sample frame and the device address set AddrSet in the port configuration. (This is based on the total number of sample frames.) Statistical satisfaction Frame count ,but In this embodiment, when multiple devices are connected to the port, AddrSet can be a discrete set, and the motherboard determines its behavior based on set inclusion relationships; when only a single device is connected to the port, AddrSet is a single-element set. It can effectively identify the "frame verification passes but device does not respond" problem caused by a mismatch between the configured address and the actual on-site address. Threshold Based on the distribution of on-site equipment, this embodiment... The value should be between 0.85 and 0.98, and preferably above 0.95 when AddrSet is a single-element set.

[0038] Field validity pass rate This is used to characterize whether the key fields after parsing meet preset physical or enumeration reasonableness constraints. The motherboard has preset field constraint tables for different protocol types; for example, it sets non-negativity and upper limit constraints for measurement fields, enumeration range constraints for status fields, and incrementing or wraparound constraints for time fields. (The last sentence appears to be incomplete and possibly refers to a separate, unrelated statement about total number of sample frames.) Count the number of frames that satisfy the field constraints. ,but In this embodiment, the field constraint table is loaded with the protocol identifier as the index. It is not required to model all fields. Only a few key fields that can reflect the stability of business status need to be constrained, such as amount, volume, transaction status code, fault code, etc.

[0039] The validation indicators are formed using a stratified judgment method: firstly, it requires... and Reaching the threshold respectively , Further requests Reaching the threshold ,or Reaching the threshold ,in Use values ​​between 0.90 and 0.99. The ValidationReport generated by the motherboard includes... , In addition, supplementary indicators are also included. and It also clearly provides the comparison results of each indicator with its corresponding threshold, for example, by using a "satisfied / unsatisfied" flag, or by using a comparison result field. This allows the management system to intuitively obtain the criteria for passing and the reasons for failing candidate configurations, supporting maintenance personnel to make targeted parameter corrections and re-verifications.

[0040] Furthermore, the shadow digest value is a digest value obtained by performing a digest operation on the parameter set of the shadow configuration, and the verification digest value is a digest value obtained by performing a digest operation on the verification indicators in the verification report; the motherboard only allows the atomic switch to be performed when the shadow digest value and verification digest value carried by the configuration submission command are consistent with the shadow digest value and verification digest value stored by the motherboard, and the switch is refused when either is inconsistent.

[0041] In this embodiment, to bind the shadow configuration version with the replay verification result and avoid inconsistencies such as incorrect version submission, duplicate submission, or submission after tampering during the configuration submission process, the motherboard generates a ShadowDigest value and a VerifyDigest value for the shadow configuration and verification report, respectively, and uses both as admission verification conditions for atomic switching. The ShadowDigest value is used to uniquely identify a version of the shadow configuration, and the VerifyDigest value is used to uniquely identify the replay verification conclusion corresponding to the shadow configuration, ensuring that "submission effective" necessarily corresponds to "verified version".

[0042] The ShadowDigest value is obtained by encoding the set of parameters in the shadow configuration according to a fixed field order and then performing a digest operation. In this embodiment, the set of shadow configuration parameters includes at least the port identifier port_id, the protocol identifier proto_id, the communication parameter CommParam, and the device address set AddrSet. To ensure consistency across different system implementations, the motherboard serializes the fields using a fixed order and fixed encoding rules. For example, a byte sequence is generated according to the sequence Sshadow=[port_id,proto_id,Baud,Parity,DataBits,StopBits,AddrSet], and then a digest operation is performed on the byte sequence to obtain the ShadowDigest. The VerifyDigest value is obtained by encoding the set of verification indicators in the verification report according to a fixed field order and then performing a digest operation. In this embodiment, a byte sequence is generated according to the sequence Sverify=[M,R_crc,R_len,R_addr,R_plaus,T_crc,T_len,T_addr,T_plaus], and then a digest operation is performed to obtain the VerifyDigest. The digest operation uses a fixed algorithm for engineering reproduction. In this embodiment, SHA-256 is used, and the output digest value is 256 bits in length. The motherboard saves it in the form of a hexadecimal string or a binary array.

[0043] In terms of application, after completing playback verification, the motherboard sends a verification report to the management system and simultaneously sends ShadowDigest and VerifyDigest. Upon confirmation of effectiveness, the management system sends a configuration commit command (CommitCmd), which carries at least ShadowDigest and VerifyDigest. Upon receiving CommitCmd, the motherboard performs two consistency checks: first, the ShadowDigest carried by CommitCmd matches the ShadowDigest currently stored on the motherboard; second, the VerifyDigest carried by CommitCmd matches the VerifyDigest currently stored on the motherboard. Only when both consistency checks are satisfied simultaneously will the motherboard allow entry into the secure handover window for judgment and execution of an atomic handover; if either is inconsistent, the motherboard refuses the handover and returns a rejection reason identifier, such as "Shadow Digest Inconsistency" or "Verification Digest Inconsistency." The mechanism serves several purposes: when the management system reissues a new port configuration proposal after verification, causing changes to the shadow configuration, the old CommitCmd will fail verification, thus preventing the unverified new shadow configuration from being mistakenly switched to the effective configuration; when replay or accidental triggering in the communication link leads to duplicate submissions, the motherboard can perform idempotent processing based on version consistency because the digest value is bound to a specific version; when the verification report or configuration parameters are abnormally modified, the change in the digest value will trigger a consistency failure, thereby preventing risky configurations from going live.

[0044] Furthermore, when the management system includes a cloud backend management system and a host computer management system, the preset arbitration rule includes: when the motherboard receives configuration submission instructions from the cloud backend management system and the host computer management system within a preset time window and the shadow digest values ​​carried by the two are inconsistent, the motherboard refuses to perform the atomic switch and returns conflict prompt information to the cloud backend management system and the host computer management system.

[0045] In this embodiment, to address the potential configuration contention, overlap, and repeated switching issues that may arise when the cloud backend management system and the host computer management system coexist, the motherboard introduces a preset arbitration rule in step S4. This rule aggregates configuration submission commands on the same port within a time window and determines consistency, thereby ensuring the determinism and traceability of the configuration activation process. The technical principle of this arbitration rule is as follows: the "submission action" is limited to the confirmation of the same version of the shadow configuration. If different management terminals submit different versions of the shadow configuration to the same port within a short period of time, it is considered a conflict and switching is prohibited, thus avoiding the deployment of configurations that have not been uniformly confirmed online.

[0046] In practice, the motherboard maintains a WindowCommit monitoring window for each port and sets a preset time window. , For example Set to 3s to 10s, in this embodiment Take 5 seconds. The motherboard receives the configuration submission command from the cloud backend management system. Record its arrival time. With the shadow summary value carried Upon receiving the configuration submission command from the host computer management system Record its arrival time. With the shadow summary value carried If satisfied ,and If a conflict occurs, the motherboard determines it as a conflict submission, refuses to perform the atomic switch, and generates a conflict message (ConflictInfo) which is returned to the cloud backend management system and the host computer management system. ConflictInfo includes at least the port identifier (port_id), the conflict type identifier (conflict_type), two shadow digest values, the timestamp of the conflict occurrence, and a suggested action identifier, such as "Please resubmit after unifying the configuration version." The motherboard simultaneously maintains its current effective configuration and keeps the shadow configuration in a pending confirmation state to allow the management side to further negotiate or reissue the configuration proposal.

[0047] In terms of application, conflicts typically occur when on-site maintenance personnel temporarily modify port parameters using a host computer, while the cloud backend simultaneously issues remote policy updates. For example, the cloud backend submits shadow configuration version A to Port3, carrying... The on-site host computer submits shadow configuration version B to Port3, carrying... The arrival interval between the two is less than and If the port switches repeatedly, the motherboard will refuse to switch and simultaneously notify both ends of the conflict. Based on this, the cloud and the host computer can choose to have the host computer cancel the local parameter changes and resynchronize the cloud configuration, or have the cloud confirm the adoption of the host computer version and regenerate a unified configuration proposal and verification process, thereby avoiding communication interruptions and service disruptions caused by multiple port switches in a short period of time.

[0048] Furthermore, when the security switching window conditions are met, the motherboard suspends the target port's transmission and reception and clears the framing state associated with the old effective configuration before performing the atomic switch.

[0049] In this embodiment, to reduce the disturbance to online communication caused by configuration switching and to avoid problems such as half-frame residue, incorrect framing, and misparsing during the switching process, the motherboard, after determining that the safe switching window conditions are met, completes the port switching control in the order of "pausing transmission and reception, clearing the old state, and then performing atomic switching." The technical principle of this process is as follows: Multi-protocol serial communication usually relies on a framing state machine to divide a continuous byte stream into frame structures. If the residual framing buffer, timeout counter, frame header matching state, etc. formed under the old effective configuration are directly brought into the new protocol parser, it will cause the new protocol parser to start working from the error boundary, resulting in continuous verification failures, address misjudgments, or even output of abnormal service fields. By explicitly pausing transmission and reception and clearing the old state during switching, it can be ensured that the new effective configuration enters synchronization from a consistent initial state, improving the speed and stability after switching.

[0050] After the target port meets the safe switching window conditions, the motherboard first sets the PauseFlag on that port, causing the serial port receive interrupt and DMA receive callback to enter discard mode, thus pausing the target port's transmit and receive duration. In this embodiment The timeout period is set to 10ms to 50ms, with 20ms being preferred. During the pause, the motherboard does not send protocol frames outwards and does not enter the framing state machine for input bytes, avoiding the generation of new half-frame data during the switch. Subsequently, the motherboard clears the framing states associated with the old effective configuration. These framing states include at least the residual bytes in the receive buffer, frame header matching status, length field parsing status, timeout counter, frame check intermediate variables, continuous error counter, and acknowledgment waiting status associated with the old protocol. After the clearing action is completed, the motherboard performs an atomic switch, replacing the shadow configuration with the effective configuration in one go, resetting the initial state of the new protocol parser, and restoring the serial port parameters and port protocol binding relationship. Finally, the motherboard cancels the PauseFlag and resumes transmission and reception, enabling the target port to start receiving and parsing frame data according to the new effective configuration.

[0051] In terms of application, for example, when Port5 switches from an old protocol version to a new protocol version, if old frame remnants are not cleared, an incomplete byte sequence received under the old protocol may be mistakenly treated as a frame header by the new protocol parser, leading to continuous verification failures and triggering retries, resulting in communication unavailability for a short period after the switch. With the pause and clear strategy of this embodiment, the switchover action occurs within the port's idle window, and new byte stream input is blocked before the switchover. The old remnant state is thoroughly cleared, and the new protocol parser resynchronizes from an empty state. Normal transmission and reception can be restored in a relatively short time after the switchover.

[0052] Furthermore, the unified format data includes a logical device identifier, a message type, and a service data field. The logical device identifier is generated by combining a port identifier, a device address, and a protocol identifier. The motherboard determines the target port and target protocol based on the logical device identifier to complete the mapping and distribution of the control command to the target protocol frame.

[0053] In this embodiment, to achieve unified uploading and unified control under the condition of parallel access of multiple vendor protocols, the motherboard converts the parsing results of each port into a unified format data UDM, which includes at least a logical device identifier. Message type The business data field payload includes: The logical device identifier, used to uniquely identify "which device on which port, and which protocol," enabling the management system to perform device-level management and command issuance even without understanding the details of various manufacturers' protocols; the message type, used to describe the semantic category of the data; and the business data field, used to carry specific content such as metering, status, alarms, and transactions.

[0054] Logical device identifier It is generated by combining the port identifier (port_id), device address (addr), and protocol identifier (proto_id). This embodiment uses a fixed-format encoding method, and the encoding sequence is as follows: The `port_id` is a unique identifier in the motherboard port resource table, `addr` is a specific address within the device address set defined in the port configuration proposal, and `proto_id` is the protocol identifier of the currently active port configuration. Encoding can be done via string concatenation or fixed-length field concatenation. This embodiment uses fixed-length field concatenation: `port_id` occupies 1 byte, `addr` occupies 1 to 2 bytes, and `proto_id` occupies 1 byte, generating a fixed-length or variable-length binary identifier, which is then uploaded in hexadecimal format for storage and retrieval. When the motherboard parses the protocol frame, it obtains `addr` from the address field within the frame and reads the currently active port configuration to obtain `proto_id`, thus generating the corresponding... This information is written into the UDM header, allowing the same management system to process messages from different protocol ports simultaneously without confusion.

[0055] Message Type Using a pre-defined enumeration, this embodiment includes at least the following types: status reporting, transaction data, parameter read response, alarm events, and heartbeats. The business data field payload uses a key-value pair structure or a fixed-length structure; this embodiment uses a key-value pair structure. Field names are standardized semantic names, such as amount, volume, price, transaction status, and fault code. Field values ​​are filled by the motherboard according to the field mapping rules of each manufacturer's protocol. Through this standardization, the cloud backend management system and the host computer management system can use the same data model to complete display, storage, alarm threshold judgment, and report statistics.

[0056] During the control issuance process, the management system sends a control command (Cmd), which must contain at least the target logical device identifier. The control action, which can include actions such as querying status, reading parameters, resetting, and starting / stopping, has a unified semantics. The motherboard receives the Cmd and then... Perform route resolution for the index: From The port_id, addr, and proto_id can be obtained by parsing, or by querying the local mapping table. The corresponding port_id and proto_id are used to determine the target port and target protocol. The motherboard then selects the corresponding protocol's command wrapper based on the proto_id, maps the action and parameters to the target protocol frame Frame_cmd, and writes the addr into the address field of the target protocol frame. Finally, it sends the frame to the corresponding refueling machine via the target port. After the refueling machine returns a response frame, the motherboard parses it using the same proto_id and generates a UDM response, which is then sent upwards.

[0057] For example, if Port2 connects to two fuel dispensers from manufacturer B, with device addresses 10 and 11 respectively and the protocol identifier being ProtoB, then the motherboard will generate... They are respectively and The management system to The motherboard issues a "Query Transaction Status" command, which routes to Port2 and encapsulates the query frame using ProtoB, writes it to address 10, and sends it. After receiving the response, it parses the status code and fills the payload with the unified field "state" and sends it up.

[0058] Please see Figure 2 , Figure 2This invention provides a framework diagram of a multi-protocol data interaction system integrating cloud management and host computer control. The system includes a motherboard and a management system, which is either a cloud-based backend management system or a host computer management system. The motherboard includes a processor and multiple independent serial ports, each corresponding to multiple RS485 ports and at least one RS232 port. The RS485 ports are used to connect to a fuel dispenser, and the RS232 ports are used for communication with the management system. The motherboard also includes a memory and program instructions executed by the processor. These instructions enable the motherboard to: establish management communication with the management system and report port information and a set of supported protocols; receive port configuration proposals sent by the management system; generate shadow configurations while maintaining the effective configuration; and establish a raw frame buffer for the port corresponding to the port identifier in the port configuration proposal. The region stores a preset number of original byte sequences of pre-defined frames in chronological order, and records the reception time information and frame interval information for each original byte sequence; based on the original frame buffer, the shadow configuration is replayed and verified, a verification report is generated, and a shadow digest value and a verification digest value are generated, wherein the replay verification is based at least on the verification pass rate and frame length consistency rate to determine the verification indicators; a configuration submission instruction is received according to a preset arbitration rule, and when the shadow digest value and verification digest value carried by the configuration submission instruction are consistent with the current shadow digest value and the current verification digest value, respectively, and the security switching window condition is met, the shadow configuration is atomically switched to the effective configuration, wherein the security switching window condition includes at least a continuous preset idle time determination condition or a frame interval threshold determination condition; under the effective configuration, each port is parsed according to the corresponding protocol and converted into unified format data and sent to the management system, and the control instructions of the management system are mapped into target protocol frames and sent down through the target ports to realize multi-protocol bidirectional data interaction.

[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0060] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-protocol data interaction method integrating cloud management and host computer control, applied to an intelligent communication control system, wherein the system includes a motherboard and a management system, the management system being a cloud-based backend management system or a host computer management system; the motherboard includes a processor and multiple independent serial ports, each independent serial port corresponding to multiple RS485 ports and at least one RS232 port, the RS485 ports being connected to a fuel dispenser, and the RS232 ports being communicatively connected to the management system, characterized in that... The method includes: Step S1, the motherboard establishes management communication with the management system and reports port information and a set of supported protocols; Step S2, the motherboard receives a port configuration proposal sent by the management system, the port configuration proposal including at least a port identifier and a protocol identifier; the motherboard generates a shadow configuration while keeping the effective configuration unchanged, and establishes an original frame buffer for the port corresponding to the port identifier, the original frame buffer storing a preset number of segmented original byte sequences in chronological order, and recording reception time information and frame interval information for each original byte sequence; Step S3, the motherboard performs playback verification on the shadow configuration based on the segmented original byte sequences in the original frame buffer, generates a verification report, and generates a shadow digest value and a verification digest value, wherein the playback verification includes at least parsing and verifying the segmented original byte sequences according to the protocol corresponding to the shadow configuration, and determining verification indicators based at least on the verification pass rate and frame length consistency rate. The verification report is used to characterize whether the verification indicators meet the preset threshold; Step S4: The motherboard receives the configuration submission instruction according to the preset arbitration rules. The configuration submission instruction carries a shadow digest value and a verification digest value; When the shadow digest value carried by the configuration submission instruction is consistent with the current shadow digest value, and the verification digest value carried by the configuration submission instruction is consistent with the current verification digest value, and the security switching window condition is met, the motherboard atomically switches the shadow configuration to the effective configuration; The security switching window condition includes at least one of the following: the target port has not received the segmented original byte sequence within a continuous preset idle time, or the frame interval of the most recent preset number of segmented original byte sequences of the target port is greater than the preset interval threshold; Step S5: Under the effective configuration, the motherboard parses each port according to the corresponding protocol and converts it into unified format data and sends it to the management system, and maps the control instructions of the management system into target protocol frames and sends them down through the target port to realize multi-protocol bidirectional data interaction.

2. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: The port configuration proposal also includes a set of communication parameters and device addresses corresponding to the port identifier. The communication parameters include at least one or more of baud rate, parity check, data bits, and stop bits. The motherboard sets different protocol identifiers and corresponding communication parameters for different RS485 ports according to the port configuration proposal to achieve parallel access of multiple protocols.

3. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: The original frame buffer is a circular buffer. When the number of stored frames reaches the preset number, the earliest stored original frame byte sequence is overwritten by the newly received original frame byte sequence.

4. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: The replay verification is further supplemented by the verification indicators based on at least one of address matching rate and field rationality pass rate, and the verification report includes the verification indicators and their comparison results with the preset threshold.

5. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: The shadow digest value is a digest value obtained by performing a digest operation on the parameter set of the shadow configuration, and the verification digest value is a digest value obtained by performing a digest operation on the verification indicators in the verification report. The motherboard only allows the atomic switch to be performed when the shadow digest value and verification digest value carried by the configuration submission command are consistent with the shadow digest value and verification digest value stored by the motherboard, and refuses to switch if either is inconsistent.

6. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that, When the management system includes a cloud backend management system and a host computer management system, the preset arbitration rule includes: when the motherboard receives a configuration submission instruction from the cloud backend management system and the host computer management system within a preset time window and the shadow digest values ​​carried by the two are inconsistent, the motherboard refuses to perform the atomic switch and returns a conflict prompt message to the cloud backend management system and the host computer management system.

7. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: When the security switching window conditions are met, the motherboard suspends the target port's transmission and reception and clears the framing status associated with the old effective configuration before performing the atomic switch.

8. The multi-protocol data interaction method for integrated cloud management and host computer control according to claim 1, characterized in that: The unified format data includes a logical device identifier, a message type, and a service data field. The logical device identifier is generated by combining a port identifier, a device address, and a protocol identifier. The motherboard determines the target port and target protocol based on the logical device identifier to complete the mapping and distribution of the control command to the target protocol frame.

9. A multi-protocol data interaction system integrating cloud management and host computer control, characterized in that, The system includes a motherboard and a management system, wherein the management system is a cloud-based backend management system or a host computer management system. The motherboard includes a processor and multiple independent serial ports, each corresponding to multiple RS485 ports and at least one RS232 port. The RS485 ports are used to connect to the fuel dispenser, and the RS232 ports are used to communicate with the management system. The motherboard also includes a memory and program instructions executed by the processor. The program instructions enable the motherboard to: establish management communication with the management system and report port information and a set of supported protocols; receive port configuration proposals sent by the management system, generate shadow configurations while keeping the effective configuration unchanged, and establish a raw frame buffer for the port corresponding to the port identifier in the port configuration proposal. The raw frame buffer stores a preset number of pre-defined framed raw byte sequences in chronological order and records the reception time information and frame interval information for each raw byte sequence; perform playback verification of the shadow configuration based on the raw frame buffer, generate a verification report, and generate a shadow digest value and a verification digest value, wherein the playback verification is based at least on the verification pass rate and frame length consistency rate to determine the verification indicators. The configuration submission instruction is received according to the preset arbitration rules. When the shadow digest value and verification digest value carried by the configuration submission instruction are consistent with the current shadow digest value and the current verification digest value and the security switching window condition is met, the shadow configuration is atomically switched to the effective configuration. The security switching window condition includes at least the continuous preset idle time determination condition or the frame interval threshold determination condition. Under the active configuration, each port is parsed according to the corresponding protocol and converted into data in a unified format and sent to the management system. The control commands of the management system are mapped into target protocol frames and sent down through the target port to realize bidirectional data interaction of multiple protocols.

Images