Vehicle risk processing method, device and computer equipment

By receiving risk assessment data from associated servers, matching vehicle information to generate risk assessment results and formulate strategies, the problem of intelligent vehicle terminals being unable to identify security threats has been solved, improving the accuracy and efficiency of risk assessment and handling.

CN119939597BActive Publication Date: 2025-10-28CHERY AUTOMOBILE CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510005029.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-01-02
Publication Date
2025-10-28
Estimated Expiration
2045-01-02

AI Technical Summary

Technical Problem

In existing technologies, hardware analysis of intelligent vehicle terminals cannot identify security threats and vulnerabilities in vehicle systems, resulting in incomplete risk assessments and an inability to formulate effective risk management strategies.

Method used

By receiving updated risk assessment data from associated servers, matching vehicle-related information, generating risk assessment results, and formulating risk handling strategies, the integrity and timeliness of the data are ensured.

Benefits of technology

This improved the accuracy and efficiency of vehicle risk assessment, ensured the effectiveness and accuracy of risk management strategies, and enhanced vehicle safety.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119939597B_ABST
    Figure CN119939597B_ABST
Patent Text Reader

Abstract

This application discloses a method, apparatus, and computer device for handling vehicle risks, belonging to the field of vehicle-mounted systems. The method includes: receiving first risk assessment update data sent by at least one associated server and storing it in a first risk assessment database; obtaining vehicle-related information of a first vehicle; matching the first risk assessment database with the vehicle-related information of the first vehicle to obtain a risk assessment result for the first vehicle, wherein the risk assessment result includes a risk scenario corresponding to the first vehicle, and the risk scenario refers to a usage scenario in which the first vehicle generates a risk; and obtaining a risk handling strategy for the first vehicle based on the risk assessment result. This further improves the accuracy and effectiveness of determining the risk handling strategy.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted systems, and in particular to a method, apparatus, and computer device for handling vehicle risks. Background Technology

[0002] With the rapid development of intelligent vehicle terminals, the issue of vehicle information security has gradually become a major concern.

[0003] In related technologies, companies and vehicle component suppliers that manufacture intelligent vehicle terminals perform manual analysis in advance to obtain the analysis results of the intelligent vehicle terminals.

[0004] However, manual analysis can only analyze the hardware structure of intelligent vehicle terminals and is prone to omissions, failing to identify security threats and vulnerabilities in the vehicle system within the intelligent vehicle terminal. Summary of the Invention

[0005] This application provides a method, apparatus, and computer equipment for handling vehicle risks, enabling hierarchical management of seismic data, improving the efficiency of vehicle risk assessment, and enhancing the efficiency of developing vehicle risk management strategies. The technical solution is as follows:

[0006] According to one aspect of this application, a method for handling vehicle risks is provided, the method comprising:

[0007] The system receives first risk assessment update data sent by at least one associated server and stores it in a first risk assessment database. The at least one associated server maintains a second risk assessment database. The first risk assessment update data is data updated to the second risk assessment database within the data update cycle.

[0008] Obtain vehicle-related information of the first vehicle, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle;

[0009] Match the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle. The risk assessment result includes the risk scenario corresponding to the first vehicle. The risk scenario refers to the usage scenario in which the first vehicle will generate a risk.

[0010] Based on the risk assessment results, a risk management strategy for the first vehicle is obtained, and the risk management strategy is used to address the risk scenario.

[0011] According to one aspect of this application, a vehicle risk handling device is provided, the device comprising:

[0012] A receiving module is configured to receive first risk assessment update data sent by at least one associated server and store it in a first risk assessment database. The at least one associated server maintains a second risk assessment database. The first risk assessment update data is data updated to the second risk assessment database within a data update cycle.

[0013] An acquisition module is used to acquire vehicle-related information of the first vehicle, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle.

[0014] The matching module is used to match the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle. The risk assessment result includes the risk scenario corresponding to the first vehicle, and the risk scenario refers to the usage scenario in which the first vehicle generates a risk.

[0015] The acquisition module is used to acquire a risk handling strategy for the first vehicle based on the risk assessment result, and the risk handling strategy is used to deal with the risk scenario.

[0016] According to one aspect of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the processor loading and executing the computer program to implement the above-described method for handling vehicle risks.

[0017] According to another aspect of this application, a computer-readable storage medium is provided, which stores a computer program that is loaded and executed by a processor to implement the above-described method for handling vehicle risks.

[0018] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned vehicle risk handling method.

[0019] The beneficial effects of the technical solutions provided in this application include at least the following:

[0020] The vehicle server is associated with at least one associated server storing updated first risk assessment data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the updated first risk assessment data. Subsequently, based on the vehicle-related information of the first vehicle, the risk assessment result is matched from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of a method for handling vehicle risks provided in an exemplary embodiment of this application;

[0023] Figure 2 This is a flowchart of a vehicle risk handling method provided in an exemplary embodiment of this application;

[0024] Figure 3 This is a flowchart of a method for handling vehicle risks provided in another exemplary embodiment of this application;

[0025] Figure 4 This is a flowchart of a method for handling vehicle risks provided in another exemplary embodiment of this application;

[0026] Figure 5 This is a flowchart of a method for handling vehicle risks provided in yet another exemplary embodiment of this application;

[0027] Figure 6 This is a flowchart of a vehicle risk handling apparatus provided in an exemplary embodiment of this application;

[0028] Figure 7 This is a flowchart of a vehicle risk processing apparatus provided in another exemplary embodiment of this application;

[0029] Figure 8 This is a structural block diagram of a computer device provided in an exemplary embodiment of this application;

[0030] Figure 9 This is a structural block diagram of a server provided in an exemplary embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0032] like Figure 1 As shown, Figure 1A structural block diagram of a computer system provided in an exemplary embodiment is shown. Based on this structural block diagram, the execution process of the vehicle risk handling method provided in this application embodiment will be described. The computer system includes a first vehicle 100, a server 101 corresponding to the first vehicle, and at least one associated server 102. The following process is described using the server 101 corresponding to the first vehicle as an example of the execution subject.

[0033] In this embodiment of the application, the server 101 corresponding to the first vehicle establishes a communication connection with at least one associated server 102, that is, the server 101 and at least one associated server 102 are mutually associated.

[0034] Server 101 maintains a first risk assessment database 103, which stores risk assessment update data. The risk assessment update data is used to determine the risk scenario corresponding to a vehicle based on the vehicle-related information.

[0035] At least one associated server 102 maintains a second risk assessment database 104, wherein the first number of the second risk assessment databases is equal to the second number of associated servers, that is, each associated server maintains a corresponding second risk assessment database.

[0036] Server 101 obtains vehicle-related information corresponding to the first vehicle 100, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle.

[0037] Server 101 matches the vehicle-related information with the first risk assessment update data stored in the first risk assessment database to obtain the risk assessment result of the first vehicle 100.

[0038] Server 101 uses a preset algorithm to determine the risk handling strategy corresponding to the first vehicle 100. The risk handling strategy is used to deal with risk scenarios and maintain the vehicle safety of the first vehicle 100.

[0039] The above process describes the execution process of cooperation between the first vehicle 100, server 101, and at least one associated server 102. In practical applications, this can be accomplished by the first vehicle 100 cooperating with an external terminal.

