A highway toll management method and system based on an edge cloud architecture

Abstract

The application provides a highway toll management method and system based on an edge cloud architecture, and relates to the technical fields of intelligent transportation and edge computing. Edge computing nodes, service calling ports and roadside sensing data streams in a toll road network are identified. The edge computing nodes are taken as local decision domains, and the computing power load fluctuation rate generated by toll transaction behavior is extracted. The computing power load fluctuation rate is mapped to an edge computing node load portrait set, and segmented refreshing is performed according to the tidal period characteristics of the toll business. The peak value and the valley value of the computing power load fluctuation rate are located in the refreshed load portrait set, the collaborative complementary index between the edge computing nodes is calculated, and roadside computing power scheduling and deployment suggestion strategies are generated. The application can evaluate the resource complementary capability between the edge computing nodes before the toll business is opened, realize cross-node computing power collaborative scheduling, effectively cope with the tidal traffic impact in the highway toll scene, and improve the overall service level guarantee level of the toll system.

Description

Technical Field

[0001] This invention relates to the fields of intelligent transportation and edge computing technology, and more specifically, to a highway toll management method and system based on an edge cloud architecture. Background Technology

[0002] With the continuous expansion of the expressway network and the rapid growth of motor vehicle ownership, toll collection services place higher demands on the real-time performance and reliability of computing resources. Traditional centralized cloud architectures upload all toll data to a central server for processing, resulting in problems such as high data transmission latency, concentrated pressure on backbone network bandwidth, and a wide impact from single points of failure. Edge computing architectures, by pushing computing power down to edge computing nodes closer to toll lanes, can significantly reduce processing latency and improve the response speed of the toll collection system.

[0003] However, highway toll collection exhibits significant tidal characteristics. During peak hours, holidays, and other specific periods, some toll booths or lanes' edge computing nodes may face the risk of momentary overload, leading to excessive transaction processing latency and reduced traffic efficiency. Meanwhile, edge computing nodes in adjacent road sections or opposing lanes may be in a low-load, idle state. In existing technologies, each edge computing node typically operates independently, lacking a dynamic perception and collaborative scheduling mechanism for the load status between nodes, making it difficult to achieve elastic cross-node allocation of computing resources.

[0004] Furthermore, different toll lane types have different requirements for service level agreements (SLPs). ETC lanes require millisecond-level rapid response, while mixed lanes and manual lanes have relatively longer latency tolerances. Existing solutions do not fully consider the differentiated needs of different business types when assessing the load status of edge computing nodes, resulting in inaccurate risk assessments and a lack of targeted scheduling decisions.

[0005] Therefore, there is an urgent need for a method and system that can dynamically sense the load status of edge computing nodes, quantitatively assess the resource complementarity capabilities between nodes, and generate computing power collaborative scheduling strategies based on the differences in business types, in order to solve the above-mentioned technical problems. Summary of the Invention

[0006] The purpose of this invention is to provide a highway toll management method and system based on an edge cloud architecture, to solve the technical problems in existing technologies where there is a lack of collaborative scheduling mechanisms among edge computing nodes, making it difficult to cope with the tidal impact of toll collection operations. In view of the above-mentioned technical problems, this invention provides a highway toll management method and system based on an edge cloud architecture.

[0007] In a first aspect, the present invention provides a highway toll management method based on an edge cloud architecture, the method comprising:

[0008] Step S1: Identify the edge computing nodes in the toll road network, the service call ports inside the edge computing nodes, and the roadside sensing data stream;

[0009] Step S2: Using the edge computing nodes as the local decision domain, identify each edge computing node that has engaged in toll transactions and associate it with the corresponding roadside sensing data stream. Extract the computing load volatility based on the association results.

[0010] Step S3: Map the computing power load volatility to the edge computing power node load profile set, and perform a segmented refresh operation on the edge computing power node load profile set according to the tidal time characteristics of the charging service.

[0011] Step S4: Locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set to define the synergy and complementarity index between edge computing nodes; based on the synergy and complementarity index, generate roadside computing power scheduling and deployment recommendation strategies for toll services.

[0012] Furthermore, the specific implementation process for identifying the toll road network includes:

[0013] The system collects statistics on all open service call ports of edge computing nodes and the roadside sensing data streams carried by each service call port, and establishes indexes for the service call ports and roadside sensing data streams respectively.

[0014] The roadside sensing data stream contains the service call ports that execute toll collection business logic. The service call ports are clustered and divided through the roadside sensing data stream to form port dependency groups of the roadside sensing data stream.

[0015] Furthermore, the specific implementation process for extracting the computing load volatility based on the correlation results includes:

[0016] Treating a single edge computing node as a local decision domain, the roadside sensing data stream is associated and locked based on the charging business logic executed by each service call port of the edge computing node. If the processing behavior of a certain roadside sensing data stream is triggered through the internal service call port of a certain edge computing node, the roadside sensing data stream is associated and locked; otherwise, the roadside sensing data stream is not associated and locked.

