Vehicle control method and vehicle

CN122770752APending Publication Date: 2026-09-18GREAT WALL MOTOR CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610990495.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-03
Publication Date
2026-09-18

AI Technical Summary

Technical Problem

[0003]然而,目前大多数车载告警方案在推送告警信息时,会直接在中控显示屏显示告警内容

Benefits of technology

[0011] Combining the first aspect and the above implementation methods, in some implementation methods of the first aspect, the cloud is used to determine the user's target danger level based on vehicle context information, and to determine the corresponding target rescue strategy based on the target danger level.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122770752A_ABST
    Figure CN122770752A_ABST
Patent Text Reader

Abstract

The application provides a vehicle control method and a vehicle, and applies to the technical field of intelligent cockpit. The method comprises the following steps: obtaining an alarm content package and running state information of the vehicle, wherein the alarm content package comprises an abnormal event type and emergency suggestion information for the abnormal event; in the case that the running state information meets a preset condition, outputting alarm information to a user in a voice broadcast mode, and prohibiting a display screen of the vehicle from displaying the alarm content package; and in the case that the running state information does not meet the preset condition, displaying the alarm content package on the display screen of the vehicle. According to different running state information of the vehicle, the application can dynamically select an alarm output mode, eliminate a safety hazard of a secondary accident caused by the alarm notification itself, improve the safety of alarm information output in an accident alarm scene, and thus effectively improve driving safety.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of intelligent cockpit technology, specifically to a vehicle control method and a vehicle. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, issuing warnings to users when vehicles experience collisions, abnormal tire pressure, or other abnormal events to promptly alert them to potential driving hazards has become a core aspect of ensuring driving safety.

[0003] However, most current in-vehicle warning solutions display warning information directly on the central control screen when pushing out warning messages. Since the central control screen usually houses key driver assistance functions such as surround view and navigation during driving, the warning content directly obscures this core information, preventing users from timely obtaining information about the vehicle's surroundings and interfering with their normal judgment of road conditions. This significantly increases the probability of secondary accidents such as scrapes and collisions, thus posing a threat to driving safety. Summary of the Invention

[0004] This application provides a vehicle control method and a vehicle. This application can dynamically select the alarm output mode according to different vehicle operating status information, eliminate the safety hazard of secondary accidents caused by the alarm notification itself, improve the safety of alarm information output in accident alarm scenarios, and thus effectively improve driving safety.

[0005] Firstly, a vehicle control method is provided, comprising: acquiring an alarm content package and vehicle operating status information, wherein the alarm content package includes an abnormal event type and emergency suggestion information for the abnormal event; when the operating status information meets preset conditions, outputting alarm information to the user based on voice broadcast and prohibiting the vehicle's display screen from displaying the alarm content package; and when the operating status information does not meet preset conditions, displaying the alarm content package on the vehicle's display screen.

[0006] Based on the above technical solution, in this embodiment, when an abnormal event is detected in the vehicle, if the vehicle's display screen shows a reversing image or surround view image, an alarm message is output to the user via voice broadcast, and the display screen is prohibited from displaying the alarm content package. This effectively conveys the alarm information to the user while preventing the alarm interface from obstructing the assisted driving image, ensuring the user can clearly observe the vehicle's surrounding environment and accurately judge road conditions, reducing secondary accidents such as scrapes and collisions caused by obstructed vision. When the vehicle's display screen does not show a reversing image or surround view image, the alarm content package is displayed, allowing the user to clearly and efficiently obtain the type of abnormal event and emergency advice information for the abnormal event. This application can dynamically select the alarm output method according to different vehicle operating status information, eliminating the safety hazard of the alarm notification itself causing secondary accidents, improving the safety of alarm information output in accident alarm scenarios, and thus effectively improving driving safety.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: obtaining user feedback on alarm information or alarm content packages within a preset time period; if the feedback is a confirmation instruction, uploading the confirmation instruction and confirmation timestamp to the cloud, and displaying the corresponding function page on the display screen based on the type of abnormal event, and / or determining the target service store based on the vehicle information and the service store information; wherein, the function page is used to display relevant rescue resource information; if the feedback is a denial instruction, uploading the denial instruction and denial timestamp to the cloud, and controlling the vehicle's display screen to cancel the display of the alarm content package.

[0008] Based on the above technical solution, this embodiment collects user feedback information and uploads it to the cloud after outputting alarm information, fully retaining the handling record of alarm events, which facilitates data archiving and statistical analysis in the background. If the user issues a confirmation command, the corresponding rescue resource page is loaded on the display screen according to the current abnormal event type. Simultaneously, based on the vehicle location, vehicle model parameters, and the location information and business status of each store, the appropriate target service store is selected, providing the user with emergency operation guidance and the nearest repair and rescue channel, simplifying the handling operation after the fault occurs. If the user issues a denial command, the denial record is uploaded simultaneously and the alarm interface on the display screen is cleared, restoring the original display content, avoiding false alarm pop-ups from obstructing the driving view, and effectively improving the handling efficiency and driving safety in vehicle fault or accident scenarios.

[0009] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the method further includes: if no feedback information from the user regarding the alarm information or alarm content package is received within a preset time period, then obtaining vehicle context information, the vehicle context information including at least one of vehicle motion parameters, user status, and environmental information; uploading the vehicle context information to the cloud, the cloud being used to determine the corresponding target rescue strategy based on the vehicle context information, and executing the target rescue strategy to rescue the user.

[0010] Based on the above technical solution, in this embodiment of the application, when the user fails to respond to the alarm information or alarm content package within the timeout period, the vehicle context information is automatically obtained and uploaded to the cloud. The cloud then analyzes the information from multiple dimensions, including the vehicle's operating status, the user's status, and the on-site environment. This allows the cloud to verify the user's true situation from different dimensions, avoiding misjudgments or omissions that may result from relying on a single information source. This improves the accuracy of identifying high-risk scenarios, thereby determining the corresponding target rescue strategy and executing the target rescue strategy to rescue the user. This enhances the intelligence level of accident handling and the timeliness of rescue.

[0011] Combining the first aspect and the above implementation methods, in some implementation methods of the first aspect, the cloud is used to determine the user's target danger level based on vehicle context information, and to determine the corresponding target rescue strategy based on the target danger level.

[0012] Based on the above technical solution, this application embodiment uses cloud-based systems to jointly analyze multi-dimensional data such as vehicle motion parameters, user status, and environmental information to determine the target danger level currently experienced by the user. This allows the cloud to match differentiated rescue strategies based on different danger levels. Compared to relying solely on single information for judgment or applying a uniform rescue response method to all scenarios with no response time, this application can accurately distinguish the severity of on-site hazards and adapt corresponding rescue and disposal plans for different danger levels. This avoids excessive rescue in low-risk scenarios, preventing resource waste, while also preventing insufficient handling and inadequate rescue responses in high-risk situations. It ensures that rescue strategies are highly matched to the actual dangerous operating conditions of the vehicle, effectively improving the rationality, pertinence, and effectiveness of emergency rescue dispatch.

[0013] Combining the first aspect and the above implementation methods, in some implementation methods of the first aspect, the cloud is used to input vehicle context information into the hazard level detection model to obtain the user's target hazard level.

