Intelligent electric meter data acquisition system based on Ethernet

Abstract

The invention relates to the technical field of industrial Ethernet, and particularly discloses an Ethernet-based intelligent electric meter data acquisition system, which abandons passive congestion monitoring, and actively calculates a predictive congestion level capable of pre-judging a congestion trend by analyzing a change speed and an acceleration of a network key index time sequence. And then, the system deeply fuses the prediction level and the task priority, and dynamically generates a dynamic scheduling table which allocates an exclusive uploading time slot and an adaptive sampling rate to each ammeter. And finally, the electric meters perform ordered peak shifting data uploading according to the dispatch table. According to the scheme, the synchronous and concurrent data flood flow is converted into the asynchronous time division data flow, so that the formation of a data acquisition storm is avoided fundamentally, and the acquisition integrity and timeliness of key data are ensured under high network pressure.

Description

Technical Field

[0001] This application relates to the field of industrial Ethernet technology, and more specifically, to an Ethernet-based smart meter data acquisition system. Background Technology

[0002] With the continuous development of smart grids, advanced metering architectures are placing higher demands on the ability to perceive the grid status. Traditional power line carrier or wireless radio frequency communication methods, due to their limited bandwidth, high latency, and susceptibility to environmental interference, are no longer sufficient to meet the high-frequency, high-reliability data acquisition requirements of massive numbers of smart meters. This performance bottleneck becomes increasingly apparent, especially in advanced application scenarios requiring refined load analysis, power quality monitoring, and fault instantaneous waveform recording. Therefore, using Ethernet technology, which offers advantages such as high bandwidth, low latency, and high reliability, to construct smart meter data acquisition systems has become a key technological development direction supporting the realization of the future grid's observable, measurable, and controllable goals.

[0003] However, in existing technological practices, Ethernet-based smart meter data acquisition systems typically employ a centralized request-response polling model. In this model, the master station or data concentrator acts as the control center, concurrently initiating data acquisition commands to a large number of meters according to a preset strategy. When the power grid experiences disturbances or requires regional centralized monitoring, the system triggers sudden high-frequency data acquisition tasks, demanding that hundreds or thousands of smart meters in the area simultaneously upload massive amounts of data within a very short time. This open-loop scheduling method, lacking awareness of the network's end-point status, easily triggers data acquisition storms at the aggregation switch level, causing instantaneous network traffic to far exceed the link's carrying capacity, resulting in severe network congestion, massive packet loss, and a dramatic increase in transmission latency. More importantly, this means that at the critical moments when real-time data is most needed, the system, due to its own scheduling mechanism deficiencies, is unable to obtain complete and timely power grid status information, violating the original intention of using Ethernet for high-frequency data acquisition.

[0004] Therefore, an optimized Ethernet-based smart meter data acquisition system is desired. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide an Ethernet-based smart meter data acquisition system.

[0006] According to one aspect of this application, an Ethernet-based smart meter data acquisition system is provided, comprising: The task distribution module is used to distribute task collection based on the central task request in order to obtain the local collaborative mode activation status. The congestion level prediction module is used to calculate the predictive congestion level based on the acquired raw SNMP data and raw RTT data. The dynamic acquisition and scheduling module is used to generate a dynamic acquisition and scheduling strategy based on the predictive congestion level and the task priority in the central task request to obtain a dynamic scheduling table. The scheduling table distribution module is used to distribute the dynamic scheduling table to all smart meters in the target meter group via broadcast. The meter data acquisition module is used by each smart meter to extract its own meter-specific scheduling entries from the dynamic scheduling table, and to collect data based on these meter-specific scheduling entries to obtain cached data packets.

[0007] Compared to existing technologies, this application provides an Ethernet-based smart meter data acquisition system that abandons passive congestion monitoring. Instead, it proactively calculates a predictive congestion level by analyzing the rate of change and acceleration of key network indicators over time. The system then deeply integrates this predictive level with task priorities, dynamically generating a dynamic scheduling table that assigns a dedicated upload time slot and adaptive sampling rate to each meter. Finally, each meter uploads data in an orderly, staggered manner according to this scheduling table. This solution fundamentally avoids data acquisition storms by transforming synchronous concurrent data floods into asynchronous time-division multiplexed data streams, thus ensuring the integrity and timeliness of critical data acquisition under high network pressure. Attached Figure Description

[0008] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0009] Figure 1 This is a system block diagram of an Ethernet-based smart meter data acquisition system according to an embodiment of this application.

[0010] Figure 2 This is a schematic diagram of data flow in an Ethernet-based smart meter data acquisition system according to an embodiment of this application.

[0011] Figure 3 This is a block diagram of a congestion level prediction module in an Ethernet-based smart meter data acquisition system according to an embodiment of this application.

[0012] Figure 4 This is a block diagram of the dynamic acquisition and scheduling module in an Ethernet-based smart meter data acquisition system according to an embodiment of this application. Detailed Implementation

[0013] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0014] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0015] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0016] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0017] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0018] Existing technologies generally employ open-loop scheduling when handling sudden high-frequency data acquisition tasks, which can easily lead to network congestion and loss of critical data. To address this issue, this application proposes an Ethernet-based smart meter data acquisition system. The system is first activated by a congestion level prediction module. Instead of passively responding to congestion, it acquires and analyzes raw SNMP and RTT data from the underlying network in real time, constructs a time-series model, and extracts multi-level dynamic features, including rate of change and acceleration, to calculate a predictive congestion level that anticipates network deterioration trends. Subsequently, a dynamic acquisition scheduling module intervenes, fusing the predictive congestion level with the priority of the central task to generate a refined dynamic scheduling table. This table not only adaptively adjusts the data sampling rate for each meter in the target meter group but, more importantly, allocates a unique, non-conflicting upload time window for each. Finally, the scheduling table is distributed to all target meters, and each meter acquires and caches data according to its dedicated scheduling entry, strictly adhering to staggered upload times within its allocated time slots. Through this series of processes, the originally chaotic synchronous concurrent data stream is reshaped into an orderly asynchronous time-division data stream, which avoids the formation of data collection storms from the source and effectively ensures the integrity and reliability of data collection under high load scenarios.