[0017] Based on the association locking results, the computing load volatility generated by the internal service call port of the edge computing node when processing the roadside sensing data stream is obtained. The computing load volatility is defined as: the relative deviation of the average processing latency of a single toll transaction generated by each service call port of the edge computing node in processing the roadside sensing data stream during the life cycle from establishment to release of the roadside sensing data stream, relative to the benchmark value of the single transaction processing latency measured by the edge computing node when executing the built-in simulated transaction calculation task during the idle period.

[0018] The average processing latency of a single charging transaction is the ratio of the total processing latency over the lifetime to the number of transactions; the built-in simulated transaction calculation task is a set of standardized charging business logic that the edge computing node periodically executes locally when there is no external charging request, used to calibrate the node's theoretical minimum processing latency.

[0019] Furthermore, the specific implementation process of performing the segmented refresh operation includes:

[0020] When an edge computing node is regarded as a local decision domain, the computing load fluctuation rate generated by each service call port within the edge computing node when processing the data streams of each roadside perception is summarized, and an edge computing node load profile set is established.

[0021] Based on the inherent tidal time period characteristics of toll collection services, time slices are divided, and a certain toll collection service time slice is used as the observation window corresponding to the life cycle of each roadside sensing data stream. Within the observation window, the load profile set of each edge computing node is refreshed in segments.

[0022] Furthermore, the specific implementation process for determining the peak and trough values ​​of the location computing power load volatility includes:

[0023] In the updated edge computing node load profile set, the peak and trough values ​​of computing load volatility are located respectively.

[0024] Traverse the discrete sampling sequence of load volatility within the observation window, set the sampling interval, and count the number of continuous sampling points exceeding the service level agreement guarantee baseline and the cumulative over-limit sum.

[0025] Assess the over-limit risk index and idle margin index of edge computing nodes within the observation window;

[0026] The Service Level Agreement (SLA) guarantee baseline includes differentiated baseline parameters set according to the toll service type. The baseline parameters include a first baseline for ETC lanes, a second baseline for mixed lanes, and a third baseline for manual lanes. The SLA guarantee baseline selects the first, second, and third baselines based on the toll service type corresponding to the roadside perception data stream processed by the edge computing node. If the edge computing node selects a combination of the first, second, and third baselines, the corresponding baselines are substituted into the formulas for the over-limit risk index and the idle margin index to calculate the independent over-limit risk index and the independent idle margin index, respectively. The largest independent over-limit risk index is taken as the over-limit risk index, and the smallest independent idle margin index is taken as the idle margin index.

[0027] Furthermore, the specific implementation process for defining the collaborative complementarity index among edge computing nodes includes:

[0028] Obtain network transmission latency and available bandwidth between edge computing nodes, and set collaborative reachability condition trigger values;

[0029] Evaluate the synergistic complementarity index of the two edge computing nodes within the observation window.

[0030] Furthermore, the specific implementation process of generating roadside computing power scheduling and deployment recommendation strategies for toll collection services includes:

[0031] Based on the calculation results of the synergistic complementarity index, roadside computing power scheduling instructions are generated:

[0032] Preset collaborative scheduling trigger thresholds and global scheduling trigger thresholds;

[0033] If the synergy complementarity index is greater than or equal to the synergy scheduling trigger threshold, it is determined that there is a resource complementarity condition between the two edge computing power nodes within the observation window, and a suggestion is output to include the two edge computing power nodes in the same edge computing power resource pool to smooth out the tidal impact of charging services.

[0034] If the collaborative complementarity index is not greater than or equal to the collaborative scheduling trigger threshold, it is determined that there is no resource complementarity between the two edge computing power nodes within the observation window, and it is determined whether the over-limit risk index of the two edge computing power nodes is greater than or equal to the global scheduling trigger threshold.

[0035] If the risk index of both edge computing nodes is greater than or equal to the global scheduling trigger threshold, a regional global scheduling request is triggered to incorporate the two edge computing nodes into the central cloud node and output a suggestion to call global computing resources from the central cloud node.

[0036] If the risk index of both edge computing nodes is not greater than or equal to the global scheduling trigger threshold, and the output is a suggestion to perform local caching peak shaving or dynamic rate limiting control on the charging services carried by the two edge computing nodes;

[0037] Based on the roadside computing power scheduling instructions, the deployment recommendation strategy is executed to generate toll service flow table update instructions:

[0038] When it is determined that there are conditions for resource complementarity between edge computing nodes, a paid service migration tunnel is established between edge computing nodes where resource complementarity conditions exist, so as to interconnect the idle service call ports between edge computing nodes.

[0039] When a regional-level global scheduling request is triggered, the toll service overload status is reported to the regional scheduling controller, which then readjusts the service processing assignment relationship between each edge computing node and the toll lane based on the load view of the entire network's edge computing nodes.

[0040] When it is determined that local cache peak shaving should be performed, the fee transaction requests that exceed the processing capacity of the edge computing nodes will be temporarily stored in the local high-speed cache queue and asynchronously reissued during the load reduction period in a first-in-first-out order.