[0040] Indicatively, the external terminal integrates updated risk assessment data from a second risk assessment database maintained by at least one associated server and stores it on a local disk.

[0041] An external terminal obtains vehicle-related information corresponding to the first vehicle 100, matches the vehicle-related information with the first risk assessment update data in the local disk, obtains the risk assessment result corresponding to the first vehicle 100, and generates a risk handling strategy for the first vehicle 100 based on the risk assessment result.

[0042] This application does not limit the implementation scenarios of the vehicle risk handling method provided in the above embodiments.

[0043] It is worth noting that when the aforementioned external terminal is implemented as a smart terminal, the smart terminal can be: a smartphone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, or a desktop computer. The terminal can also be referred to as user equipment, a portable terminal, a laptop terminal, a desktop terminal, or other names, and this application does not limit the specific name used.

[0044] The aforementioned server 101 and at least one associated server 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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 (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, the server can also be implemented as a node in a blockchain system.

[0045] It should be noted that all information (including but not limited to vehicle-related information), data (including but not limited to data used for analysis, data stored, data displayed), and signals involved in this application are authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0046] like Figure 2 As shown, Figure 2 A flowchart illustrating the execution of a vehicle risk handling method provided in an exemplary embodiment of this application is shown. The method is described with the vehicle server corresponding to the vehicle as the executing entity.

[0047] Step 200: Receive first risk assessment update data sent by at least one associated server and store it in the first risk assessment database.

[0048] In this embodiment, the vehicle is connected to a vehicle server, a network connection is established between the vehicle and the vehicle server, and a communication connection is established between the vehicle server and at least one associated server for exchanging (mutually storing) their respective stored data.

[0049] The vehicle server maintains a first risk assessment database, and at least one associated server maintains a second risk assessment database.

[0050] The following is an introduction to the content of the first and second risk assessment databases:

[0051] The first and second risk assessment databases are centralized databases or knowledge bases for storing and managing security threat information. They contain potential threats, vulnerabilities, attack vectors, malicious applications, exploit code, and other security-related data across various domains.

[0052] The first and second risk assessment databases are used to analyze, identify, respond to, and defend against security threats.

[0053] The first and second risk assessment databases collect security threat information across various sectors (with the same meaning as the risk assessment update data described below), including publicly available security bulletins, vulnerability databases, security communities, and intelligence sharing platforms.

[0054] The first and second risk assessment databases categorize the collected security threat information according to preset types and risk severity levels. The preset types include at least one of malicious applications, network attacks, and vulnerabilities, while the risk severity levels range from level 1 to level 5, with higher levels indicating greater risk.

[0055] The first and second risk assessment databases provide contextual information about security threats, including at least one of the following: the attacker, the motive, the target, and the method of attack.

[0056] The following describes the relevant content regarding the completion of data updates for the second risk assessment database:

[0057] In this embodiment, at least one associated server maintains a second risk assessment database storing updated first risk assessment data. This updated second risk assessment data refers to security-related data such as potential threats, vulnerabilities, attack vectors, and malicious applications existing in a predetermined domain. The predetermined domains include automotive, computer, mechanical, and artificial intelligence domains, among others.

[0058] At least one associated server updates the first risk assessment update data stored in the second risk assessment database according to the data update cycle.

[0059] The data update cycle can be every preset time period, or it can be whenever data migration operations occur in the second risk database; this application does not limit this. Optionally, the data migration operation includes at least one of data addition, data deletion, and data copying operations.

[0060] As an illustration, at least one associated server updates the first risk assessment update data stored in the second risk assessment database every preset time interval.

[0061] In response to the addition of first data to the second risk assessment database within a preset time period, at least one associated server adds the first data to the first risk assessment update data.

[0062] In response to the deletion of the second data from the second risk assessment database within a preset time period, at least one associated server deletes the second data from the first risk assessment update database.

[0063] In response to a preset time period, at least one associated server performs a deduplication operation on the first risk assessment update data stored in the second risk assessment database, counts the duplicate third data in the first risk assessment update data, and deletes the third data from the first risk assessment update data.

[0064] The following describes the data interaction between the vehicle server corresponding to the vehicle and at least one associated server:

[0065] The vehicle server receives first risk assessment update data sent by at least one associated server and stores the first risk assessment update data in the first risk assessment database maintained by the vehicle server.

[0066] After storing the first risk assessment update data, at least one associated server determines the first risk characteristic corresponding to the first risk assessment update data. The first risk characteristic includes at least one of the following: the target of the risk, the risk name, the risk number, the attacker corresponding to the risk, the attack path corresponding to the risk, and the attack principle corresponding to the risk.

[0067] Among them, the risk target refers to the application object of the first risk assessment update data, the risk name refers to the name of the first risk assessment update data, the risk number refers to the number corresponding to the first risk assessment update data, the attacker corresponding to the risk refers to the object that launches an attack on the risk target, causing the risk target to have a security threat, the attack path corresponding to the risk refers to the execution path adopted by the attacker, and the attack principle corresponding to the risk refers to the mechanism and method by which the attacker uses vulnerabilities or weaknesses in the system, network or application to carry out an attack.

[0068] In another alternative embodiment, the vehicle server uses a preset data acquisition algorithm to obtain first risk assessment update data sent by at least one associated server.

[0069] The vehicle server acquires preset vehicle characteristics, which are features related to the hardware structure and software architecture of the first vehicle. These include, but are not limited to, the application names corresponding to each hardware component within the first vehicle, the software system corresponding to the software architecture, the software execution algorithm, and the data interaction process within the vehicle system.

[0070] The vehicle server determines the first risk feature corresponding to the first risk assessment update data, and obtains the risk target and risk name in the first risk feature.

[0071] Based on the risk's target and name, the data is matched with the aforementioned preset vehicle characteristics. Second risk assessment update data unrelated to the preset vehicle characteristics is determined from the first risk assessment update data, and third risk assessment update data related to the preset vehicle characteristics is determined from the first risk assessment update data.

[0072] Optionally, the vehicle server retains the third risk assessment update data and identifies it as the first risk assessment update data, storing it in the first risk assessment database.

[0073] In another optional embodiment, based on the risk target and the risk name, second risk assessment update data that is unrelated to preset vehicle characteristics is deleted from the first risk assessment update data to obtain first risk assessment data, and the first risk assessment data is stored in the first risk assessment database.

[0074] The following describes the specific process by which the vehicle server obtains the first risk assessment update data from at least one associated server:

[0075] The vehicle server uses a preset acquisition algorithm to obtain the first risk assessment update data sent by at least one associated server.

[0076] The preset data acquisition algorithm includes any one of the following: automated script acquisition method, application programming interface call method, database extraction method, log file analysis method, etc.

[0077] The automated script acquisition method refers to using pre-written scripts by relevant personnel to obtain the first risk assessment update data stored in at least one associated server.

[0078] The application programming interface (API) call method refers to obtaining the first risk assessment update data from at least one associated server by utilizing the API interface.

[0079] The database extraction method refers to the vehicle server directly connecting to at least one associated server to directly obtain the updated data of the first risk assessment from the second risk assessment database.

[0080] Log file analysis refers to obtaining log files from at least one associated server and extracting the first risk assessment update data from the log files.

[0081] The following details the process of obtaining updated data for the first risk assessment using automated scripts:

[0082] Optionally, at least one associated server maintains a second risk assessment database that stores the first risk assessment update data in the form of data association tuples.

[0083] The data association tuple includes the first risk assessment update data and the corresponding data network storage address.

[0084] Optionally, a first network storage address is obtained, wherein the first network storage address is the address corresponding to storing the first risk assessment update data sent by at least one associated server.

[0085] Identify at least one associated tuple of data stored within a second risk assessment database maintained by an associated server.

[0086] The first network storage address is updated based on the data association tuple to obtain the updated network storage address. Specifically: the webpage content within the data network storage address corresponding to the first risk assessment update data is read, and the webpage content is compared with the first risk assessment update data. If the two contents match, the first network storage address is updated based on the data association tuple to obtain the updated network storage address. The vehicle server directly reads the webpage content from the updated network storage address and identifies the webpage content as first risk assessment update data stored on at least one associated server. The first risk assessment update data is then obtained and stored in the first risk assessment database.

[0087] In another optional embodiment, a first network storage address and a data network storage address corresponding to the first risk assessment update data stored in at least one associated server are obtained.

[0088] Based on the first network address, the data network storage address corresponding to the first risk assessment update data is read using an automated script acquisition method, and the data network storage address is stored in the first network address to obtain the updated network storage address.

[0089] The vehicle server stores the updated network storage addresses in the first risk assessment database. When subsequent updates to the first risk assessment data are needed, the server reads the webpage content corresponding to each address from the updated network storage addresses and uses it as the updated first risk assessment data.

[0090] In the process of retrieving data network storage addresses using automated scripts, if new first risk assessment update data appears in at least one associated server, a deduplication process is also involved in this embodiment to further ensure data non-repeatability. Specifically, at least one associated server stores m first risk assessment update data points, where m is a positive integer. The m first risk assessment update data points correspond to m data network storage addresses.

[0091] When the vehicle server reads the 0th data network storage address, it adds the 0th data network storage address to the address list and reads the 0th first risk assessment update data corresponding to the 0th data network storage address. When reading the (0+1)th data network storage address, it checks whether the (0+1)th data network storage address appears in the address list. If it does, it does not read the (0+1)th first risk assessment update data corresponding to the (0)th data network storage address (which is identical to the 0th first risk assessment update data). If it does not appear, it reads the (0+1)th first risk assessment update data corresponding to the (0+1)th data network storage address. Here, 0 is a positive integer less than or equal to m.

[0092] In an optional embodiment, a stop condition is set for the automated script acquisition method, which indicates a condition for stopping the acquisition of first risk assessment update data stored in at least one associated server.

[0093] In an optional embodiment, the first risk database includes a data acquisition module and a data filtering module. The data acquisition module is used to acquire first risk assessment update data from at least one associated server, and the data filtering module is used to filter second risk assessment update data from the acquired first risk assessment update data.

[0094] Step 201: Obtain vehicle-related information for the first vehicle.

[0095] Optionally, vehicle-related information is used to characterize the hardware structure and software architecture corresponding to the first vehicle.

[0096] The hardware structure refers to the physical components and systems that constitute the first vehicle, which work together to realize the functions of the first vehicle. Different first vehicles correspond to different hardware structures.

[0097] The hardware structure includes the powertrain system, chassis system, body of the first vehicle, fuel system, emission control system, safety system, and user experience system.

[0098] The following is a brief introduction to each system in the above hardware architecture:

[0099] The power system primarily provides power to the first vehicle and mainly consists of physical components such as the engine, transmission, drive shaft, and differential.

[0100] The chassis system primarily controls the driving, steering, and braking functions of the first vehicle. It mainly consists of the chassis system, suspension subsystem, steering subsystem, braking subsystem, wheels, and tires. The chassis system includes the vehicle frame, which supports and connects other physical components within the vehicle. The suspension subsystem connects the wheels to the frame and includes independent or non-independent suspension. The steering subsystem is primarily responsible for the vehicle's direction of travel. It mainly includes physical components such as the steering gear, steering column, steering gear, and steering tie rods. The braking subsystem is primarily responsible for the vehicle's deceleration and stopping, and includes physical components such as brake discs, brake calipers, master cylinder, wheel cylinders, and brake fluid. The wheels and tires are the parts of the first vehicle that directly contact the ground, primarily providing traction.

[0101] The body of the first vehicle includes a body shell, doors, windows, and a roof. The body shell primarily provides aerodynamic performance, while the doors, windows, and roof primarily provide access to the first vehicle.

[0102] The fuel system is mainly responsible for transporting fuel from the fuel tank to the engine, and mainly includes physical components such as fuel pump, fuel filter, fuel lines and fuel injectors.

[0103] The emission control system is mainly responsible for expelling the exhaust gases from the engine into the first vehicle, and mainly includes physical components such as the exhaust manifold, catalytic converter, and muffler.

[0104] The safety system is primarily responsible for protecting passengers from injury in a collision and improving the maneuverability of the first vehicle during emergency braking.

[0105] Software architecture refers to the methods and principles for designing and organizing the software systems integrated within a first vehicle. Software architecture includes at least one of the following: automotive open system architecture, application software layer, runtime environment, basic software layer, and automotive electronic and electrical architecture.

[0106] In this embodiment, the software architecture is implemented as an embedded layered structure.

[0107] The following is a brief introduction to each system in the above software architecture:

[0108] The open system architecture for automobiles mainly includes software architecture, methodology, and application interfaces. Among these, software architecture is the key to achieving the separation of software and hardware.

[0109] The application software layer contains at least one software component (SWC), which interacts with each other through ports. Each software component may contain one or more runnable entities (REs), which encapsulate the relevant control algorithms.

[0110] The runtime environment acts as a bridge between the application software layer and the infrastructure software layer, ensuring the separation of hardware and software. Runnable Entity Events (RTE events) enable communication between software components, between infrastructure software components, and between software components and infrastructure software components. RTEs encapsulate communication and services within the infrastructure software layer, providing standardized infrastructure software and communication interfaces for application layer software components.

[0111] The basic software layer includes the Services Layer, the ECU Abstraction Layer, the Microcontroller Abstraction Layer (MCAL), and the Complex Drivers Layer.

[0112] The automotive electronic and electrical architecture includes all the hardware, software, sensors, actuators, and electronic and electrical distribution systems on the first vehicle, and integrates the above through system integration tools.

[0113] In this embodiment of the application, the specific process by which the vehicle server obtains the vehicle-related information of the first vehicle is as follows:

[0114] Obtain the hardware and software structures corresponding to the first vehicle; generate the hardware structure information corresponding to the hardware structure and the software architecture information corresponding to the software architecture.

[0115] The external device that interacts with the first vehicle is identified. The external device can be a smart terminal or another vehicle other than the first vehicle. This application does not limit the specific device to this.

[0116] Data interaction refers to the existence of data flow between the first vehicle and the external device. That is, there is one-way communication or two-way communication between the first vehicle and the external device. One-way communication means that the first vehicle (external device) sends data to the external device (first vehicle) unilaterally, while two-way communication means that the first vehicle and the external device send and receive data to each other.

[0117] The vehicle data generated within the first vehicle is determined. Vehicle data refers to data related to the hardware structure and software architecture. This is illustrative. The hardware structure includes various sensors, and the vehicle data is implemented as sensor data collected by each sensor. The software architecture includes the intelligent driving system, and the vehicle data is implemented as intelligent driving commands (such as automatic deceleration).