[0014] Based on the above technical solution, this application embodiment inputs vehicle context information into a cloud-based hazard level detection model, which then comprehensively judges and outputs the user's target hazard level. This avoids the subjectivity and limitations that may arise from manually setting judgment rules, thereby more accurately identifying the user's current hazard level and providing a reliable basis for matching differentiated rescue strategies.

[0015] Combining the first aspect and the aforementioned implementation methods, in some implementation methods of the first aspect, the target hazard level includes a first level, a second level, and a third level, where the hazard level of the second level is greater than that of the first level but less than that of the third level. Specifically, when the target hazard level is the first level, the target rescue strategy controls the vehicle to send an alarm message to the user again to confirm whether the user needs rescue. When the target hazard level is the second level, the target rescue strategy sends an accident notification message to the terminal corresponding to the preset emergency contact. When the target hazard level is the third level, the target rescue strategy triggers a rescue call and reports accident-related information to the rescue platform after the rescue call is connected.

[0016] Based on the above technical solution, this application embodiment divides the target hazard level into three levels (Level 1, Level 2, and Level 3) and configures differentiated rescue strategies for each level, achieving a refined graded response to the user's hazard level. It can match rescue strategies appropriate to the user's actual hazard level, avoiding resource waste in low-risk scenarios and ensuring timely rescue in high-risk scenarios, thus improving the rationality of rescue strategy formulation and the effectiveness of resource allocation.

[0017] Combining the first aspect and the above-mentioned implementation methods, in some implementation methods of the first aspect, the accident-related information includes accident notification information and occupant status information inside the vehicle. The occupant status information includes the number of occupants inside the vehicle, occupant seating distribution information, and occupant consciousness status.

[0018] Based on the above technical solution, this embodiment incorporates occupant status information into accident-related information and reports it to the rescue platform. This allows the rescue platform to know in advance the number of occupants, the distribution of seats for each occupant, and the occupants' level of consciousness. This enables the platform to grasp the basic situation of the people inside the vehicle before rescue forces arrive at the scene. Rescue personnel can then rationally allocate rescue resources, prepare corresponding first-aid equipment and treatment plans, avoiding delays in treatment due to assessment of occupant conditions only upon arrival at the scene, thus improving the targeting and efficiency of the rescue response.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, the above-mentioned acquisition of alarm content package includes: acquiring sensor data collected by multiple sensors in the vehicle; sending the sensor data to the cloud, whereby the cloud uses an abnormal event detection model to determine whether an abnormal event has occurred in the vehicle based on the sensor data; and receiving the alarm content package sent from the cloud, wherein the alarm content package is obtained based on the vehicle's vehicle identifier when the cloud determines that an abnormal event has occurred in the vehicle.

[0020] Based on the above technical solution, the embodiments of this application collect data through vehicle sensors and upload it to the cloud. The cloud then calls the abnormal event detection model to identify whether an abnormal event has occurred in the vehicle. Compared with the local identification method on the vehicle, the cloud can rely on more powerful computing capabilities to perform comprehensive feature analysis on multi-dimensional sensor data, improve the accuracy and stability of abnormal event identification, and at the same time reduce the pressure on local data storage and algorithm calculation on the vehicle.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the operating status information includes the vehicle's gear information; the operating status information meeting preset conditions includes the gear information being in reverse gear; the operating status information not meeting preset conditions includes the gear information being in a non-reverse gear. Alternatively, the operating status information includes the vehicle's gear information and vehicle speed; the operating status information meeting preset conditions includes the gear information being in reverse gear and the vehicle speed being greater than or equal to a preset vehicle speed; the operating status information not meeting preset conditions includes the gear information being in a non-reverse gear and / or the vehicle speed being less than a preset vehicle speed.

[0022] Based on the above technical solution, this application embodiment determines whether the vehicle's operating status meets preset conditions by using gear information and a combination of gear information and vehicle speed. This accurately distinguishes between vehicle operating conditions that meet and do not meet the preset conditions. The determination result truly reflects the vehicle's current actual operating status, ensuring that the selection of subsequent alarm output methods provides an accurate and reliable basis for judgment.

[0023] Secondly, a vehicle control device is provided, the vehicle control device comprising: The acquisition module is used to acquire alarm content packages and vehicle operating status information. The alarm content packages include abnormal event types and emergency suggestion information for abnormal events. The control module is used to output alarm information to the user via voice broadcast when the operating status information meets preset conditions, and to prevent the vehicle's display screen from displaying the alarm content package; when the operating status information does not meet preset conditions, it displays the alarm content package on the vehicle's display screen.

[0024] Thirdly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to perform the vehicle control method of the first aspect or any possible implementation thereof.

[0025] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to execute the vehicle control method in the first aspect or any possible implementation thereof.

[0026] Fifthly, a computer-readable storage medium is provided, which stores a computer program that, when executed, causes the computer to perform the vehicle control method described in the first aspect or any possible implementation thereof. Attached Figure Description

[0027] Figure 1 A schematic flowchart of a vehicle control method provided in an embodiment of this application is shown; Figure 2 A schematic flowchart of a vehicle control method provided in an embodiment of this application is shown; Figure 3 This paper shows a schematic diagram of the structure of a vehicle control device provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of a vehicle provided in an embodiment of this application is shown. Detailed Implementation

[0028] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0030] With the rapid development of intelligent connected vehicle technology, issuing warnings to users when vehicles experience collisions, abnormal tire pressure, or other abnormal events to promptly alert them to potential driving hazards has become a core aspect of ensuring driving safety.

[0031] However, most current in-vehicle warning solutions display warning information directly on the central control screen when pushing out warning messages. Since the central control screen usually houses key driver assistance functions such as surround view and navigation during driving, the warning content directly obscures this core information, preventing users from timely obtaining information about the vehicle's surroundings and interfering with their normal judgment of road conditions. This significantly increases the probability of secondary accidents such as scrapes and collisions, thus posing a threat to driving safety.

[0032] To address the aforementioned issues, this application provides a vehicle control method and vehicle. When an abnormal event is detected, if the vehicle's display screen shows a reversing image or surround view image (or other driver assistance features), a warning message is output to the user via voice broadcast, while the display screen is prevented from showing the warning content package. This effectively delivers the warning information to the user while preventing the warning interface from obstructing the driver assistance display, ensuring the user can clearly observe the vehicle's surroundings and accurately assess road conditions, reducing secondary accidents such as scrapes and collisions caused by obstructed vision. When the vehicle's display screen does not show a reversing image or surround view image, the warning content package is displayed, allowing the user to clearly and efficiently obtain the type of abnormal event and emergency advice. This application can dynamically select the warning output method based on different vehicle operating status information, eliminating the safety hazard of the warning notification itself causing secondary accidents, improving the safety of warning information output in accident warning scenarios, and thus effectively improving driving safety.

[0033] Figure 1 The diagram shows a flowchart of a vehicle control method according to an embodiment of this application; the executing entity of the vehicle control method provided in this embodiment is a vehicle controller, specifically as follows... Figure 1 As shown, the method includes the following steps: S110: Obtain alarm content packages and vehicle operating status information. The alarm content packages include abnormal event types and emergency response suggestions for abnormal events.