[0041] Furthermore, the specific implementation process for establishing the toll service migration tunnel includes:

[0042] One of the two edge computing nodes that have complementary resources is marked as the source edge computing node, and the other edge computing node is marked as the destination edge computing node.

[0043] Insert flow table forwarding rules into the task distribution component of the source edge computing node to modify the destination address of the roadside perception data stream corresponding to the target lane to the service call port of the business processing of the destination edge computing node;

[0044] A temporary processing instance is created in the service processing component of the edge computing node. The temporary processing instance independently processes the migration of the toll service during the existence of the toll service migration tunnel and automatically releases the occupied computing resources after the toll service migration tunnel is dismantled.

[0045] Secondly, the present invention also provides a highway toll management system based on an edge cloud architecture. The system includes: a memory, a processor, an edge computing node management module, a computing load analysis module, a load profile refresh module, and a collaborative scheduling module. The memory stores a highway toll management program based on the edge cloud architecture, which is executed by the processor to realize the functions of each module of the edge computing node management module, the computing load analysis module, the load profile refresh module, and the collaborative scheduling module.

[0046] The edge computing node management module is used to identify edge computing nodes in the toll road network, service call ports within the edge computing nodes, and roadside sensing data streams. The computing load analysis module is used to determine each edge computing node that has engaged in toll transactions and associate it with the corresponding roadside sensing data stream, using the edge computing nodes as the local decision domain, and extract the computing load volatility based on the association results. The load profile refresh module is used to map the computing load volatility to the edge computing node load profile set and perform segmented refresh operations on the edge computing node load profile set according to the tidal characteristics of toll business. The collaborative scheduling module is used to locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set to define the collaborative complementarity index between edge computing nodes, and generate roadside computing power scheduling and deployment suggestions for toll business based on the collaborative complementarity index.

[0047] Furthermore, the collaborative scheduling module incorporates a collaborative complementarity index calculation subunit and a strategy generation subunit, used to collaboratively generate roadside computing power scheduling and deployment recommendation strategies; the collaborative complementarity index calculation subunit is used to calculate the collaborative complementarity index based on the over-limit risk index, the idle margin index, network transmission latency, and available bandwidth; the strategy generation subunit generates toll service migration tunnel establishment instructions, regional global scheduling request instructions, or local cache peak shaving instructions based on the collaborative complementarity index.

[0048] One or more technical solutions provided in this invention have at least the following technical effects or advantages:

[0049] (1) By introducing the computing power load volatility as a quantitative indicator of the load status of edge computing power nodes, the load level is measured by the relative deviation of the average processing time of a single fee transaction relative to the idle benchmark value. This eliminates the absolute performance difference between nodes with different hardware configurations, making the load comparison across nodes more accurate and fair.

[0050] (2) By performing segmented updates on the load profile set of edge computing nodes based on the tidal time characteristics of toll collection services, the load profile can dynamically follow the time distribution pattern of traffic flow, providing timely data support for subsequent scheduling decisions.

[0051] (3) By constructing a two-dimensional assessment system of over-limit risk index and idle margin index, the risk contribution of over-limit duration, cumulative over-limit magnitude and instantaneous peak value are comprehensively considered. Different service level agreement guarantee baselines are set for ETC lanes, mixed lanes and manual lanes to achieve a refined assessment of node load status.

[0052] (4) By calculating the collaborative complementarity index, the resource complementarity between adjacent edge computing nodes is quantitatively evaluated, and the collaborative reachability is judged in combination with physical constraints such as network transmission delay and available bandwidth, so as to ensure the feasibility of collaborative scheduling decisions.

[0053] (5) Through progressive scheduling decision logic, the idle computing power of neighboring nodes is used first for collaborative migration. When both are severely overloaded, regional global scheduling is triggered. In other cases, local cache is used to smooth out peaks, forming a multi-level elastic computing power allocation system from local collaboration to global scheduling, effectively coping with the tidal impact of charging services.

[0054] The above description is merely an overview of the technical solution of the present invention. To better understand the technical means of the present invention and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of the present invention more apparent, specific embodiments of the present invention are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily apparent from the following description. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0056] Figure 1 This is a schematic diagram illustrating the steps of a highway toll management method based on an edge cloud architecture according to the present invention.

[0057] Figure 2 This is a schematic diagram of the structure of a highway toll management system based on an edge cloud architecture according to the present invention. Detailed Implementation