[0118] Determine the data interaction details when vehicle data interacts with external devices. Specifically, this involves: determining whether the vehicle data is generated and processed by the first vehicle itself; if the vehicle data is not generated and processed by the first vehicle itself, determining that the vehicle data generated by the first vehicle needs to be completed through interaction with external devices, and determining the data interaction details when the first vehicle and external devices interact based on the vehicle data. The data interaction details include information such as the recipient and sender of the vehicle data, and the corresponding data content.

[0119] Based on the data interaction, the first asset type corresponding to the hardware structure is identified, and a first binary array is generated. The first binary array includes the hardware structure and the first asset type. The first asset type can be either a physical asset or a digital asset.

[0120] Based on the data interaction, the second asset type corresponding to the software architecture is identified, and a second binary array is generated. The second binary array includes the hardware structure and the second asset type. The second asset type can be either a physical asset or a digital asset.

[0121] Vehicle-related information is generated based on the first binary array and the second binary array. Optionally, vehicle-related information is generated based on the first binary array, the second binary array, and data interaction details.

[0122] In another optional embodiment, the hardware structure and software architecture corresponding to the first vehicle are obtained; the hardware name corresponding to the hardware structure is determined, and the software name corresponding to the software architecture is determined.

[0123] Based on the above data interaction, the first asset type corresponding to the hardware structure is identified from the perspectives of data interaction execution process, data flow, data storage, and the interacting parties, and the second asset type corresponding to the software architecture is identified.

[0124] Among them, physical assets are used to represent the physical components that objectively exist in the first vehicle, while digital assets refer to information that exists in the first vehicle in digital form, such as ECU firmware, communication data, user privacy data, security algorithms, etc.

[0125] Step 202: Match the first risk assessment database with vehicle-related information to obtain the risk assessment result of the first vehicle.

[0126] Optionally, the vehicle-related information can be compared with the updated first risk assessment data stored in the first risk assessment database to obtain the comparison results.

[0127] Based on the comparison results, the risk scenarios corresponding to vehicle-related information are analyzed using a preset risk identification standard. A risk scenario refers to a usage scenario in which the first vehicle generates a risk. The preset risk identification standard is implemented using the ISO 21434 standard, but it can also be a standard specified by relevant personnel based on the actual application of the vehicle; this application does not impose any limitations on this.

[0128] The risk assessment results for the risk scenario are determined by using preset risk identification criteria.

[0129] The following describes the usage scenarios where the first vehicle poses a risk:

[0130] The risk scenario is implemented as a cloud-based risk, where attackers put the first vehicle in a dangerous situation by attacking the vehicle server or related servers.

[0131] The risk scenario is implemented as a hardware risk, which mainly refers to an attacker putting the first vehicle in a dangerous situation by attacking (tampering with) the data or physical interfaces corresponding to the hardware structure built into the first vehicle. For example, attacking the temperature sensor inside the first vehicle and tampering with the temperature collected by the temperature sensor can prevent the vehicle's built-in system from correctly obtaining the vehicle's temperature, resulting in an incorrect response.

[0132] The risk scenario is implemented as an environmental risk, which mainly refers to the first vehicle being in a dangerous situation due to interference from the external environment. For example, the first vehicle is in a foggy environment.

[0133] The risk scenario is implemented as a vehicle system risk. This risk mainly refers to the attacker attacking the first vehicle's built-in system (including but not limited to navigation system, in-vehicle entertainment system, intelligent driving system, etc.) through methods such as identity information forgery, virus implantation, firmware update (or hijacking), replay attack, mobile application, physical access and protocol security, etc., putting the first vehicle in a dangerous situation.

[0134] Optionally, based on the comparison results, the risk scenarios and attack information corresponding to vehicle-related information are analyzed using preset risk identification standards. The attack information includes the attacker corresponding to the risk scenario, the target of the attacker's attack, and the risk execution process implemented by the attacker in the risk scenario. For example, if an attacker needs to obtain management access to the first vehicle's built-in system, they must first crack the management password for the first vehicle, and then bypass the login authentication set by the first vehicle to gain management access to the first vehicle's built-in system. In this attack process, the target of the attack is the first vehicle's built-in system, and the attack path is: crack password – bypass login authentication – obtain access to the built-in system.

[0135] In another optional embodiment, after obtaining the attack information corresponding to the vehicle-related information, the difficulty level of the attack information is determined. Attack information whose difficulty level meets preset requirements is identified, and the risk assessment result corresponding to the attack information is determined using preset risk identification criteria.

[0136] Step 203: Obtain the risk management strategy for the first vehicle based on the risk assessment results.

[0137] In this embodiment of the application, the vehicle server also provides the function of specifying a risk handling strategy based on the risk assessment results.

[0138] That is, after determining the risk assessment results, the risk handling strategy corresponding to the risk assessment results is determined by using preset risk identification standards. The risk handling strategy is used to deal with risk scenarios and put the first vehicle in a safe scenario.

[0139] In this embodiment, different risk assessment results correspond to different risk handling strategies. Illustratively, in response to a risk assessment result pointing to the hardware structure of the first vehicle, a risk handling strategy related to adjusting the hardware structure is formulated; in response to a risk assessment result pointing to the software architecture of the first vehicle, a risk handling strategy related to adjusting the software architecture is formulated.

[0140] In this application, a vehicle server is associated with at least one associated server storing updated first risk assessment data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the updated first risk assessment data. Subsequently, based on the vehicle-related information of the first vehicle, a risk assessment result is obtained by matching data from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy.

[0141] like Figure 3 As shown, Figure 3A flowchart illustrating the execution of a vehicle risk handling method provided in another exemplary embodiment of this application is shown. The method is described using a vehicle server corresponding to a first vehicle as the executing entity.

[0142] Step 300: Match the first risk assessment database with vehicle-related information to obtain the risk scenario corresponding to the first vehicle.

[0143] Optionally, the risk assessment results may include the risk scenarios corresponding to the first vehicle, where a risk scenario refers to the usage scenario in which the first vehicle would generate a risk.

[0144] The execution process for this step is the same as step 202 above, and will not be repeated here.

[0145] Step 301: Determine the risk execution process corresponding to the risk scenario.

[0146] A protection target for the first vehicle is determined, which represents the ultimate target or threat an attacker intends to attack the first vehicle. An attack tree model corresponding to the first vehicle is then determined based on the protection target. In this embodiment, different protection targets correspond to different attack tree models.

[0147] Optionally, the attack tree model includes n layers of attack nodes, including the root node, and each layer contains y attack nodes. The root node represents the maintenance of the aforementioned protection objective, and the attack nodes indicate the execution conditions for achieving the protection objective. An attack path is formed between the (i+1)th layer attack nodes connected to the i-th layer attack node, indicating the path taken to achieve the execution conditions corresponding to the i-th layer attack node. Here, n and y are positive integers, and i is a positive integer less than or equal to n.

[0148] Identify the risk characteristics corresponding to the risk scenario. Risk characteristics include the object of the risk and the risk name.

