In-line detection method, electronic device and computer readable storage medium

Abstract

The application provides a kind of with flow detection method, electronic equipment and computer readable storage medium, belong to the technical field of Internet of Vehicles.The method comprises: obtaining the with flow detection data uploaded by multiple road side units in Internet of Vehicles, and the with flow detection data includes the running index data of at least one vehicle;The with flow detection data is input into a preset evaluation model for processing to obtain an evaluation result;The evaluation result reflects the processing capacity of the vehicle in response to the anomaly;According to the evaluation result, the target running state of the vehicle is determined;The target running state of the vehicle is sent to the road side unit corresponding to the vehicle, so that the road side unit forwards the target running state to the vehicle, so that the vehicle operates based on the target running state.The embodiments of the present application can reduce the proportion of vehicle anomalies, thereby improving the safety of vehicle operation.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, and in particular to a flow detection method, electronic device, and computer-readable storage medium. Background Technology

[0002] With the continuous development of communication technology and the gradual increase in network scale, in order to ensure that the network can provide high-quality, stable and reliable network services, it is necessary to obtain relevant perception data of vehicles in order to provide better navigation services for vehicles.

[0003] However, current vehicle-to-everything (V2X) systems rely on different roadside devices to detect vehicles on certain road sections. This only allows control over the vehicle's driving behavior on those sections and fails to provide comprehensive vehicle detection. This reduces the accuracy of vehicle detection and cannot guarantee vehicle safety. Summary of the Invention

[0004] To address this issue, the present invention provides a flow-following detection method, an electronic device, and a computer-readable storage medium to solve the problem in the prior art where inaccurate vehicle detection leads to the inability to adjust the vehicle's operating status in a timely manner, resulting in vehicle malfunctions.

[0005] To achieve the above objectives, the first aspect of the present invention provides a flow-following detection method applied to a core server. The method includes: acquiring flow-following detection data uploaded by multiple roadside units in a vehicle-to-everything (V2X) network, wherein the flow-following detection data includes operational index data of at least one vehicle; inputting the flow-following detection data into a preset evaluation model for processing to obtain an evaluation result; the evaluation result reflecting the vehicle's ability to handle anomalies; determining the vehicle's target operating state based on the evaluation result; and sending the vehicle's target operating state to the roadside unit corresponding to the vehicle, so that the roadside unit can forward the target operating state to the vehicle, enabling the vehicle to operate based on the target operating state.

[0006] In some embodiments, the following steps involve inputting the flow detection data into a preset evaluation model for processing to obtain evaluation results: normalizing the flow detection data according to its data type to obtain normalized data; the flow detection data includes indicator data of at least two data types; determining an evaluation score based on the weights corresponding to each data type and the normalized data; wherein different data types have different weights, and the weights characterize the sensitivity of the flow detection data in different business scenarios; and determining the evaluation result based on the evaluation score.

[0007] In some embodiments, the metric data of at least two data types include: vehicle throughput, vehicle data transmission latency, jitter, and packet loss rate; the normalized data includes at least one of the following: throughput score, latency score, jitter score, and packet loss rate score.

[0008] In some embodiments, the following detection data is the vehicle's operating index data detected by the vehicle through a camera device and / or a lidar device; based on the evaluation results, the target operating state of the vehicle is determined, including: when the evaluation results indicate that the vehicle's packet loss rate suddenly increases to a preset packet loss threshold, and the vehicle's data transmission delay is less than a preset delay threshold, the collision warning level of the vehicle is determined to be reduced, and the target operating state of the vehicle is the state after at least one collision warning level reduction.

[0009] In some embodiments, the flow-following detection data is the operational index data of each vehicle in the convoy acquired by the roadside unit; the number of vehicles in the convoy is at least three; based on the evaluation results, the target operating state of the vehicles is determined, including: if the evaluation results are determined to meet the preset operating conditions, determining the distance to be increased between adjacent vehicles in the convoy; determining the convoy operation stability index based on the initial distance between adjacent vehicles in the convoy and the distance to be increased; and determining the target operating state of each vehicle in the convoy based on the convoy operation stability index.

[0010] In some embodiments, the preset operating conditions include at least one of the following: the packet loss rate of communication between adjacent vehicles in the fleet within a preset time period is lower than a preset packet loss threshold; the data transmission jitter of adjacent vehicles in the fleet exceeds a budgeted jitter threshold; and the data transmission latency between adjacent vehicles in the fleet is less than a preset latency threshold.

[0011] Secondly, the present invention provides a flow-following detection method applied to a roadside unit, comprising: responding to sensing data sent by a vehicle, detecting the sensing data according to a preset detection rule to obtain flow-following detection data; the flow-following detection data includes operating index data of at least one vehicle; sending the flow-following detection data to a core server for the core server to process the flow-following detection data and determine the target operating state of the vehicle; and responding to the target operating state of the vehicle sent by the core server, forwarding the target operating state to the vehicle for the vehicle to operate based on the target operating state.

[0012] In some embodiments, the method further includes: generating preset detection rules based on user detection requirements and application-aware identifiers; wherein the preset detection rules are rules based on vector processing instructions, and the application-aware identifiers are identifiers representing the vehicle's identity or the application scenario in which the vehicle is located.

[0013] Thirdly, the present invention provides an electronic device comprising: one or more processors; a memory storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-described flow detection methods; and one or more I / O interfaces connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0014] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described flow detection methods.