[0058] This invention provides a highway toll management method and system based on an edge cloud architecture, which solves the technical problems in the prior art such as the lack of a collaborative scheduling mechanism among edge computing nodes, the difficulty in coping with the tidal impact of toll business, and the inability to assess the load status according to the differences in business types. Specifically, this invention uses the single transaction processing latency measured by edge computing nodes under idle conditions as a benchmark, and defines the relative deviation of actual business processing latency as the computing load volatility, eliminating the evaluation bias caused by heterogeneous hardware. Based on this, it constructs an over-limit risk index that integrates over-limit duration, cumulative over-limit magnitude, and instantaneous peak risk contribution, as well as an idle margin index that incorporates over-limit duration correction. Furthermore, it sets differentiated service level agreement guarantee baselines for ETC lanes, mixed lanes, and manual lanes, achieving refined and differentiated evaluation of node load status. Further, it quantitatively characterizes the degree of resource complementarity between adjacent nodes ("one overloaded, one idle") through a collaborative complementarity index, and introduces network latency and available bandwidth as physical constraints for collaborative reachability, ensuring the engineering feasibility of scheduling decisions. Finally, it generates a multi-level elastic computing power allocation strategy according to progressive priorities, from inter-node collaborative migration to regional global scheduling and then to local cache peak shaving. Based on the above-mentioned technical context, this invention achieves the technical effects of dynamically sensing the load status of edge computing nodes, accurately quantifying the resource complementarity capabilities between nodes, effectively mitigating the impact of toll collection surges, improving the overall service level of the toll collection system, and enhancing the system's resilience under extreme conditions.

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. It should be understood that the present invention is not limited to the exemplary embodiments described herein. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. It should also be noted that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, and not all of them.

[0060] Example 1, please refer to Figure 1 This paper provides a highway toll management method based on an edge cloud architecture, the method comprising:

[0061] Step S1: Identify the edge computing nodes in the toll road network, the service call ports inside the edge computing nodes, and the roadside sensing data stream;

[0062] Specifically, all open service call ports of the edge computing nodes and the roadside sensing data streams carried by each service call port are statistically analyzed. Indexes are then established for both the service call ports and the roadside sensing data streams, and the i-th service call port is marked as... Mark the j-th roadside sensing data stream as ;

[0063] The roadside sensing data stream contains the service call ports for executing toll collection logic. The service call ports are clustered and divided to form roadside sensing data streams. The port dependency group, denoted as Where I represents the total number of service call ports.

[0064] Step S2: Using the edge computing nodes as the local decision domain, identify each edge computing node that has engaged in toll transactions and associate it with the corresponding roadside sensing data stream. Extract the computing load volatility based on the association results.

[0065] Specifically, a single edge computing node is considered as a local decision domain. Based on the tolling business logic executed by each service call port of the edge computing node, the roadside perception data stream is correlated and locked. If it passes through the m-th edge computing node... The internal service call port triggered the data stream from the roadside sensing system. The processing behavior then affects the roadside sensing data stream. Perform association locking if it is through the m-th edge computing node The internal service call port did not trigger the data flow for roadside sensing. The processing behavior does not affect the roadside sensing data stream. Perform association locking;

[0066] Based on the association locking results, obtain the edge computing nodes. The internal service call port processes roadside sensing data streams. The fluctuation rate of computing load generated at that time is denoted as The computing load fluctuation rate is defined as: the fluctuation rate of roadside sensing data streams. During the lifecycle from establishment to release, edge computing nodes Each service calls a port to process roadside sensing data streams. The average processing latency of a single fee transaction, relative to edge computing nodes. The relative deviation of the benchmark value of single transaction processing latency measured when the built-in simulated transaction calculation task is executed during idle periods;

[0067] The average processing latency of a single charge transaction is the ratio of the total processing latency over the lifetime to the number of transactions. The built-in simulated transaction calculation task is a set of standardized charging business logic that edge computing nodes periodically execute locally when there is no external charging request, used to calibrate the node's theoretical minimum processing latency.

[0068] Considering the significant differences in hardware configurations (such as CPU model, clock speed, and memory capacity) among different edge computing nodes, directly comparing absolute processing latency cannot accurately reflect the load saturation of each node relative to its own processing capacity. Normalization to a relative deviation amplitude ensures consistency and comparability in cross-node load comparisons. Furthermore, considering that single-transaction processing latency is a key indicator directly affecting the driver's experience, using this indicator as a load measure provides a more accurate reflection of the operational quality of the toll collection service than underlying system indicators such as CPU utilization and memory usage. Therefore, the computing load volatility uses the single-transaction processing latency measured by edge computing nodes executing built-in simulated transaction calculation tasks under completely idle conditions as a theoretical benchmark. The average single-transaction processing latency measured when the node is actually handling toll collection services is compared with this benchmark value, and the relative deviation amplitude characterizes the node's load level.

[0069] Step S3: Map the computing power load volatility to the edge computing power node load profile set, and perform segmented refresh operation on the edge computing power node load profile set according to the tidal time characteristics of the charging service.

[0070] Specifically, edge computing nodes When considered as a local decision domain, the edge computing power nodes are aggregated. The internal service call ports handle the computing load fluctuations generated when processing the sensing data streams from various roadside nodes, and establish a load profile set for edge computing nodes. J represents the total amount of roadside sensing data stream;

[0071] Based on the inherent tidal time period characteristics of toll collection services, time slices are divided. The k-th toll collection service time slice is used as the observation window corresponding to the lifecycle of each roadside sensing data stream. Within the observation window, the load profile of each edge computing node is refreshed in segments. The refreshed result is recorded as .

