Vehicle automatic driving risk identification method and device, equipment and storage medium

Abstract

The invention discloses a risk identification method and device for vehicle automatic driving, equipment and a storage medium, and relates to the technical field of automatic driving. The method comprises the steps of obtaining at least two types of road environment data of a road where an automatic driving vehicle is located; wherein the data sources of any two types of road environment data are different; calling an automatic driving algorithm, and performing feature extraction on each type of road environment data to obtain road environment features of each type of road environment data; and performing risk judgment on the road according to the road environment characteristics of the at least two types of road environment data to obtain a risk road. According to the method, the risk road influencing the automatic driving safety of the vehicle can be effectively found, and the identification accuracy of the automatic driving risk of the vehicle is improved.

Description

Technical Field

[0001] This application relates to the field of autonomous driving technology, and in particular to a risk identification method, device, equipment, and storage medium for autonomous driving of vehicles. Background Technology

[0002] Autonomous vehicles may encounter hazardous roads that affect driving safety, such as dangerous roads with backlighting at tunnel entrances, strong light at tunnel exits, or continuous curves, as well as roads in adverse environments such as heavy rain or fog. Related technologies primarily determine whether a road is hazardous based on whether an autonomous vehicle has been involved in a traffic accident. However, even without a traffic accident, an autonomous vehicle might malfunction on a particular road, such as experiencing temporary visual impairment followed by recovery, or exhibiting abnormal lateral acceleration beyond normal operating limits. In such cases, the road should be classified as hazardous, but related technologies cannot achieve this.

[0003] In summary, the relevant technologies have low accuracy in identifying risks associated with autonomous driving. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a risk identification method, apparatus, device, and storage medium for autonomous driving of vehicles, which can effectively identify risky roads affecting the safety of autonomous driving and improve the accuracy of risk identification for autonomous driving.

[0005] To achieve the above objectives, a first aspect of this application proposes a risk identification method for autonomous driving of vehicles, the method comprising: Acquire at least two types of road environment data for the road where the autonomous vehicle is located; wherein the data sources for any two types of road environment data are different; The autonomous driving algorithm is invoked to extract features from each type of road environment data to obtain the road environment features of each type of road environment data. Risk roads are determined by assessing the road's risk based on the road environment characteristics of at least two types of road environment data.

[0006] Optionally, the step of determining the risk of a road based on the road environment characteristics of at least two types of road environment data to obtain a risky road includes: Anomaly detection is performed based on the correlation between the road environment features of at least two types of road environment data to obtain a first detected anomaly. Vehicle operation data is generated based on the road environment features of at least two types of road environment data. Anomaly detection is performed based on the correlation between the vehicle operation data and preset operation constraint data to obtain a second detected anomaly. In response to detecting at least one of the first detection anomaly and the second detection anomaly, the road is identified as a risk road.

[0007] Optionally, the at least two types of road environment data include a first type of road environment data and a second type of road environment data; The step of performing anomaly detection based on the correlation between road environment features of at least two types of road environment data to obtain a first detected anomaly includes: When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data belong to the same feature category, a consistency check is performed on the road environment features of the first type of road environment data and the road environment features of the second type of road environment data to obtain the first detected anomaly. When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data do not belong to the same feature category, the road environment constraint features of the second type of road environment data are generated based on the road environment features of the first type of road environment data, and constraint verification is performed based on the road environment constraint features and the road environment features of the second type of road environment data to obtain the first detected anomaly.

[0008] Optionally, generating road environment constraint features for the second type of road environment data based on the road environment features of the first type of road environment data includes: When the road environment features of the second type of road environment data indicate vehicle speed, road environment constraint features for indicating speed range are generated based on the road environment features of the first type of road environment data. When the road environment features of the second type of road environment data indicate the sensing target, road environment constraint features for indicating the list of sensing targets are generated based on the road environment features of the first type of road environment data.

[0009] Optionally, the operational constraint data includes traffic rule constraint data and vehicle capability constraint data; The step of detecting anomalies based on the correlation between the vehicle operation data and preset operation constraint data to obtain a second detected anomaly includes: When the vehicle operation data includes the trajectory of the autonomous vehicle, constraint verification is performed based on the trajectory and the traffic rule constraint data to obtain the second detected anomaly; When the vehicle operation data includes a control command request for controlling the autonomous vehicle, constraint verification is performed based on the control command request and the vehicle capability constraint data to obtain the second detected anomaly.

[0010] Optionally, the autonomous driving algorithm includes a vehicle-side autonomous driving algorithm and a cloud-based autonomous driving algorithm; the step of determining the risk of the road based on the road environment characteristics of at least two types of road environment data to obtain risky roads includes: From the road environment features of at least two types of road environment data, the vehicle-side road environment features extracted by the vehicle-side autonomous driving algorithm and the cloud-side road environment features extracted by the cloud-side autonomous driving algorithm are obtained by filtering. Anomaly detection is performed on the road based on the vehicle-side road environment characteristics and the cloud-based road environment characteristics to obtain a third detected anomaly. In response to the detection of the third detection anomaly, the road is identified as a risk road.

[0011] Optionally, the method further includes: If the risky road has a first detected anomaly, a road improvement strategy for improving the road environment is generated; If a second detection anomaly exists on the risky road, a vehicle-side improvement strategy is generated to improve the vehicle-side. If a third detection anomaly exists on the risky road, a vehicle-road-cloud improvement strategy is generated to enhance communication between the vehicle and at least one of the roadside equipment and other vehicles.

[0012] To achieve the above objectives, a second aspect of this application provides a risk identification device for autonomous driving of vehicles, the device comprising: The data acquisition module is used to acquire at least two types of road environment data of the road where the autonomous vehicle is located; wherein the data sources of any two types of road environment data are different; The feature extraction module is used to call the autonomous driving algorithm to extract features from each type of road environment data to obtain the road environment features of each type of road environment data. The risk assessment module is used to assess the risk of a road based on the road environment characteristics of at least two types of road environment data, and to identify risky roads.