[0015] The following detection method provided by this invention acquires following detection data uploaded by multiple roadside units in the vehicle-to-everything (V2X) network through a core server. This following detection data includes operational index data of at least one vehicle, enabling comprehensive detection of the vehicle and clarifying its operational index data throughout the entire driving process, facilitating more accurate analysis of the vehicle's driving status. The following detection data is input into a preset evaluation model for processing to obtain an evaluation result. This evaluation result reflects the vehicle's ability to handle anomalies. The preset evaluation model enables comprehensive analysis of the vehicle's following detection data, providing more accurate evaluation results. Based on the evaluation result, a target operating state of the vehicle is determined, enabling the vehicle to operate promptly based on this target operating state, reducing the proportion of vehicle anomalies and thus improving vehicle operating safety.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 This is a schematic flowchart of a flow detection method provided in an embodiment of the present invention;

[0019] Figure 2 This is a schematic flowchart of a flow detection method provided in an embodiment of the present invention;

[0020] Figure 3 A block diagram illustrating the composition of a core server provided in an embodiment of the present invention;

[0021] Figure 4 A block diagram illustrating the composition of a roadside unit provided in an embodiment of the present invention;

[0022] Figure 5 A block diagram of a flow detection system provided in an embodiment of the present invention;

[0023] Figure 6 This is a schematic flowchart illustrating a method for performing vehicle detection using a flow-following detection system according to an embodiment of the present invention.

