Method and system for remote transmission of high-speed rail public network distribution box with sub-user metering operator equipment

Abstract

This application relates to railway power distribution technology and smart energy metering technology. A method for remote transmission of metering data from a high-speed rail public network distribution box to a sub-user metering operator includes: periodically collecting metering data from the metering equipment in the high-speed rail public network distribution box, obtaining the power data of each metering device, wherein the identifier of the metering device is bound to the operator to form a corresponding relationship; concatenating the identifier with the corresponding power data to form power data specific to the operator, and encrypting it to form encrypted data; storing the encrypted data; and transmitting it to the cloud space within a preset time period to obtain a transmission result, wherein the transmission result indicates that the operator, after receiving the encrypted data in the cloud space, feeds back data to the distribution box, and the feedback data includes received, not received, or partially received; when the transmission result includes not received or partially received, the channel is adjusted and the encrypted data is retransmitted.

Description

Technical Field

[0001] This application relates to the fields of railway power distribution technology and intelligent power metering technology. Specifically, it relates to a method and system for remote transmission of metering equipment for sub-users in a high-speed railway public network power distribution box. Background Technology

[0002] Currently, high-speed rail public network power distribution boxes generally adopt a deployment mode where multiple operators share the same box. Each operator has an independent meter inside the box, and power consumption data is aggregated and transmitted remotely through a single data acquisition gateway. However, this approach has significant technical shortcomings in practical application. Firstly, the data acquisition gateway within the box only performs simple data aggregation and forwarding, lacking a mechanism to assign independent and reliable identifiers to the metering data of each operator. When discrepancies such as power consumption statistical deviations or data gaps occur after transmission to the platform, it is impossible to trace the original data status at the source in the distribution box. It is difficult to determine whether the issue stems from metering anomalies, gateway acquisition errors, or data loss or tampering during transmission. This directly leads to ambiguity in the division of responsibilities between railway maintenance personnel and various operators, affecting the fairness of user-specific billing and settlement.

[0003] Based on the shortcomings of the existing technologies, there is an urgent need for a method and system for remote transmission of metering equipment for operators connected to the public power distribution box of high-speed railways. Summary of the Invention

[0004] The main objective of this application is to provide a method and system for remote transmission of metering equipment for sub-users in a high-speed railway public network power distribution box, in order to solve the technical problems in the background art.

[0005] To achieve the above objectives, the first aspect of this application proposes a method for remote transmission of metering equipment for individual users in a high-speed rail public network distribution box, comprising: Periodically collect metering data from the power distribution boxes of high-speed rail public networks in rail transit to obtain power data for each metering device. The identifier of each metering device is bound to the operator to form a corresponding relationship. The identifier is concatenated with the corresponding power data to form power data specific to the operator, and then encrypted to form encrypted data. The encrypted data is stored and sent to the cloud space within a preset time period to obtain a sending result. The sending result indicates that after the operator receives the encrypted data in the cloud space, it feeds back data to the distribution box. The feedback data includes whether the data was received, not received, or partially received. If the transmission result includes "not received" and "partially received", then the channel is adjusted and the encrypted data is retransmitted.

[0006] In some feasible methods, the step of periodically collecting metering equipment data from the high-speed rail public network power distribution boxes in rail transit to obtain the power data of each metering device includes: Each metering device is configured with a unique identifier, and the identifier is bound to the operator to form a mapping table; Periodically collect metering data from the power distribution boxes of high-speed rail public networks in rail transit, and store the collected power data in correspondence with the identifier to obtain the power data of each metering device.

[0007] In some feasible methods, the step of concatenating the identifier with the corresponding power data to form dedicated operator power data and encrypting it to form encrypted data includes: Based on the identifier, the power data is determined and concatenated to obtain an identifier-power data pair; According to the agreement with the operator, the corresponding encryption algorithm is invoked to encrypt the identifier-battery data pair, thereby obtaining encrypted data.

[0008] In some feasible methods, the step of encrypting the identifier-battery data pair by invoking the corresponding encryption algorithm according to the agreement with the operator to obtain encrypted data includes: Based on the agreement with the operator, construct a data encryption algorithm library corresponding to the operator; Based on the encryption algorithm used for the next transmission carried in the previous operator's feedback data, the current identifier-battery data pair is encrypted to obtain encrypted data.

[0009] In some implementable methods, the step of encrypting the current identifier-battery data pair based on the encryption algorithm used for the next transmission carried in the previous operator's feedback data to obtain encrypted data includes: The identifier-battery data pair of each operator is encrypted to form encrypted data for each operator; Each operator's encrypted data is packaged into encrypted data.