[0013] To achieve the above objectives, a third aspect of this application provides a risk identification device for autonomous driving of vehicles, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0015] The method, apparatus, device, and storage medium for risk identification of autonomous driving proposed in this application first acquire at least two types of road environment data of the road where the autonomous vehicle is located. The data sources providing this road environment data can include onboard data sources (such as onboard radar) and roadside data sources (such as roadside cameras), which are used to plan the autonomous driving of the vehicle. Next, an autonomous driving algorithm is invoked to extract features from the aforementioned road environment data to obtain road environment features, such as distance to obstacles ahead and speed of vehicles ahead. Then, based on the road environment features of at least two types of road environment data, a risk assessment is performed on the road to identify risky roads. For example, when a vehicle is traveling in a lane, one type of road environment feature indicates that the vehicle is in a tunnel, but another type of road environment feature indicates that the vehicle is not in a tunnel. Roads with these contradictory road environment features will affect the safety of autonomous driving and will be identified as risky roads. In summary, this application can effectively identify risky roads that affect the safety of autonomous driving and improve the accuracy of risk identification for autonomous driving.

[0016] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0017] Figure 1 This is a flowchart of a risk identification method for autonomous driving of vehicles provided in an embodiment of this application; Figure 2 yes Figure 1 Flowchart for step 103; Figure 3 yes Figure 2 Flowchart of step 201; Figure 4 yes Figure 3 Flowchart for step 302; Figure 5 yes Figure 2 Flowchart for step 202; Figure 6 This is a flowchart of a risk identification method for autonomous driving of vehicles provided in another embodiment of this application; Figure 7 This is a schematic diagram of the arrangement of the sensing targets in the straight-moving state of the vehicle provided in the embodiments of this application; Figure 8 This is a schematic diagram of the arrangement of the sensing targets in the vehicle turning state provided in the embodiments of this application; Figure 9 This is an overall block diagram of the multi-dimensional determination of improvement strategies provided in the embodiments of this application; Figure 10 This is a system architecture diagram of the vehicle autonomous driving risk identification method provided in the embodiments of this application. Figure 11 This is a design relationship diagram of anomaly detection between the cloud and the vehicle, provided as an example in this application; Figure 12 This is another example of the design relationship diagram for anomaly detection between the cloud and the vehicle side provided in this application; Figure 13 This is a flowchart of a risk identification method for autonomous driving of vehicles provided in an example of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] This application provides a method, device, and computer-readable storage medium for identifying risks in autonomous driving, aiming to effectively identify risky roads that could cause abnormal situations in autonomous driving and improve the accuracy of risk identification.

[0022] The risk identification method for autonomous driving provided in this application can be applied to terminals and servers, or it can be software running on the server. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The software can be an application that implements the risk identification method for autonomous driving, but it is not limited to the above forms.

[0023] This application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: server computers, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable risk identification devices for autonomous driving in consumer vehicles, network PCs, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0024] The risk identification method, risk identification device, and computer-readable storage medium for autonomous driving of vehicles provided in this application are specifically described through the following embodiments. First, the risk identification method for autonomous driving of vehicles in this application embodiment is described.

[0025] Please refer to Figure 1 , Figure 1 An optional flowchart of a risk identification method for autonomous driving of vehicles is disclosed, which can be executed by at least one of the vehicle and the cloud. Figure 1 The method may include, but is not limited to, steps 101 to 103.

[0026] Step 101: Obtain at least two types of road environment data for the road where the autonomous vehicle is located; Step 102: Call the autonomous driving algorithm to extract features from each type of road environment data to obtain the road environment features of each type of road environment data; Step 103: Determine the risk of a road based on the road environment characteristics of at least two types of road environment data to obtain risky roads.

[0027] Steps 101 to 103 as shown in the embodiments of this application can effectively identify risky roads that affect the safety of autonomous driving and improve the accuracy of identifying risks to autonomous driving.

[0028] In step 101, at least two types of road environment data are acquired for the road where the autonomous vehicle is located. An autonomous vehicle refers to a vehicle that has activated its autonomous driving mode, or a vehicle in autonomous driving mode. Autonomous vehicles can include manned autonomous vehicles and unmanned autonomous vehicles. A road is a segment of road used to test whether the vehicle's autonomous driving function exhibits abnormalities. Roads can include: closed or semi-closed sections within research sections / test tracks, controlled traffic test sections (such as closed-time test sections in urban roads), complex real-world road sections (such as urban arterial roads, secondary arterial roads, etc.), and road sections under adverse weather and lighting conditions. It should be noted that those skilled in the art can select roads based on the actual application.

[0029] The data sources for any two types of road environment data are different. Data sources include vehicle-mounted data sources and roadside data sources. Autonomous vehicles include multiple vehicle-mounted data sources, such as vehicle-mounted sensors (including vehicle-mounted cameras, vehicle-mounted LiDAR, etc.) and vehicle-mounted mapping systems. Road environment data refers to data obtained by perceiving the road where the autonomous vehicle is located through data sources. Roadside data sources may include roadside cameras, roadside radar, roadside locators, etc.

[0030] It should be noted that the data sources of any two types of road environment data are different, including at least one of the following situations: (1) The data source of one type of road environment data is an in-vehicle data source, and the data source of the other type of road environment data is a roadside data source. (2) The in-vehicle data sources of the two types of road environment data are different, for example, the data source of one type of road environment data is an in-vehicle sensor, and the data source of the other type of road environment data is an in-vehicle map system, etc. (3) The roadside data sources of the two types of road environment data are different, for example, the data source of one type of road environment data is a roadside radar, and the data source of the other type of road environment data is an in-vehicle map system, etc.