[0072] Step S4: Locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set to define the synergy and complementarity index between edge computing nodes; based on the synergy and complementarity index, generate roadside computing power scheduling and deployment recommendation strategies for toll collection services.

[0073] Specifically, step S4 includes the following sub-steps:

[0074] S4.1, Locating peak and valley values:

[0075] Load profile of edge computing nodes The peak values ​​of computing power load volatility are located in the middle. and the bottom value .

[0076] S4.2, Statistical Exceeding Limits:

[0077] Traversing the discrete sampling sequence of load volatility within the observation window The sampling interval is Statistics exceed the service level agreement guarantee baseline. Number of continuous sampling points and cumulative over-limit range and .

[0078] S4.3 Introduce differentiated service level agreement (SLA) baselines:

[0079] Service Level Agreement (SLA) Guarantee Baseline This includes differentiated baseline parameters set according to the type of toll collection service. The baseline parameters include the first baseline corresponding to the ETC lane. The second baseline corresponding to the mixed lane and the third baseline corresponding to the manual lane Service Level Agreement (SLA) Guarantee Baseline The first baseline is selected based on the toll collection service type corresponding to the roadside perception data stream processed by the edge computing nodes. Second baseline and the third baseline If the edge computing nodes select the first baseline Second baseline and the third baseline When combining the two, the corresponding baselines are substituted into the formulas for the excess risk index and the idle margin index to calculate the independent excess risk index and the independent idle margin index, respectively. The largest independent excess risk index is taken as the excess risk index, and the smallest independent idle margin index is taken as the idle margin index.

[0080] S4.4 Calculate the over-limit risk index and the idle margin index:

[0081] Evaluate edge computing nodes Over-limit risk index within the k-th observation window And idle margin index :

[0082] ;

[0083] In the formula, Represents edge computing nodes The sampled value of the computing power load fluctuation rate at sampling time t, where S is the total number of sampling points. The preset cumulative over-limit threshold, Risk contribution for exceeding time limits Risk contribution in the cumulative over-limit dimension and Risk contribution in the instantaneous peak dimension , and The value is determined by configuring it differently based on the sensitivity of the charged business to different risk dimensions, and it meets the following requirements: , This is the idle confidence factor, used to adjust the confidence level for calculating the idle margin index. Minimum idle trust level and Minimum idle trust is used to characterize the basic idle trust level retained under a continuous overload of charging tasks.

[0084] It is worth mentioning that after obtaining the time series of computing load volatility, this invention comprehensively evaluates the node status from two orthogonal perspectives: risk and idleness. The overload risk index decomposes the degree to which load volatility exceeds the service level agreement (SLA) baseline into three weighted dimensions. The first dimension represents the risk contribution of overload duration and the proportion of overload time within the observation window. The second dimension represents the risk contribution of cumulative overload magnitude and the normalized integral of the overload magnitude over time. The third dimension represents the risk contribution of instantaneous peak and the relative degree of maximum load deviation from the baseline within the observation window. For scenarios with instantaneous spikes but rapid recovery, evaluating solely based on peak value might be misjudged as high-risk; introducing the duration dimension allows for reasonable weight reduction. The idle margin index is based on the deviation of the load volatility trough value from the baseline, while also introducing a correction factor related to overload duration. Considering that if a node is in an overloaded state for a long period within the observation window, even if a low trough value occurs at a certain moment, the actual stable idle computing power it can provide is limited, a correction factor is introduced. .

[0085] S4.5, Set collaborative reachability conditions:

[0086] Obtain edge computing nodes With edge computing nodes Network transmission latency between and available bandwidth Set collaborative reachability condition trigger value If satisfied and Then let If not satisfied and Then let In the formula, To maximize the tolerable collaboration latency for paid services, a pre-set value is provided based on the real-time requirements of these services. The minimum collaborative bandwidth threshold is preset based on the minimum bandwidth guarantee required for data transmission of chargeable services.

[0087] S4.6 Calculate the synergistic complementarity index:

[0088] Evaluate edge computing nodes With edge computing nodes Synergistic complementarity index within the k-th observation window In the formula, It is a bidirectional overload penalty coefficient used to suppress the synergistic complementarity index when both edge computing nodes present the risk of overload in charging tasks.

[0089] It is worth mentioning that the synergy and complementarity index is used to quantify the degree of resource complementarity between two edge computing nodes. For positive complementarity, it represents the product of the risk of node m and the idle resources of node m+1. In one possible case, when the overload risk of node m is high and the idle resources of node m+1 are sufficient, this value is larger, indicating that node m+1 has the ability to absorb the overflow traffic of node m. This is a symmetric term, representing the product of the risk of node m+1 and the idleness of node m, used to capture reverse resource complementarity relationships; As a penalty term, one possible scenario is that when two nodes simultaneously exhibit a high risk of overload, even if the product term may have a non-zero value due to certain factors, the penalty term will suppress the cooperative complementarity index to a low level, preventing the system from attempting ineffective inter-node cooperation when both nodes are already overloaded. As a collaborative reachability switch, it determines whether there is a practically usable collaborative channel between two nodes based on two physical constraints: network transmission latency and available bandwidth, thus ensuring the feasibility of scheduling decisions in engineering.