[0010] In some feasible methods, the steps of storing the encrypted data and sending it to the cloud within a preset time period to obtain the sending result include: Encrypted data for each operator is stored separately; A data trust verification code is generated using a hash algorithm. Encrypted data carrying the data trust verification code is sent to the cloud space within a preset time period. The sending result indicates that after the operator verifies the data trust verification code in the cloud space, it decrypts the encrypted data using an encryption algorithm and receives the encrypted data, providing feedback on whether the data was received, not received, or partially received.

[0011] In some implementable methods, the step of adjusting the channel and retransmitting the encrypted data when the transmission result includes both non-received and partially received data includes: If the transmission result includes "not received" and "partially received", the channel with the best communication quality is selected from the preset rail transit dedicated backup channel pool to complete the channel switching, and the encrypted data is retransmitted.

[0012] Secondly, this application provides a remote transmission system for high-speed rail public network power distribution boxes with sub-user metering operator equipment, applied to the aforementioned remote transmission method for high-speed rail public network power distribution boxes with sub-user metering operator equipment. The system includes: The data acquisition unit is used to periodically collect data from the metering devices of the high-speed rail public network power distribution boxes in rail transit, and obtain the power data of each metering device. The identifier of each metering device is bound to the operator to form a corresponding relationship. An encryption unit is used to concatenate the identifier with the corresponding power data to form power data specific to the operator, and then encrypt the data to form encrypted data. A sending unit is used to store the encrypted data and send it to the cloud space within a preset time period to obtain a sending result. The sending result represents feedback data in response to the operator receiving the encrypted data in the cloud space. The received data includes received, not received, or partially received. The result unit is used to adjust the channel and retransmit the encrypted data when the transmission result includes "not received" and "partially received".

[0013] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the aforementioned method.

[0014] Fourthly, this application provides a computer program that, when executed by a processor, implements the steps of the aforementioned method.

[0015] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application discloses a method for remote transmission of metering data from a high-speed rail public network distribution box to multiple operators. By binding the metering equipment to the operator, and by using a dedicated splicing and encryption process for the identifier and electricity data, this method effectively solves the technical defects of existing high-speed rail public network distribution boxes shared by multiple operators. These defects include the lack of independent and reliable identifiers for data, difficulty in tracing the source, and unclear definition of responsibility. Simultaneously, encrypted storage ensures data authenticity and security. Combined with a transmission result feedback and channel adjustment retransmission mechanism, this method improves the reliability of remote data transmission, ensuring accurate and traceable electricity data from operators, clarifying the responsibility boundaries between railway maintenance providers and various operators, guaranteeing the fairness of metering and settlement for each user, and adapting to the needs of unattended, multi-entity shared high-speed rail public network distribution boxes. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 The flowchart provided in this application illustrates a method for remote transmission of metering equipment from a high-speed rail public network distribution box to individual users. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0020] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0021] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0022] like Figure 1 As shown, in a first aspect, this application provides a method for remote transmission of metering equipment for sub-users in a high-speed rail public network distribution box, comprising: S100 periodically collects metering data from the high-speed rail public network power distribution box in rail transit to obtain the power data of each metering device.

[0023] The metering device is linked to the operator to form a corresponding relationship.

[0024] It should be noted that the metering device can be a dedicated outdoor metering meter for high-speed rail. Each meter is pre-configured with a unique hardware identifier, and the unique identifier of the meter is pre-bound with the corresponding operator information to form a one-to-one operator-meter binding mapping table, ensuring that the electricity data of each meter can be accurately attributed to the corresponding operator.

[0025] Specifically, obtaining the power data for each of the metering devices may include the following steps: S101, Configure a unique identifier for each metering device and bind the identifier to the operator to form a mapping table.

[0026] Specifically, each meter corresponding to each operator within the high-speed rail public network distribution box is assigned a unique meter identifier. This identifier is in string format and includes characteristic fields such as the distribution box number, operator code, and meter serial number, ensuring that it is not repeated throughout the entire rail transit line. Through the data acquisition gateway within the high-speed rail public network distribution box, the unique meter identifier of each meter is associated with the corresponding operator information (including operator name, settlement account, exclusive communication identifier, etc.) and entered into the data acquisition gateway. The data acquisition gateway then organizes the above associations to generate an operator-meter binding mapping table. This mapping table is stored in the non-volatile storage module of the data acquisition gateway, which has the characteristics of being tamper-proof and not lost when power is off.

[0027] S102, periodically collect metering equipment data from the high-speed rail public network power distribution box in rail transit, and store the collected power data in correspondence with the identifier to obtain the power data of each metering device.