[0034] The alarm content package includes abnormal event types and emergency advice information for abnormal events. Abnormal event types include collision events and abnormal tire pressure events. Emergency advice information for abnormal events refers to information provided to users to guide them in emergency response or to obtain rescue assistance when an abnormal event occurs in the vehicle.

[0035] Specifically, various sensors installed in the vehicle continuously collect vehicle data. The vehicle controller analyzes the collected sensor data to determine whether an abnormal event has occurred. For example, when the vehicle's acceleration sensor detects a sudden and severe deceleration exceeding a preset deceleration threshold, or when the deformation sensor detects abnormal deformation of the vehicle body structure, the vehicle controller determines that a collision has occurred. Similarly, when the vehicle's tire pressure sensor detects a rapid drop in tire pressure below a preset tire pressure threshold, the vehicle controller determines that a tire pressure anomaly has occurred. Once a collision or tire pressure anomaly is identified, the vehicle controller immediately generates a corresponding alarm content package based on the type of abnormal event and vehicle information. Optionally, the alarm content package can also be generated in the cloud and distributed to the vehicle controller.

[0036] The vehicle's operating status information refers to information characterizing the vehicle's current operating condition, including gear position and speed. Specifically, the vehicle controller can obtain the current gear position information in real time through the vehicle communication network and collect the vehicle's speed through wheel speed sensors installed at the wheels.

[0037] In one possible implementation, obtaining the alarm content package includes the following steps: Acquire sensor data collected by multiple sensors inside the vehicle; Sensor data is sent to the cloud, where the abnormal event detection model is invoked to determine whether an abnormal event has occurred in the vehicle based on the sensor data. Receive alarm content packets sent from the cloud. The alarm content packets are obtained based on the vehicle's vehicle identifier when the cloud determines that an abnormal event has occurred in the vehicle.

[0038] Specifically, the vehicle controller sends sensor data collected from multiple sensors to the cloud. The cloud-based anomaly detection model, including a collision detection model and a tire pressure anomaly identification model, performs real-time analysis of the sensor data to detect whether an abnormal event has occurred. Upon detecting a collision or tire pressure anomaly, the detection result is sent to the cloud-based accident state machine. The accident state machine determines the current vehicle model based on its vehicle identifier (e.g., vehicle identification code) and retrieves information such as emergency knowledge sets and rescue phone configurations matching the vehicle model and event type from the vehicle model knowledge base. This information, including the event type, emergency knowledge sets, and rescue phone configurations, is encapsulated into a structured alarm content package, which is then sent to the vehicle. The vehicle controller receives the alarm content package from the cloud.

[0039] Optionally, before sending an alarm content package to a vehicle, the cloud will also query the vehicle's software version information based on the vehicle identification number to confirm whether the vehicle has installed and supports the accident handling function. If the vehicle has not installed or does not support the function, the cloud will not push an alarm content package to the vehicle, thereby avoiding sending invalid alarm notifications to vehicles that do not have the ability to handle accidents.

[0040] Based on the above technical solution, the embodiments of this application collect data through vehicle sensors and upload it to the cloud. The cloud then calls the abnormal event detection model to identify whether an abnormal event has occurred in the vehicle. Compared with the local identification method on the vehicle, the cloud can rely on more powerful computing capabilities to perform comprehensive feature analysis on multi-dimensional sensor data, improve the accuracy and stability of abnormal event identification, and at the same time reduce the pressure on local data storage and algorithm calculation on the vehicle.

[0041] S120: When the operating status information meets the preset conditions, output alarm information to the user based on voice broadcast and prohibit the vehicle's display screen from displaying alarm content packages.

[0042] Among them, the operation status information meets the preset conditions to indicate that the vehicle's display screen is showing the driver assistance interface, which includes a reversing camera interface and / or a surround view camera interface.

[0043] Specifically, when the display screen is currently showing the reversing camera or surround view camera, the operating status information is determined to meet preset conditions. At this time, the reversing camera or surround view camera, or other driver assistance images, are occupying the display screen. If a warning pop-up window appears, it will obstruct the user's view of the vehicle's surroundings, making it difficult for the user to clearly observe the vehicle's surroundings and increasing the risk of secondary accidents such as scrapes and collisions. Therefore, the vehicle controller uses voice broadcast to output warning information to the user and prevents the display screen from showing the warning content package. The vehicle controller retrieves the abnormal event type and simplified risk warning text recorded in the warning content package and transmits it to the in-vehicle voice broadcast device. The warning is then delivered to the user via the in-vehicle audio system in the form of human voice, allowing the user to know that there is an abnormality in the vehicle without looking at the display screen. The content of the voice broadcast differs for different abnormal event types. For example, when the abnormal event type is a collision-related event, the voice broadcast will say, "Hello, a suspected collision has been detected. Have you been in an accident?" When the abnormal event type is tire pressure abnormality, the system will announce, "A suspected abnormal tire pressure has been detected. Please keep a firm grip on the steering wheel and slowly pull over to the side of the road. Do you need assistance?" The voice announcement in tire pressure scenarios integrates immediate safety guidance while informing the user of the abnormality, combining notification and key operational instructions into a single announcement. Simultaneously, the vehicle controller issues a lock command to the display screen, directly blocking the push channel for alarm content pop-ups. This prevents any alarm text or pop-ups from appearing on the display screen, ensuring the assisted driving interface is fully displayed and unobstructed. Users can continuously observe their surroundings, avoiding secondary collisions such as scrapes and rear-end collisions due to lost visibility.

[0044] Optionally, while the vehicle controller outputs alarm information to the user via voice broadcast, the vehicle controller simultaneously activates the voice monitoring function, pre-setting keywords that can be responded to in this alarm scenario. The user does not need to utter any wake-up word; they can directly say confirmation words such as "yes," "there is," or "it happened," or denial words such as "no," "no need," or "no accident" to complete the intended response to the alarm information. The pre-set keywords differ for different types of abnormal events. When the abnormal event type is a collision-related event, confirmation words include "yes," "there is," or "it happened," while denial words include "no," "no need," "no accident," or "it didn't happen." When the abnormal event type is a tire pressure abnormality event, confirmation words include "yes," "need," or "help," while denial words include "no," "no need," "no abnormality," or "normal tire pressure." The keywords for each scenario cover the spoken expressions that users might blurt out under high stress conditions during an accident. The above keywords are only valid for a preset duration after the voice broadcast; after the preset duration ends, monitoring is automatically turned off, without interfering with the use of other vehicle voice functions. Optionally, the preset duration is 15 seconds, starting from the start of the voice broadcast.

[0045] S130: If the operating status information does not meet the preset conditions, display an alarm content package on the vehicle's display screen.

[0046] Among them, the "operation status information does not meet the preset conditions" means that the vehicle's display screen does not show the driver assistance interface, that is, the display screen does not currently display the reversing image and / or surround view image. At this time, there is no risk that the reversing image or surround view image is obstructed, so the alarm content package can be displayed on the display screen.