[0024] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0026] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. When the term "comprising" is used in this invention, it specifies the presence of the stated feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0027] Unless otherwise specified, all terms used in this invention (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in common dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined by the invention.

[0028] In a first aspect, embodiments of the present invention provide a method for detecting flow.

[0029] Figure 1 This is a flowchart illustrating a flow-following detection method provided in an embodiment of the present invention. This flow-following detection method is applied to a core server. For example... Figure 1 As shown, the method includes, but is not limited to, the following steps.

[0030] Step S101: Obtain the flow detection data uploaded by multiple roadside units in the vehicle network.

[0031] The flow-following detection data includes operational indicator data for at least one vehicle. These operational indicator data characterize vehicle performance during operation, such as throughput and data transmission latency.

[0032] It should be noted that during the journey, the vehicle will pass through multiple roadside units. Each roadside unit will upload the flow detection data of the vehicle to the core server. The core server will analyze the flow detection data of each vehicle to determine whether each vehicle is driving normally.

[0033] Step S102: Input the flow detection data into the preset evaluation model for processing to obtain the evaluation result.

[0034] The evaluation results reflect the vehicle's ability to handle anomalies. The preset evaluation model is a model that processes the flow detection data. Through this preset evaluation model, it is possible to analyze the vehicle's flow detection data to determine whether there are any anomalies in the vehicle and the vehicle's ability to handle anomalies.

[0035] Step S103: Determine the target operating state of the vehicle based on the evaluation results.

[0036] In cases where the assessment results indicate that the vehicle's current operating status cannot support its normal operation, it is determined that the vehicle needs to change its operating status, and a suggested target operating status is provided so that the vehicle can respond to any anomalies it encounters based on the target operating status, thereby restoring the vehicle to normal operation.

[0037] Step S104: Send the target operating status of the vehicle to the roadside unit corresponding to the vehicle, so that the roadside unit can forward the target operating status to the vehicle so that the vehicle can operate based on the target operating status.

[0038] The core server can use broadcast messages to locate the roadside unit corresponding to the vehicle and send the vehicle's target operating status to the roadside unit; the roadside unit forwards the target operating status to the vehicle to change the vehicle's operating status to the target operating status.

[0039] According to the flow-following detection method in this embodiment, the core server acquires flow-following detection data uploaded by multiple roadside units in the vehicle network. This flow-following detection data includes operational index data of at least one vehicle, enabling comprehensive detection of the vehicle and clarifying its operational index data throughout the entire driving process, facilitating more accurate analysis of the vehicle's driving status. The flow-following detection data is input into a preset evaluation model for processing to obtain an evaluation result. This evaluation result reflects the vehicle's ability to handle anomalies. The preset evaluation model can perform a comprehensive analysis of the vehicle's flow-following detection data, providing a more accurate evaluation result. Based on this evaluation result, the target operating state of the vehicle is determined, enabling the vehicle to operate promptly based on the target operating state upon acquisition, reducing the proportion of vehicle anomalies and thereby improving vehicle operating safety.

[0040] In some embodiments, the following steps involve inputting the flow detection data into a preset evaluation model for processing to obtain evaluation results: normalizing the flow detection data according to the data type to obtain normalized data; determining an evaluation score based on the weights corresponding to each data type and the normalized data; and determining the evaluation result based on the evaluation score.

[0041] The flow detection data includes at least two types of indicator data; the at least two types of indicator data include: vehicle throughput, vehicle data transmission latency, jitter, and packet loss rate.

[0042] For each type of indicator data, a corresponding scoring function needs to be determined to facilitate the normalization of each indicator data.

[0043] For example, a sigmoid function is used to normalize the data transmission latency of vehicles to obtain a latency score; an inverse proportional function is used to normalize the packet loss rate to obtain a packet loss rate score.

[0044] The normalized data includes at least one of the following: throughput score, latency score, jitter score, and packet loss rate score.

[0045] Normalization facilitates the unified processing of indicator data of different data types, enabling the measurement of indicator data of various data types based on the same standard.

[0046] Furthermore, different data types have different weights, and the weights represent the sensitivity of the flow detection data in different business scenarios.

[0047] For example, for a specific business scenario in the Internet of Vehicles (IoV), the following weight values ​​can be set: latency weight. Packet loss rate weight Dithering weights Throughput weight To ensure .

[0048] By using different weight values, specific processing of different data types of metrics can be achieved in different business scenarios. For example, in the above example, more emphasis is placed on the control of latency and packet loss rate, thereby enhancing the weight of latency and packet loss rate.

[0049] Then, based on the weights corresponding to each data type and the normalized data, an evaluation score is determined; the evaluation result is determined based on the evaluation score so that the evaluation result reflects the vehicle's ability to handle the anomalies it encounters.

[0050] In some embodiments, the following detection data is the vehicle's operating index data detected by the vehicle through a camera device and / or a lidar device; based on the evaluation results, the target operating state of the vehicle is determined, including: when the evaluation results indicate that the vehicle's packet loss rate suddenly increases to a preset packet loss threshold, and the vehicle's data transmission delay is less than a preset delay threshold, the collision warning level of the vehicle is determined to be reduced, and the target operating state of the vehicle is the state after at least one collision warning level reduction.

[0051] The vehicle obtains image data streams (e.g., 1080p video streams) through camera equipment and 10Hz lidar point cloud data streams through lidar equipment. Then, the vehicle's operating index data (e.g., vehicle packet loss rate and vehicle data transmission latency) are obtained by parsing the above image data streams and / or lidar point cloud data streams.

[0052] If the evaluation results indicate that the vehicle's packet loss rate suddenly increases to a preset packet loss threshold (e.g., 15%), and the vehicle's data transmission latency is less than a preset latency threshold (e.g., 100 milliseconds (ms)), it is determined that the vehicle needs to reduce its collision warning level. For example, the vehicle's warning algorithm can be downgraded from "visual + laser" to "pure laser" mode to ensure that the vehicle's data transmission latency is still less than 80ms.

[0053] If the collision warning level corresponding to the "vision + laser" warning algorithm is set to the first level and the collision warning level corresponding to the "pure laser" warning algorithm is set to the second level, then the target running state of the vehicle can be determined to be the second level to reduce the detection sensitivity of the vehicle and ensure that the data transmission delay of the vehicle is within the preset range.

[0054] In some embodiments, the flow-following detection data is the operational index data of each vehicle in the convoy acquired by the roadside unit; the number of vehicles in the convoy is at least three; based on the evaluation results, the target operating state of the vehicles is determined, including: if the evaluation results are determined to meet the preset operating conditions, determining the distance to be increased between adjacent vehicles in the convoy; determining the convoy operation stability index based on the initial distance and the distance to be increased between adjacent vehicles in the convoy; and determining the target operating state of each vehicle in the convoy based on the convoy operation stability index.

[0055] The preset operating conditions include at least one of the following: the packet loss rate of communication between adjacent vehicles in the fleet is lower than the preset packet loss threshold within a preset time period; the data transmission jitter of adjacent vehicles in the fleet exceeds the budgeted jitter threshold; and the data transmission latency between adjacent vehicles in the fleet is less than the preset latency threshold.

[0056] Since multiple vehicles are traveling simultaneously in the convoy, the initial interval between two adjacent vehicles in the convoy is set at the start, for example, the initial interval is set to 10 meters. However, as the convoy travels, the vehicles in the convoy may change their speed, which may cause changes in the operating parameters between adjacent vehicles in the convoy. Therefore, if the evaluation result is determined to meet the preset operating conditions, it is determined that the driving interval between adjacent vehicles in the convoy needs to be changed.

[0057] Specifically, the platoon stability index can be determined based on the initial and incremental intervals between adjacent vehicles in the platoon. For example, if the initial interval between adjacent vehicles in the platoon is set to... (e.g., 10m), the interval distance to be increased is Then the fleet's operational stability index can be determined. .

[0058] Among them, if If the CSI value is 0.97 for a 7% random packet loss between vehicles, and / or the CSI value is 0.92 or below for a 200ms sudden interruption, then it is determined that the vehicle's operating status needs to be adjusted to the target operating status.

[0059] By implementing the planned changes to the operational status of the fleet, the accuracy of each vehicle's detection of anomalies can be effectively improved. When an anomaly is detected, the vehicle's operational status can be proactively changed to the target operational status, thereby enabling the vehicle to better cope with anomalies, reducing the proportion of vehicle damage, and ensuring the operational stability of each vehicle in the fleet.

[0060] Figure 2This is a schematic flowchart illustrating a flow-following detection method according to an embodiment of the present invention. This flow-following detection method is applied to roadside units. For example... Figure 2 As shown, the method includes, but is not limited to, the following steps.

[0061] Step S201: In response to the perception data sent by the vehicle, the perception data is detected according to the preset detection rules to obtain the flow detection data.

[0062] The flow-based detection data includes operational metrics data for at least one vehicle. These operational metrics data include at least one of the following: vehicle throughput, vehicle data transmission latency, jitter, and packet loss rate.

[0063] The preset detection rule is a rule based on vector processing instructions. In other words, the preset detection rule can execute the same detection rule for a set of data (vectors or vectors) at once.

[0064] For example, for a specific vehicle, operational metrics data across different dimensions are extracted from its perception data, such as throughput, data transmission latency, jitter, and packet loss rate. Then, vector processing instructions are used to simultaneously detect the vehicle's packet loss rate and data transmission latency, obtaining flow-following detection data. This flow-following detection data reveals whether data packet loss exists, the packet loss ratio, and whether the data transmission latency meets preset vehicle-to-everything (V2X) security standards.

[0065] Step S202: Send the following detection data to the core server so that the core server can process the following detection data and determine the target operating status of the vehicle.

[0066] When the core server receives the vehicle's flow detection data, it inputs the data into a preset evaluation model for processing to obtain an evaluation result. This evaluation result reflects the vehicle's ability to handle anomalies.

[0067] The preset evaluation model is a model that processes the flow detection data. This model enables the analysis of the vehicle's flow detection data to determine whether any anomalies exist and the vehicle's ability to respond to these anomalies. Furthermore, the core server determines the vehicle's target operating state based on the evaluation results.

[0068] Step S203: In response to the target operating status of the vehicle sent by the core server, forward the target operating status to the vehicle so that the vehicle can operate based on the target operating status.

[0069] When the roadside unit receives the target operating status of a vehicle from the core server, it forwards the target operating status to the corresponding vehicle so that the vehicle can change its operating status to the target operating status and improve the vehicle's ability to cope with anomalies.

[0070] In some embodiments, the method further includes generating preset detection rules based on user detection requirements and application-aware identifiers.

[0071] Among these, user testing requirements refer to the safe driving requirements of vehicles in specific scenarios. For example, user testing requirements could be used to verify whether the vehicle's emergency braking response still meets the requirements of the IoT security standards published by the European Telecommunications Standards Institute (ETSI) when the vehicle experiences 5%, 10%, and 20% packet loss (e.g., data transmission latency ≤100ms).

[0072] Among them, the preset detection rules are rules based on vector processing instructions, and the application perception identifier is an identifier that represents the vehicle's identity or the application scenario in which the vehicle is located.

[0073] For example, the application perception identifier may be a value obtained by hashing the vehicle's license plate number, or a value determined based on a preset data stream and the identifier of the application scenario in which the vehicle is located (e.g., the identifier of the vehicle in an emergency braking scenario, or the vehicle's number in a convoy during a certain movement).