[0031] In one example, for the above scenario (2), various types of road environment data may include environmental images provided by vehicle-mounted cameras, point cloud data provided by vehicle-mounted LiDAR, and positioning data provided by vehicle-mounted map systems. The vehicle-mounted map system may be a map-based navigation application. Map-based navigation applications can provide road environment data, such as positioning data for roads on slopes or curves.

[0032] In step 102, an autonomous driving algorithm is invoked to extract features from each type of road environment data, obtaining the road environment features for each type of road environment data. The autonomous driving algorithm can be used to plan vehicle autonomous driving, including vehicle-side autonomous driving algorithms deployed on the vehicle and cloud-based autonomous driving algorithms deployed in the cloud. Road environment features refer to the environmental features on the road calculated by the autonomous driving algorithm. For example, road environment features for multiple types of road environment data include perceived road features from onboard data sources and located road features from roadside data sources. Another example is road environment features for multiple types of road environment data, which include perceived road features from onboard sensors and located road features from onboard map systems. Yet another example is road environment features for multiple types of road environment data, which include perceived road features from roadside radar and located road features from roadside locators.

[0033] Both perceived road features and located road features fall under the category of road category features. Road category features can include a main classification of expressways / highways / townships / urban areas + major road feature classifications (curvature, slopes, tunnels, bridges, etc.) + lane line classifications + median classifications.

[0034] In step 103, the risk of a road can be determined based on the road environment characteristics of at least two types of road environment data. The purpose is to verify whether there are contradictions between the road environment characteristics of different types of road environment data, or to verify whether the vehicle operation data (such as vehicle speed) planned based on the road environment characteristics of different types of road environment data meets the specifications, so as to determine the road as a risk road.

[0035] It should be noted that risky roads are those that cause abnormalities in the autonomous driving of vehicles. Abnormalities in autonomous driving can include the following situations: (1) visual obscurity recovers after time t; (2) lateral acceleration exceeding normal operation; (3) yaw rate exceeding normal yaw rate; (4) sudden large deceleration demand; (5) sudden large deceleration demand; (6) sudden deceleration demand without a target ahead; (7) driving on unconventional available road surfaces; (8) inability to recognize road construction signs; (9) sudden speeding (exceeding the speed limit); (10) insufficient braking distance (exceeding the ability to stop under emergency braking); (11) abnormal vehicle bumps (bumps can be extracted from roll angle and longitudinal acceleration signals); (12) restricted targets are detected; (13) unknown targets beyond the normal autonomous driving perception range (e.g., vehicles pulling long steel bars); (14) insufficient line of sight.

[0036] In one embodiment, reference is made to Figure 2 Step 103 may include: Step 201: Perform anomaly detection based on the correlation between road environment features of at least two types of road environment data to obtain the first detected anomaly; Step 202: Generate vehicle operation data based on the road environment characteristics of at least two types of road environment data; perform anomaly detection based on the correlation between the vehicle operation data and the preset operation constraint data to obtain a second detected anomaly. Step 203: In response to detecting at least one of the first detection anomaly and the second detection anomaly, the road is identified as a risk road.

[0037] In step 201, the system can determine whether there is a contradiction between the road environment features of any two types of road environment data based on the correlation between their respective features. For example, if one type of road environment feature includes a perceived road feature indicating that the road is a tunnel, and the other type of road environment feature includes a localized road feature indicating that the road is a bridge, then there is a contradiction between the perceived road feature and the localized road feature, and a first detection anomaly will be automatically generated. This first detection anomaly is used to indicate that the autonomous driving of the vehicle malfunctions due to a contradiction in the correlation between the features. Alternatively, if both the perceived road feature and the localized road feature indicate that the road is a tunnel, then there is no need to generate a first detection anomaly.

[0038] In step 202, vehicle operation data can be generated first based on road environment features from at least two types of road environment data. Then, anomaly detection is performed based on the correlation between the vehicle operation data and preset operation constraint data to obtain a second detected anomaly. This second detected anomaly indicates that anomalies occur in the vehicle's autonomous driving due to a contradiction in the correlation between a feature and a constraint feature generated by another feature. Vehicle operation data refers to control commands (such as braking commands and steering commands) and driving parameters (such as vehicle speed and trajectory) used to control the vehicle's autonomous driving. Operation constraint data refers to specifications used to constrain vehicle operation data (such as maximum executable values ​​for braking, maximum executable values ​​for steering, maximum vehicle speed, and prohibition of driving over solid lines).

[0039] For example, at least two types of road environment data include perception data provided by vehicle-mounted sensors and positioning data provided by vehicle-mounted map systems. Based on the road environment characteristics of these two types of data, vehicle operation data including steering value and vehicle speed can be generated. Then, anomaly detection is performed on the vehicle operation data based on the maximum executable value of steering request and the maximum vehicle speed in the operation constraint data. If the steering value exceeds the maximum executable value of steering request and / or the vehicle speed exceeds the maximum vehicle speed, a second anomaly is generated.

[0040] In step 203, in response to the detection of at least one of the first detection anomaly and the second detection anomaly, the road is identified as a risk road.

[0041] The advantage of the embodiments of steps 201 to 203 described above is that anomaly detection can be achieved based on the correlation between road environment features or based on the combination of multiple road environment features. Through dual-branch anomaly detection, the accuracy of risk identification is further improved.

[0042] In one embodiment, at least two types of road environment data include a first type of road environment data and a second type of road environment data; refer to Figure 3 Step 201 may include: Step 301: When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data belong to the same feature category, then perform a consistency check on the road environment features of the first type of road environment data and the road environment features of the second type of road environment data to obtain the first detected anomaly. Step 302: When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data do not belong to the same feature category, the road environment constraint features of the second type of road environment data are generated based on the road environment features of the first type of road environment data, and constraint verification is performed based on the road environment constraint features and the road environment features of the second type of road environment data to obtain the first detected anomaly.