[0149] Match the second risk feature with the attack tree model to determine the risk execution flow. That is, analyze the correlation between the risk feature and all attack nodes within the attack tree model. Specifically, in response to the risk feature's correlation with the p-th attack node of the k-th layer attack node in the attack tree meeting a preset correlation requirement, determine the first attack node directly connected to the p-th attack node, and the second attack node directly connected to the first attack node. Consider the first and second attack nodes as the attack path (i.e., the risk execution flow) of the p-th attack node. This attack path is a path from the root node to the bottom layer node, including the p-th attack node. Here, k is a positive integer less than or equal to n, and p is a positive integer less than or equal to i.

[0150] The feasibility results corresponding to the above risk execution process are analyzed. These feasibility results are used to describe the ease or difficulty of implementing the risk scenario according to the risk execution process.

[0151] Based on the risk scenario and feasibility results, the risk assessment results for the first vehicle were obtained.

[0152] In this implementation, the vehicle server is associated with at least one associated server storing updated first risk assessment data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the updated first risk assessment data. Subsequently, based on the vehicle-related information of the first vehicle, a risk assessment result is obtained by matching data from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy.

[0153] In this embodiment, risk handling strategies corresponding to risk scenarios are analyzed in the form of attack trees, providing a structured approach to identify and analyze potential security threats to the first vehicle. Furthermore, the attack tree graphically displays the attack paths corresponding to the risk scenarios, making complex attack logic and relationships more intuitive and understandable. Finally, the feasibility results corresponding to the risk execution process (attack paths) are analyzed using the attack tree to quantify each attack path, thereby calculating the probability of attack success and potential impact under each possible scenario, providing strong support for subsequent risk assessment.

[0154] like Figure 4 As shown, Figure 4 A flowchart illustrating the execution of a vehicle risk handling method provided in another exemplary embodiment of this application is shown. The method is described using a vehicle server corresponding to a first vehicle as the executing entity.

[0155] Step 400: Generate the risk management strategy corresponding to the first vehicle.

[0156] Optionally, after determining the risk handling strategy corresponding to the first vehicle, a first strategy template is obtained, which refers to the framework of the pre-stored risk handling strategy.

[0157] In this embodiment, the first strategy template includes a visual chart section and a text section. The visual chart section is used to display the content corresponding to the risk management strategy in the form of mathematical charts. The text section is used to display the content corresponding to the risk management strategy in text form.

[0158] In this embodiment of the application, the textual and numerical content within the risk handling strategy is obtained;

[0159] The text content is adjusted according to the first preprocessing method, and the adjusted text content is then input into the text section. The first preprocessing method includes at least one of the following: key data extraction, text classification, text translation, text checking and error correction, text deduplication, and text supplementation.

[0160] Optionally, the first preprocessing method mainly generates a summary of the text content.

[0161] The digital content is adjusted according to the second preprocessing method, and the adjusted digital content is input into the visualization chart section. The second preprocessing method refers to converting the digital content into a chart format for presentation.

[0162] Based on text sections and visual chart sections, generate visual reports corresponding to risk management strategies.

[0163] Optionally, the vehicle server corresponding to the first vehicle sends a visualization report to the second vehicle, and the second vehicle displays the visualization report on the in-vehicle screen after receiving it.

[0164] In an optional embodiment, while the report is visualized on the in-vehicle screen of the second vehicle, the content of the text section within the visualized report is played through the sound system inside the second vehicle.

[0165] In an optional embodiment, a management account for managing the first vehicle is obtained. The management account refers to an account that has management and usage permissions for the first vehicle. The management account can be the account corresponding to a smart terminal that has established a communication connection with the first vehicle, the account corresponding to a second vehicle that has established a communication connection with the first vehicle, or the account corresponding to any terminal located at a preset distance from the first vehicle.

[0166] After generating the risk handling strategy for the first vehicle, adjust the risk handling strategy according to the above strategy template to obtain and export a visual report. Send the visual report to the terminal device used by the management account.

[0167] In response to receiving an adjustment operation from the management account for the visualization report, the system updates the visualization report, resulting in an updated visualization report. Adjustment operations include, but are not limited to, modifying, deleting, and adding operations.

[0168] Obtain the filling format of the visualization and text sections in the updated visualization report, and generate the corresponding second strategy template for the updated visualization report according to the filling format;

[0169] A target risk management strategy is generated according to the second strategy template. The target risk management strategy is used to indicate the risk management strategy generated at a future time based on the vehicle-related information of the first vehicle.

[0170] As an illustration, if an adjustment operation is received after updating the strategy template and a visualization report generated according to the strategy template is received, a risk handling strategy for the first vehicle at a future time will be generated according to the adjusted strategy template.

[0171] In this implementation, the vehicle server is associated with at least one associated server storing updated first risk assessment data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the updated first risk assessment data. Subsequently, based on the vehicle-related information of the first vehicle, a risk assessment result is obtained by matching data from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy.

[0172] like Figure 5 As shown, Figure 5 A flowchart illustrating the execution of a vehicle risk handling method provided in another exemplary embodiment of this application is shown. The method is described using a vehicle server corresponding to a first vehicle as the executing entity.

[0173] Step 500, defining the object of the first vehicle.

[0174] Optionally, the hardware structure, software architecture, and data flow diagram of the first vehicle can be obtained to generate vehicle-related data for the first vehicle.

[0175] In other words, the object definition mentioned in this embodiment is consistent with the vehicle-related information in step 200 above, and will not be repeated here.

[0176] Step 501, asset definition for the first vehicle.

[0177] Optionally, the hardware structure and software architecture corresponding to the first vehicle are obtained; the hardware name corresponding to the hardware structure is determined, and the software name corresponding to the software architecture is determined.

[0178] Based on the above data interaction, the first asset type corresponding to the hardware structure is identified from the perspectives of data interaction execution process, data flow, data storage, and the interacting parties, and the second asset type corresponding to the software architecture is identified.

[0179] Among them, physical assets are used to represent the physical components that objectively exist in the first vehicle, while digital assets refer to information that exists in the first vehicle in digital form, such as ECU firmware, communication data, user privacy data, security algorithms, etc.

[0180] Step 502: Identify the threat scenario corresponding to the first vehicle.

[0181] Optionally, the vehicle-related information can be compared with the updated first risk assessment data stored in the first risk assessment database to obtain the comparison results.

[0182] Based on the comparison results, the risk scenarios corresponding to vehicle-related information are analyzed using a preset risk identification standard. A risk scenario refers to a usage scenario in which the first vehicle generates a risk. The preset risk identification standard is implemented using the ISO 21434 standard, but it can also be a standard specified by relevant personnel based on the actual application of the vehicle; this application does not impose any limitations on this.

[0183] The specific execution process of this step is the same as that of step 202 above, and will not be repeated here.

[0184] Step 503: Perform an impact assessment process based on the threat scenario.

[0185] Optionally, the impact of the threat scenario can be assessed, primarily from the perspectives of security, property, operational, and privacy.

[0186] Optionally, assess the impact of threat scenarios on the confidentiality, integrity, and availability of physical and / or digital assets from a security perspective, and assign a Level 1 rating.

[0187] Assess the impact of threat scenarios on the confidentiality, integrity, and availability of physical and / or digital assets from a property perspective, and make a Level 2 assessment.

[0188] The operational impact of threat scenarios on the confidentiality, integrity, and availability of physical and / or digital assets is assessed, and a Level 3 rating is given.