[0074] By combining application-aware identifiers with user detection needs, not only can the generated preset detection rules meet the user's detection requirements, but the application-aware identifiers can also more accurately represent the application scenarios corresponding to the vehicle and the vehicle's identity information, thereby enabling faster vehicle detection and improving the accuracy of vehicle detection.

[0075] According to the flow detection method in this embodiment, in response to the sensing data sent by the vehicle, the sensing data is detected according to a preset detection rule to obtain flow detection data. The flow detection data includes the operating index data of at least one vehicle to clarify the operating status of at least one vehicle. Then, the flow detection data is sent to the core server for the core server to process the flow detection data, determine the target operating status of the vehicle, realize a comprehensive analysis of the flow detection data of the vehicle, and give a more accurate evaluation result. In response to the target operating status of the vehicle sent by the core server, the target operating status is forwarded to the vehicle so that the vehicle can operate based on the target operating status, thereby reducing the proportion of vehicle anomalies and improving the safety of vehicle operation.

[0076] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the protection scope of this invention. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the protection scope of this invention patent.

[0077] Secondly, embodiments of the present invention provide a core server.

[0078] Figure 3 This is a block diagram illustrating the composition of a core server according to an embodiment of the present invention. Figure 3 As shown, the core server 300 includes, but is not limited to, the following modules.

[0079] The acquisition module 301 is used to acquire the flow detection data uploaded by multiple roadside units in the vehicle network.

[0080] The flow-following detection data includes operational indicator data for at least one vehicle.

[0081] The evaluation module 302 is used to input the flow detection data into a preset evaluation model for processing and to obtain the evaluation results.

[0082] The assessment results reflect the vehicle's ability to handle anomalies.

[0083] The determination module 303 is used to determine the target operating state of the vehicle based on the evaluation results.

[0084] The first sending module 304 is used to send the target operating status of the vehicle to the roadside unit corresponding to the vehicle, so that the roadside unit can forward the target operating status to the vehicle and the vehicle can operate based on the target operating status.

[0085] It should be noted that the core server in this embodiment can implement any of the following detection methods applied to the core server in this embodiment of the invention.

[0086] According to the core server of this embodiment, the acquisition module acquires the following detection data uploaded by multiple roadside units in the vehicle network. This following detection data includes the operating index data of at least one vehicle, enabling comprehensive detection of the vehicle and clarifying the operating index data of the vehicle throughout the entire driving process, facilitating more accurate analysis of the vehicle's driving status. The evaluation module inputs the following detection data into a preset evaluation model for processing to obtain an evaluation result. This evaluation result reflects the vehicle's ability to handle anomalies. The preset evaluation model enables comprehensive analysis of the vehicle's following detection data, providing a more accurate evaluation result. The determination module determines the vehicle's target operating state based on the evaluation result, enabling the vehicle to operate promptly based on the target operating state upon obtaining it, reducing the proportion of vehicle anomalies and thus improving vehicle operating safety.

[0087] Thirdly, embodiments of the present invention provide a roadside unit.

[0088] Figure 4 This is a block diagram illustrating the composition of a roadside unit according to an embodiment of the present invention. This roadside unit can be installed on both sides of a road, or in traffic facilities at intersections. Figure 4 As shown, the roadside unit 400 includes, but is not limited to, the following modules.

[0089] The detection module 401 is used to respond to the perception data sent by the vehicle, and to detect the perception data according to the preset detection rules to obtain the flow detection data.

[0090] The flow-following detection data includes operational indicator data for at least one vehicle.

[0091] The second sending module 402 is used to send the following detection data to the core server so that the core server can process the following detection data and determine the target operating status of the vehicle.

[0092] The forwarding module 403 is used to respond to the target running status of the vehicle sent by the core server and forward the target running status to the vehicle so that the vehicle can run based on the target running status.

[0093] It should be noted that the roadside unit in this embodiment can implement any of the flow detection methods applied to the roadside unit in this embodiment of the invention.