[0047] Specifically, when the operating status information is determined to be inconsistent with preset conditions, an alarm dialog box corresponding to the alarm content package is overlaid on the current display screen. This alarm dialog box includes an abnormal event type title, a question message corresponding to the abnormal event type, and at least one touch response option. The touch response option includes a confirmation option and a denial option. The question message asks the user whether the abnormal event has occurred or whether assistance is needed. The confirmation option allows the user to confirm the occurrence of the abnormal event or confirm the need for assistance. The denial option allows the user to deny the occurrence of the abnormal event or indicate that assistance is not needed, enabling the user to respond to the alarm information via touch. For example, when the abnormal event type is a collision event, the alarm dialog box displays the question message "A suspected collision has been detected. Have you been in an accident?" and simultaneously displays two touch options, "Confirm" and "Denial," for the user to respond by touching the screen. When the abnormal event type is a tire pressure abnormality event, the alarm dialog box displays the question message "A suspected tire pressure abnormality has been detected. Do you need assistance?" and simultaneously displays two touch options, "Confirm" and "Denial," for the user to respond by touching the screen. In this approach, the dialog box has higher visual priority than other displayed elements on the current screen. The original content of the current screen continues to run or be displayed beneath the dialog box, and the user can restore the original screen after handling the alarm and closing the dialog box. This method is suitable for screens that are currently displaying navigation, music playback, or vehicle settings, which are still of reference value, to avoid users having to reset their navigation destination or search for their current location again after receiving alarm information.

[0048] Optionally, when the operating status information is determined to be inconsistent with preset conditions, the current display interface of the screen is directly switched to the full-screen alarm interface corresponding to the alarm content package. This full-screen alarm interface fully displays all content such as the abnormal event type, emergency suggestion information, and rescue service contact information. The original display content is restored after the alarm interface is closed. This method is suitable for situations where the content currently displayed on the screen has low reference value in the alarm scenario, such as when the screen is currently in the main menu interface, standby interface, or screen-off state. In this case, full-screen switching allows users to obtain alarm information most directly and completely.

[0049] Optionally, if the operating status information does not meet preset conditions, in addition to displaying the alarm content package on the screen, a voice broadcast can also be triggered simultaneously, allowing users to obtain alarm information through both auditory and visual channels, thereby improving the efficiency of alarm information delivery. Users can complete the intent response either through the confirmation or denial options on the touch screen, or by directly speaking the confirmation or denial words. The two channels work independently and in parallel, allowing users to freely choose according to their current driving status and personal habits, without having to wait or switch between specific channels, making alarm interaction more flexible and efficient.

[0050] In one possible implementation, the operating status information includes the vehicle's gear information. If the operating status information meets the preset conditions, it means that the gear information is in reverse gear. If the operating status information does not meet the preset conditions, it means that the gear information is in non-reverse gear. Alternatively, the operating status information includes the vehicle's gear information and speed. If the operating status information meets the preset conditions, it means that the gear information is in reverse gear and the speed is greater than or equal to the preset speed. If the operating status information does not meet the preset conditions, it means that the gear information is in a non-reverse gear and / or the speed is less than the preset speed.

[0051] The gear information is used to determine the vehicle's current gear, which includes R (reverse), N (neutral), D (drive), and P (park). The preset speed is a threshold value used to determine whether the vehicle is currently traveling at high speed. The preset speed can be 8 km / h, but it can be set according to the actual application scenario. This application embodiment does not impose a specific limitation on this.

[0052] Specifically, if the operating status information meets the preset conditions, including the gear being in reverse (R), the vehicle is in reverse and the display is showing the reversing image. If a warning pop-up appears, it would obstruct the user's view of obstacles behind them. Therefore, the warning information is output via voice broadcast, and the display is disabled from showing the warning content package. If the operating status information does not meet the preset conditions, including the gear being in a non-reversing gear (N, D, or P), the display does not show the reversing image, and there is no risk of the reversing image being obstructed. Therefore, the warning content package can be displayed on the screen.

[0053] Alternatively, the operating status information includes the vehicle's gear position and speed. If the operating status information meets preset conditions, such as the gear being in reverse and the speed being greater than or equal to a preset speed, the vehicle is in reverse and the reversing speed is relatively high. The driver needs to observe the rear environment and obstacles in a shorter time, making them more reliant on the reversing camera. If a warning pop-up window were to appear, it would severely obstruct the reversing camera, increasing the risk of a collision. Therefore, a voice broadcast method is used to output the warning information, and the display screen is prohibited from showing the warning content package. If the operating status information does not meet preset conditions, such as the gear being in a non-reversing gear and / or the speed being less than a preset speed, there is no risk of the reversing camera being obstructed, or the reversing speed is relatively slow, giving the driver ample time to observe and react. Therefore, the warning content package can be displayed on the screen.

[0054] Based on the above technical solution, this application embodiment determines whether the vehicle's operating status meets preset conditions by using gear information and a combination of gear information and vehicle speed. This accurately distinguishes between vehicle operating conditions that meet and do not meet the preset conditions. The determination result truly reflects the vehicle's current actual operating status, ensuring that the selection of subsequent alarm output methods provides an accurate and reliable basis for judgment.

[0055] Based on the above technical solution, in this embodiment, when an abnormal event is detected in the vehicle, if the vehicle's display screen shows a reversing image or surround view image, an alarm message is output to the user via voice broadcast, and the display screen is prohibited from displaying the alarm content package. This effectively conveys the alarm information to the user while preventing the alarm interface from obstructing the assisted driving image, ensuring the user can clearly observe the vehicle's surrounding environment and accurately judge road conditions, reducing secondary accidents such as scrapes and collisions caused by obstructed vision. When the vehicle's display screen does not show a reversing image or surround view image, the alarm content package is displayed, allowing the user to clearly and efficiently obtain the type of abnormal event and emergency advice information for the abnormal event. This application can dynamically select the alarm output method according to different vehicle operating status information, eliminating the safety hazard of the alarm notification itself causing secondary accidents, improving the safety of alarm information output in accident alarm scenarios, and thus effectively improving driving safety.

[0056] In one possible implementation, the method further includes: Obtain user feedback on alarm information or alarm content packages within a preset time period; If the feedback information is a confirmation instruction, the confirmation instruction and confirmation timestamp will be uploaded to the cloud, and the corresponding function page will be displayed on the screen based on the type of abnormal event, and / or the target service store will be determined based on the vehicle information and the service store information; wherein, the function page is used to display relevant rescue resource information; If the feedback message is a denial command, the denial command and denial timestamp are uploaded to the cloud, and the vehicle's display screen is controlled to cancel the display of the alarm content package.

[0057] The preset duration refers to the time remaining before a user responds after a voice announcement, or the time remaining before a user touches the screen after an alarm dialog box or full-screen alarm interface is displayed. For example, the preset duration could be 15 seconds.