[0043] In step 301, for example, the first type of road environment data refers to road environment data from an onboard data source, and the second type of road environment data refers to road environment data from a roadside data source. As another example, the first type of road environment data refers to road environment data from an onboard map system, and the second type of road environment data refers to road environment data from an onboard sensor. Yet another example, the first type of road environment data refers to road environment data from a roadside radar, and the second type of road environment data refers to road environment data from a roadside locator.

[0044] In one example, the road environment features of the first type of road environment data include perceived road features, and the road environment features of the second type of road environment data include located road features. Since both located road features and perceived road features are used to indicate road categories, i.e., they belong to the same feature category, a consistency check can be performed on the located road features and perceived road features. If they are consistent, there is no need to generate the first detection anomaly; if they are inconsistent, the first detection anomaly is automatically generated.

[0045] In step 302, for example, the road environment features of the first type of road environment data include location road features, and the road environment features of the second type of road environment data include perceived vehicle speed features. Since the location road features are used to indicate the road category, and the perceived vehicle speed features are used to indicate the vehicle speed (e.g., a vehicle speed of 50 km / h or 20 km / h), road environment constraint features can be generated based on the location road features to constrain the perceived vehicle speed features (e.g., generating a maximum vehicle speed of 30 km / h based on the road being a curve). Then, constraint verification is performed based on the road environment constraint features and the road environment features of the second type of road environment. If the road environment features are not within the constraint range of the road environment constraint features, for example, 50 km / h is greater than 30 km / h, then a first anomaly detection is automatically generated. If the road environment features are within the constraint range of the road environment constraint features, for example, 20 km / h is less than 30 km / h, then there is no need to generate a first anomaly detection.

[0046] In one example, after constraining and validating the road environment features of the second type of road environment, the following situations may occur: vehicle speed does not match the curve; vehicle speed does not match the speed limit sign; vehicle speed at the lane merging position does not match the reversible lane distance; the position of road obstacles at the current vehicle speed cannot support obstacle avoidance control or braking control; no deceleration buffer zone is detected to support entering the ramp. When the above situations occur, the first detection anomaly is automatically generated.

[0047] The advantage of the embodiments of steps 301 to 302 described above is that anomaly detection can be achieved based on the consistency between features, or based on the constraint of one type of feature on another type of feature. Through bi-branch anomaly detection, the accuracy of anomaly detection is improved, thereby improving the accuracy of risk identification for autonomous driving of vehicles.

[0048] In one embodiment, reference is made to Figure 4 Step 302, which generates road environment constraint features for the second type of road environment data based on the road environment features of the first type of road environment data, may include: Step 401: When the road environment features of the second type of road environment data indicate vehicle speed, generate road environment constraint features to indicate the speed range based on the road environment features of the first type of road environment data. Step 402: When the road environment features of the second type of road environment data indicate the sensing target, road environment constraint features for indicating the list of sensing targets are generated based on the road environment features of the first type of road environment data.

[0049] In step 401, for example, the road environment features of the second type of road environment data indicate vehicle speed, while the road environment features of the first type of road environment data indicate speed limit signs, variable lane distances, obstacle positions, etc. Road environment constraint features indicating speed ranges can be generated based on speed limit signs, variable lane distances, obstacle positions, etc. For example, if a speed limit sign requires a minimum and a maximum vehicle speed, then the speed range includes both the minimum and maximum speeds. Then, the vehicle speed is compared with the depth range. If the vehicle speed is not within the depth range, a first anomaly detection is automatically generated. If the vehicle speed is within the depth range, there is no need to generate a first anomaly detection.

[0050] In step 402, for example, the road environment features of the second type of road environment data indicate the sensing targets (such as parking spaces, highway signs, oncoming vehicles, pedestrians crossing the road, unknown obstacles, urban road signs (pedestrian crossings, traffic lights, etc.)), and the road environment features of the first type of road environment data indicate that vehicles are operating in driving zones, urban areas, or highway zones. Road environment constraint features used to indicate the list of sensing targets can be generated based on whether vehicles are operating in driving zones, urban areas, or highway zones. For example, if vehicles are operating in driving zones, parking spaces should not theoretically appear, so the list of sensing targets does not include parking spaces. However, if the road environment features of the second type of road environment data indicate that the sensing targets include parking spaces, this indicates that the road environment features are not within the constraints of the road environment constraint features, and a first detection anomaly will be automatically generated. For example, when a vehicle is operating in a highway area, there should be no pedestrians crossing the road, unknown obstacles, or urban road signs. Therefore, the list of perceived targets does not include pedestrians crossing the road, unknown obstacles, or urban road signs. However, the road environment features of the second road feature environment data indicate that the perceived targets include pedestrians crossing the road, unknown obstacles, or urban road signs. In this case, it means that the road environment features are not within the constraints of the road environment constraint features, and the first detection anomaly will be automatically generated.

[0051] In one example, the road environment feature of the second type of road environment data indicates that the perceived target is without a target and the duration is longer than a predetermined duration threshold (e.g., 300ms), while the road environment feature of the first type of road environment data indicates that there is an urban road sign ahead. This means that the road environment feature is not within the constraint range of the road environment constraint feature, and the first detection anomaly will be automatically generated.

[0052] The advantage of the embodiments of steps 401 to 402 above is that anomaly detection is achieved by using speed constraints and perception target constraints generated from one type of road environment data to another type of road environment data, thereby improving the accuracy of anomaly detection.

[0053] In one embodiment, the operational constraint data includes traffic rule constraint data and vehicle capability constraint data; refer to Figure 5Step 202 may include: Step 501: When the vehicle operation data includes the trajectory of the autonomous vehicle, constraint verification is performed based on the trajectory and traffic rule constraint data to obtain the second detected anomaly. Step 502: When the vehicle operation data includes control command requests for controlling the autonomous vehicle, constraint verification is performed based on the control command requests and vehicle capability constraint data to obtain a second detected anomaly.