[0028] Specifically, a data collection period can be pre-set using a data acquisition gateway. This period can be flexibly configured according to the operator's settlement requirements (the default configuration is once a day). When the collection period arrives, the data acquisition gateway, based on the operator-meter binding mapping table, initiates a data collection command to all meters in the distribution box. The command carries the unique identifier of the target meter for accurate addressing and to avoid data collection confusion. After receiving the command, the meter (metering device) verifies that the unique identifier matches its own configuration and then initiates electricity data collection. The collected data includes the cumulative electricity consumption for the current period and instantaneous voltage / current values ​​(used to assist in verifying the validity of the electricity data). The meter then processes the collected electricity data. Each meter is associated with its own unique identifier and encapsulated to form a structured data message of "unique meter identifier - electricity consumption data". This message is then fed back to the data acquisition gateway via the local communication bus (such as RS485 bus) within the distribution box. After receiving the structured data message from each meter, the data acquisition gateway parses and extracts the unique meter identifier and corresponding electricity consumption data. It then compares this data with the operator-meter binding mapping table to confirm the operator to which the data belongs. The data acquisition gateway then stores the "operator information - unique meter identifier - electricity consumption data - data acquisition timestamp" in a linked manner. The data acquisition timestamp is synchronized with the local clock of the data acquisition gateway, and the storage format adopts a general data file format for easy subsequent querying and tracing. Finally, the complete electricity consumption data of each meter belonging to the corresponding operator is obtained.

[0029] S200, the identifier is concatenated with the corresponding power data to form power data for the dedicated operator, and then encrypted to form encrypted data.

[0030] The core purpose of the S200 step is to ensure that the power data of each operator has unique ownership and transmission security, while adapting to the needs of scenarios where high-speed rail public network power distribution boxes are shared by multiple entities and have limited remote transmission bandwidth.

[0031] Specifically, generating encrypted data may include the following steps: S201, Based on the identifier, determine the power data and concatenate them to obtain an identifier-power data pair.

[0032] Specifically, the data acquisition gateway retrieves the "Operator Information - Meter Unique Identifier - Electricity Data - Collection Timestamp" dataset already associated with the S102 from the local storage module; it performs precise matching based on the meter's unique identifier, filtering out the electricity data and corresponding collection timestamp corresponding to that identifier, ensuring that "one identifier corresponds to a complete set of data" and avoiding data confusion; it then concatenates the data according to a preset fixed format, with the concatenation rule being, for example, "Meter Unique Identifier + Fixed Separator + Collection Timestamp + Fixed Separator + Electricity Data + Fixed Separator + Voltage / Current Auxiliary Verification Value," ensuring that fields can be quickly split during subsequent parsing. After concatenation, a structured "Meter Unique Identifier - Electricity Data Pair" is generated, for example, Identifier - Electricity Data: "PX-001-YYS-02-DB-10086|2024-05-2014:00:00|125.6kWh|220V / 15A", This data carries attribution identifiers and time dimension information.

[0033] It should be noted that if the data collected by the acquisition gateway is abnormal and not processed before proceeding with subsequent steps, it will result in a waste of resources. In other words, the collected data needs to be pre-judged, and if problems are found, supplementary data collection is required. The specific steps include the following: A data anomaly pre-judgment model is deployed at the edge of the data acquisition gateway. The data anomaly pre-judgment model can perform anomaly pre-judgment screening on the identifier-electricity data pair to obtain anomaly points. The anomaly pre-judgment screening includes at least three dimensions: metering compliance, acquisition time sequence, and numerical logic. Anomaly points refer to the points formed by data missing, distortion, or acquisition interruption located through anomaly pre-judgment screening. For the abnormal points identified during screening, the edge side initiates an active supplementary sampling command on-site to fill in the missing power data, generate complete and compliant identifier-power data pairs, and output them to the downstream encryption process.

[0034] Specifically, the data anomaly prediction model is a pre-built model that can be trained using historical data. After the data anomaly prediction model is loaded, it enters a real-time standby state, without occupying the computing power of the remote core side, and accesses the identifier-power data pairs generated by S201 in real time. The data anomaly prediction model starts anomaly prediction screening without uploading the original data to the remote end, thus achieving local lightweight processing. According to preset rules, complete the anomaly prediction screening in at least three dimensions and locate the anomaly points: Metering compliance dimension: Verify whether the electricity data is within the rated acquisition range of the front-end metering equipment, screen for anomalies such as values ​​exceeding the range and metering distortion (such as sudden changes or jumps), and locate the points of metering anomalies; Data collection time sequence dimension: Verify whether the data collection timestamps of the identifier-power data pair are continuous, without gaps, and without reverse order, and screen for data missing points caused by data collection interruption or time sequence disorder; Numerical logic dimension: Verify whether the binding relationship between the identifier and the power data is compliant, and screen for invalid data points such as mismatch between the identifier and the power, empty power values, and duplicate redundancy; All abnormal points identified during screening are categorized and marked, and the abnormality type of each point (missing / distorted / interrupted data acquisition) is clearly defined, forming a fixed label; the original data is not modified throughout the process, only the points are calibrated.