[0090] S4.7, Generate scheduling decisions and execution instructions:

[0091] Preset coordinated scheduling trigger threshold and global scheduling trigger threshold ;

[0092] Based on the calculation results of the synergy and complementarity index, roadside computing power scheduling instructions are generated in the following priority order:

[0093] The first priority is inter-node collaboration: if the collaboration complementarity index is satisfied... Then determine the edge computing node within the k-th observation window. With edge computing nodes There are conditions for resource complementarity, and the output will be edge computing nodes. With edge computing nodes A suggestion is made to incorporate them into the same edge computing resource pool to mitigate the impact of toll collection surges. In this case, a toll collection migration tunnel is established between edge computing nodes with complementary resources to interconnect idle service call ports. Specifically, one of the two edge computing nodes with complementary resources is designated as the source edge computing node, and the other as the destination edge computing node. A flow table forwarding rule is inserted into the task distribution component of the source edge computing node to modify the destination address of the roadside sensing data stream corresponding to the target lane to the service call port for the business processing of the destination edge computing node. A temporary processing instance is created in the business processing component of the destination edge computing node. This temporary processing instance independently processes the toll collection migration during the existence of the toll collection migration tunnel and automatically releases the occupied computing resources after the tunnel is dismantled.

[0094] The second priority is regional-level global scheduling: if the first priority condition is not met, but is met... and This triggers a regional-level global scheduling request, which will allocate edge computing nodes. With edge computing nodes Integrate into the central cloud node to provide suggestions for requesting global computing resources from the central cloud node. Specifically, report the overload status to the regional scheduling controller, which then readjusts the business processing assignment relationship between each edge computing node and the toll lane based on the load view of the entire network's edge computing nodes, offloading overloaded traffic to more distant, low-load edge computing nodes or the central cloud node.

[0095] The third priority is local peak shaving: if neither of the above two priority conditions is met, and the output is for edge computing nodes. With edge computing nodes The suggestion is to implement local caching for peak shaving or dynamic rate limiting for the charged services carried; specifically, to temporarily store the charged transaction requests that exceed the processing capacity of the edge computing nodes in the local high-speed cache queue, and to asynchronously reissue them during the load fallback period in a first-in-first-out order.

[0096] Example 2, please refer to Figure 2 This paper provides a highway toll management system based on an edge cloud architecture, which includes:

[0097] The system includes a memory module, a processor module, an edge computing node management module, a computing load analysis module, a load profile refresh module, and a collaborative scheduling module.

[0098] The memory stores a highway toll management program based on an edge cloud architecture, which, when executed by the processor, implements the functions of the aforementioned modules.

[0099] Specifically, the functions of each module are as follows:

[0100] Edge computing node management module: used to identify edge computing nodes in the toll road network, service call ports inside the edge computing nodes, and roadside sensing data streams.

[0101] Computing load analysis module: It is used to identify each edge computing node that has a toll transaction behavior and associate it with the corresponding roadside perception data stream, and extract the computing load volatility based on the association results, using the edge computing nodes as the local decision domain.

[0102] Load profile refresh module: used to map the computing power load volatility to the edge computing power node load profile set, and perform segmented refresh operations on the edge computing power node load profile set according to the tidal time characteristics of the billing service.

[0103] Collaborative scheduling module: used to locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set, in order to define the collaborative complementarity index between edge computing nodes, and generate roadside computing power scheduling and deployment suggestions for toll services based on the collaborative complementarity index.

[0104] In addition, the collaborative scheduling module has a built-in collaborative complementarity index calculation subunit and a strategy generation subunit. The collaborative complementarity index calculation subunit is used to calculate the collaborative complementarity index based on the over-limit risk index, idle margin index, network transmission latency, and available bandwidth. The strategy generation subunit generates instructions for establishing toll service migration tunnels, regional global scheduling request instructions, or local cache peak shaving instructions based on the collaborative complementarity index.

[0105] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. The highway toll management method and specific examples based on an edge cloud architecture described in Embodiment 1 are also applicable to the highway toll management system based on an edge cloud architecture in this embodiment. Through the foregoing detailed description of the highway toll management method based on an edge cloud architecture, those skilled in the art can clearly understand the highway toll management system based on an edge cloud architecture in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here. As the system disclosed in the embodiments corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant details can be found in the method section.

[0106] In the several embodiments provided by this invention, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0107] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0108] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0109] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory, random access memory, magnetic disks, or optical disks.

[0110] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0111] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0112] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. If such modifications and variations fall within the scope of this invention and its equivalents, then this invention is also intended to include such modifications and variations.

Claims