[0054] In step 501, for example, after constraint verification based on trajectory and traffic rule constraint data, the following situations may occur: running over solid lines is detected; running in the wrong lane is detected; incorrect running of left / right turns or straight lanes is detected; running in the emergency lane is detected; gravel features are detected on the highway; ice and snow features are detected on the highway; no speed reduction buffer zone is detected to support entering the ramp; no road feature warning is detected in the tunnel area; right-of-way is detected (overtaking priority vehicle, failing to yield); running a red light is detected; continuous passage through a no-entry sign is detected. If any of the above situations occur, a second detection anomaly is automatically generated.

[0055] Step 502 primarily verifies whether the control command requests issued by the autonomous driving algorithm (specifically, either a vehicle-side autonomous driving algorithm or a cloud-based autonomous driving algorithm) exceed the vehicle capability constraint data. The vehicle capability constraint data is a set of data boundaries: the maximum capability support value based on the chassis's dynamic model's execution boundary feedback. For example, the maximum executable values ​​for braking and steering (real-time chassis feedback). In principle, the kinematic model of autonomous driving should not exceed the chassis's executable response range. If it does, it indicates a failure or error in road recognition or perception recognition, or a passive avoidance situation; otherwise, it generally indicates comfortable driving.

[0056] The advantage of the embodiments of steps 501 to 502 above is that they propose constraint verification based on trajectory and traffic rule constraint data, and constraint verification based on control command request and vehicle capability constraint data. Through such dual-branch anomaly detection, the accuracy of anomaly detection is improved, thereby improving the accuracy of risk identification for autonomous driving.

[0057] In one embodiment, reference is made to Figure 6 Step 103 may include: Step 601: From the road environment features of at least two types of road environment data, filter to obtain the vehicle-side road environment features extracted by the vehicle-side autonomous driving algorithm and the cloud-side road environment features extracted by the cloud-side autonomous driving algorithm; Step 602: Based on the road environment characteristics on the vehicle side and the road environment characteristics on the cloud, perform anomaly detection on the road to obtain the third detected anomaly; Step 603: In response to the detection of a third detection anomaly, the road is identified as a risk road.

[0058] In step 601, one type of road environment data is sourced from a roadside data source, and the other type is sourced from an in-vehicle data source. The vehicle-side autonomous driving algorithm extracts vehicle-side road environment features from the road environment data provided by the in-vehicle data source. The cloud-based autonomous driving algorithm extracts cloud-based road environment features from the road environment data provided by the roadside data source. For example, vehicle-side road environment features include perceived road features from in-vehicle radar in the in-vehicle data source, and cloud-based road environment features include located road features from roadside locators in the roadside data source.

[0059] In one example, a cloud-based autonomous driving algorithm deployed in the cloud collects vehicle environment data (such as vehicle images (including images of the environment around the vehicle and images of targets around the vehicle), vehicle point cloud data, vehicle position data, roadside constraint data (such as speed limit signs), road feature data, etc.) from roadside devices (such as roadside cameras, roadside radar, roadside locators, etc.) on the road environment where the autonomous vehicle is located, and identifies cloud-based road environment features (such as perceived target 1, target speed 1, following distance 1, control constraints, road feature 1, etc.).

[0060] In step 602, anomaly detection may include: consistency detection of perception, driving rule-based detection, and road feature detection. For example, the vehicle-side road environment features indicate perceived target 2, target speed 2, following distance 2, control features, road feature 2, etc. A third anomaly detection can be generated based on at least one of the following detection results: consistency detection results of perceived target 1 and perceived target 2, consistency detection results of target speed 1 and target speed 2, consistency detection results of following distance 1 and following distance 2, driving rule-based detection results of control constraints and control features, and road feature detection results of road feature 1 and road feature 2.

[0061] The design of the consistency detection of perception is as follows: the shortest distance at which the target corresponding to the vehicle speed that the vehicle can process must be identified without the target appearing is the most stringent design "boundary scale". In low-end product solutions, the target recognition capability that is greater than or equal to this boundary scale is an acceptable risk-free and controllable product. Otherwise, it means that the target recognition distance of the vehicle is insufficient to support the safe braking of the vehicle or the obstacle time response is insufficient, which poses a risk.

[0062] The following distance is adjusted according to the planned path. The following distance is the distance between the perceived target and the position of the autonomous vehicle along the X-axis in the direction of motion. For example, referring to... Figure 7The perceived targets of the autonomous vehicle traveling in a straight-line state include perceived target m1, perceived target m2, perceived target m3, perceived target m4, perceived target m5, perceived target m6, perceived target m7, and perceived target m8. The following distance is the distance between the autonomous vehicle and perceived target m2. (Refer to...) Figure 8 In the cornering state, the perceived targets of the autonomous vehicle include perceived target m9, perceived target m10, perceived target m11, perceived target m12, and perceived target m13. The following distance is the distance between the autonomous vehicle and perceived target m11.

[0063] The design of the contradiction between the judgment of target speed and following distance is based on the definition of speed error requirements. Referring to Table 1, the "boundary scale spacing of the perceived target" is used as the lower limit. The vehicle speed can only be recognized as greater than, not less than, which is the same principle as the collision distance and braking capability control requirements.

[0064] Table 1

[0065] Referring to Table 1, `min` refers to the minimum distance at which a following vehicle can brake to a stop without colliding. However, it should generally not be smaller than this; otherwise, even if the target is visible, a collision may still occur, regardless of user experience. `TBD` refers to the value to be calibrated; it can be larger than this, or this value can be used as the `min` value. Distance control can be improved based on the braking phase control strategy of the autonomous driving controller to balance user experience. The final "boundary scale" is then established using the calibrated minimum braking distance supported by the autonomous driving system control strategy.