[0035] Finally, we obtain the calibrated anomaly locations (including anomaly type labels), compliant and anomaly-free identifiers - power data fragments, and edge-side screening logs. Next, the edge side of the data acquisition gateway sends a targeted supplementary data acquisition instruction to the corresponding metering device based on the abnormal point. The instruction is bound to the data acquisition time period and unique identifier corresponding to the point. The metering device (the metering device is an existing metering device, and this application has not improved it) re-captures the electricity data of the corresponding point according to the instruction and sends it back to the edge side of the data acquisition gateway. Verify the compliance of the three-dimensional screening rules for the reuse of supplementary data. After the verification is passed, use the supplementary data to fill in the abnormal points. The missing data points are spliced ​​and integrated with the existing compliant data, and the integrity is verified twice across the entire domain to generate complete identifier-electricity data pairs without missing or distortion.

[0036] The final output includes complete and compliant identifier-power data pairs and proactive data collection execution logs.

[0037] S202, according to the agreement with the operator, the corresponding encryption algorithm is invoked to encrypt the identifier-battery data pair to obtain encrypted data.

[0038] Step S202 employs an "operator-specific encryption strategy," meaning that electricity data from different operators are processed using their pre-negotiated encryption methods to ensure that the data can only be decrypted by the corresponding operator, thus protecting data privacy.

[0039] Furthermore, step S202 may include the following steps: S2021, Construct a data encryption algorithm library corresponding to the operator according to the agreement with the operator.

[0040] Specifically, the railway maintenance provider and various operators sign data transmission security agreements through offline negotiations, clarifying the encryption methods supported by each operator, key negotiation rules, algorithm switching permissions, and other details. Based on these agreements, a dedicated encryption algorithm library with an "operator-encryption algorithm" mapping is built into the encryption module of the data acquisition gateway. This library employs symmetric encryption (data encryption and decryption are achieved through a preset key, known only to the railway maintenance provider and the corresponding operator). The algorithm library configures at least two alternative encryption methods for each operator (such as SM4 encryption based on the national cryptographic standard and lightweight symmetric encryption adapted to low bandwidth), and assigns a unique algorithm identifier to each encryption method for quick subsequent retrieval via the identifier.

[0041] S2022, based on the encryption algorithm used for the next transmission carried in the previous operator's feedback data, the current identifier-battery data pair is encrypted to obtain encrypted data.

[0042] Specifically, each time the data acquisition gateway receives feedback data from the operator, it automatically parses the "next transmission algorithm identifier" field in the feedback message (this field is specified by the operator based on its own data security requirements or network environment status). If it is the first transmission (no historical feedback data), it will default to calling the highest priority encryption method corresponding to that operator in the algorithm library (the priority order is pre-agreed in the protocol). Based on the parsed algorithm identifier, the data acquisition gateway retrieves the corresponding encryption logic from the operator's proprietary encryption algorithm library. The core principle of this logic is: to treat the "identifier-power data pair" as plaintext, and to perform data obfuscation processing using a fixed key pre-negotiated with the operator, so that the plaintext is converted into ciphertext that cannot be directly read, and the ciphertext can only be decrypted back to plaintext using the same key and the corresponding encryption logic.

[0043] Furthermore, step S2022 may include the following steps: S20221, After encrypting the identifier-power data pair of each operator, encrypted data for each operator is formed.

[0044] Specifically, the data acquisition gateway groups all “identifier-electricity data pairs” according to the operator dimension, that is, the encrypted data corresponding to multiple meters of electricity from the same operator are grouped into one group; For the initial encrypted data within each group ("encryption algorithm identifier + key version number + ciphertext"), add operator-specific header information. The header information includes the operator code (consistent with the operator code in the unique identifier of the electricity meter), the number of electricity meters in the group, and the total length of the data, forming a single operator-specific encrypted data packet. Assign a unique number within the group to the single operator-specific encrypted data packet (e.g., "YYS-02-2024052014", i.e., operator code + date + time period) to distinguish encrypted data from different time periods of the same operator, and to facilitate subsequent storage and traceability. After the single operator-specific encrypted data packet is generated, proceed to the next packaging process.

[0045] S20222, which packages the encrypted data of each operator into encrypted data.

[0046] Specifically, the data acquisition gateway aggregates all operator-specific encrypted data packets, which can be arranged in a fixed order of "operator code ascending" to avoid parsing errors caused by disordered packaging order; a unified data packet header (hereinafter referred to as "master packet header") is constructed, which includes: a unique distribution box number, a packaging timestamp (synchronized with the collection timestamp, accurate to the second), the number of operators, the total length of the master packet data, and a master packet verification field (generated based on the content of all operator-specific encrypted data packets, used to verify the integrity of the master packet); the data is aggregated and packaged in the format of "master packet header + operator-specific encrypted data packet 1 + operator-specific encrypted data packet 2 + ... + operator-specific encrypted data packet n" to ensure that the data of each operator can be accurately split during cloud parsing; after packaging, the final "multi-operator aggregated encrypted data packet" is generated, which is suitable for scenarios with limited long-distance transmission bandwidth along high-speed rail lines.