[0189] The assessment evaluates the impact of threat scenarios on the confidentiality, integrity, and availability of physical and / or digital assets from a privacy perspective, and assigns a Level 4 rating.

[0190] Based on the above-mentioned first-level assessment, second-level assessment, third-level assessment, and fourth-level assessment, the impact assessment level corresponding to the threat scenario is determined.

[0191] Step 504: Analyze the attack path based on the threat scenario.

[0192] The specific execution process of this step is the same as that of steps 202 and 300-301 above, and will not be repeated here.

[0193] Step 505: Determine the risk level corresponding to the first vehicle.

[0194] Optionally, based on the attack path corresponding to the threat scenario determined above, the risk level corresponding to the first vehicle is determined. The risk level here is consistent with the meaning expressed by the feasibility results in the above embodiments.

[0195] Step 506: Determine the risk handling strategy corresponding to the first vehicle based on the risk level.

[0196] Optionally, based on the threat scenario and risk level, the impact of cybersecurity uncertainties on the first vehicle can be described in conjunction with the impact assessment level and feasibility results, and corresponding risk management strategies can be developed.

[0197] In this implementation, the vehicle server is associated with at least one associated server storing updated first risk assessment data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the updated first risk assessment data. Subsequently, based on the vehicle-related information of the first vehicle, a risk assessment result is obtained by matching data from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy.

[0198] Figure 6 This application shows a structural block diagram of a vehicle risk handling apparatus provided in an exemplary embodiment, the apparatus comprising:

[0199] The receiving module 600 is used to receive first risk assessment update data sent by at least one associated server and store it in a first risk assessment database. The at least one associated server maintains a second risk assessment database. The first risk assessment update data is data updated to the second risk assessment database within the data update cycle.

[0200] The acquisition module 601 is used to acquire vehicle-related information of the first vehicle, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle.

[0201] The matching module 602 is used to match the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle. The risk assessment result includes the risk scenario corresponding to the first vehicle. The risk scenario refers to the usage scenario in which the first vehicle generates a risk.

[0202] The acquisition module 601 is used to acquire a risk handling strategy for the first vehicle based on the risk assessment result, and the risk handling strategy is used to deal with the risk scenario.

[0203] In an optional embodiment, such as Figure 7 As shown, the device further includes a determining module 603 and a deleting module 604;

[0204] The acquisition module 601 is used to acquire the first risk assessment update data sent by the at least one associated server using a preset data acquisition algorithm.

[0205] The determination module 603 is used to determine the first risk feature corresponding to the first risk assessment update data, wherein the first risk feature includes the risk target and the risk name.

[0206] The deletion module 604 is used to delete second risk assessment update data that is unrelated to preset vehicle characteristics from the first risk assessment update data according to the risk target and the risk name, and store the updated first risk assessment update data in the first risk assessment database. The preset vehicle characteristics are features that are related to the hardware structure and the software architecture and are preset.

[0207] In an optional embodiment, such as Figure 7 As shown, the acquisition module 601 is used to acquire a first network storage address, which is an address that provides storage for the first risk assessment update data sent by the at least one associated server;

[0208] The determining module 603 is used to determine the data association tuple stored in the second risk assessment database maintained by the at least one associated server. The data association tuple includes the second risk assessment update data and the data network storage address corresponding to the second risk assessment update data.

[0209] The update module 605 is used to update the first network storage address based on the data association tuple to obtain the updated network storage address;

[0210] The acquisition module 601 is used to acquire the first risk assessment update data stored on at least one associated server from the updated network storage address.

[0211] In an optional embodiment, such as Figure 7 As shown, the matching module 602 is used to match the first risk assessment database with the vehicle-related information to obtain the risk scenario corresponding to the first vehicle;

[0212] The determining module 603 is used to determine the risk execution process corresponding to the risk scenario, wherein the risk execution process refers to the process by which the first vehicle generates the risk scenario;

[0213] Analysis module 606 is used to analyze the feasibility results corresponding to the risk execution process, and the feasibility structure is used to describe the ease or difficulty of implementing the risk scenario according to the risk execution process;

[0214] The determining module 603 is used to obtain the risk assessment result corresponding to the first vehicle based on the risk scenario and the feasibility result.

[0215] In an optional embodiment, such as Figure 7 As shown, the determining module 603 is used to determine the attack tree model corresponding to the first vehicle. The attack tree model includes n layers of attack nodes, including the root node. The root node is used to represent the protection target of the first vehicle. The attack nodes are used to indicate the execution conditions for achieving the protection target. An attack path is formed between the (i+1)th layer attack nodes connected to the i-th layer attack node. The attack path is used to indicate the path taken to achieve the execution conditions corresponding to the i-th layer attack node. n is a positive integer, and i is a positive integer less than or equal to n.

[0216] The determining module 603 is used to determine the second risk characteristic corresponding to the risk scenario;

[0217] The matching module 602 is used to analyze the correlation between the risk feature and all attack nodes in the attack tree model; in response to the correlation between the risk feature and the p-th attack node of the k-th layer attack node in the attack tree model meeting a preset correlation requirement, it determines a first attack node directly connected to the p-th attack node, and a second attack node directly connected to the first attack node, where k is a positive integer less than or equal to n, and p is a positive integer less than or equal to i; and determines the first attack node and the second attack node as the risk execution flow.

[0218] In an optional embodiment, such as Figure 7 As shown, the acquisition module 601 is used to acquire the hardware structure and software architecture of the first vehicle;

[0219] The determining module 603 is used to determine the external device that interacts with the first vehicle.

[0220] The determining module 603 is used to determine the data interaction situation when the vehicle data generated in the first vehicle interacts with the external device.

[0221] The identification module 607 is used to identify the first asset type corresponding to the hardware structure and generate a first binary array based on the data interaction situation.

[0222] The identification module 607 is used to identify the second asset type corresponding to the software architecture and generate a second binary array based on the data interaction situation.

[0223] The determining module 603 is used to obtain the vehicle-related information based on the first binary array and the second binary array.

[0224] In an optional embodiment, such as Figure 7 As shown, the acquisition module 601 is used to acquire a first strategy template, which refers to a framework for pre-storing the risk management strategy. The strategy template includes a visual chart section and a text section.

[0225] The acquisition module 601 is used to acquire the text and numerical content within the risk handling strategy.

[0226] The adjustment module 608 is used to adjust the text content according to the first preprocessing method and input the adjusted text content into the text block;

[0227] The adjustment module 608 is used to adjust the digital content according to the second preprocessing method and input the adjusted digital content into the visualization chart module;

[0228] The determining module 603 is used to generate a visual report corresponding to the risk handling strategy based on the text section and the visual chart section.

[0229] The sending module 609 is used to send the visualization report to the second vehicle, the visualization report being used to display the driving situation in a visual manner on the in-vehicle screen of the second vehicle.

[0230] In an optional embodiment, such as Figure 7 As shown, the acquisition module 601 is used to acquire the management account for managing the first vehicle;

[0231] The export module 610 is used to export the visualization report and send the visualization report to the terminal device used by the management account;

[0232] The update module 605 is used to update the visualization report in response to receiving the adjustment operation of the management account on the visualization report, so as to obtain the updated visualization report;

[0233] The determining module 603 is used to generate a second strategy template corresponding to the updated visualization report;