[0094] According to an embodiment of the present invention, the roadside unit responds to the sensing data sent by the vehicle through a detection module, and detects the sensing data according to a preset detection rule to obtain flow-following detection data. The flow-following detection data includes the operating index data of at least one vehicle to clarify the operating status of at least one vehicle. Then, the flow-following detection data is sent to the core server using a second sending module, so that the core server can process the flow-following detection data, determine the target operating status of the vehicle, realize a comprehensive analysis of the flow-following detection data of the vehicle, and give a more accurate evaluation result. Finally, the forwarding module responds to the target operating status of the vehicle sent by the core server, and forwards the target operating status to the vehicle so that the vehicle can operate based on the target operating status, thereby reducing the proportion of vehicle anomalies and improving the safety of vehicle operation.

[0095] The functions or modules of the roadside unit provided in the embodiments of the present invention can be used to execute the flow detection method applied to the roadside unit described in the above embodiments. The specific implementation and technical effects can be referred to the description of the method embodiments above. For the sake of brevity, they will not be repeated here.

[0096] It should be noted that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by this invention; however, this does not mean that other units are absent from this embodiment.

[0097] Fourthly, embodiments of the present invention provide a flow detection system.

[0098] Figure 5 This is a block diagram of a flow-following detection system provided in an embodiment of the present invention. Figure 5 As shown, the flow detection system includes, but is not limited to, the following devices: a core server 510, multiple roadside units (e.g., first roadside unit 521, second roadside unit 522, ..., mth roadside unit 52m, where m is an integer greater than or equal to 1), and multiple terminals (e.g., first terminal 531, second terminal 532, ..., nth terminal 53n, where n is an integer greater than or equal to 1).

[0099] The terminals are all vehicle-mounted terminals installed in the vehicles; each roadside unit and each terminal are connected and communicate with each other via a wireless network.

[0100] It should be noted that when a vehicle passes through each roadside unit, the on-board terminal installed on the vehicle will report the sensing data it has detected to the roadside unit it has passed through, so that the roadside unit can detect the sensing data according to the preset detection rules and obtain the flow detection data.

[0101] In some embodiments, this flow-following detection system can be applied to scenarios where a single vehicle in a vehicle-to-everything (V2X) network provides a collision warning, or to scenarios where a fleet of multiple vehicles in a V2X network requires driving control. This invention does not limit the application scenarios of this system, and will not elaborate further here.

[0102] The following section provides a more detailed introduction to the methods for vehicle flow detection in typical vehicle-to-everything (V2X) scenarios. Figure 6 This is a schematic flowchart illustrating a method for performing vehicle flow detection using a flow-following detection system, as provided in an embodiment of the present invention. Figure 6 As shown, the method includes, but is not limited to, the following steps.

[0103] In step S601, the roadside unit responds to the sensing data sent by the vehicle and detects the sensing data according to the preset detection rules to obtain flow detection data.

[0104] The flow-based detection data includes operational metrics data for at least one vehicle. These operational metrics data include: vehicle throughput, vehicle data transmission latency, jitter, and packet loss rate.

[0105] For example, if the observation window is set to T (e.g., T represents the past 5 minutes starting from the current moment), the data of each operating indicator are calculated in the following way.

[0106] 1) .

[0107] The vehicle's throughput reflects its effective bandwidth utilization capability under conditions of current vehicle-to-everything (V2X) connectivity impairments.

[0108] 2) Vehicle data transmission latency: Quantiles are typically used to avoid the influence of extreme values, making this parameter more reflective of the user experience. For example, vehicle data transmission latency is calculated using the following formula.

[0109]

[0110] The 95th percentile latency is determined as follows: Vehicle data transmission latency is sorted from smallest to largest; the latency value at the 95th percentile is the 95th percentile latency. The 95th percentile latency is used to evaluate the tail latency of real-time services in vehicle-to-everything (V2X) networks.

[0111] 3) Jitter: This represents the variation in data transmission delay of a vehicle, typically expressed as the average of the absolute values ​​of the differences in delay between consecutive messages, or the standard deviation. For example, Where n represents the n data acquisition times, and n is an integer greater than 1; Σ represents the summation operation, and |*| represents the absolute value operation. This jitter parameter reflects the network stability of the vehicle network. High jitter will seriously affect the quality of real-time audio, video, and control commands.

[0112] 4) Packet loss rate is the most direct indicator of network reliability.

[0113] It should be noted that the roadside unit is any one of the multiple roadside units that the vehicle passes through during its journey. All the roadside units that the vehicle passes through will acquire the perception data reported by the vehicle.

[0114] In step S602, the roadside unit sends flow detection data to the core server 510.

[0115] The core server 510 is connected to multiple roadside units and can receive the following detection data for each vehicle reported by the multiple roadside units, so as to evaluate and adjust the operating status of each vehicle.

[0116] In step S603, the core server 510 inputs the flow detection data sent by multiple roadside units into a preset evaluation model for processing to obtain evaluation results.

[0117] It should be noted that the preset evaluation model processes only the data retrieved from the flow of one vehicle at a time, and the evaluation result obtained is also for one vehicle. This evaluation result can reflect the vehicle's ability to handle anomalies.

[0118] In some embodiments, the specific processing method of the preset evaluation model includes the following steps.

[0119] Step S6031: Normalize the flow detection data according to the data type to obtain normalized data.

[0120] The flow-following detection data includes indicator data of at least two types. Normalization is the process of mapping indicators of different dimensions and ranges to a unified scoring scale to generate an intuitive score (e.g., 0-1), which facilitates subsequent evaluation and processing.

[0121] In some embodiments, a corresponding scoring function needs to be determined for each type of indicator data, so as to facilitate the normalization of each indicator data.