[0047] Furthermore, in the original scheme's S2022 step, the encryption operation for the current power data is based solely on the encryption algorithm carried by the operator's previous feedback data. However, in actual application scenarios along high-speed rail lines, the network status of the dedicated high-speed rail communication link fluctuates in real time. Algorithms selected solely based on historical feedback are prone to incompatibility with the current network environment, making it difficult to further enhance the security level of dedicated data transmission. To address the aforementioned algorithm compatibility and transmission security issues, while maintaining full compatibility with the original scheme's technical logic, this embodiment adds an optimized dynamic key negotiation step after constructing the operator's encryption algorithm library in S2021 and before executing the specific encryption operation in S2022: If the negotiation succeeds, dynamic key negotiation for this transmission is first completed through the dedicated high-speed rail communication link, and then the encryption algorithm is autonomously determined based on the real-time network status; if the key negotiation fails, the offline pre-negotiated key is activated, and the encryption algorithm previously fed back by the operator is used for subsequent encrypted transmission. The specific implementation steps are as follows: Dynamic key negotiation is conducted through the dedicated high-speed rail communication link to determine the final key used in this transmission; The quality of the current high-speed rail dedicated communication link network is detected, and the final encryption algorithm for this transmission is selected from the operator's corresponding data encryption algorithm library. After the final encryption algorithm is selected, a unique algorithm identifier is fixed, which is a field code that is pre-agreed upon by both parties' algorithm libraries. Based on the final key and the final encryption algorithm, an encryption operation is performed to form encrypted data.

[0048] Specifically, the data acquisition gateway conducts two-way authentication with the operator through a dedicated high-speed rail communication link based on the operator's code. After successful authentication, the data acquisition gateway and the operator exchange random numbers bidirectionally and jointly calculate based on a key negotiation protocol to generate a dynamic session key exclusive to this transmission. This key is only valid for the encrypted transmission of this power data and is automatically destroyed after the transmission is completed. The data acquisition gateway receives a confirmation feedback from the operator that the key negotiation has been successful. It then verifies the compatibility of the dynamic key with the key type of the algorithm in the corresponding data encryption algorithm library of the operator. If the verification passes, the negotiation is considered successful. If any of the following occurs: link interruption, authentication failure, negotiation timeout, or key compatibility failure, the dynamic key negotiation is directly determined to have failed. A fallback pre-negotiated key (pre-negotiated offline between the railway maintenance party and the operator) is activated, and the previous feedback algorithm is activated simultaneously to complete the encryption adaptation.

[0049] Next, assuming the key negotiation is successful, three basic indicators of the high-speed rail dedicated communication link are collected: signal strength, real-time packet loss rate, and transmission delay. The network quality comprehensive score is calculated according to the preset weights. Based on the score level, the encryption algorithm in the corresponding data encryption algorithm library of the operator is matched and the algorithm is selected independently without relying on the algorithm feedback in the past. For the selected final encryption algorithm, the fixed field code agreed upon by both parties in advance is retrieved and solidified as the unique algorithm identifier corresponding to this transmission. Finally, the identifier-power data pair is treated as encrypted plaintext. According to the execution rules of the final encryption algorithm, the plaintext is standardized and grouped. The final key is used in conjunction with the final encryption algorithm to perform encryption operations on the grouped plaintext to generate ciphertext. According to the original encapsulation specifications, the fixed unique algorithm identifier is encapsulated into the fixed header field of the encrypted data.

[0050] S300, the encrypted data is stored and sent to the cloud space within a preset time period to obtain the sending result.

[0051] The sending result indicates that after the operator receives the encrypted data in the cloud space, it sends data back to the distribution box. The feedback data includes whether the data was received, not received, or partially received.