[0058] Specifically, feedback information includes confirmation and denial commands. Confirmation commands are those issued by the user through the confirmation option on the touch alarm dialog box or full-screen alarm interface, or those generated after a successful voice match of a confirmed keyword. Denial commands are those issued by the user through the denial option on the touch alarm dialog box or full-screen alarm interface, or those generated after a successful voice match of a denial keyword. In scenarios where alarm information is broadcast via voice, users can directly respond by speaking the confirmation or denial keyword; a corresponding confirmation or denial command is generated upon successful voice keyword matching. In scenarios where alarm content packages are displayed on the screen, users can respond by using the confirmation or denial options on the touch alarm dialog box or full-screen alarm interface; a corresponding confirmation or denial command is generated after the touch operation.

[0059] When the feedback message is a confirmation command, the vehicle controller records a confirmation timestamp and uploads both the confirmation command and the timestamp to the cloud, allowing the cloud to record the processing result of this alarm event for user confirmation. Simultaneously, the vehicle controller displays the corresponding function page on the screen based on the type of abnormal event. This function page displays rescue resource information corresponding to the current abnormal event type, including emergency response guidance and multi-source rescue resources. Multi-source rescue resources include authorized service center phone numbers, emergency rescue, insurance company phone numbers, rescue hotlines, and highway-specific rescue services. When the abnormal event type is a collision-related event, the vehicle controller displays an accident assistant collision handling page on the screen. This page displays emergency response guidance for collision scenarios (such as instructions for activating hazard warning lights and placing a warning triangle behind the vehicle) and rescue service contact information (including one-click dialing of emergency numbers, rescue hotlines, and insurance company reporting numbers). When the abnormal event type is a tire pressure abnormality event, the vehicle controller displays a tire blowout handling page on the screen. This tire blowout handling page displays emergency handling guidance content for the tire pressure abnormality scenario (such as operation instructions such as keeping the steering wheel steady, slowing down slowly, and parking the vehicle in a safe area), rescue service contact information, etc., so that users can immediately obtain exclusive handling guidance and rescue channels for the current scenario after confirming the accident or abnormality, without having to search for relevant information across multiple interfaces or applications.

[0060] The vehicle information includes the vehicle's current location and its corresponding vehicle identification number (VIN). The target service store is a selected service store from multiple options that is compatible with the current vehicle. The service store information includes its location, identification number, service area, operating hours, and service capabilities.

[0061] The vehicle controller determines one or more service stores closest to the vehicle's current location as candidate service stores based on the vehicle's current location and the location information of each service store. Then, it parses the vehicle's model and year using the vehicle identification code to filter service stores that can provide services for that model from the candidate stores, resulting in a filtered list of service stores. Finally, based on the store information of each service store, it selects the service store that has been open for the most recent period (e.g., within 24 hours) from the filtered list as the target service store. Optionally, when multiple target service stores exist, they are displayed on the function page in order of distance from nearest to farthest. Each target service store's information includes the store name, address, contact number, and one-click dialing and navigation entry points for users to view and select.

[0062] When the feedback message is a denial command, the vehicle controller records a denial timestamp and uploads both the denial command and the timestamp to the cloud, so that the cloud records the processing result of this alarm event as user denial. Simultaneously, the vehicle controller controls the display screen to cancel the display of the alarm content package. If the current display mode is overlay, the alarm dialog box is closed, and the original display interface is restored. If the current display mode is full-screen, the full-screen alarm interface is closed, and the original display interface is restored. The processing result corresponding to the denial command, after being archived, can be used for subsequent accident false alarm rate statistics, alarm accuracy analysis, and other data applications.

[0063] Based on the above technical solution, this embodiment collects user feedback information and uploads it to the cloud after outputting alarm information, fully retaining the handling record of alarm events, which facilitates data archiving and statistical analysis in the background. If the user issues a confirmation command, the corresponding rescue resource page is loaded on the display screen according to the current abnormal event type. Simultaneously, based on the vehicle location, vehicle model parameters, and the location information and business status of each store, the appropriate target service store is selected, providing the user with emergency operation guidance and the nearest repair and rescue channel, simplifying the handling operation after the fault occurs. If the user issues a denial command, the denial record is uploaded simultaneously and the alarm interface on the display screen is cleared, restoring the original display content, avoiding false alarm pop-ups from obstructing the driving view, and effectively improving the handling efficiency and driving safety in vehicle fault or accident scenarios.

[0064] In one possible implementation, the method further includes: If no user feedback is received on the alarm information or alarm content package within a preset time period, the vehicle context information is obtained. The vehicle context information includes at least one of the following: vehicle motion parameters, user status, and environmental information. The vehicle context information is uploaded to the cloud, which then uses this information to determine the corresponding target rescue strategy and execute it to rescue the user.

[0065] The vehicle motion parameters include vehicle speed and gear status, used to determine whether the vehicle is currently moving or stationary. Optionally, the vehicle motion parameters also include vehicle acceleration, yaw rate, steering wheel angle, and / or airbag deployment status. Vehicle acceleration, yaw rate, and steering wheel angle are used to determine whether a severe impact or rollover has occurred, while airbag deployment status helps to assess the severity of the accident.

[0066] User status refers to information collected by onboard sensors that characterizes the user's current physical state, including seatbelt wearing status, seat occupancy status, and / or in-vehicle voice activity detection results. This information is used to determine whether the user is conscious, capable of active operation, or incapacitated due to injury in an accident. Optionally, user status may also include facial images and / or heart rate signals collected by a user monitoring system.

[0067] Environmental information refers to information acquired through onboard sensors or the cloud to characterize the vehicle's current external environment. This includes road type, weather conditions, and / or lighting conditions, indicating the vehicle's current location. This information is used in the cloud to assess the urgency of the rescue response and the feasibility of dispatching rescue resources. Optionally, road type includes ordinary roads, highways, mountain roads, bridges, tunnels, etc. Weather conditions include sunny, rainy, snowy, foggy, etc. Light conditions include daytime, nighttime, dawn, dusk, etc.

[0068] The target rescue strategy refers to the rescue plan determined by the cloud based on a comprehensive analysis of vehicle context information. Specifically, if no feedback is received from the user regarding the alarm information or alarm content package within a preset time period, it indicates that the user may be unconscious due to injury from the accident, or that the user, although conscious, is unable to call for help due to being trapped or injured and having limited mobility. Therefore, the vehicle controller obtains the vehicle context information and uploads it to the cloud. After receiving the vehicle context information, the cloud performs a comprehensive analysis based on vehicle motion parameters, user status, and environmental information to determine whether the triggering conditions for active rescue are met. Based on this, it decides whether to execute active rescue and what rescue method to use, and finally executes the rescue method to rescue the user.

[0069] Based on the above technical solution, in this embodiment of the application, when the user fails to respond to the alarm information or alarm content package within the timeout period, the vehicle context information is automatically obtained and uploaded to the cloud. The cloud then analyzes the information from multiple dimensions, including the vehicle's operating status, the user's status, and the on-site environment. This allows the cloud to verify the user's true situation from different dimensions, avoiding misjudgments or omissions that may result from relying on a single information source. This improves the accuracy of identifying high-risk scenarios, thereby determining the corresponding target rescue strategy and executing the target rescue strategy to rescue the user. This enhances the intelligence level of accident handling and the timeliness of rescue.

[0070] In one possible implementation, the cloud is used to determine the user's target hazard level based on vehicle context information, and to determine the corresponding target rescue strategy based on the target hazard level.