[0066] Control constraints (cloud) and control characteristics (vehicle): This refers to the discrepancy between the control constraints derived by the cloud-based autonomous driving algorithm and the control characteristic states (braking, driving, and steering control commands) derived by the vehicle-side autonomous driving algorithm. The main cloud-based estimation of control constraints is as follows: 1) If the vehicle's acceleration and steering control requests are detected by trajectory prediction in the cloud and a collision with the target is detected, then the trajectory curve of the control constraint is fed back in real time. The control characteristics are the actual acceleration and steering control requests issued by the vehicle.

[0067] 2) Cloud-based verification control constraints: The vehicle speed exceeds the speed limit (more than 20% error), the lane is an unconventional lane (outside the effective lane range of the positioning, such as in the emergency lane, or when driving with two lanes crossed and each occupying more than 20cm of lane width); the vehicle speed before merging does not match the lane merging position (according to Table 1 for the correspondence between vehicle speed and lane merging distance); the detour trajectory exceeds the minimum safety constraint (i.e., the vehicle control does not trigger the detour action even when an obstacle suddenly appears or the minimum detour distance is reached).

[0068] Road Feature 1 (Cloud) and Road Feature 2 (Vehicle): The cloud and vehicle sides are fixed attribute data groups, defined by first-level, second-level, and third-level classifications, and composed of: main classification of expressways / townships / urban areas + major road feature classification + lane line classification + median classification + road boundary classification + time and light classification + weather classification + road obstacle feature classification. For example, it is composed of: expressway area (level 1) + straight lane with no speed limit (level 2) + double solid lines (level 3) + double median strip (level 4) + single curb (level 5) + midday sunshine (level 6) + 0 rain, fog, 0 ice and snow (level 7) + no gravel (level 8).

[0069] In step 603, in response to the detection of a third detection anomaly, it is indicated that there is a contradiction between the features identified by the vehicle-side autonomous driving algorithm and the cloud-based autonomous driving algorithm. This contradiction will affect the safety of the vehicle's autonomous driving, so the road is identified as a risk road.

[0070] The advantage of the embodiments of steps 601 to 603 described above is that by combining vehicle-road-cloud detection with road environment features on the vehicle side and road environment features on the cloud, the accuracy of identifying risky roads is improved, thereby improving the accuracy of risk identification for autonomous driving.

[0071] In one embodiment, risk identification for autonomous driving may further include: If a risky road has a first-detection anomaly, a road improvement strategy is generated to improve the road environment. If a second detection anomaly is found on a risky road, a vehicle-side improvement strategy is generated to improve the autonomous vehicle. If a third detection anomaly is detected on a risky road, a vehicle-road-cloud improvement strategy is generated to enhance communication between the autonomous vehicle and at least one of the roadside devices and other vehicles.

[0072] For example, refer to Figure 9 After analyzing the data on risky roads, at least one of the following improvement strategies can be adopted: road improvement strategy, vehicle-side improvement strategy, and vehicle-road-cloud integrated improvement strategy. Road improvement strategies may include adding fixed speed limit signs, adding electronic variable signage, increasing control requirements for specific areas, removing unreasonable interference factors, and increasing protection and maintenance requirements. Vehicle-side improvement strategies may include enhancing the perception and recognition capabilities of vehicle-side autonomous driving algorithms, optimizing the decision-making, planning, and control capabilities of vehicle-side autonomous driving algorithms, introducing crowdsourced map custom layers, and modifying the functional scope of ODD constraints. Vehicle-road-cloud improvement strategies may include increasing communication between roadside equipment and vehicles, supplementing information that cannot be detected by vehicles from the roadside, supplementing information sharing between vehicles, and supplementing information sharing between interconnected big data and vehicles.

[0073] It should be noted that "introducing a crowdsourced map custom layer" means adding the features of the road segment previously passed through to the original map information after nearby area calibration and confirmation. This adds the feature, compensates for the lack of detail in the original map, achieves the purpose of customization and optimization, and supports better traffic strategies for the autonomous driving system. "Modifying the functional range of ODD constraints" means that when no other good solution is found, the risky road segment can be directly bypassed by the vehicle's autonomous driving system, with an early warning to allow manual driving to pass.

[0074] In one embodiment, reference is made to Figure 10 , Figure 10 The diagram shows the architecture of the system to which the risk identification method for autonomous driving of vehicles according to an embodiment of this application is applied; the system includes a vehicle-side algorithm area, a cloud-side algorithm area, 5G signals, map signals, and roadside signals.

[0075] The cloud-based algorithm area: The core is to use cloud-based autonomous driving algorithms to verify the rationality of all raw signals that can be used to support the scenario and are based on rules; and to perform cloud-based road reconstruction and positioning correction to output and position contradictory information, thereby forming risk roads to be analyzed.

[0076] Vehicle-side algorithm area: The core is to keep the vehicle-side autonomous driving algorithm unchanged, and selectively upload data for risky roads and upload abnormal signals that can be detected by itself.

[0077] 5G signals are commonly used for information interconnection in mobile phones or driver operations; some communication information can be interconnected using this solution as a relay information interconnection method.

[0078] Map signals: This applies to all map-based navigation applications for autonomous driving. The added road features are refined locally through crowdsourced maps, adding the necessary feature layers so that features that can be recognized by perception can be extracted and applied. Some road feature-related information can also be added to the crowdsourced layer in real time without relying on separate roadside signal equipment for connection.

[0079] Roadside signals: These are mostly used in the product testing and verification phases. The backend should minimize reliance on roadside signals, and some simplified roadside signals can be shared with 5G on the device side. However, certain road conditions may still require autonomous vehicles, which cannot be addressed with 5G alone. Examples include: autonomous driving mountain roads with no line of sight, and one-way streets excluding sequential passage. These require vehicle-to-vehicle communication or the addition of roadside cameras to provide real-time notifications of each vehicle's application status. These are road conditions that cannot be addressed by vehicle-side applications alone.