[0234] The determining module 603 is used to generate a target risk handling strategy according to the second strategy template. The target risk handling strategy is used to indicate the risk handling strategy generated at a future time based on the vehicle-related information of the first vehicle.

[0235] In this embodiment, the vehicle server is associated with at least one associated server storing the first risk assessment update data. The vehicle server synchronizes the data stored in the at least one associated server to its own maintained first risk database, ensuring the integrity and real-time nature of the first risk assessment update data. Subsequently, based on the vehicle-related information of the first vehicle, the risk assessment result is matched from the first risk database, and a corresponding risk handling strategy is formulated to determine the accuracy and effectiveness of the risk handling strategy.

[0236] Figure 8 This illustration shows a structural block diagram of a computer device 800 provided in an exemplary embodiment of this application. The computer device 800 can be a portable mobile terminal, such as a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The computer device 800 may also be referred to as a user device, portable terminal, laptop terminal, desktop terminal, or other names. Optionally, the computer device 800 can also be implemented as a mobile device, such as a vehicle-mounted terminal or other portable smart terminal.

[0237] Typically, computer device 800 includes a processor 801 and a memory 802.

[0238] Processor 801 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0239] The memory 802 may include one or more computer-readable storage media, which may be non-transitory. The memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 802 are used to store at least one instruction, which is executed by the processor 801 to implement the model training method or behavior encoding method provided in the method embodiments of this application.

[0240] In some embodiments, the computer device 800 may also optionally include a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 803 via a bus, signal line, or circuit board. For example, the peripheral device may include at least one of the following: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, a positioning assembly 815, and a power supply 808.

[0241] Peripheral device interface 803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 801 and memory 802. In some embodiments, processor 801, memory 802 and peripheral device interface 803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 801, memory 802 and peripheral device interface 803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0242] The radio frequency (RF) circuit 804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 804 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0243] Display screen 805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 801 for processing. In this case, display screen 805 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 805, disposed on the front panel of computer device 800; in other embodiments, there may be at least two display screens, disposed on different surfaces of computer device 800 or in a folded design; in still other embodiments, display screen 805 may be a flexible display screen, disposed on a curved or folded surface of computer device 800. Furthermore, display screen 805 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 805 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0244] The camera assembly 806 is used to acquire images or videos. Optionally, the camera assembly 806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0245] The audio circuit 807 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 801 for processing, or input to the radio frequency circuit 804 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each located in a different part of the computer device 800. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 801 or the radio frequency circuit 804 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 807 may also include a headphone jack.

[0246] The positioning component 815 is used to calculate the current geographic location of the device 800 in order to enable navigation or LBS (Location Based Service). The positioning component 815 can be a positioning component based on the US GPS (Global Positioning System) or the Chinese BeiDou system.

[0247] Power supply 808 is used to supply power to various components in computer device 800. Power supply 808 can be alternating current, direct current, a disposable battery, or a rechargeable battery. When power supply 808 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, while a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0248] In some embodiments, the computer device 800 further includes one or more sensors 809. The one or more sensors 809 include, but are not limited to, an accelerometer 810, a gyroscope 811, a pressure sensor 812, an optical sensor 813, and a proximity sensor 814.

[0249] Accelerometer 810 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by computer device 800. For example, accelerometer 810 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 801 can control display screen 805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 810. Accelerometer 810 can also be used for games or for acquiring user motion data.

[0250] The gyroscope sensor 811 can detect the orientation and rotation angle of the computer device 800. The gyroscope sensor 811, in conjunction with the accelerometer sensor 810, can collect 3D motion data from the user on the computer device 800. Based on the data collected by the gyroscope sensor 811, the processor 801 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0251] The pressure sensor 812 can be disposed on the side bezel of the computer device 800 and / or on the lower layer of the display screen 805. When the pressure sensor 812 is disposed on the side bezel of the computer device 800, it can detect the user's grip signal on the computer device 800, and the processor 801 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 812. When the pressure sensor 812 is disposed on the lower layer of the display screen 805, the processor 801 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 805. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0252] An optical sensor 813 is used to collect ambient light intensity. In one embodiment, the processor 801 can control the display brightness of the display screen 805 based on the ambient light intensity collected by the optical sensor 813. For example, when the ambient light intensity is high, the display brightness of the display screen 805 is increased; when the ambient light intensity is low, the display brightness of the display screen 805 is decreased. In another embodiment, the processor 801 can also dynamically adjust the shooting parameters of the camera assembly 806 based on the ambient light intensity collected by the optical sensor 813.

[0253] A proximity sensor 814, also known as a distance sensor, is typically located on the front panel of a computer device 800. The proximity sensor 814 is used to detect the distance between the user and the front of the computer device 800. In one embodiment, when the proximity sensor 814 detects that the distance between the user and the front of the computer device 800 is gradually decreasing, the processor 801 controls the display screen 805 to switch from a screen-on state to a screen-off state; when the proximity sensor 814 detects that the distance between the user and the front of the computer device 800 is gradually increasing, the processor 801 controls the display screen 805 to switch from a screen-off state to a screen-on state.

[0254] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 800, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0255] Figure 9This is a schematic diagram of a server structure according to an exemplary embodiment. The server 900 includes a Central Processing Unit (CPU) 901, a system memory 904 including Random Access Memory (RAM) 902 and Read-Only Memory (ROM) 903, and a system bus 905 connecting the system memory 904 and the CPU 901. The server 1500 also includes a basic input / output system (I / O system) 906 to facilitate information transfer between various devices within the server, and a mass storage device 907 for storing the operating system 913, application programs 914, and other program modules 1515.

[0256] The basic input / output system 906 includes a display 908 for displaying information and an input device 909 for user input, such as a mouse or keyboard. Both the display 908 and the input device 909 are connected to the central processing unit 901 via an input / output controller 910 connected to the system bus 905. The basic input / output system 906 may also include the input / output controller 910 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 910 also provides output to a display screen, printer, or other types of output devices.

[0257] The mass storage device 907 is connected to the central processing unit 901 via a mass storage controller (not shown) connected to the system bus 905. The mass storage device 907 and its associated server-readable media provide non-volatile storage for the server 900. That is, the mass storage device 907 may include server-readable media (not shown) such as a hard disk or a compact disc read-only memory (CD-ROM) drive.

[0258] Without loss of generality, the computer device readable medium may include computer device storage media and communication media. Computer device storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer device readable instructions, data structures, program modules, or other data. Computer device storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer device storage media are not limited to the above-mentioned types. The system memory 904 and mass storage device 907 described above can be collectively referred to as memory.

[0259] According to various embodiments of this disclosure, the server 900 can also be connected to a remote computer device on a network, such as the Internet. That is, the server 900 can be connected to the network 911 via a network interface unit 912 connected to the system bus 905, or it can use the network interface unit 912 to connect to other types of networks or remote computer device systems (not shown).

[0260] The memory also includes one or more programs stored in the memory, and the central processing unit 901 executes the one or more programs to implement all or part of the steps of the above-mentioned model training method or behavior encoding method.

[0261] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method for identifying the operating status of a pipeline network provided in the above-described method embodiments.

[0262] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method for identifying the operating status of a pipeline network provided in the above-described method embodiments.