[0019] Figure 1 This is a system block diagram of an Ethernet-based smart meter data acquisition system according to an embodiment of this application. Figure 2 This is a schematic diagram of the data flow in an Ethernet-based smart meter data acquisition system according to an embodiment of this application. Figure 1 and Figure 2 As shown, the Ethernet-based smart meter data acquisition system 100 according to an embodiment of this application includes: a data acquisition task distribution module 110, used to distribute data acquisition tasks based on a central task request to obtain the local collaborative mode activation status; a congestion level prediction module 120, used to calculate a predictive congestion level based on the acquired raw SNMP data and raw RTT data; a dynamic data acquisition scheduling module 130, used to generate a dynamic data acquisition scheduling strategy based on the predictive congestion level and the task priority in the central task request to obtain a dynamic scheduling table; a scheduling table distribution module 140, used to distribute the dynamic scheduling table to all smart meters in the target meter group via broadcast; and a meter data acquisition module 150, used for each smart meter to extract its own meter-specific scheduling entry from the dynamic scheduling table and to acquire data based on its own meter-specific scheduling entry to obtain cached data packets.

[0020] In the aforementioned Ethernet-based smart meter data acquisition system 100, the acquisition task distribution module 110 is used to distribute acquisition tasks based on central task requests to obtain the local collaborative mode activation state. It should be understood that system event triggers generated by the upper-level power grid management system, such as fault alarms or analysis instructions, are inherently business logic-oriented and unstructured information, which cannot be directly parsed and executed by the underlying acquisition devices. Therefore, in the technical solution of this application, the acquisition task is distributed based on central task requests to obtain the local collaborative mode activation state. This accurately transforms an abstract business requirement into an executable, target-specific localized acquisition task, and establishes a distributed collaborative framework with a data concentrator as the coordinator. This ensures that the acquisition task has a precise execution target and a clear command system from the source, laying the foundation for subsequent dynamic and refined scheduling based on network status, and avoiding blind, global instruction distribution.

[0021] Specifically, in this embodiment of the application, the task acquisition module is used to: in response to receiving a system event trigger, perform topology parsing and resource mapping on the system event trigger to obtain a central task request; perform task assignment and coordinator role establishment based on the central task request to obtain the received central task request; and perform local collaboration mode activation and group member pre-notification based on the received central task request to obtain the local collaboration mode activation status and collaboration activation signaling.

[0022] More specifically, in a concrete example of this application, the implementation process of the data acquisition task distribution module is as follows. First, the event processing engine of the master station system receives a system event trigger indicating that the third harmonic of a certain feeder exceeds the standard. The engine immediately initiates the topology resolution and resource mapping process. It queries the internally stored power grid topology database to resolve the feeder identifier into a unique target data concentrator (DCU) identifier and a list of all two hundred smart meters under that DCU. At the same time, the system quantifies the harmonic analysis task into a structured central task request containing parameters such as high priority and high sampling rate according to the preset policy rule base. Then, the master station system executes task assignment based on the central task request, sending the complete request data packet to the network address of the target DCU via the wide area network. After receiving this specific request, the DCU's role as the local coordinator is established. Finally, after parsing the received central task request, the DCU immediately activates the local coordination mode and sends a lightweight coordination activation signal containing only the task identifier to all smart meters in the target meter group via multicast through the local Ethernet, thus completing the pre-notification of group members and putting all relevant meters into a ready state waiting for detailed scheduling instructions.

[0023] In the aforementioned Ethernet-based smart meter data acquisition system 100, the congestion level prediction module 120 is used to calculate a predictive congestion level based on the acquired raw SNMP data and raw RTT data. It should be understood that existing network congestion assessment mechanisms are essentially memoryless reactive models, reflecting only the network state at the moment of assessment and completely ignoring the unique dynamic correlations between network congestion indicators and the indicators themselves over time. Specifically, it cannot effectively distinguish whether the congestion state evolves slowly or jumps instantaneously because it lacks the ability to perceive the trend of congestion changes. Furthermore, it cannot predict the acceleration of congestion deterioration, i.e., it cannot determine whether the rate of network state deterioration is accelerating or slowing down. In a scenario where a high-frequency data acquisition storm is about to form, the high rate of change and high acceleration of congestion indicators are strong precursors to network collapse, and their danger is far greater than that of a network with high absolute values ​​but a stable state. Moreover, fixed weighting coefficients cannot adapt to the dynamic shift in the importance of various monitoring indicators at different stages of congestion development. Therefore, the fundamental flaw of this mechanism lies in its inability to achieve predictive assessment. It can only measure the depth of congestion but cannot answer how quickly congestion occurs or how rapidly it worsens, thus missing the optimal opportunity to intervene in the early stages of a congestion storm. To address these technical shortcomings, this application proposes a predictive congestion assessment mechanism based on time-series dynamic characteristics in a preferred embodiment. By introducing the analysis of multiple derivatives of network state indicators, it achieves a shift from static reactive assessment to dynamic predictive assessment. In the technical solution of this application, predictive congestion levels are further calculated based on the acquired raw SNMP data and raw RTT data, thereby transforming the static, snapshot-style congestion measurement into a dynamic, predictive assessment system capable of capturing the evolution trajectory of network state. This enables the system to keenly identify the early stages of a congestion storm and quantitatively predict future network risks, providing a basis for decision-making for precise and timely adaptive scheduling interventions, and greatly improving the system's stability and data integrity in high-frequency, bursty data acquisition scenarios.