1. A highway toll management method based on an edge cloud architecture, characterized in that, The method includes the following steps: Step S1: Identify the edge computing nodes in the toll road network, the service call ports inside the edge computing nodes, and the roadside sensing data stream; Step S2: Using the edge computing nodes as the local decision domain, identify each edge computing node that has engaged in toll transactions and associate it with the corresponding roadside sensing data stream. Extract the computing load volatility based on the association results. Step S3: Map the computing power load volatility to the edge computing power node load profile set, and perform a segmented refresh operation on the edge computing power node load profile set according to the tidal time characteristics of the charging service. Step S4: Locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set to define the synergy and complementarity index between edge computing nodes; Based on the synergy and complementarity index, generate roadside computing power scheduling and deployment recommendation strategies for toll collection services. The specific implementation process for identifying the toll road network includes: The system collects statistics on all open service call ports of edge computing nodes and the roadside sensing data streams carried by each service call port. It then establishes indexes for both the service call ports and the roadside sensing data streams, marking the i-th service call port as... Mark the j-th roadside sensing data stream as ; The roadside sensing data stream contains the service call port for executing toll collection business logic, and is transmitted through the roadside sensing data stream. The service call ports are clustered and divided to form roadside sensing data streams. The port dependency group, denoted as Where I represents the total number of service call ports; The specific implementation process for extracting the computing load volatility based on the correlation results includes: Treating a single edge computing node as a local decision domain, and based on the tolling business logic executed by each service call port of the edge computing node, the roadside perception data stream is correlated and locked. If it passes through the m-th edge computing node... The internal service call port triggered the data stream from the roadside sensing system. The processing behavior then affects the roadside sensing data stream. Perform association locking if it is through the m-th edge computing node The internal service call port did not trigger the data flow for roadside sensing. The processing behavior does not affect the roadside sensing data stream. Perform association locking; Based on the association locking results, obtain the edge computing nodes. The internal service call port processes roadside sensing data streams. The fluctuation rate of computing load generated at that time is denoted as The computing power load fluctuation rate is defined as: the fluctuation rate of the roadside sensing data stream. During the lifecycle from establishment to release, edge computing nodes Each service calls a port to process roadside sensing data streams. The average processing latency of a single fee transaction, relative to edge computing nodes. The relative deviation of the benchmark value of single transaction processing latency measured when the built-in simulated transaction calculation task is executed during idle periods; The average processing latency of a single charging transaction is the ratio of the total processing latency over the lifetime to the number of transactions; the built-in simulated transaction calculation task is a set of standardized charging business logic that the edge computing node periodically executes locally when there is no external charging request, used to calibrate the node's theoretical minimum processing latency.

2. The highway toll management method based on edge cloud architecture according to claim 1, characterized in that, The specific implementation process of performing the segmented refresh operation includes: Edge computing nodes When considered as a local decision domain, the edge computing power nodes are aggregated. The internal service call ports handle the computing load fluctuations generated when processing the sensing data streams from various roadside nodes, and establish a load profile set for edge computing nodes. J represents the total amount of roadside sensing data stream; Based on the inherent tidal time period characteristics of toll collection services, time slices are divided. The k-th toll collection service time slice is used as the observation window corresponding to the lifecycle of each roadside sensing data stream. Within the observation window, the load profile of each edge computing node is refreshed in segments, and the edge computing node load profile is updated accordingly. The refreshed result is recorded as .

3. The highway toll management method based on edge cloud architecture according to claim 2, characterized in that, The specific implementation process for the peak and trough values ​​of the location computing power load volatility includes: Load profile of edge computing nodes The peak values ​​of computing power load volatility are located in the middle. and the bottom value ; Traversing the discrete sampling sequence of load volatility within the observation window The sampling interval is Statistics exceed the service level agreement guarantee baseline. Number of continuous sampling points and cumulative over-limit range and ; Evaluate edge computing nodes Over-limit risk index within the k-th observation window And idle margin index : ； In the formula, Represents edge computing nodes The sampled value of the computing power load fluctuation rate at sampling time t, where S is the total number of sampling points. The preset cumulative over-limit threshold, Risk contribution for exceeding time limits Risk contribution in the cumulative over-limit dimension and Risk contribution in the instantaneous peak dimension and The value is determined by configuring it differently based on the sensitivity of the charged business to different risk dimensions, and it meets the following requirements: This is the idle confidence factor, which is used to adjust the confidence level for calculating the idle margin index. Minimum idle trust level and The minimum idle trust level is used to characterize the basic idle trust level retained under the condition of continuous overload of charging tasks; The service level agreement guarantees the baseline. This includes differentiated baseline parameters set according to the type of toll collection service, wherein the baseline parameters include the first baseline corresponding to the ETC lane. The second baseline corresponding to the mixed lane and the third baseline corresponding to the manual lane The service level agreement guarantees the baseline. The first baseline is selected based on the toll collection service type corresponding to the roadside perception data stream processed by the edge computing nodes. Second baseline and the third baseline If the edge computing nodes select the first baseline Second baseline and the third baseline When combining the two, the corresponding baselines are substituted into the formulas for the excess risk index and the idle margin index to calculate the independent excess risk index and the independent idle margin index, respectively. The largest independent excess risk index is taken as the excess risk index, and the smallest independent idle margin index is taken as the idle margin index.