[0052] The purpose of step S300 is to achieve source retention and secure remote transmission of encrypted data. Through a design of "independent storage by operator + verification code binding + scheduled cloud upload," it ensures data traceability and prevents tampering or loss during transmission. It is also suitable for scenarios involving unattended high-speed rail public network power distribution boxes and complex remote transmission environments. The encrypted data refers to the "multi-operator aggregated encrypted data packet" generated in step S20222 (containing a general packet header + each operator's dedicated encrypted data packet), while the single-operator dedicated encrypted data packet is the operator-specific ciphertext data independently generated in step S20221.

[0053] The sending result represents the data fed back by the operator to the acquisition gateway of the distribution box through a dedicated communication link between the cloud space and the acquisition gateway after the operator receives the multi-operator aggregated encrypted data packet in the cloud space. The feedback data includes whether it was received, not received, or partially received, and the feedback data synchronously carries the number of the corresponding data packet (which is consistent with the packaging timestamp + distribution box number in the header of the main packet) and the encryption algorithm identifier of the next transmission suggestion.

[0054] Specifically, obtaining the sending result may include the following steps: S301 stores encrypted data separately for each operator.

[0055] Specifically, the storage objects are clearly defined: the acquisition gateway independently stores the "single-carrier-specific encrypted data packets" generated in S20221, and does not store the aggregated multi-carrier encrypted data packets, ensuring that the data of a single carrier can be retrieved and traced separately; Storage location and characteristics: Stored in the non-volatile storage module built into the acquisition gateway; Storage traceability and association: During storage, "storage timestamp + encryption algorithm identifier at the time of data generation + key version number" are recorded synchronously and associated with the single operator's exclusive encrypted data packet to form a complete storage traceability log, providing a basis for subsequent data anomaly investigation.

[0056] S302, a data trust verification code is generated using a hash algorithm, and encrypted data carrying the data trust verification code is sent to the cloud space within a preset time period to obtain the sending result.

[0057] The sending result indicates that after the operator verifies the data trust verification code in the cloud space, it decrypts the encrypted data using an encryption algorithm, receives the encrypted data, and then provides feedback on whether the data was received, not received, or partially received.

[0058] Specifically, the core principle of the hash algorithm in step S302 is: to extract features of a fixed length from the complete data and generate a unique string (check code). If the data content or length changes, the check code will change accordingly, thereby realizing data integrity verification.

[0059] For example, data trust verification code generation and binding: The data acquisition gateway retrieves the aggregated "multi-carrier aggregated encrypted data packet" from S20222 and extracts features from the complete content of the data packet (including the main packet header, all single-carrier-specific encrypted data packets, and packet delimiters); Based on the core principle of hash algorithm, a unique string of fixed length (such as 64 bits) is generated as a data trust verification code. This verification code corresponds one-to-one with the current multi-carrier aggregated encrypted data packet. If the data is not tampered with, the verification code remains unique and unchanged. Binding is performed according to the format of "multi-carrier aggregated encrypted data packet + fixed separator + data trusted verification code" to ensure that the verification code and data packet body can be quickly separated during cloud space parsing.

[0060] Preset time period configuration and sending preparation: The preset time period is determined through negotiation between the railway maintenance provider and the operator, and supports two configuration modes: one is fixed time period transmission, and the other is time period adjustment as needed. The specific mode can be selected according to the requirements.

[0061] Sending data to the cloud: The data acquisition gateway sends "data packets to be sent" to the preset cloud space through dedicated high-speed rail communication links (such as 4G / 5G private networks and railway backbone networks). During the sending process, it prioritizes links with stable signals and sufficient bandwidth to adapt to scenarios with network fluctuations along the high-speed rail line. After receiving the data packet, the cloud space automatically stores it in the specified directory (the directory structure is consistent with the storage directory of the acquisition gateway, which is convenient for operators to query), and sends a "cloud space reception confirmation" back to the acquisition gateway (this only indicates that the cloud space has received the data packet, and does not mean that the operator has decrypted and verified it). The acquisition gateway records this confirmation information as a sending process log.

[0062] Carrier verification, decryption, and feedback: Operators log into the cloud space, query the multi-operator aggregated encrypted data packets belonging to themselves, and extract the data trust verification code at the end of the data packets; The operator extracts features from the main body of the data packet (multi-operator aggregated encrypted data packet) (the principle is the same as that of the collection gateway generating the verification code) to obtain a local verification code. The local verification code is compared with the extracted verification code: if they match, it means that the data has not been tampered with and the decryption process begins; if they do not match, "partially received" is directly reported (the data has been tampered with). After verification, the operator uses its own proprietary key and encryption algorithm (which is the same as the algorithm used in S2022) to extract its own single-operator proprietary encrypted data packet from the multi-operator aggregated encrypted data packet and decrypt it to obtain the identifier-power data pair; The operator provides feedback on the corresponding transmission results based on the decryption results: 1. Successfully split and decrypt the complete data, feedback "received", and also carries the encryption algorithm identifier suggested for the next transmission; 2. No data packet belonging to itself was found, feedback "not received"; 3. Some fields are missing or decryption failed after the data packet was split, feedback "partially received", and indicates the missing data packet number and field information; Feedback data is transmitted to the acquisition gateway via a dedicated communication link between the cloud space and the acquisition gateway. After receiving the data, the acquisition gateway stores the feedback log, completing the closed-loop process of "sending-verifying-feedback".

[0063] S400, if the transmission result includes "not received" and "partially received", then adjust the channel and retransmit the encrypted data.

[0064] The core purpose of the S400 steps is to solve the problem of abnormal data transmission caused by network signal fluctuations and channel interference along high-speed rail lines, ensure that encrypted data is delivered to the cloud space intact, and adapt to the needs of scenarios such as unattended high-speed rail public network power distribution boxes and complex remote transmission environments (strong electromagnetic interference, unstable signals).

[0065] Specifically, retransmitting the encrypted data may include the following steps: S401, when the transmission result includes not received and partially received, select the channel with the best communication quality from the preset rail transit dedicated backup channel pool, switch the channel, and retransmit the encrypted data.

[0066] Specifically, this may include the following methods: Anomaly Analysis and Data Locking: After receiving the transmission results from the operator, the acquisition gateway first parses the core fields: If the feedback is "not received," it is determined that the entire packet transmission failed, and the corresponding multi-operator aggregated encrypted data packet (completely identical to the original sent packet) is directly retrieved from the local storage module; if the feedback is "partially received," the missing data fragments noted in the "anomaly details" are combined with the locally stored single-operator-specific encrypted data packet to regenerate a complete multi-operator aggregated encrypted data packet, ensuring that the retransmitted data is consistent with the source acquisition data. Anomaly logs are also recorded to provide a basis for subsequent maintenance and troubleshooting.

[0067] Initialization and Status Detection of Dedicated Backup Channel Pool for Rail Transit: The pre-set dedicated backup channel pool for rail transit can contain three types of communication channels adapted to high-speed rail scenarios: high-speed rail 4G / 5G private network channels (priority use, low latency, high stability), railway backbone network dedicated channels (backup 1, wide coverage, anti-interference), and satellite communication backup channels (backup 2, as a fallback for extreme environments). Each channel is assigned a unique identifier (e.g., "4G-ZT-001", "backbone network-TL-002", "satellite-WX-003"), and an initial priority is preset. The acquisition gateway initiates a real-time channel quality detection mechanism, sending small-volume test data packets (without sensitive information, only used for link verification) to each channel. Communication quality is evaluated based on three core indicators: 1. Signal strength (reflecting link stability, unit dBm, threshold ≥ -85dBm); 2. Real-time packet loss rate (reflecting transmission integrity, threshold ≤ 1%); 3. Transmission delay (reflecting response speed, threshold ≤ 50ms). The detection principle is to intuitively determine the current availability status of the channel by the time difference between the sending and feedback of the test packets and the feedback integrity, without the need for complex algorithms.

[0068] Optimal Channel Selection and Switching Execution: The data acquisition gateway establishes a simple scoring system, calculating a comprehensive score (out of 100) for each channel based on "signal strength (40% weight) + real-time packet loss rate (30% weight) + transmission delay (30% weight)". Channels with a score ≥ 80 are listed as candidate optimal channels. If multiple candidate channels exist, the channel with the highest score is selected as the target switching channel. If all channel scores are < 80 (extreme network environment), the "second-best channel" with the highest score is selected, and a channel quality alarm is triggered. During switching, the data acquisition gateway first disconnects the original failed channel connection, releases resources, and then establishes a new link based on the preset configuration parameters of the target channel (such as frequency band, access point, authentication information). After switching, a second test packet is sent to the target channel to verify link connectivity. Only after ensuring successful switching does the retransmission process begin, avoiding invalid transmission.

[0069] Retransmission with Identification and Feedback Confirmation: Based on the optimal channel after the switchover, the acquisition gateway retransmits the multi-carrier aggregated encrypted data packet according to the S302 transmission specification. Simultaneously, a "retransmission identifier" field (e.g., marked as "CF-001") is added to the header of the total data packet to facilitate identification of the retransmitted data by the cloud space and the carrier, avoiding redundant processing. After receiving the retransmitted data, the cloud space completes the data trust verification code comparison according to the verification process described above. After the carrier decrypts the data, it sends back the new transmission result. The acquisition gateway receives this result and updates its log: if the feedback is "received," the retransmission process ends; if it is still "not received" or "partially received," the second retransmission is repeated.

[0070] Secondly, this application provides a remote transmission system for high-speed rail public network power distribution boxes with sub-user metering operator equipment, applied to the aforementioned remote transmission method for high-speed rail public network power distribution boxes with sub-user metering operator equipment. The system includes: The data acquisition unit is used to periodically collect data from the metering devices of the high-speed rail public network power distribution boxes in rail transit, and obtain the power data of each metering device. The identifier of each metering device is bound to the operator to form a corresponding relationship. An encryption unit is used to concatenate the identifier with the corresponding power data to form power data specific to the operator, and then encrypt the data to form encrypted data. A sending unit is used to store the encrypted data and send it to the cloud space within a preset time period to obtain a sending result. The sending result represents feedback data in response to the operator receiving the encrypted data in the cloud space. The received data includes received, not received, or partially received. The result unit is used to adjust the channel and retransmit the encrypted data when the transmission result includes "not received" and "partially received".

[0071] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the aforementioned method.

[0072] Fourthly, this application provides a computer program that, when executed by a processor, implements the steps of the aforementioned method.

[0073] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0074] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0075] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for remote transmission of metering equipment for individual users in a high-speed railway public network distribution box, characterized in that, include: Periodically collect metering data from the power distribution boxes of high-speed rail public networks in rail transit to obtain power data for each metering device. The identifier of each metering device is bound to the operator to form a corresponding relationship. The identifier is concatenated with the corresponding power data to form power data specific to the operator, and then encrypted to form encrypted data. The encrypted data is stored and sent to the cloud space within a preset time period to obtain a sending result. The sending result indicates that after the operator receives the encrypted data in the cloud space, it feeds back data to the distribution box. The feedback data includes whether the data was received, not received, or partially received. If the transmission result includes "not received" and "partially received", then the channel is adjusted and the encrypted data is retransmitted.