[0024] Figure 3 This is a block diagram of a congestion level prediction module in an Ethernet-based smart meter data acquisition system according to an embodiment of this application. Figure 3As shown in the embodiments of this application, the congestion level prediction module 120 includes: a time-series data conversion unit 121, used to collect time-series indicator data and construct a sliding window from the original SNMP data and the original RTT data to obtain the time series of cache occupancy rate, the time series of packet loss count, and the time series of round-trip delay value; a multi-level dynamic feature extraction unit 122, used to perform multi-level dynamic feature extraction on the time series of cache occupancy rate, the time series of packet loss count, and the time series of round-trip delay value to obtain the cache occupancy rate feature vector, the packet loss count feature vector, and the round-trip delay feature vector; and a predictive congestion level fusion unit 123, used to perform predictive congestion level fusion calculation on the cache occupancy rate feature vector, the packet loss count feature vector, and the round-trip delay feature vector to obtain the predictive congestion level.

[0025] Specifically, the time-series data conversion unit 121 is used to collect time-series indicator data and construct a sliding window from the raw SNMP data and raw RTT data to obtain time series of buffer occupancy rate, packet loss count, and round-trip delay value. It should be understood that since the raw SNMP data and raw RTT data collected from the network are essentially discrete, isolated snapshot-style monitoring data, judging based on only a single data point will not provide any insight into the evolution of the network state. Therefore, it is necessary to convert the discrete snapshot-style monitoring data into continuous time-series data. In the technical solution of this application, the raw SNMP data and raw RTT data are further collected using time-series indicator data and a sliding window is constructed to obtain time series of buffer occupancy rate, packet loss count, and round-trip delay value. This places each independent measurement value within its historical context, thereby transforming discrete data points into continuous time series that reflect recent trends. This establishes the necessary data foundation for subsequent analysis of the rate and acceleration of network state changes, making the shift from static reactive assessment to dynamic predictive assessment possible.

[0026] More specifically, in a concrete example of this application, the implementation process of the time-series data conversion unit is as follows. First, the data concentrator performs time-series metric data acquisition at a fixed evaluation period (e.g., 1 second). It requests a specific management information base object related to the uplink port from its directly connected aggregation switch via the SNMP GetRequest protocol to obtain the raw values ​​of its buffer utilization and outbound packet loss count. Simultaneously, it sends an ICMP EchoRequest message to a smart meter in the target meter group that is geographically distant, and records the time elapsed from sending to receiving the EchoReply message as the raw RTT data. Next, the unit performs sliding window construction. In the DCU's memory, a fixed-length FIFO queue of length N is maintained for each of the three metrics: buffer utilization, packet loss count, and round-trip time, thus constructing a sliding time window. In each evaluation period, newly acquired metric data is pushed into the head of the corresponding queue; if the queue is full, the oldest data is removed from the tail of the queue. The ultimate result of this operation is that, at any given time, the contents of each queue constitute an ordered set containing the measurements from the most recent N periods, i.e., the required time series. This establishes the data foundation for analyzing the network state evolution trajectory and prepares for subsequent dynamic feature extraction. For example, suppose the sliding window length N is set to 5 and the evaluation period is 1 second. In the current evaluation period t, the DCU collects a switch buffer occupancy rate of 95%. In the previous four periods (t-1, t-2, t-3, t-4), the collected historical values ​​were 75%, 60%, 55%, and 50%, respectively. At time t-1, the contents of the buffer occupancy rate time series queue are [75, 60, 55, 50, 45]. In the current period t, when a new measurement value of 95% is collected, it is pushed to the head of the queue, while the oldest data of 45% is removed from the tail of the queue. Therefore, at time t, the state of the queue is updated to [95, 75, 60, 55, 50]. This array of length 5 [95,75,60,55,50] constitutes the time series of the current cache occupancy rate and is passed as output to the subsequent multi-stage dynamic feature extraction unit.

[0027] Specifically, the multi-order dynamic feature extraction unit 122 is used to perform multi-order dynamic feature extraction on the time series of cache occupancy rate, packet loss count, and round-trip delay value to obtain cache occupancy rate feature vector, packet loss count feature vector, and round-trip delay feature vector. It should be understood that since the network indicator time series generated in the previous step is merely an ordered set of raw data, it does not explicitly quantify the dynamic evolution trend of the network state. Therefore, in the technical solution of this application, multi-order dynamic feature extraction is further performed on the time series of cache occupancy rate, packet loss count, and round-trip delay value to obtain cache occupancy rate feature vector, packet loss count feature vector, and round-trip delay feature vector, thereby accurately quantifying the current value of the network state (zero-order static feature), the instantaneous deterioration rate (first-order dynamic feature), and the acceleration of the deterioration trend (second-order dynamic feature). In this way, each network metric can be expanded from a single scalar value into a three-dimensional feature vector that includes the current state, rate of change, and acceleration of change. This provides a quantifiable, multi-dimensional basis for decision-making to achieve predictive congestion level assessment, enabling the system to anticipate the trend of congestion deterioration. For example, a large positive acceleration value indicates that the rate of deterioration is accelerating, which will serve as a strong warning signal that the network is about to enter a state of out of control.