[0080] The data tracking and verification between cloud-based and vehicle-side autonomous driving algorithms can continue alongside product mass production. As the optimization of high-risk roads matures, the number of triggers from high-risk roads will decrease, eventually leading to risk-free roads. This indicates that product and road optimization have been fully integrated.

[0081] The following is combined Figure 11 and Figure 12 This diagram illustrates the design relationship between the cloud and the vehicle for anomaly detection.

[0082] Reference Figure 11 The cloud can acquire detection data of the vehicle's surrounding environment and targets from roadside cameras and roadside radar, as well as output data of road features and roadside constraints from the locator, and cloud signals uploaded by the vehicle (including control features and road features). Then, the cloud can invoke cloud-based autonomous driving algorithms to perform anomaly detection actions such as perception consistency detection, driving rule detection, and road feature detection based on the above data, obtaining the cloud-based positioning output information. The cloud-based positioning output information can include: Perceived Target 1 (cloud) VS Perceived Target 2 (vehicle), Target Speed ​​1 (cloud) VS Target Speed ​​2 (vehicle), Following Distance 1 (cloud) VS Following Distance 2 (vehicle), Control Constraints (cloud) VS Control Features (vehicle), and Road Feature 1 (cloud) VS Road Feature 2 (vehicle).

[0083] The vehicle can acquire input data from its onboard cameras, radar, and map system. Then, it can invoke its autonomous driving algorithm to perform anomaly detection actions such as consistency detection between perception and map localization, decision planning detection, and execution control detection, obtaining the vehicle's positioning output information. This output information can include: perceived road features (vehicle-side) vs. localized road features (vehicle-side), target speed (vehicle-side) vs. road feature constraints (vehicle-side), target trajectory (vehicle-side) vs. traffic rule constraints (vehicle-side), control out-of-range (vehicle-side) vs. vehicle capability constraints (vehicle-side), and system model anomalies (vehicle-side) vs. environmental images (vehicle-side).

[0084] Reference Figure 12 , Figure 12 and Figure 11The difference lies in the fact that the signals uploaded from the vehicle to the cloud can include the vehicle's perceived target, target speed, following distance, control features, and road features. The signals sent from the cloud to the vehicle also include the cloud's perceived target, target speed, following distance, control constraints, and road features. The output information for vehicle positioning also includes: perceived target 1 (cloud) VS perceived target 2 (vehicle), target speed 1 (cloud) VS target speed 2 (vehicle), following distance 1 (cloud) VS following distance 2 (vehicle), control constraints (cloud) VS control features (vehicle), and road feature 1 (cloud) VS road feature 2 (vehicle).

[0085] In one example, refer to Figure 13 The risk identification method for autonomous driving of vehicles may include the following steps: (1) Identify risky roads (e.g., identify roads as risky roads according to steps 101 to 103); (2) Design the road environment based on the risk roads, apply cloud-based autonomous driving algorithms and vehicle-side autonomous driving algorithms to embed points, and check the current solvable capabilities; (3) Both the data condition setting on the vehicle end and the data condition setting on the cloud are used for road analysis to confirm whether it is a roadside solution; (4) Implement the road improvement strategy and re-verify whether it passes; if yes, proceed to step (8); if no, proceed to step (5). (5) Implement the vehicle-side improvement strategy and re-verify whether it passes; if yes, proceed to step (8); if no, proceed to step (6). (6) Implement the road improvement strategy and vehicle improvement strategy, and re-verify whether they pass; if yes, proceed to step (8); if no, proceed to step (7). (7) Implement vehicle-road-cloud improvement strategies or prohibit autonomous vehicles from passing through this section of road; (8) End.

[0086] Risky roads are those that could cause anomalies in autonomous driving systems. These anomalies include limitations in perception, algorithmic computation, and vehicle movement. Combinations of extreme conditions, based on currently analyzable factors, are used to verify the rationality and usability of the triggering mechanism for the data collection algorithm.

[0087] Causes of road-related anomalies (related to or unrelated to road environmental factors): Limitations related to road environmental factors can be addressed through optimization within this process. Limitations unrelated to road environmental factors require solutions to be designed and implemented by the autonomous driving system itself.

[0088] Vehicle-side autonomous driving algorithm detection (data embedding): After identifying risky roads, the vehicle-side autonomous driving algorithm can be verified. This vehicle-side autonomous driving algorithm detection is based on a perception, decision-making, planning and control model, which is consistent with the original vehicle autonomous driving model, but with the addition of some embedded data output and condition setting design.

[0089] Cloud-based autonomous driving algorithm detection (data tracking): After identifying risky roads, the cloud-based autonomous driving algorithm can be validated. This detection is based on rule models collected from the cloud and transplanted vehicle characteristic models, enabling the repositioning of contradictory information and reconstruction of the road environment. For example, if the vehicle's map path leads to an R200 curve, but the speed remains at 120 km / h in the curve area, this is definitely problematic and will be addressed through cloud-based tracking. This identifies the source of the issue causing the discrepancy between the vehicle information and the cloud display.

[0090] Improvement strategy: This refers to the point where the final optimization scheme needs to be designed after the previous steps are completed. Please refer to the last column of Table 2.

[0091] In one example, the data tracking design scheme for the risk identification method of autonomous driving is shown in Table 2.

[0092] Table 2

[0093] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0094] This application also discloses a risk identification device for autonomous driving of vehicles. The risk identification device for autonomous driving of vehicles includes: a data acquisition module, used to acquire at least two types of road environment data of the road where the autonomous driving vehicle is located; wherein the data sources of any two types of road environment data are different; a feature extraction module, used to call an autonomous driving algorithm to extract features from each type of road environment data to obtain the road environment features of each type of road environment data; and a risk determination module, used to determine the risk of the road based on the road environment features of at least two types of road environment data to obtain the risky road.