[0071] The target hazard level refers to the classification result determined by the cloud based on a comprehensive analysis of vehicle context information, used to characterize the degree of danger currently faced by the user. Specifically, after receiving vehicle context information, the cloud determines the severity of the accident based on vehicle motion parameters, whether the user is incapacitated based on their status (e.g., whether the user is unconscious), and whether the user's current location poses potential environmental risks (e.g., whether the vehicle is located in mountainous areas, near rivers, cliffs, or in severe weather, which are unfavorable for rapid arrival or rescue by rescue personnel). This multi-dimensional information is then used to jointly assess and classify the user's current hazard level into different levels. For example, if the vehicle speed is zero, the gear is in park or neutral, the airbags have deployed, and the user is unresponsive, the cloud determines the user to be in the highest hazard level. If the vehicle speed is normal, the airbags have not deployed, and the user is in a normal state, the cloud determines the user to be in the low hazard level. This hazard level classification allows the cloud to match differentiated rescue strategies according to different hazard levels, avoiding over-response in low-risk scenarios that waste resources, and avoiding delayed response and missed rescue opportunities in high-risk scenarios.

[0072] Based on the above technical solution, this application embodiment uses cloud-based systems to jointly analyze multi-dimensional data such as vehicle motion parameters, user status, and environmental information to determine the target danger level currently experienced by the user. This allows the cloud to match differentiated rescue strategies based on different danger levels. Compared to relying solely on single information for judgment or applying a uniform rescue response method to all scenarios with no response time, this application can accurately distinguish the severity of on-site hazards and adapt corresponding rescue and disposal plans for different danger levels. This avoids excessive rescue in low-risk scenarios, preventing resource waste, while also preventing insufficient handling and inadequate rescue responses in high-risk situations. It ensures that rescue strategies are highly matched to the actual dangerous operating conditions of the vehicle, effectively improving the rationality, pertinence, and effectiveness of emergency rescue dispatch.

[0073] In one possible implementation, the cloud is used to input vehicle context information into the hazard level detection model to obtain the user's target hazard level.

[0074] Specifically, a hazard level detection model is deployed in the cloud. This model determines the user's target hazard level based on vehicle context information. Vehicle context information includes vehicle motion parameters, user status, and environmental information. The input to this hazard level detection model is the aforementioned multi-dimensional information, and the output is the user's target hazard level. The hazard level detection model can be an AI model, pre-trained on a large number of historical vehicle context information samples labeled with real hazard levels. This AI model can learn the hazard levels corresponding to different combinations of vehicle motion parameters, user status, and environmental information, and output the corresponding target hazard level based on the input vehicle context information.

[0075] Based on the above technical solution, this application embodiment inputs vehicle context information into a cloud-based hazard level detection model, which then comprehensively judges and outputs the user's target hazard level. This avoids the subjectivity and limitations that may arise from manually setting judgment rules, thereby more accurately identifying the user's current hazard level and providing a reliable basis for matching differentiated rescue strategies.

[0076] In one possible implementation, the target hazard level includes a first level, a second level, and a third level, where the hazard level of the second level is greater than that of the first level but less than that of the third level. In the case of a target hazard level of Level 1, the target rescue strategy is used to control the vehicle to send an alarm message to the user again to confirm whether the user needs rescue. When the target hazard level is Level 2, the target rescue strategy is used to send accident notification information to the terminal corresponding to the preset emergency contact. When the target hazard level is Level 3, the target rescue strategy is used to trigger a rescue call and report accident-related information to the rescue platform after the rescue call is connected.

[0077] The first level indicates a low level of danger for the user. The second level indicates a moderate level of danger, meaning the user faces some safety risk. The third level indicates the highest level of danger, meaning the user faces serious danger. The danger level of the second level is greater than that of the first level but less than that of the third level.

[0078] Specifically, the cloud-based system matches the target hazard level output by the hazard level detection model with the corresponding target rescue strategy. When the target hazard level is Level 1, it indicates that the user may not be injured or is only slightly unwell, but the cloud cannot confirm whether the user is truly safe. In this case, the target rescue strategy controls the vehicle to issue another warning to the user to confirm whether the user needs rescue. For example, the vehicle can ask the user again via voice broadcast, waiting for the user's response. If the user responds that they do not need rescue, the alarm process ends. If the user responds that they need rescue or there is no response after another timeout, the response is escalated to a higher-level handling strategy.

[0079] When the target hazard level is Level 2, it indicates that the user faces some safety risk but has not yet reached the highest level of urgency, requiring an external distress call. In this case, the target rescue strategy sends an accident notification to the terminal corresponding to the preset emergency contact. The preset emergency contact can be a relative or friend's contact information pre-set by the user in the vehicle system. The accident notification information can include the vehicle's current location, the type of abnormal event, and the time of the event, so that the emergency contact can be promptly informed of the user's accident situation and take appropriate measures. Optionally, the cloud also provides a tracking link to the emergency contact, allowing them to view the vehicle's location and the progress of the accident handling in real time.

[0080] When the target danger level is Level 3, it indicates that the user is facing serious danger and may have lost the ability to call for help due to injury caused by an accident. At this time, the target rescue strategy triggers a rescue call and reports relevant accident information to the rescue platform after the call is connected. The cloud automatically initiates a voice call request to the rescue service hotline or emergency rescue platform. Once the call is connected, relevant accident information such as the vehicle's current location, the type of abnormal event, the vehicle identification code, and the severity assessment of the accident is reported to the rescue platform, enabling the platform to quickly understand the situation on-site and dispatch rescue forces to the incident location. Optionally, while triggering the rescue call, the cloud also sends a network data packet containing vehicle location information to the rescue platform, allowing the platform to view the vehicle's location simultaneously during the call, improving the accuracy and efficiency of rescue dispatch.

[0081] Based on the above technical solution, this application embodiment divides the target hazard level into three levels (Level 1, Level 2, and Level 3) and configures differentiated rescue strategies for each level, achieving a refined graded response to the user's hazard level. It can match rescue strategies appropriate to the user's actual hazard level, avoiding resource waste in low-risk scenarios and ensuring timely rescue in high-risk scenarios, thus improving the rationality of rescue strategy formulation and the effectiveness of resource allocation.

[0082] In one possible implementation, the accident-related information includes accident notification information and occupant status information inside the vehicle. The occupant status information includes the number of occupants inside the vehicle, occupant seating distribution information, and occupant consciousness status.

[0083] Specifically, accident-related information includes accident notification information and occupant status information within the vehicle. Accident notification information may include the vehicle's current location, type of abnormal event, vehicle identification number, time of the incident, and an assessment of the accident's severity, allowing the rescue platform to quickly understand the basic situation. Occupant status information includes the number of occupants, their seating arrangement, and their level of consciousness. The number of occupants indicates the total number of people in the vehicle. Seating arrangement indicates the specific seating position of each occupant, such as the driver's seat, front passenger seat, rear left seat, or rear right seat. Occupant level of consciousness indicates whether each occupant is currently conscious, for example, through in-vehicle voice activity detection, changes in seat occupancy, or image information collected by the occupant monitoring system. After the occupant status information is reported to the rescue platform, rescue personnel can know the number of people in the vehicle and their individual levels of consciousness in advance, allowing them to prepare for rescue and treatment before arriving at the scene and to rationally allocate rescue forces and emergency resources. For example, if the occupant status information indicates that there are two occupants in the vehicle, with the front passenger unresponsive and the driver conscious, the rescue platform can prepare two treatment plans in advance and prioritize treatment for the unresponsive front passenger. Optionally, the occupant status information can also include information about the occupants' injuries, such as preliminary assessments using images collected by the vehicle's cameras or occupant monitoring system, and report this information to the rescue platform so that rescue personnel can prepare appropriate first-aid equipment or medications in advance.