[0028] More specifically, in this embodiment, the multi-order dynamic feature extraction unit is used to: extract zero-order static features of cache utilization from the time series of cache utilization; extract first-order dynamic features of cache utilization from the time series of cache utilization; extract second-order dynamic features of cache utilization from the time series of cache utilization; and vectorize the zero-order static features, first-order dynamic features, and second-order dynamic features of cache utilization to obtain a cache utilization feature vector. It is worth noting that here, the weight of the zero-order static features of cache utilization is greater than that of the first-order dynamic features of cache utilization, and the weight of the first-order dynamic features of cache utilization is greater than that of the second-order dynamic features of cache utilization.

[0029] In a specific example of this application, the implementation process of the multi-order dynamic feature extraction unit is as follows. First, taking the time series of cache utilization rate as an example, the unit extracts the latest data point from the time series as the current indicator value, and after processing by a normalization function, obtains the zero-order static feature of cache utilization rate. That is, the zero-order static feature is the current indicator value itself after processing by the normalization function, and its calculation formula is: in, This represents the original value of indicator M at the current time t. It is a normalization function that maps the original value to the interval [0,1]. These are the normalized static eigenvalues.

[0030] Next, this unit extracts the two most recent data points from the time series, calculates the difference between their normalized values, and obtains the first-order dynamic feature of cache utilization, which characterizes the rate of change of cache utilization. This is expressed by the following formula: in, This represents the original value of indicator M at the previous time point. This represents the rate of change of the indicator. In this way, it can accurately capture the instantaneous rate of deterioration of the network state, and a large positive value directly reveals that a congestion storm is rapidly forming.

[0031] Subsequently, this unit extracts the three most recent data points from the time series and calculates the difference in the rate of change between the current period and the previous period to obtain the second-order dynamic feature of cache utilization. This feature characterizes the acceleration of cache utilization changes. It is expressed by the following formula: in, The original values ​​of indicator M at the first two time points. This represents the acceleration of the indicator's change.

[0032] Finally, the unit combines the calculated zero-order static features, first-order dynamic features, and second-order dynamic features of the cache utilization rate into a three-dimensional vector, which serves as the output cache utilization rate feature vector. This process is also applied in parallel to the time series of packet loss counts and round-trip latency values, respectively, to obtain their respective feature vectors, namely the packet loss count feature vector and the round-trip latency feature vector.

[0033] Specifically, in a concrete numerical calculation example, the time series of cache occupancy received by this unit is [95, 75, 60, 55, 50], where the data unit is percentage, and the normalization function is f(x) = x / 100. Extracting the zero-order static feature of cache occupancy: This unit takes the latest data point 95 and calculates its normalized value F0 = f(95) = 0.95. Extracting the first-order dynamic feature of cache occupancy: This unit takes the two latest data points 95 and 75 and calculates the difference between their normalized values ​​F1 = f(95) - f(75) = 0.95 - 0.75 = 0.20. Extracting the second-order dynamic features of cache utilization: This unit takes the three latest data points 95, 75, and 60, and calculates their rate of change F2=(f(95)-f(75))-(f(75)-f(60))=(0.95-0.75)-(0.75-0.60)=0.20-0.15=0.05. Vectorization: This unit combines the above three feature values, and the final output cache utilization feature vector is [0.95,0.20,0.05]. This vector intuitively shows the dangerous network state of high cache utilization, rapid growth rate, and accelerating growth momentum.

[0034] Specifically, the predictive congestion level fusion unit 123 is used to perform predictive congestion level fusion calculation on the buffer occupancy feature vector, packet loss count feature vector, and round-trip delay feature vector to obtain the predictive congestion level. It should be understood that since the buffer occupancy feature vector, packet loss count feature vector, and round-trip delay feature vector generated in the previous step are independent multi-dimensional data, although they contain rich dynamic information, they cannot be directly used as a unified scalar indicator for scheduling decisions. Therefore, in the technical solution of this application, the predictive congestion level fusion calculation is further performed on the buffer occupancy feature vector, packet loss count feature vector, and round-trip delay feature vector to obtain the predictive congestion level. This allows for the intelligent fusion of the multi-dimensional features of all indicators through a two-layer weighted model, generating a single risk indicator that comprehensively reflects future congestion trends.

[0035] More specifically, in the embodiments of this application, the predictive congestion level fusion unit is used to: perform intra-component weighting on the cache occupancy feature vector, the packet loss count feature vector, and the round-trip delay feature vector to obtain the cache occupancy comprehensive risk component, the packet loss count comprehensive risk component, and the round-trip delay comprehensive risk component; and calculate the weighted sum of the cache occupancy comprehensive risk component, the packet loss count comprehensive risk component, and the round-trip delay comprehensive risk component to obtain the predictive congestion level.

[0036] In a specific example of this application, the implementation process of the predictive congestion level fusion unit is as follows: First, the unit performs a weighted calculation within the first layer of components. It receives the input cache occupancy feature vector and multiplies the zero-order, first-order, and second-order feature components with preset weight coefficients, respectively. Then, it sums the three products to obtain the comprehensive cache occupancy risk component. This is expressed by the following formula: in, , and These are the weighting coefficients corresponding to static values, velocity, and acceleration, respectively; that is, the zero-order static feature, first-order dynamic feature, and second-order dynamic feature of cache utilization. This is the comprehensive risk component of indicator M at time t. Specifically, here, the weight of the zero-order static feature of cache utilization is greater than the weight of the first-order dynamic feature of cache utilization, and the weight of the first-order dynamic feature of cache utilization is greater than the weight of the second-order dynamic feature of cache utilization. This is achieved by setting... > > It assigns extremely high penalty weights to drastically changing and rapidly deteriorating network states. Even if the absolute value of the indicator is not high, its drastic dynamic changes will lead to extremely high risk scores, enabling the system to identify high-risk signals in the early stages of congestion storms. This process is applied in parallel to the packet loss count feature vector and the round-trip delay feature vector to obtain the packet loss count comprehensive risk component and the round-trip delay comprehensive risk component, respectively.