[0095] In one embodiment, the risk identification device for autonomous driving of vehicles may further include: a risk resolution module, configured to: generate a road improvement strategy for improving the road environment if a first detection anomaly exists on the risky road; generate a vehicle-side improvement strategy for improving the vehicle if a second detection anomaly exists on the risky road; and generate a vehicle-road-cloud improvement strategy for enhancing communication between the vehicle and at least one of the roadside equipment and other vehicles if a third detection anomaly exists on the risky road.

[0096] It should be noted that the specific implementation of the risk identification device for autonomous driving of this vehicle is basically the same as the specific implementation of the risk identification method for autonomous driving of the vehicle described above, and will not be repeated here.

[0097] This application also discloses a risk identification device for autonomous driving of vehicles, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the risk identification method for autonomous driving of vehicles as described above. The risk identification device for autonomous driving of vehicles can be an electronic device, such as an in-vehicle terminal, smartphone, wearable device, or portable computer, etc. The risk identification device for autonomous driving of vehicles can also be a vehicle. The vehicle can be a new energy vehicle, such as a hybrid vehicle or a pure electric vehicle. For example, the vehicle can be a sedan, SUV, MPV, pickup truck, van, bus, etc.

[0098] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the risk identification method for autonomous driving of vehicles as described above.

[0099] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0101] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0102] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

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

[0105] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may 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; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0110] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A risk identification method for autonomous driving of vehicles, characterized in that, The method includes: Acquire at least two types of road environment data for the road where the autonomous vehicle is located; wherein the data sources for any two types of road environment data are different; The autonomous driving algorithm is invoked to extract features from each type of road environment data to obtain the road environment features of each type of road environment data. Risk assessment is performed on the road based on the road environment characteristics of at least two types of road environment data to obtain risky roads.

2. The method according to claim 1, characterized in that, The step of determining the risk of a road based on the road environment characteristics of at least two types of road environment data to obtain risky roads includes: Anomaly detection is performed based on the correlation between the road environment features of at least two types of road environment data to obtain a first detected anomaly. Vehicle operation data is generated based on the road environment features of at least two types of road environment data. Anomaly detection is performed based on the correlation between the vehicle operation data and preset operation constraint data to obtain a second detected anomaly. In response to detecting at least one of the first detection anomaly and the second detection anomaly, the road is identified as a risk road.

3. The method according to claim 2, characterized in that, The at least two types of road environment data include a first type of road environment data and a second type of road environment data; The step of performing anomaly detection based on the correlation between road environment features of at least two types of road environment data to obtain a first detected anomaly includes: When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data belong to the same feature category, a consistency check is performed on the road environment features of the first type of road environment data and the road environment features of the second type of road environment data to obtain the first detected anomaly. When the road environment features of the first type of road environment data and the road environment features of the second type of road environment data do not belong to the same feature category, the road environment constraint features of the second type of road environment data are generated based on the road environment features of the first type of road environment data, and constraint verification is performed based on the road environment constraint features and the road environment features of the second type of road environment data to obtain the first detected anomaly.

4. The method according to claim 3, characterized in that, The step of generating road environment constraint features for the second type of road environment data based on the road environment features of the first type of road environment data includes: When the road environment features of the second type of road environment data indicate vehicle speed, road environment constraint features for indicating speed range are generated based on the road environment features of the first type of road environment data. When the road environment features of the second type of road environment data indicate the sensing target, road environment constraint features for indicating the list of sensing targets are generated based on the road environment features of the first type of road environment data.

5. The method according to claim 2, characterized in that, The operational constraint data includes traffic rule constraint data and vehicle capability constraint data; The step of detecting anomalies based on the correlation between the vehicle operation data and preset operation constraint data to obtain a second detected anomaly includes: When the vehicle operation data includes the trajectory of the autonomous vehicle, constraint verification is performed based on the trajectory and the traffic rule constraint data to obtain the second detected anomaly; When the vehicle operation data includes a control command request for controlling the autonomous vehicle, constraint verification is performed based on the control command request and the vehicle capability constraint data to obtain the second detected anomaly.

6. The method according to any one of claims 1 to 5, characterized in that, The autonomous driving algorithm includes vehicle-side autonomous driving algorithm and cloud-based autonomous driving algorithm; The step of determining the risk of a road based on the road environment characteristics of at least two types of road environment data to obtain risky roads includes: From the road environment features of at least two types of road environment data, the vehicle-side road environment features extracted by the vehicle-side autonomous driving algorithm and the cloud-side road environment features extracted by the cloud-side autonomous driving algorithm are obtained by filtering. Anomaly detection is performed on the road based on the vehicle-side road environment characteristics and the cloud-based road environment characteristics to obtain a third detected anomaly. In response to the detection of the third detection anomaly, the road is identified as a risk road.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: If a first detection anomaly exists on the risky road, a road improvement strategy for improving the road environment is generated; If a second detection anomaly exists on the risky road, a vehicle-side improvement strategy is generated to improve the vehicle-side. If a third detection anomaly exists on the risky road, a vehicle-road-cloud improvement strategy is generated to enhance communication between the vehicle and at least one of the roadside equipment and other vehicles.

8. A risk identification device for autonomous driving of vehicles, characterized in that, The device includes: The data acquisition module is used to acquire at least two types of road environment data of the road where the autonomous vehicle is located; wherein the data sources of any two types of road environment data are different; The feature extraction module is used to call the autonomous driving algorithm to extract features from each type of road environment data to obtain the road environment features of each type of road environment data. The risk assessment module is used to assess the risk of a road based on the road environment characteristics of at least two types of road environment data, and to identify risky roads.

9. A risk identification device for autonomous driving of vehicles, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images