[0084] Based on the above technical solution, this embodiment incorporates occupant status information into accident-related information and reports it to the rescue platform. This allows the rescue platform to know in advance the number of occupants, the distribution of seats for each occupant, and the occupants' level of consciousness. This enables the platform to grasp the basic situation of the people inside the vehicle before rescue forces arrive at the scene. Rescue personnel can then rationally allocate rescue resources, prepare corresponding first-aid equipment and treatment plans, avoiding delays in treatment due to assessment of occupant conditions only upon arrival at the scene, thus improving the targeting and efficiency of the rescue response.

[0085] Figure 2 A schematic flowchart of a vehicle control method provided in an embodiment of this application is shown, such as... Figure 2 As shown, the method includes the following steps: S201 uploads the vehicle's sensor data and vehicle identification code to the cloud; S202, the cloud determines whether an abnormal event has occurred in the vehicle based on the vehicle's sensor data; S203, in the event of an abnormal event, the cloud obtains the alarm content package based on the vehicle identification code; S204, receives alarm content packets sent from the cloud; Specifically, the vehicle controller continuously collects vehicle data through various sensors installed on the vehicle and uploads the collected sensor data along with the vehicle identification code to the cloud. The cloud deploys anomaly event detection models, including collision detection and tire pressure anomaly recognition models. The cloud uses these models to analyze the sensor data in real time to detect whether an abnormal event has occurred. When the cloud detects an abnormal event, it determines the vehicle model based on the vehicle identification code, retrieves an alarm content package from the vehicle model knowledge base according to the type of abnormal event, and sends the alarm content package to the vehicle. The vehicle controller receives the alarm content package sent from the cloud.

[0086] S205, obtains vehicle gear information and speed; S206: When the vehicle is in reverse gear and the speed is greater than or equal to the preset speed, an alarm message is output to the user via voice broadcast, and the alarm content package is not displayed on the screen. S207, when the vehicle is not in reverse gear and / or the vehicle speed is less than the preset speed, outputs alarm information to the user through voice broadcast and displays the alarm content package on the display screen; Specifically, the vehicle controller obtains the vehicle's current gear information and speed to determine if the gear is reverse and if the speed is greater than or equal to a preset speed. During reversing, if the speed exceeds the preset speed, it indicates a rapid reversing maneuver, significantly increasing the driver's reliance on rear visibility. In this case, a warning pop-up on the display screen would directly obstruct the reversing camera view, hindering the driver's timely observation of the area behind the vehicle and posing a safety hazard. Therefore, when the gear is reverse and the speed is greater than or equal to the preset speed, the vehicle controller outputs a warning via voice broadcast and disables the display screen from showing the warning content package. Conversely, when the gear is not reverse or the speed is below the preset value, the warning content package is displayed on the screen, allowing the user to intuitively obtain complete warning information. Simultaneously, voice broadcast can be triggered, improving warning delivery efficiency through a dual-channel approach.

[0087] S208, Receive user feedback on alarm information or alarm data packets; S209: If the feedback is a confirmation command, upload the confirmation command and confirmation timestamp to the cloud; if the feedback is a denial command, upload the denial command and denial timestamp to the cloud; if no feedback is received from the user, obtain the vehicle context information and upload the vehicle context information to the cloud. S210: The cloud determines the user's target hazard level based on the vehicle context information, determines the corresponding target rescue strategy based on the target hazard level, and rescues the user according to the target rescue strategy.

[0088] Specifically, the system receives user feedback on alarm information or alarm data packets. If the user confirms the alarm by speaking a confirmation word or clicking the confirmation option via touch within a preset time, the vehicle controller receives the confirmation command and uploads the confirmation command and confirmation timestamp to the cloud. This allows the cloud to record the processing result of the alarm event for user confirmation. For example, when the abnormal event type is a tire pressure abnormality event, the vehicle controller displays a tire blowout handling page on the screen. This page displays emergency handling guidance for the tire pressure abnormality scenario, such as maintaining a firm grip on the steering wheel, gradually slowing down, and pulling the vehicle to a safe area. Simultaneously, the vehicle controller queries the cloud-based vehicle model knowledge base based on the vehicle identification code to obtain emergency handling knowledge entries specific to the current vehicle model, such as the specific location of the spare tire or tire repair tools. The cloud determines the current vehicle model based on the vehicle identification code, retrieves the specific knowledge entries associated with that model, and returns a real-life interior photo of the spare tire or tire repair tool location along with corresponding text descriptions to the vehicle controller. The vehicle controller then displays this information to the user on the function page, allowing the user to quickly locate the tools by referring to the real-life photo. The function page also provides quick question tags for users to click, such as "Where is the tire repair tool?" and "How to remove the spare tire?". After a user clicks on any tag, the system retrieves a specific knowledge entry matching the vehicle model and the question from the vehicle knowledge base using the vehicle identification code as an index and displays it to the user. If the user speaks a denial word or clicks the denial option via touch within a preset time, the vehicle controller receives the denial command, uploads the denial command and denial timestamp to the cloud, so that the cloud records the processing result of this alarm event as a denial by the user, and controls the display screen to cancel the display of the alarm content package.

[0089] If the user does not receive either a confirmation or denial command within a preset time period, it is determined that the user has not responded within the timeout period. The result of the timeout and the vehicle context information at the time of the timeout are uploaded to the cloud. After receiving the result of the timeout and the vehicle context information, the cloud performs a joint analysis based on the vehicle motion parameters, user status, and environmental information to determine the target danger level of the user's current location. Based on the target danger level, the cloud matches the corresponding target rescue strategy and executes the target rescue strategy to rescue the user.

[0090] Based on the above technical solution, this application embodiment identifies abnormal events through the cloud and obtains alarm content packages, which are then sent to the vehicle to achieve unified encapsulation and delivery of alarm content. The driving scenario is comprehensively judged based on gear information and vehicle speed. When reversing at a relatively high speed, voice broadcast is used and the display screen is disabled to prevent alarm pop-ups from obscuring the reversing image. When not in reverse gear or at a relatively low speed, the alarm content is displayed on the screen, allowing users to intuitively obtain alarm information. Simultaneously, this application fully uploads three results—user confirmation, denial, and no response after timeout—to the cloud, ensuring traceability of the handling results. In the case of no response after timeout, vehicle motion parameters, user status, and environmental information are combined and uploaded to the cloud. The cloud comprehensively assesses the user's danger level and matches corresponding rescue strategies, triggering proactive rescue in a timely manner when the user faces danger, improving accident handling efficiency and rescue timeliness.