[0037] Next, the unit performs a second-level weighted sum calculation. It multiplies each of the three combined risk components obtained in the previous step with another set of preset final fusion weights, and then sums the three products to obtain the final predictive congestion level. This predictive congestion level is a single risk indicator that includes predictions of the network's future state, used to guide subsequent data collection and scheduling strategies. It is expressed by the following formula: in, , , These are the comprehensive risk components of cache utilization, packet loss count, and round-trip latency. , and These are their corresponding final fusion weights. This is a predictive congestion level.

[0038] Specifically, in a concrete numerical calculation example, the buffer occupancy feature vector received by this unit is [0.95, 0.20, 0.05]. Meanwhile, it is assumed that the calculated packet loss count feature vector is [0.01, 0.01, 0.00], and the round-trip delay feature vector is [0.30, 0.00, 0.00]. The weighting coefficients within the first-layer components ( , and The weights are set to (0.2, 0.3, 0.5), following the principle that acceleration weights are greater than velocity weights, and velocity weights are greater than static values. The second layer fusion weights ( , and The values ​​are set to (0.6, 0.1, 0.3). The overall risk component of cache occupancy is calculated. =0.2*0.95+0.3*0.20+0.5*0.05=0.19+0.06+0.025=0.275. Calculate the comprehensive risk component for packet loss count. =0.2*0.01+0.3*0.01+0.5*0.00=0.002+0.003+0.000=0.005. Calculate the comprehensive risk component of round-trip delay. =0.2*0.30+0.3*0.00+0.5*0.00=0.06+0.00+0.00=0.060. Calculate the final predictive congestion level ( =0.6* +0.1* +0.3* =0.6*0.275+0.1*0.005+0.3*0.060=0.165+0.0005+0.018=0.1835. This output value of 0.1835 is the final predictive congestion level, which combines the current values ​​and future trends of all indicators and will serve as the core input for the subsequent dynamic data collection and scheduling module.

[0039] Through the above preferred embodiments, the original static, reactive congestion assessment can be transformed into a dynamic, predictive congestion risk assessment system. By introducing the extraction and weighting of multi-level dynamic features (velocity and acceleration) of network indicator time series, the newly generated predictive congestion level is no longer merely a passive description of the current network state, but an intelligent indicator that can keenly capture the trend of congestion storm formation and quantitatively predict future network risks. This enables the data acquisition system to identify the signs of network deterioration before congestion actually occurs and leads to large-scale data loss, thereby enabling more accurate and timely adaptive scheduling interventions, greatly improving the system's stability and data integrity in high-frequency, bursty data acquisition scenarios.

[0040] In the aforementioned Ethernet-based smart meter data acquisition system 100, the dynamic acquisition scheduling module 130 is used to generate a dynamic scheduling table by performing dynamic acquisition scheduling strategy based on the predictive congestion level and the task priority in the central task request. It should be understood that since the predictive congestion level calculated in the previous step and the task priority in the central task request are two independent but crucial inputs for scheduling decisions, without an effective fusion and transformation mechanism, the system will be unable to transform abstract risk assessments and business requirements into specific, executable acquisition control parameters. Therefore, in the technical solution of this application, a dynamic acquisition scheduling strategy is further generated based on the predictive congestion level and the task priority in the central task request to obtain a dynamic scheduling table. This establishes a complete decision chain from macro-level network status and business importance to micro-level device behavior, matching network carrying capacity with task requirements in real time. This ensures that the generated acquisition strategy can proactively avoid foreseeable network congestion while guaranteeing the service quality of high-priority tasks, transforming the previously conflicting, best-effort data uploads into collaborative, resource-optimized, and orderly data aggregation.

[0041] Figure 4 This is a block diagram of the dynamic acquisition and scheduling module in an Ethernet-based smart meter data acquisition system according to an embodiment of this application. Figure 4 As shown in the embodiments of this application, the dynamic acquisition and scheduling module 130 includes: a task bandwidth upper limit determination unit 131, used to determine the task bandwidth upper limit based on the predictive congestion level, task priority, and physical link bandwidth; a parameter adaptive adjustment unit 132, used to adaptively adjust the single-meter sampling parameters based on the task bandwidth upper limit and the maximum sampling rate to obtain an adaptive sampling rate and a single-meter periodic data volume; a time slot allocation unit 133, used to perform time domain resource partitioning and time slot allocation on the target meter group to obtain a time slot allocation list; and a final scheduling table integration unit 134, used to integrate and generate a final scheduling table based on the adaptive sampling rate, single-meter periodic data volume, and time slot allocation list to obtain a dynamic scheduling table.

[0042] Specifically, the task bandwidth upper limit determination unit 131 is used to determine the task bandwidth upper limit based on the predictive congestion level, task priority, and physical link bandwidth. It should be understood that since the predictive congestion level, task priority, and physical link bandwidth are three independent inputs with different dimensions, they jointly determine the boundary of network resources available for the current task. However, the system needs a clear, quantifiable single indicator to constrain subsequent scheduling calculations. Therefore, in the technical solution of this application, the task bandwidth upper limit is further determined based on the predictive congestion level, task priority, and physical link bandwidth. This transforms the abstract network health status and service importance into a specific bandwidth quota that can be directly used for resource allocation calculations. This provides a solid and dynamically changing resource ceiling for subsequent fine-grained scheduling steps such as adaptive sampling rate adjustment and time slot allocation, ensuring that all scheduling decisions are made within the safe range that the network can bear, thus preventing resource overload at its source.

[0043] More specifically, in a concrete example of this application, the implementation process of the task bandwidth upper limit determination unit is as follows. First, the unit receives three input parameters: a predictive congestion level of 0.1835, an identifier representing a high-priority task, and a physical link bandwidth of 100 Mbps. Next, the unit performs a first-step calculation, which reduces the physical link bandwidth according to the predictive congestion level to obtain the total effective bandwidth currently available in the network. This calculation is: Effective bandwidth = 100 Mbps * (1 - 0.1835) = 81.65 Mbps. Subsequently, the unit performs a second-step calculation, which allocates a bandwidth quota specific to this task from the effective bandwidth based on the task priority. It queries its internal priority weight mapping table to obtain the weight coefficient 0.8 corresponding to high priority, and then calculates the task bandwidth upper limit = 81.65 Mbps * 0.8 = 65.32 Mbps. Finally, the unit outputs the calculated 65.32 Mbps as the task bandwidth upper limit value for use by the subsequent parameter adaptive adjustment unit.

[0044] Specifically, the parameter adaptive adjustment unit 132 is used to adaptively adjust the single-table sampling parameters based on the task bandwidth limit and the maximum sampling rate to obtain an adaptive sampling rate and a single-table periodic data volume. It should be understood that since the task bandwidth limit determined in the previous step is a macro-level resource constraint for the entire data acquisition task, while the maximum sampling rate in the central task request represents the business demand under ideal conditions, there may be a conflict between the two. That is, the total bandwidth required for the ideal demand may exceed the current network's actual carrying capacity. Therefore, in the technical solution of this application, the single-table sampling parameters are further adaptively adjusted based on the task bandwidth limit and the maximum sampling rate to obtain an adaptive sampling rate and a single-table periodic data volume. This establishes a closed-loop feedback adjustment mechanism between demand and resources, dynamically transforming the macro-level bandwidth constraint into micro-level, unified acquisition parameters that can be executed by all meters. This ensures that under any network health condition, the aggregated data traffic generated by all meters strictly adheres to the security boundary, achieving the best balance between data acquisition accuracy and network carrying capacity while ensuring the continuity of the data acquisition task, thus avoiding systemic congestion caused by parameter mismatch from the source.

[0045] More specifically, in a specific example of this application, the implementation process of the parameter adaptive adjustment unit is as follows. The unit receives a task bandwidth limit of 65.32 Mbps, a maximum sampling rate of 6.4 kHz, a number of 200 meters, and a data width of 16 bits per sampling point. First, the unit calculates the total requested bandwidth generated by all meters at the maximum sampling rate. This calculation is: Total requested bandwidth = 6.4 kHz * 200 * 16 bits = 20.48 Mbps. Next, the unit compares the total requested bandwidth of 20.48 Mbps with the task bandwidth limit of 65.32 Mbps. Since the total requested bandwidth is less than the task bandwidth limit, it indicates that network resources are sufficient, and there is no need to lower the sampling rate. Therefore, the unit determines that the final adaptive sampling rate is the maximum sampling rate of 6.4 kHz. Based on this sampling rate, the unit further calculates the amount of data generated by a single meter in one sampling cycle (1 second), i.e., the amount of data generated per meter per cycle = 6.4 kHz * 1 second * 16 bits = 102.4 kbits, or 12.8 KB. Finally, the unit outputs an adaptive sampling rate of 6.4kHz and a single-sheet periodic data volume of 12.8KB, which are then passed to the subsequent time slot allocation unit and the final scheduling table integration unit.

[0046] Specifically, the time slot allocation unit 133 is used to perform time-domain resource partitioning and time slot allocation on the target meter group to obtain a time slot allocation list. It should be understood that although the previous step controlled the total data generation within a collection cycle by adaptively adjusting the sampling rate, it did not constrain the data upload behavior of each meter in terms of time. If all meters simultaneously upload data at the beginning of the collection cycle, a momentary, catastrophic traffic peak, i.e., a data collection storm, will still be formed at the aggregation switch. Therefore, in the technical solution of this application, the target meter group is further partitioned in the time domain and time slots are allocated to obtain a time slot allocation list. This orthogonally decouples the concurrent data streams that were originally aggregated in space in the time dimension, planning a dedicated, conflict-free transmission channel time for each meter. This fundamentally eliminates data upload competition and collisions, transforming uncontrollable burst traffic into a stable, orderly, and predictable serial data stream, thereby maximizing network bandwidth utilization while ensuring low latency and high reliability of data transmission.

[0047] More specifically, in a specific example of this application, the implementation process of the time slot allocation unit is as follows. First, the unit performs time domain resource partitioning. It obtains that the task's acquisition period is 1 second and the number of members in the target meter group is 200. Based on this, it divides the 1-second acquisition period into 200 independent time slots, calculating the duration of each time slot to be 1 second / 200 = 5 milliseconds. Next, the unit performs time slot allocation. It traverses the device list of the target meter group and, according to a predetermined order (e.g., based on the meter asset number), assigns a unique, non-repeating time slot to each meter in the list. For example, the first meter is assigned to the first 5-millisecond time slot (0ms-5ms), the second meter is assigned to the second 5-millisecond time slot (5ms-10ms), and so on, until the last meter is assigned to the 200th time slot (995ms-1000ms). Finally, this unit integrates the mapping relationship between meter identifiers and their corresponding time slot start times to generate a time slot allocation list containing 200 records. This list clearly defines the precise time window during which each meter is authorized to initiate data uploads within the collection period, and is passed as output to the final scheduling table integration unit.

[0048] Specifically, the final scheduling table integration unit 134 is used to integrate and generate a dynamic scheduling table by combining the adaptive sampling rate, the single-sheet periodic data volume, and the time slot allocation list. It should be understood that since the adaptive sampling rate, single-sheet periodic data volume, and time slot allocation list generated in the preceding steps are independent intermediate calculation results, they have not yet formed a unified instruction set that can be directly parsed and executed by the terminal device. Therefore, in the technical solution of this application, the adaptive sampling rate, single-sheet periodic data volume, and time slot allocation list are further integrated and generated by the final scheduling table to obtain a dynamic scheduling table. This structurally binds the global acquisition parameters with individualized time-domain scheduling information, generating a unique scheduling entry containing complete execution parameters for each device in the target meter group. This ensures that the control instructions for the entire collaborative acquisition task are solidified into an atomic, distributable data structure, providing the final and indispensable basis for the accurate issuance of subsequent instructions and the autonomous and orderly execution of each meter, thereby closing the entire control loop from state perception to collaborative execution.

[0049] More specifically, in a specific example of this application, the implementation process of the final scheduling table integration unit is as follows. First, the unit receives three core input data: a globally applicable adaptive sampling rate value of 6.4kHz, a globally applicable single-sheet periodic data volume value of 12.8KB, and a time slot allocation list containing 200 mapping records. Next, the unit initializes an empty dynamic scheduling table data structure and begins traversing each record in the time slot allocation list. Taking the first record in the list as an example, this record specifies that the meter with asset number Meter_001 is allocated a time slot of 0ms-5ms. The unit creates a new scheduling entry for Meter_001, filling the corresponding field of the entry with the globally applicable adaptive sampling rate of 6.4kHz and the single-sheet periodic data volume of 12.8KB, while also writing the time slot information (e.g., start time 0ms). The unit repeats this process until scheduling entries containing their unique identifier, unified acquisition parameters, and dedicated upload time slots are generated for all 200 meters in the time slot allocation list. Ultimately, the complete set of these 200 scheduling entries constitutes the final dynamic scheduling table, ready to be distributed to the target meter group.

[0050] In the aforementioned Ethernet-based smart meter data acquisition system 100, the scheduling table distribution module 140 is used to distribute the dynamic scheduling table to all smart meters within the target meter group via broadcast. It should be understood that since the dynamic scheduling table generated in the previous step is a centralized instruction set located in the local memory of the data concentrator (acting as a coordinator), and the main entities performing the acquisition and upload tasks are two hundred smart meters distributed across the network, issuing instructions via point-to-point communication would not only significantly increase the total instruction distribution time and delay the start of the entire collaborative acquisition cycle, but would also generate a large number of control messages in a short period, placing an unnecessary burden on the network. Therefore, in the technical solution of this application, the dynamic scheduling table is further distributed to all smart meters within the target meter group via broadcast, thereby utilizing a highly efficient one-to-many communication paradigm to achieve synchronous and full-coverage distribution of control instructions to the entire target group at the transmission cost of a single data packet. This minimizes the delay in instruction distribution, ensuring that all meters receive completely consistent scheduling instructions on the same time base, providing a crucial synchronization prerequisite and instruction consistency guarantee for all members to strictly follow the schedule in their collaborative actions.

[0051] More specifically, in a concrete example of this application, the implementation process of the dynamic acquisition and scheduling module is as follows. First, the protocol stack within the data concentrator serializes the dynamic scheduling table generated in the previous step, which contains 200 scheduling entries, converting it into a continuous byte stream, and uses this as the application layer data payload. Next, the DCU encapsulates this data payload into a UDP datagram, specifying a pre-defined port number in the UDP header. Subsequently, at the network layer, the UDP datagram is encapsulated into an IP packet, the key being that the destination IP address is set to the broadcast address of the local Ethernet subnet, such as 192.168.1.255. Finally, at the data link layer, the IP packet is encapsulated into an Ethernet frame, with its destination MAC address set to the broadcast MAC address FF:FF:FF:FF:FF:FF. The resulting Ethernet frame is sent out through the DCU's physical port. After receiving this broadcast frame, the aggregation switch in the local network will copy it and forward it to all other ports except the source port, thus ensuring that all 200 smart meters connected to the switch can receive this broadcast data packet containing the complete dynamic scheduling table.

[0052] In the aforementioned Ethernet-based smart meter data acquisition system 100, the meter data acquisition module 150 is used for each smart meter to extract its own meter-specific scheduling entries from the dynamic scheduling table, and to acquire data based on these meter-specific scheduling entries to obtain cached data packets. It should be understood that since the dynamic scheduling table broadcast in the previous step is a global instruction set containing scheduling information for all target meters, and each smart meter only needs to concern itself with and execute its own specific task parameters, without an effective instruction parsing and extraction mechanism, this global instruction cannot be transformed into individualized, executable device behavior. Therefore, in the technical solution of this application, each smart meter further extracts its own meter-specific scheduling entries from the dynamic scheduling table, and acquires data based on these meter-specific scheduling entries to obtain cached data packets. This completes the key transformation from centralized instructions to distributed, autonomous execution, enabling each meter to accurately identify and internalize its role and the rules it must follow in the entire collaborative acquisition process. This ensures that the global scheduling strategy is unambiguously decomposed and implemented at every execution end, laying a solid data and status foundation for all subsequent meters to upload data accurately and orderly within their respective designated time windows.

[0053] More specifically, in a concrete example of this application, the execution process of the smart meter is as follows. First, the smart meter with asset number Meter_001 receives the broadcast data packet on its network interface. Its protocol stack parses the data packet layer by layer, finally delivering the UDP payload containing the dynamic scheduling table to the upper-layer application. Next, the meter's control program deserializes the received byte stream, restoring it to a structured scheduling table containing 200 records. Subsequently, the program traverses this scheduling table, searching for the meter identifier field in each record and comparing it with its own fixed asset number Meter_001. After finding a matching entry, it immediately extracts the key execution parameters from this dedicated scheduling entry: an adaptive sampling rate of 6.4kHz and an upload time slot start time of 0ms. Finally, the meter performs data acquisition based on the extracted parameters. It immediately configures the sampling frequency of its internal metering chip or ADC module to 6.4kHz and initiates the digital acquisition of analog quantities such as voltage and current. During the next 1-second acquisition cycle, the acquired data is continuously written to a local send buffer until a complete data packet with a network header added is formed, which is the cached data packet. This data packet is kept in a ready state locally, waiting for its 0ms upload time to arrive.

[0054] In summary, the Ethernet-based smart meter data acquisition system according to the embodiments of this application is explained. It abandons passive congestion monitoring and actively calculates a predictive congestion level by analyzing the rate of change and acceleration of key network indicators over time. Then, the system deeply integrates this predictive level with task priorities, dynamically generating a dynamic scheduling table that assigns a dedicated upload time slot and adaptive sampling rate to each meter. Finally, each meter uploads data in an orderly, staggered manner according to this scheduling table. This solution fundamentally avoids the formation of data acquisition storms by transforming synchronous concurrent data floods into asynchronous time-division data streams, thereby ensuring the integrity and timeliness of key data acquisition under high network pressure.

[0055] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A smart meter data acquisition system based on Ethernet, characterized in that, include: The task distribution module is used to distribute task collection based on the central task request in order to obtain the local collaborative mode activation status. The congestion level prediction module is used to calculate the predictive congestion level based on the acquired raw SNMP data and raw RTT data. The dynamic acquisition and scheduling module is used to generate a dynamic acquisition and scheduling strategy based on the predictive congestion level and the task priority in the central task request to obtain a dynamic scheduling table. The scheduling table distribution module is used to distribute the dynamic scheduling table to all smart meters in the target meter group via broadcast. The meter data acquisition module is used by each smart meter to extract its own meter-specific scheduling entries from the dynamic scheduling table, and to collect data based on these meter-specific scheduling entries to obtain cached data packets.

2. The smart meter data acquisition system based on Ethernet according to claim 1, characterized in that, The data acquisition task distribution module is used for: In response to receiving a system event trigger, perform topology parsing and resource mapping on the system event trigger to obtain the central task request; Based on the central task request, task assignment and coordinator role establishment are carried out to obtain the received central task request. Based on the received central task request, activate the local collaboration mode and pre-notify group members to obtain the local collaboration mode activation status and collaboration activation signaling.

3. The smart meter data acquisition system based on Ethernet according to claim 1, characterized in that, The congestion level prediction module includes: The time-series data conversion unit is used to collect time-series indicator data and construct sliding windows from raw SNMP data and raw RTT data to obtain time series of cache utilization, packet loss count, and round-trip latency values. The multi-stage dynamic feature extraction unit is used to perform multi-stage dynamic feature extraction on the time series of cache utilization, packet loss count, and round-trip latency to obtain cache utilization feature vector, packet loss count feature vector, and round-trip latency feature vector. The predictive congestion level fusion unit is used to perform predictive congestion level fusion calculation on the buffer occupancy feature vector, packet loss count feature vector and round-trip delay feature vector to obtain the predictive congestion level.

4. The Ethernet-based smart meter data acquisition system according to claim 3, characterized in that, The multi-stage dynamic feature extraction unit is used for: Extract zero-order static features of cache utilization from the time series of cache utilization; Extract first-order dynamic features of cache utilization from the time series of cache utilization; Extract second-order dynamic features of cache utilization from the time series of cache utilization; The zero-order static feature, the first-order dynamic feature, and the second-order dynamic feature of cache utilization are vectorized to obtain the cache utilization feature vector.

5. The Ethernet-based smart meter data acquisition system according to claim 4, characterized in that, The predictive congestion level fusion unit is used for: The cache utilization feature vector, packet loss count feature vector, and round-trip latency feature vector are weighted within their respective components to obtain the comprehensive risk components of cache utilization, packet loss count, and round-trip latency. The predictive congestion level is obtained by calculating the weighted sum of the comprehensive risk components of cache occupancy, packet loss count, and round-trip delay.

6. The Ethernet-based smart meter data acquisition system according to claim 5, characterized in that, The weight of the zero-order static feature of cache utilization is greater than that of the first-order dynamic feature of cache utilization, and the weight of the first-order dynamic feature of cache utilization is greater than that of the second-order dynamic feature of cache utilization.

7. The Ethernet-based smart meter data acquisition system according to claim 1, characterized in that, The dynamic acquisition and scheduling module includes: The task bandwidth limit determination unit is used to determine the task bandwidth limit based on the predictive congestion level, task priority, and physical link bandwidth. The parameter adaptive adjustment unit is used to adaptively adjust the single-table sampling parameters based on the task bandwidth limit and the maximum sampling rate to obtain the adaptive sampling rate and the amount of data per single table period. The time slot allocation unit is used to perform time domain resource partitioning and time slot allocation on the target meter group to obtain a time slot allocation list; The final scheduling table integration unit is used to integrate and generate a dynamic scheduling table by considering the adaptive sampling rate, the amount of data per period in a single form, and the time slot allocation list.

Images