2. The method for remote transmission of metering equipment for high-speed rail public network distribution boxes with sub-users as described in claim 1, characterized in that, The step of periodically collecting metering data from the high-speed rail public network power distribution boxes in rail transit to obtain the power data of each metering device includes: Each metering device is configured with a unique identifier, and the identifier is bound to the operator to form a mapping table; Periodically collect metering data from the power distribution boxes of high-speed rail public networks in rail transit, and store the collected power data in correspondence with the identifier to obtain the power data of each metering device.

3. The method for remote transmission of metering equipment for high-speed rail public network distribution boxes with sub-users as described in claim 2, characterized in that, The step of concatenating the identifier with the corresponding power data to form dedicated operator power data and encrypting it to form encrypted data includes: Based on the identifier, the power data is determined and concatenated to obtain an identifier-power data pair; According to the agreement with the operator, the corresponding encryption algorithm is invoked to encrypt the identifier-battery data pair, thereby obtaining encrypted data.

4. The method for remote transmission of metering equipment for sub-users in a high-speed rail public network distribution box as described in claim 3, characterized in that, The step of encrypting the identifier-battery data pair by invoking the corresponding encryption algorithm according to the agreement with the operator to obtain encrypted data includes: Based on the agreement with the operator, construct a data encryption algorithm library corresponding to the operator; Based on the encryption algorithm used for the next transmission carried in the previous operator's feedback data, the current identifier-battery data pair is encrypted to obtain encrypted data.