[0091] Figure 3 A schematic diagram of the structure of a vehicle control device provided in an embodiment of this application is shown, such as... Figure 3 As shown, the vehicle control device 300 includes: The acquisition module 310 is used to acquire alarm content packages and vehicle operating status information. The alarm content packages include abnormal event types and emergency suggestion information for abnormal events. The control module 320 is used to output alarm information to the user via voice broadcast when the operating status information meets preset conditions, and to prevent the vehicle's display screen from displaying the alarm content package; when the operating status information does not meet preset conditions, it displays the alarm content package on the vehicle's display screen.

[0092] In one possible implementation, module 310 is used for: Obtain user feedback on alarm information or alarm content packages within a preset time period; If the feedback information is a confirmation instruction, the confirmation instruction and confirmation timestamp will be uploaded to the cloud, and the corresponding function page will be displayed on the screen based on the type of abnormal event, and / or the target service store will be determined based on the vehicle information and the service store information; wherein, the function page is used to display relevant rescue resource information; If the feedback message is a denial command, the denial command and denial timestamp are uploaded to the cloud, and the vehicle display screen is controlled to cancel the display of the alarm content package.

[0093] In one possible implementation, module 310 is used for: If no user feedback is received on the alarm information or alarm content package within a preset time period, the vehicle context information is obtained. The vehicle context information includes at least one of the following: vehicle motion parameters, user status, and environmental information. The vehicle context information is uploaded to the cloud, which then uses this information to determine the corresponding target rescue strategy and execute it to rescue the user.

[0094] In one possible implementation, module 310 is used for: Acquire sensor data collected by multiple sensors inside the vehicle; Sensor data is sent to the cloud, where the abnormal event detection model is invoked to determine whether an abnormal event has occurred in the vehicle based on the sensor data. Receive alarm content packets sent from the cloud. The alarm content packets are obtained based on the vehicle's vehicle identifier when the cloud determines that an abnormal event has occurred in the vehicle.

[0095] It should be noted that the vehicle control device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the vehicle control method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the vehicle control device and the vehicle control method embodiments provided in the above embodiments belong to the same concept. Therefore, for details not disclosed in the device embodiments of this application, please refer to the embodiments of the vehicle control method of this application, which will not be repeated here.

[0096] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0097] Figure 4 This application provides a schematic diagram of the structure of a vehicle according to an embodiment of the present application. Figure 4 As shown, the vehicle 400 includes a memory 401 and a processor 402, wherein the memory 401 stores executable program code 4011, and the processor 402 is used to call and execute the executable program code 4011 to implement a vehicle control method.

[0098] This embodiment can divide the vehicle into functional modules according to the above method example. For example, each function can be assigned to a separate module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0099] The vehicle provided in this embodiment is used to execute the vehicle control method described above, and therefore can achieve the same effect as the above implementation method.

[0100] The vehicle may include a processing module and a storage module. The processing module is used to control and manage the vehicle's actions. The storage module is used to support the vehicle in executing relevant program code and data.

[0101] The processing module may be a processor or a controller, which can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0102] In addition, the vehicle provided in the embodiments of this application may specifically be a chip, component or module. The vehicle may include a connected processor and a memory. The memory is used to store instructions. When the vehicle is running, the processor may call and execute the instructions to make the chip execute a vehicle control method in the above embodiments.

[0103] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement a vehicle control method in the above embodiment.

[0104] The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and / or data.

[0105] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a vehicle control method provided in the above embodiment.

[0106] In this embodiment, the vehicle, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding vehicle control method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding vehicle control method provided above, and will not be repeated here.

[0107] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0108] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0109] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle control method, characterized in that, Applied to vehicles, the method includes: Obtain alarm content packages and the vehicle's operating status information. The alarm content packages include abnormal event types and emergency response suggestions for the abnormal events. When the operating status information meets the preset conditions, an alarm message is output to the user via voice broadcast, and the display screen of the vehicle is prohibited from displaying the alarm content package; If the operating status information does not meet the preset conditions, the alarm content package is displayed on the vehicle's display screen.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the user's feedback information on the alarm information or the alarm content package within a preset time period; If the feedback information is a confirmation instruction, the confirmation instruction and confirmation timestamp are uploaded to the cloud, and the corresponding function page is displayed on the screen based on the abnormal event type, and / or the target service store is determined based on the vehicle information and the service store information; wherein, the function page is used to display relevant rescue resource information; If the feedback information is a denial command, the denial command and denial timestamp are uploaded to the cloud, and the vehicle's display screen is controlled to cancel the display of the alarm content package.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If no feedback from the user regarding the alarm information or the alarm content package is received within the preset time period, then vehicle context information is obtained. The vehicle context information includes at least one of vehicle motion parameters, user status, and environmental information. The vehicle context information is uploaded to the cloud, which is used to determine the corresponding target rescue strategy based on the vehicle context information and execute the target rescue strategy to rescue the user.

4. The method according to claim 3, characterized in that, The cloud platform is used to determine the user's target danger level based on the vehicle context information, and to determine the corresponding target rescue strategy based on the target danger level.

5. The method according to claim 4, characterized in that, The cloud platform is used to input the vehicle context information into the hazard level detection model to obtain the user's target hazard level.

6. The method according to claim 4, characterized in that, The target hazard level includes a first level, a second level, and a third level, wherein the hazard level of the second level is greater than that of the first level but less than that of the third level; Wherein, when the target danger level is the first level, the target rescue strategy is used to control the vehicle to output alarm information to the user again to confirm whether the user needs rescue; When the target danger level is the second level, the target rescue strategy is used to send accident notification information to the terminal corresponding to the preset emergency contact. When the target hazard level is the third level, the target rescue strategy is used to trigger a rescue call and report accident-related information to the rescue platform after the rescue call is connected.

7. The method according to claim 6, characterized in that, The accident-related information includes the accident notification information and the occupant status information inside the vehicle. The occupant status information includes the number of occupants inside the vehicle, the occupant seating distribution information, and the occupants' state of consciousness.

8. The method according to claim 1, characterized in that, The acquisition of alarm content packages includes: Acquire sensor data collected by multiple sensors inside the vehicle; The sensor data is sent to the cloud, whereby the cloud is used to invoke an abnormal event detection model to determine whether an abnormal event has occurred in the vehicle based on the sensor data. The alarm content packet sent from the cloud is received. The alarm content packet is obtained based on the vehicle's vehicle identifier when the cloud determines that an abnormal event has occurred in the vehicle.

9. The method according to claim 1, characterized in that, The operating status information includes the vehicle's gear information. If the operating status information meets the preset conditions, it means that the gear information is in reverse gear. If the operating status information does not meet the preset conditions, it means that the gear information is in non-reverse gear. Alternatively, the operating status information includes the vehicle's gear information and speed. The operating status information meeting the preset conditions includes the gear information being in reverse gear and the speed being greater than or equal to a preset speed. The operating status information not meeting the preset conditions includes the gear information being in a non-reverse gear and / or the speed being less than the preset speed.

10. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the vehicle to perform the vehicle control method as described in any one of claims 1 to 9.