[0122] For example, to address the time delay in flow-fed detection data, an S-shaped function can be defined; the time delay fraction is determined according to the following formula: .

[0123] Where L_max represents the maximum tolerable delay (e.g., 100ms); L_min represents the ideal delay (e.g., 10ms); the range of delay values ​​in the above formula is: .

[0124] like If, then the delay score = 0; if ,but .

[0125] As can be seen from the above definition, the delay score changes significantly near the critical point, and can sensitively reflect the performance degradation of the vehicle's data transmission delay.

[0126] For example, to determine the packet loss rate in the flow detection data, an inverse proportional function can be set; for instance, the packet loss rate score can be determined using the following formula: .

[0127] Here, L_loss_max represents the maximum tolerable packet loss rate (e.g., 20%). When the packet loss rate equals L_loss_max, the packet loss rate score is 0.

[0128] For normalization processing of other data types in the flow detection data, the above method can be used as a reference. For example, for throughput, a direct proportional function can be set to calculate its corresponding throughput score; for jitter, an inverse proportional function can be set to calculate its corresponding jitter score, etc.

[0129] Step S6032: Assign weights to the indicator data of each data type.

[0130] Different data types have different weights, and the weights represent the sensitivity of the flow detection data in different business scenarios.

[0131] For example, for a specific business scenario in the Internet of Vehicles (IoV), the following weight values ​​can be set: latency weight. Packet loss rate weight Dithering weights Throughput weight To ensure .

[0132] Step S6033: Determine the evaluation score based on the weights corresponding to each data type and the normalized data.

[0133] For example, the assessment score can be calculated using the following formula.

[0134]

[0135] Furthermore, different score levels are assigned to correspond to the vehicle's ability to handle anomalies.

[0136] Level 1: The assessment score is between 90 and 100 points, indicating that the vehicle has a strong ability to handle abnormalities.

[0137] Level 2: The evaluation score is between 70 and 89 points. The vehicle is able to handle abnormalities and take corresponding actions. The user's business experience is slightly reduced but acceptable.

[0138] Level 3: Evaluation score between 60 and 69: The vehicle's ability to handle anomalies is insufficient, and the user's business experience is significantly reduced, which requires attention.

[0139] Level 4: Assessment score < 60 points, the vehicle is unable to cope with the current anomaly, and the risk of business interruption is high.

[0140] Step S6034: Determine the evaluation result based on the evaluation score.

[0141] In some embodiments, a visual interface can be used to display the above evaluation scores and their corresponding evaluation results. The content displayed on this visual interface includes: damage type, damage degree, performance index parameters, etc.

[0142] Users can easily view and analyze the evaluation results through this visual interface, and make corresponding optimizations and adjustments based on the evaluation results to improve the vehicle's ability to cope with anomalies, thereby enhancing the reliability of the vehicle's data processing.

[0143] Step S604: Determine the target operating state of the vehicle based on the evaluation results.

[0144] The target operating state is the operating state that the vehicle needs to use. By controlling the vehicle to switch to the target operating state, the vehicle can better perform business processing and deal with anomalies encountered by the vehicle.

[0145] In step S605, the core server 510 sends the target operating status of the vehicle to the roadside unit corresponding to the vehicle.

[0146] In step S606, the roadside unit forwards the target operating status of the vehicle to the vehicle so that the vehicle can operate based on the target operating status.

[0147] In some embodiments, the roadside unit can locate its corresponding vehicle by broadcasting, and then send the target operating status of the vehicle to the on-board terminal on the vehicle.

[0148] The specific implementation of the above processing steps varies in different application scenarios. The following are examples of two different application scenarios.

[0149] Example 1: A scenario where a vehicle in a vehicle-to-everything (V2X) network issues a collision warning.

[0150] A city has deployed roadside units (RSUs) at traffic light intersections. The perception modules in vehicles upload the perception data they perceive to the RSUs in real time (e.g., using 5G networks to realize the communication channel for vehicle-to-everything (V2X), transmitting perception data including image data streams (e.g., 1080p video streams) and 10Hz LiDAR point cloud data streams). The RSUs detect the perception data according to preset detection rules, obtain the flow detection data, and send the flow detection data to the core server.

[0151] The image data stream can be transmitted via port 4001 using the User Datagram Protocol (UDP); the LiDAR point cloud data stream can be transmitted via port 4002 using the UDP protocol; and the follow-up detection data can be transmitted to the core server via port 4003 using the UDP protocol.

[0152] In this application scenario, it is necessary to verify whether the RSU's fusion algorithm and the vehicle's emergency braking response still meet the requirements of the IoT safety standards issued by ETSI (e.g., data transmission latency ≤100ms) when the vehicle experiences 5%, 10%, and 20% packet loss.

[0153] The communication equipment in this vehicle-to-everything (V2X) network includes: an onboard unit (OBU) installed on the vehicle, multiple roadside units based on 5G base stations, and a core server.

[0154] In some embodiments, the roadside unit responds to the sensing data sent by the vehicle and detects the sensing data according to a preset detection rule to obtain the flow detection data. The roadside unit can send the following instructions to the vehicle-mounted unit to achieve this step.

[0155] bash

[0156] # Image data stream: (xxxx = hash value corresponding to the license plate)

[0157]

[0158] # LiDAR point cloud data stream: This only applies to 20% of the vehicles in the connected vehicle network.

[0159]

[0160] # Warning for downlink data stream: Packet loss is not allowed

[0161] vppctl set packdmg dst-port 4003 loss 0.

[0162] Among them, APN ID represents the service type identifier in the Internet of Vehicles, and is the data processing method of the computing power network implemented based on the VPP framework.