4. The highway toll management method based on edge cloud architecture according to claim 3, characterized in that, The specific implementation process for defining the collaborative complementarity index among edge computing nodes includes: Obtain edge computing nodes With edge computing nodes Network transmission latency between and available bandwidth Set collaborative reachability condition trigger value If satisfied and Then let If not satisfied and Then let In the formula, To maximize the tolerance for collaboration latency for paid services, The minimum collaborative bandwidth threshold; Evaluate edge computing nodes With edge computing nodes Synergistic complementarity index within the k-th observation window In the formula, It is a bidirectional overload penalty coefficient used to suppress the synergistic complementarity index when both edge computing nodes present the risk of overload in charging tasks.

5. The highway toll management method based on edge cloud architecture according to claim 4, characterized in that, The specific implementation process of generating roadside computing power scheduling and deployment recommendation strategies for toll-based services includes: Based on the calculation results of the synergistic complementarity index, roadside computing power scheduling instructions are generated: Preset coordinated scheduling trigger threshold and global scheduling trigger threshold ; If the synergistic complementarity index is satisfied Then determine the edge computing node within the k-th observation window. With edge computing nodes There are conditions for resource complementarity, and the output will be edge computing nodes. With edge computing nodes Recommendation to include them in the same edge computing resource pool to mitigate the impact of peak and off-peak periods for paid services; If not satisfied Then determine the edge computing node within the k-th observation window. With edge computing nodes If there is no resource complementarity between them, then determine whether the conditions are met. and ; If satisfied and This triggers a regional-level global scheduling request, which will allocate edge computing nodes. With edge computing nodes Integrate into the central cloud node to output suggestions for calling global computing resources from the central cloud node; If not satisfied and And output to edge computing nodes With edge computing nodes Recommendations for implementing local caching for peak shaving or dynamic rate limiting for the charged services being handled; Based on the roadside computing power scheduling instructions, the deployment recommendation strategy is executed to generate toll service flow table update instructions: When it is determined that there are conditions for resource complementarity between edge computing nodes, a paid service migration tunnel is established between edge computing nodes where resource complementarity conditions exist, so as to interconnect the idle service call ports between edge computing nodes. When a regional-level global scheduling request is triggered, the overload status is reported to the regional scheduling controller, which then readjusts the business processing assignment relationship between each edge computing node and the toll lane based on the load view of the entire network's edge computing nodes. When it is determined that local cache peak shaving should be performed, the fee transaction requests that exceed the processing capacity of the edge computing nodes will be temporarily stored in the local high-speed cache queue and asynchronously reissued during the load reduction period in a first-in-first-out order.

6. The highway toll management method based on edge cloud architecture according to claim 5, characterized in that, The specific implementation process for establishing the toll service migration tunnel includes: One of the two edge computing nodes that have complementary resources is marked as the source edge computing node, and the other edge computing node is marked as the destination edge computing node. Insert flow table forwarding rules into the task distribution component of the source edge computing node to modify the destination address of the roadside perception data stream corresponding to the target lane to the service call port of the business processing of the destination edge computing node; A temporary processing instance is created in the service processing component of the edge computing node. The temporary processing instance independently processes the migration of the toll service during the existence of the toll service migration tunnel and automatically releases the occupied computing resources after the toll service migration tunnel is dismantled.

7. A highway toll management system that implements the highway toll management method based on an edge cloud architecture as described in claim 1, characterized in that, The highway toll management system includes: a memory, a processor, an edge computing node management module, a computing load analysis module, a load profile refresh module, and a collaborative scheduling module. The memory stores a highway toll management program based on an edge cloud architecture, which is executed by the processor to implement the functions of each module: the edge computing node management module, the computing load analysis module, the load profile refresh module, and the collaborative scheduling module. The edge computing node management module is used to identify edge computing nodes in the toll road network, service call ports within the edge computing nodes, and roadside sensing data streams. The computing load analysis module is used to determine each edge computing node that has engaged in toll transactions and associate it with the corresponding roadside sensing data stream, using the edge computing nodes as the local decision domain, and extract the computing load volatility based on the association results. The load profile refresh module is used to map the computing load volatility to the edge computing node load profile set and perform segmented refresh operations on the edge computing node load profile set according to the tidal characteristics of toll business. The collaborative scheduling module is used to locate the peak and trough values ​​of computing load volatility in the refreshed edge computing node load profile set to define the collaborative complementarity index between edge computing nodes, and generate roadside computing power scheduling and deployment suggestions for toll business based on the collaborative complementarity index.

8. The highway toll management system according to claim 7, characterized in that, The collaborative scheduling module has a built-in collaborative complementarity index calculation subunit and a strategy generation subunit, which are used to collaboratively generate roadside computing power scheduling and deployment suggestion strategies. The collaborative complementarity index calculation subunit is used to calculate the collaborative complementarity index based on the over-limit risk index, the idle margin index, network transmission latency, and available bandwidth. The strategy generation subunit generates toll service migration tunnel establishment instructions, regional global scheduling request instructions, or local cache peak shaving instructions based on the collaborative complementarity index.

Images