5. The method for remote transmission of metering equipment for sub-users in a high-speed rail public network distribution box as described in claim 4, characterized in that, The step of encrypting the current identifier-battery data pair based on the encryption algorithm used for the next transmission carried in the previous operator's feedback data to obtain encrypted data includes: The identifier-battery data pair of each operator is encrypted to form encrypted data for each operator; Each operator's encrypted data is packaged into encrypted data.

6. The method for remote transmission of metering operator equipment for high-speed rail public network distribution boxes with sub-users as described in claim 5, characterized in that, The steps of storing the encrypted data and sending it to the cloud within a preset time period to obtain the sending result include: Encrypted data for each operator is stored separately; A data trust verification code is generated using a hash algorithm. Encrypted data carrying the data trust verification code is sent to the cloud space within a preset time period. A sending result is obtained, wherein the sending result indicates that after the operator verifies the data trust verification code in the cloud space, it decrypts the encrypted data using an encryption algorithm, receives the encrypted data, and provides feedback on whether the data was received, not received, or partially received.

7. The method for remote transmission of metering equipment for sub-users in a high-speed rail public network distribution box as described in claim 1, characterized in that, The step of adjusting the channel and retransmitting the encrypted data when the transmission result includes "not received" and "partially received" includes: If the transmission result includes "not received" and "partially received", the channel with the best communication quality is selected from the preset rail transit dedicated backup channel pool to complete the channel switching, and the encrypted data is retransmitted.

8. A remote transmission system for high-speed rail public network power distribution boxes with sub-user metering operator equipment, characterized in that, The method for remote transmission of metering equipment for high-speed rail public network distribution boxes with distributed users, applicable to any one of claims 1-7, comprises: The data acquisition unit is used to periodically collect data from the metering devices of the high-speed rail public network power distribution boxes in rail transit, and obtain the power data of each metering device. The identifier of each metering device is bound to the operator to form a corresponding relationship. An encryption unit is used to concatenate the identifier with the corresponding power data to form power data specific to the operator, and then encrypt the data to form encrypted data. A sending unit is used to store the encrypted data and send it to the cloud space within a preset time period to obtain a sending result. The sending result represents feedback data in response to the operator receiving the encrypted data in the cloud space. The received data includes received, not received, or partially received. The result unit is used to adjust the channel and retransmit the encrypted data when the transmission result includes "not received" and "partially received".

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images