[0163] In this process, the perception data of each vehicle can be treated as a "stream" and the packet loss rate and vehicle data transmission latency can be used as operational indicators. The data is then processed based on a preset evaluation model to obtain the evaluation results.

[0164] When the evaluation result indicates that the packet loss rate of the image data stream of a certain vehicle suddenly increases to more than 15%, the core server will trigger a Grafana alarm and send an alarm message to the roadside unit. After receiving the alarm message, the roadside unit will control the vehicle to change its operating state. For example, it will control the vehicle to operate in the target operating state, that is, immediately reduce the vehicle fusion frame rate and downgrade the vehicle's warning algorithm from "vision + laser" to "pure laser" mode to ensure that the vehicle's data transmission latency is still less than 80ms.

[0165] In some embodiments, the content displayed on the visualization interface includes: an intersection map, in which the color of each vehicle represents its corresponding current packet loss rate (e.g., green indicates a current packet loss rate of <5%, yellow indicates a current packet loss rate of 5-15%, and red indicates a current packet loss rate of >15%); and the average latency curve of the data traffic over the past 5 minutes starting from the current moment, and the 95th percentile latency.

[0166] In some embodiments, the content displayed in the visualization interface is updated in real time.

[0167] If a 20% packet loss rate is detected in the vehicle's lidar point cloud data stream, the core server can control the vehicle to perform degradation processing to maintain the vehicle's average warning latency at 72ms and control the vehicle's emergency braking false trigger rate to be less than 1%, thereby meeting the requirements of the aforementioned IoT security standards.

[0168] Example 2: A scenario involving driving control of a convoy of multiple vehicles.

[0169] In this scenario, the convoy consists of at least a lead vehicle, middle vehicles, and a tail vehicle. The headway between any two adjacent vehicles in the convoy is 0.3 seconds, and they are traveling at a speed of 80 km / h. The lead vehicle periodically broadcasts its speed and acceleration information (e.g., via UDP protocol transmission over port 5001) through cellular vehicle-to-everything (C-V2X) based on the 5G protocol. The tail vehicle automatically adjusts its engine torque based on the broadcast messages it receives.

[0170] If a random packet loss of 7% or a sudden disconnection of 200ms occurs between the middle vehicle and the tail vehicle, determine whether the convoy can still maintain a safe distance of 10m.

[0171] The communication equipment in this vehicle-to-everything (V2X) network includes: an On-Board Unit (OBU) installed on the lead vehicle, multiple roadside units based on 5G base stations, an OBU on the tail vehicle, and a core server.

[0172] In some embodiments, the roadside unit responds to the sensing data sent by the vehicle and detects the sensing data according to a preset detection rule to obtain the flow detection data. The roadside unit can send the following instructions to the vehicle-mounted unit to achieve this step.

[0173] bash

[0174] # Match the first car → last car unicast stream (APN ID last 32 bits = 0x0a0b0c0d)

[0175]

[0176] #Sudden interruption: Triggers a 200ms 100% packet loss window every 30s.

[0177]

[0178] The roadside unit sends data such as the one-way delay (OWD) and packet loss burst length corresponding to the detected data stream "0xaaaa0a0b0c0d" to the core server in real time. The core server processes the data stream according to the preset evaluation model to obtain the evaluation result. If the evaluation result is determined to meet the preset operating conditions, the system determines the distance to be increased between adjacent vehicles in the fleet. Based on the initial distance and the distance to be increased between adjacent vehicles in the fleet, the system determines the fleet operation stability index. Based on the fleet operation stability index, the system determines the target operating state of each vehicle in the fleet.

[0179] The preset operating conditions include at least one of the following: the packet loss rate of communication between adjacent vehicles in the fleet is lower than the preset packet loss threshold within a preset time period; the data transmission jitter of adjacent vehicles in the fleet exceeds the budgeted jitter threshold; and the data transmission latency between adjacent vehicles in the fleet is less than the preset latency threshold.

[0180] For example, if the initial interval between adjacent vehicles in a platoon is set to d0 (e.g., 10m), and the interval to be increased is... Then the fleet's operational stability index can be determined. Among them, if If the CSI value is 0.97 for a 7% random packet loss between vehicles, and / or the CSI value is 0.92 or below for a 200ms sudden interruption, then it is determined that the vehicle's operating status needs to be adjusted to the target operating status.

[0181] However, if the CSI value recovers to 0.96 within 0.6 seconds, it can also indicate that the vehicles in the fleet are operating normally.

[0182] In some embodiments, the core server can send a downgrade command to the tail vehicle through a direct communication interface (e.g., PC5 interface). The tail vehicle switches its operating state to the target operating state (e.g., vehicle radar following mode) according to the downgrade command. At this time, the torque response time of the tail vehicle can be relaxed from 50ms to 150ms, thereby avoiding abnormalities caused by emergency braking.

[0183] In some embodiments, data transmission latency and jitter between vehicles in a fleet can be used as measurement parameters. For example, the weights for latency, packet loss rate, jitter, and throughput can be set to 0.4, 0.4, 0.1, and 0.1 respectively.

[0184] The flow-following detection method used in the flow-following detection system of this embodiment can effectively improve the accuracy of vehicle anomaly detection. When an anomaly is detected, the system can actively change the vehicle's operating state to the target operating state, thereby enabling the vehicle to better cope with anomalies, reduce the proportion of vehicle damage, and ensure the vehicle's operational stability.

[0185] Fifthly, embodiments of the present invention provide an electronic device.