[0263] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above descriptions are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for handling vehicle risks, characterized in that, The method includes: The system receives first risk assessment update data sent by at least one associated server and stores it in a first risk assessment database. The at least one associated server maintains a second risk assessment database. The first risk assessment update data is data updated to the second risk assessment database within the data update cycle. Obtain vehicle-related information of the first vehicle, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle; Match the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle. The risk assessment result includes the risk scenario corresponding to the first vehicle. The risk scenario refers to the usage scenario in which the first vehicle generates a risk. The risk assessment result includes the risk scenario. The risk scenario corresponds to a risk execution process. The risk execution process refers to the process by which the first vehicle generates the risk scenario. Based on the risk assessment results, a risk management strategy for the first vehicle is obtained, and the risk management strategy is used to address the risk scenario. The steps for determining the risk execution process include: determining the attack tree model corresponding to the first vehicle, wherein the attack tree model includes n layers of attack nodes, including the root node, the root node is used to represent the protection target of maintaining the first vehicle, the attack nodes are used to indicate the execution conditions for achieving the protection target, and an attack path is formed between the (i+1)th layer attack nodes connected to the i-th layer attack node, wherein the attack path is used to indicate the path taken to achieve the execution conditions corresponding to the i-th layer attack node, where n is a positive integer and i is a positive integer less than or equal to n; determining the risk characteristics corresponding to the risk scenario; and analyzing the correlation between the risk characteristics and all attack nodes in the attack tree model. In response to the fact that the correlation between the risk feature and the p-th attack node of the k-th attack node in the attack tree model meets the preset correlation requirement, a first attack node directly connected to the p-th attack node and a second attack node directly connected to the first attack node are determined, where k is a positive integer less than or equal to n and p is a positive integer less than or equal to i; the first attack node and the second attack node are determined as the risk execution flow.

2. The method according to claim 1, characterized in that, The step of receiving first risk assessment update data sent by at least one associated server and storing it in the first risk assessment database includes: The first risk assessment update data sent by the at least one associated server is obtained using a preset data acquisition algorithm; Determine the risk characteristics corresponding to the first risk assessment update data, wherein the risk characteristics include the risk target and the risk name; Based on the risk target and the risk name, delete the second risk assessment update data that is unrelated to the preset vehicle characteristics from the first risk assessment update data, and store the updated first risk assessment update data in the first risk assessment database. The preset vehicle characteristics are features that are related to the hardware structure and the software architecture and are preset.

3. The method according to claim 2, characterized in that, The step of acquiring the first risk assessment update data sent by the at least one associated server using a preset data acquisition algorithm includes: Obtain a first network storage address, which is an address provided for storing the first risk assessment update data sent by the at least one associated server; Determine the data association tuple stored in the second risk assessment database maintained by the at least one associated server, wherein the data association tuple includes the second risk assessment update data and the data network storage address corresponding to the second risk assessment update data; The first network storage address is updated based on the data association tuple to obtain the updated network storage address; Obtain the first risk assessment update data stored on at least one associated server from the updated network storage address.

4. The method according to any one of claims 1 to 3, characterized in that, The process of matching the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle includes: Match the first risk assessment database with the vehicle-related information to obtain the risk scenario corresponding to the first vehicle; Analyze the feasibility results corresponding to the risk execution process, and the feasibility results are used to describe the ease or difficulty of implementing the risk scenario according to the risk execution process; Based on the risk scenario and the feasibility results, the risk assessment result corresponding to the first vehicle is obtained.

5. The method according to any one of claims 1 to 3, characterized in that, The acquisition of vehicle-related information for the first vehicle includes: Obtain the hardware structure and software architecture of the first vehicle; Identify the external devices that interact with the first vehicle; Determine the data interaction situation when the vehicle data generated in the first vehicle interacts with the external device; Based on the data interaction, identify the first asset type corresponding to the hardware structure and generate a first binary array; Based on the data interaction, identify the second asset type corresponding to the software architecture and generate a second binary array; Based on the first binary array and the second binary array, the vehicle-related information is obtained.

6. The method according to any one of claims 1 to 3, characterized in that, After obtaining the risk handling strategy for the first vehicle based on the risk assessment results, the method further includes: Obtain the first strategy template, which refers to the framework for pre-storing the risk management strategy. The first strategy template includes a visual chart section and a text section. Obtain the text and numerical content within the risk management strategy; The text content is adjusted according to the first preprocessing method, and the adjusted text content is input into the text block; The digital content is adjusted according to the second preprocessing method, and the adjusted digital content is input into the visualization chart section; Based on the text section and the visualization chart section, a visualization report corresponding to the risk management strategy is generated; The visualization report is sent to the second vehicle and is used to display the report in a visual form on the in-vehicle screen of the second vehicle.

7. The method according to claim 6, characterized in that, The method further includes: Obtain the management account for managing the first vehicle; Export the visualization report and send it to the terminal device used by the management account; In response to receiving the adjustment operation of the management account on the visualization report, the visualization report is updated to obtain the updated visualization report; Generate the second strategy template corresponding to the updated visualization report; A target risk handling strategy is generated according to the second strategy template. The target risk handling strategy is used to indicate the risk handling strategy generated at a future time based on the vehicle-related information of the first vehicle.

8. A vehicle risk management device, characterized in that, The device includes: A receiving module is configured to receive first risk assessment update data sent by at least one associated server and store it in a first risk assessment database. The at least one associated server maintains a second risk assessment database. The first risk assessment update data is data updated to the second risk assessment database within a data update cycle. An acquisition module is used to acquire vehicle-related information of the first vehicle, wherein the vehicle-related information is used to characterize the hardware structure and software architecture of the first vehicle. The matching module is used to match the first risk assessment database with the vehicle-related information of the first vehicle to obtain the risk assessment result of the first vehicle. The risk assessment result includes the risk scenario corresponding to the first vehicle. The risk scenario refers to the usage scenario in which the first vehicle generates a risk. The risk assessment result includes the risk scenario. The risk scenario corresponds to a risk execution process. The risk execution process refers to the process by which the first vehicle generates the risk scenario. A determination module is used to determine the attack tree model corresponding to the first vehicle. The attack tree model includes n layers of attack nodes, including a root node. The root node represents the protection target of the first vehicle. The attack nodes indicate the execution conditions for achieving the protection target. An attack path is formed between the (i+1)th layer attack nodes connected to the i-th layer attack node. The attack path indicates the path taken to achieve the execution conditions corresponding to the i-th layer attack node. n is a positive integer, and i is a positive integer less than or equal to n. The module also determines the risk characteristics corresponding to the risk scenario. The matching module is further configured to analyze the correlation between the risk feature and all attack nodes in the attack tree model; in response to the correlation between the risk feature and the p-th attack node of the k-th layer attack node in the attack tree model meeting a preset correlation requirement, a first attack node directly connected to the p-th attack node and a second attack node directly connected to the first attack node are determined, where k is a positive integer less than or equal to n and p is a positive integer less than or equal to i; the first attack node and the second attack node are determined as the risk execution flow; The acquisition module is used to acquire a risk handling strategy for the first vehicle based on the risk assessment result, and the risk handling strategy is used to deal with the risk scenario.

9. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one program, which is loaded and executed by the processor to implement the vehicle risk handling method as described in any one of claims 1 to 7.

Citation Information

Patent Citations

  • Vehicle network data security risk assessment system, method and device

    CN115190058A

  • Method for determining an attack path in a system model and computer-readable storage medium

    DE102014212419A1