[0186] Figure 7 This is a block diagram illustrating the composition of an electronic device according to an embodiment of the present invention. Figure 7As shown, the electronic device includes: one or more processors 701; a memory 702 storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement any of the above-mentioned flow detection methods; and one or more I / O interfaces 703 connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0187] Among them, processor 701 is a device with data processing capabilities, including but not limited to central processing unit (CPU); memory 702 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); I / O interface (read-write interface) 703 is connected between processor 701 and memory 702, and can realize information interaction between processor 701 and memory 702, including but not limited to data bus (Bus).

[0188] In some embodiments, the processor 701, memory 702, and I / O interface 703 are connected via a bus (e.g., ...). Figure 7 The thick lines shown in the diagram are interconnected, and in turn connected to other components of the computing device.

[0189] This embodiment also provides a computer-readable medium having a computer program stored thereon. When the program is executed by a processor, it implements the flow detection method provided in this embodiment. To avoid repetition, the specific steps of the flow detection method will not be repeated here.

[0190] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described flow detection method.

[0191] Those skilled in the art will understand that all or some of the steps, systems, or apparatuses in the methods, systems, and apparatuses described above can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0192] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0193] Those skilled in the art will understand that although some embodiments described herein include certain features that are included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this embodiment and form different embodiments.

[0194] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A method for detecting flow-in-flow, characterized in that, Applied to the core server, the method includes: Acquire flow-following detection data uploaded by multiple roadside units in the vehicle-to-everything (V2X) network. The flow-following detection data includes operational index data of at least one vehicle, which includes at least one of the vehicle's throughput, data transmission latency, jitter, and packet loss rate. The flow-following detection data is input into a preset evaluation model for processing to obtain evaluation results; the evaluation results reflect the vehicle's ability to handle anomalies. Based on the evaluation results, the target operating state of the vehicle is determined, which includes adjusting the collision warning level of the vehicle or adjusting the spacing distance in the convoy in which the vehicle is located. The target operating status of the vehicle is sent to the roadside unit corresponding to the vehicle, so that the roadside unit can forward the target operating status to the vehicle so that the vehicle can operate based on the target operating status.

2. The method according to claim 1, characterized in that, The step of inputting the flow-fed detection data into a preset evaluation model for processing to obtain evaluation results includes: The following flow detection data is normalized according to the data type to obtain normalized data; the following flow detection data includes indicator data of at least two data types; An evaluation score is determined based on the weights corresponding to each data type and the normalized data; wherein, different data types have different weights, and the weights characterize the sensitivity of the flow detection data in different business scenarios. The evaluation result is determined based on the evaluation score.

3. The method according to claim 2, characterized in that, The at least two types of data indicators include: the vehicle's throughput, the vehicle's data transmission latency, jitter, and packet loss rate; The normalized data includes at least one of the following: throughput score, latency score, jitter score, and packet loss rate score.

4. The method according to claim 1, characterized in that, The following flow detection data refers to the vehicle's operating index data detected by the vehicle through camera equipment and / or lidar equipment; Determining the target operating state of the vehicle based on the evaluation results includes: If the evaluation result indicates that the packet loss rate of the vehicle suddenly increases to a preset packet loss threshold, and the data transmission delay of the vehicle is less than a preset delay threshold, then it is determined to reduce the collision warning level of the vehicle. The target operating state of the vehicle is the state after at least one reduction in the collision warning level.

5. The method according to claim 1, characterized in that, The flow-following detection data is the operational index data of each vehicle in the convoy obtained by the roadside unit; the number of vehicles in the convoy is at least three. Determining the target operating state of the vehicle based on the evaluation results includes: If the evaluation result is determined to meet the preset operating conditions, the additional spacing distance between adjacent vehicles in the fleet is determined. The fleet operation stability index is determined based on the initial interval distance between adjacent vehicles in the fleet and the interval distance to be increased. Based on the fleet operation stability index, the target operating status of each vehicle in the fleet is determined.

6. The method according to claim 5, characterized in that, The preset operating conditions include at least one of the following: The packet loss rate of communication between adjacent vehicles in the fleet is lower than a preset packet loss threshold within a preset time period. The data transmission jitter of each adjacent vehicle in the convoy exceeds the budgeted jitter threshold; The data transmission delay between adjacent vehicles in the fleet is less than a preset delay threshold.

7. A method for detecting flow-in-flow, characterized in that, Applied to roadside units, including: In response to the sensing data sent by the vehicle, the sensing data is detected according to a preset detection rule to obtain flow detection data; the flow detection data includes at least one vehicle operation index data, and the vehicle operation index data includes at least one of the vehicle's throughput, the vehicle's data transmission latency, jitter and packet loss rate. The following detection data is sent to the core server so that the core server can process the following detection data to determine the target operating state of the vehicle. The target operating state includes adjusting the collision warning level of the vehicle or adjusting the spacing distance in the convoy of the vehicle. In response to the target operating status of the vehicle sent by the core server, the target operating status is forwarded to the vehicle so that the vehicle can operate based on the target operating status.

8. The method according to claim 7, characterized in that, The method further includes: The preset detection rules are generated based on user detection requirements and application awareness identifiers; The preset detection rule is a rule based on vector processing instructions, and the application perception identifier is an identifier that represents the vehicle's identity or the application scenario in which the vehicle is located.

9. An electronic device, characterized in that, include: One or more processors; A memory having stored one or more programs thereon, which, when executed by one or more processors, cause the one or more processors to implement the flow detection method as described in any one of claims 1-6, or to implement the flow detection method as described in any one of claims 7-8; One or more I / O interfaces are connected between the processor and the memory and configured to enable information interaction between the processor and the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the flow detection method as described in any one of claims 1-6, or implements the flow detection method as described in any one of claims 7-8.

Images