Method and apparatus for risk detection in vehicle scene, server, and vehicle-mounted device

Abstract

The present application relates to the technical field of automobile services, and provides a method and apparatus for risk detection in a vehicle scene, a server, and a vehicle-mounted device. The method comprises: acquiring a first scene of a vehicle, the first scene being a scene to be created, and the first scene comprising at least one first trigger condition and at least one piece of first action information, the at least one piece of first action information being executed when the at least one first trigger condition is met; determining whether there is a conflict between the first scene and at least one second scene of the vehicle, the at least one second scene being a created scene, and the second scene comprising at least one second trigger condition and at least one piece of second action information, and, when the at least one second trigger condition is met, executing the at least one second action information; when there is a conflict between the first scene and the at least one second scene, outputting first conflict prompt information. According to the described solution, by means of detecting a scene conflict and performing conflict prompting, the user experience can be improved.

Description

Vehicle scenario risk detection methods, devices, servers, and in-vehicle equipment

[0001] This application claims priority to Chinese patent application filed on December 9, 2024, with application number 202411803015.1 and entitled "Vehicle Scene Risk Detection Method, Apparatus, Server and In-Vehicle Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of automotive service technology, and more specifically, to a vehicle scenario risk detection method, device, server, and in-vehicle equipment. Background Technology

[0003] With the continuous development of intelligent vehicles, more and more car manufacturers are opening up the capabilities of their vehicles to users. Users can customize and combine various functions of the vehicle according to their own preferences, driving habits and needs to achieve customized scenarios.

[0004] Users may configure vehicle functions in an unreasonable way. For example, a user might create a scenario where seat ventilation is activated when the driver's seat is occupied, and another scenario where seat heating is activated when the driver's seat is occupied. Since ventilation and heating of seat components are mutually exclusive, the vehicle might not activate either seat ventilation or seat heating when the driver's seat is occupied. Clearly, unreasonable configurations between scenarios can lead to a poor user experience, and may even pose safety risks or cause functional disruptions to the vehicle's infotainment system. Summary of the Invention

[0005] This application provides a vehicle scene risk detection method, device, server, and in-vehicle equipment, which can improve user experience by detecting scene conflicts and providing conflict prompts.

[0006] Firstly, a vehicle scene risk detection method is provided, which can be applied to servers, in-vehicle devices, or terminal devices. The method includes: acquiring a first scene of the vehicle, the first scene being a scene to be created, the first scene including at least one first trigger condition and at least one first action information, wherein the at least one first action information is executed when all at least one first trigger condition is met; determining whether there is a conflict between the first scene and at least one second scene of the vehicle, the at least one second scene being a created scene, the second scene including at least one second trigger condition and at least one second action information, wherein the at least one second action information is executed when all at least one second trigger condition is met; and outputting a first conflict warning message when a conflict exists between the first scene and at least one second scene.

[0007] It should be understood that the first conflict warning information indicates a conflict between the first scenario and the at least one second scenario. The method provided in this application embodiment can be executed by a server, an in-vehicle device, or a terminal device. When the method provided in this application embodiment is executed by a server, the server can output the first warning information to the in-vehicle device or terminal device (e.g., a mobile phone or tablet). After receiving the first conflict warning information, the vehicle or terminal device can display the first conflict warning information on the display screen.

[0008] The method provided in this application improves the user experience during scene creation by detecting conflicts between a scene to be created and an existing scene, and provides a conflict warning when conflicts exist. This enhances the user's sense of intelligence when using the vehicle's infotainment system. Furthermore, by modifying conflicting scenes according to the conflict warning, users can better avoid safety risks and mechanical malfunctions caused by conflicts between scenes.

[0009] In one possible implementation, determining whether a conflict exists between a first scenario and at least one second scenario of the vehicle includes: determining whether a loopback conflict exists between the first scenario and at least one second scenario of the vehicle. A loopback conflict indicates that the execution of a target first action information in the at least one first action information leads to the execution of a target second action information in the at least one second action information, and the execution of the target second action information leads to the execution of the target first action information.

[0010] In other words, if the fulfillment of the triggering condition of the first scenario causes the system to enter an infinite loop, that is, to repeatedly execute the action information in the first scenario and the action information in the second scenario, it indicates that there is a loop conflict between the first scenario and the at least one second scenario.

[0011] Loop conflicts can lead to execution errors or execution disorder. According to the solution provided in the embodiments of this application, by detecting whether there is a loop conflict between the first scenario and at least one second scenario and providing a conflict prompt, users can modify the scenario settings in a timely manner based on the conflict prompt to avoid the occurrence of loop conflicts.

[0012] In one possible implementation, determining whether a loop conflict exists between the first scenario and the at least one second scenario includes: identifying action information-trigger condition pairs in the first scenario and the at least one second scenario, which consist of action information and trigger conditions belonging to different scenarios; determining whether the identified at least one action information-trigger condition pair includes a negatively associated action information-trigger condition pair, wherein a negatively associated action information-trigger condition pair indicates that the trigger condition is not satisfied after the action information is executed; if the at least one action information-trigger condition pair does not include a negatively associated action information-trigger condition pair, determining that a loop conflict exists between the first scenario and the at least one second scenario.

[0013] Based on the above implementation method, it can be determined whether there is a loop conflict between the first scenario and the at least one second scenario.

[0014] In one possible implementation, determining whether there is a conflict between the first scenario and the at least one second scenario includes: determining whether there is a repetitive execution conflict between the first scenario and the at least one second scenario, wherein a repetitive execution conflict means that action information for the same object is executed multiple times within a preset control time interval.

[0015] Action information for the same object includes action information from the same non-mechanical control and action information from the same mechanical control. In one example, if the same non-mechanical control action information is executed multiple times within a preset control time interval, the user is allowed to create a first scene. If the same mechanical control action information is executed multiple times within a preset control time interval, the user is not allowed / prohibited from creating a first scene.

[0016] If the same mechanical control action information is executed multiple times within a preset control time interval, i.e., frequently controlling the same machine within a time period shorter than the preset control time interval, it may cause mechanical failure and affect the machine's lifespan. For example, frequently raising and lowering the suspension within a short period of time may cause suspension failure. In this embodiment, by detecting whether there is a repeated execution conflict between the first scene and the at least one second scene and providing a conflict warning, the user can adjust the scene settings in a timely manner to avoid repeated execution conflicts, thereby preventing mechanical failures caused by repeated execution conflicts.

[0017] In one possible implementation, determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario includes: obtaining multiple execution time intervals associated with third action information, wherein an execution time interval associated with an action information indicates that the action information is executed after a delay of the execution time interval, the third action information is action information for the same object in the first scenario and the at least one second scenario, and the third action information includes at least two different action information; and determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario based on the multiple execution time intervals.

[0018] In one possible implementation, determining whether there is a repeated execution conflict between the first scenario and the at least one second scenario based on the plurality of execution time intervals includes: determining whether there is a repeated execution conflict between the first scenario and the at least one second scenario based on the plurality of execution time intervals and a preset control time interval; if the average value of the plurality of execution time intervals is greater than the preset control time interval, determining that there is a repeated execution conflict between the first scenario and the at least one second scenario.

[0019] In one possible implementation, the first conflict warning message indicates a risk of mechanical failure.

[0020] According to this prompt, users can modify the scene settings to avoid potential mechanical failures.

[0021] In one possible implementation, the first conflict alert information includes information about the existence of a conflict and / or suggestions for resolving the conflict.

[0022] In one possible implementation, before determining whether there is a conflict between the first scene and at least one second scene of the vehicle, the method further includes: during the creation of the second scene, acquiring first information and second information, wherein the first information is information already added to the first scene, and the second information is information to be added to the first scene, the first information including a fourth trigger condition and / or fourth action information, wherein the fourth action information is executed when the fourth trigger condition is met, and the second information including a fifth trigger condition or fifth action information; determining whether there is a conflict between the first information and the second information; and outputting a second conflict prompt information if there is a conflict between the first information and the second information.

[0023] The method provided in this application improves the user experience during scene creation by detecting conflicts within the scene during scene creation and providing conflict alerts when conflicts exist. This enhances the user's sense of intelligence when using the vehicle's infotainment system. Furthermore, by modifying conflicting information based on the conflict alerts, users can better avoid safety risks and mechanical malfunctions caused by conflicts within the scene.

[0024] In one possible implementation, determining whether there is a conflict between the first information and the second information includes: determining that there is a conflict between the first information and the second information if one or more of the following conditions are met: the fifth action information is not executable when the fourth triggering condition is met, the fourth triggering condition and the fifth triggering condition are mutually exclusive, or the execution of the fourth action information makes the fifth action information not executable.

[0025] Based on the above implementation method, it can be determined whether there is a conflict between the first information and the second information.

[0026] In one implementation, determining whether there is a conflict between the first and second information includes: if the object corresponding to the fourth triggering condition is a dependent object of the fifth action information, and the dependency relationship between the fourth triggering condition and the fifth action information is a negative dependency, then a conflict exists between the fourth triggering condition and the fifth action information. Specifically, a negative dependency between an action information and the state of its dependent object indicates that the action information cannot be executed when the vehicle is in the state of the dependent object.

[0027] In one possible implementation, when the first information includes a fourth triggering condition, determining whether there is a conflict between the first information and the second information includes: determining whether the fourth action information and the fifth action information are action information for the same object; if the fourth action information and the fifth action information are action information for the same object, determining that there is a conflict between the first information and the second information; or, if the fourth action information and the fifth action information are different action information for the same object, and the execution time interval between the fourth action information and the fifth action information is less than a preset control time interval, determining that there is a conflict between the first information and the second information.

[0028] Based on the above implementation method, it can be determined whether there is a conflict between the first information and the second information. Furthermore, if the conflicting action information is the same mechanical control action information, a conflict warning can be issued to avoid unloading failures.

[0029] In one possible implementation, before determining whether a conflict exists between the first scenario and at least one second scenario of the vehicle, the method further includes: determining whether a conflict exists between the second scenarios in response to a user action that creates the second scenario.

[0030] The method provided in this application improves the user experience during scene creation by detecting conflicts within the scene during scene creation and providing conflict alerts when conflicts exist. This enhances the user's sense of intelligence when using the vehicle's infotainment system. Furthermore, by modifying conflicting information based on the conflict alerts, users can better avoid safety risks and mechanical malfunctions caused by conflicts within the scene.

[0031] In one possible implementation, determining whether a conflict exists in the second scenario includes: determining that a conflict exists in the second scenario if the second scenario satisfies one or more of the following: there is at least one triggering condition in the second scenario that makes at least one action information unexecutable, there are mutually exclusive triggering conditions in the second scenario, or the execution of one action information in the second scenario causes the other action information to become unexecutable.

[0032] Based on the above implementation method, it can be determined whether there is a conflict between the first information and the second information.

[0033] In one possible implementation, determining whether a conflict exists in the second scenario includes: determining whether the second scenario includes multiple action information for the same object; if the second scenario includes multiple action information for the same object, or if the second scenario includes multiple action information for the same object and the average execution time interval between the multiple action information is less than a preset control time interval, then the second scenario is determined to have a conflict.

[0034] Based on the above implementation method, it can be determined whether there is a conflict between the first information and the second information. Furthermore, if the conflicting action information is the same mechanical control action information, a conflict warning can be issued to avoid unloading failures.

[0035] Secondly, a vehicle scenario risk detection device is provided, which includes units for implementing the steps of the method in the first aspect or any possible implementation of the first aspect.

[0036] For example, the device may be a server, a vehicle-mounted device, or a terminal device.

[0037] Thirdly, a vehicle scenario risk detection device is provided. The device includes at least one processor and a memory coupled together. The memory stores program instructions. When the program instructions stored in the memory are executed by the processor, the method in the first aspect or any possible implementation of the first aspect is executed.

[0038] For example, the device may be a server, a vehicle-mounted device, or a terminal device.

[0039] Fourthly, a vehicle scene risk detection device is provided, the device including at least one processor and interface circuit, wherein the at least one processor is used to execute the method in the first aspect or any possible implementation of the first aspect.

[0040] For example, the device may be a server, a vehicle-mounted device, or a terminal device.

[0041] Fifthly, a vehicle scenario risk detection system is provided, which is used to execute the methods in the first aspect or any possible implementation of the first aspect.

[0042] In a sixth aspect, a computer program product is provided, the computer program product including computer program instructions, which, when executed, cause the method in the first aspect or any possible implementation thereof to be performed.

[0043] In a seventh aspect, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed, the method in the first aspect or any possible implementation thereof is performed.

[0044] Eighthly, a chip is provided, the chip comprising: a processor for calling and running a computer program from a memory, such that the method in the first aspect or any possible implementation thereof is executed. Attached Figure Description

[0045] Figures 1A to 1J are schematic diagrams illustrating the process of creating a scene in a customized manner according to embodiments of this application;

[0046] Figures 2A to 2D are schematic diagrams illustrating the process of creating a scene by adding a sharing code according to an embodiment of this application.

[0047] Figures 3A to 3C are schematic diagrams illustrating the process of creating a scene by adding officially recommended scenes, as provided in the embodiments of this application.

[0048] Figures 4A and 4B are schematic diagrams of a scenario for triggering conflict detection and providing conflict prompts according to an embodiment of this application.

[0049] Figures 5A to 5C are schematic diagrams of another scenario for triggering conflict detection and providing conflict prompts according to the embodiments of this application;

[0050] Figure 6 is a schematic diagram of a system architecture provided in an embodiment of this application;

[0051] Figure 7 is a schematic flowchart of the vehicle scenario risk detection method provided in this application;

[0052] Figure 8 is a schematic diagram illustrating positive and negative correlations provided in this application;

[0053] Figure 9 is a schematic diagram of the relationship between action information-triggering condition pairs between scenes provided in the embodiments of this application;

[0054] Figure 10 is a schematic diagram of the second scenario provided in the embodiments of this application;

[0055] Figure 11 is a schematic diagram of the second scenario provided in the embodiment of this application;

[0056] Figure 12 is a schematic diagram of another system architecture provided in an embodiment of this application;

[0057] Figure 13 is a schematic flowchart of the vehicle scenario risk detection method provided in the embodiments of this application;

[0058] Figures 14A to 14D are schematic diagrams of a scenario for triggering conflict detection and providing conflict prompts according to an embodiment of this application.

[0059] Figures 15A and 15B are schematic diagrams of another scenario for triggering scenario conflict detection and providing conflict prompts according to the embodiments of this application;

[0060] Figure 15C is a schematic diagram of scene setting modification based on conflict prompts provided in an embodiment of this application;

[0061] Figures 16A to 16C are schematic diagrams of another scenario for triggering conflict detection and providing conflict prompts according to the embodiments of this application;

[0062] Figure 17 is a schematic flowchart of the vehicle scenario risk detection method provided in the embodiments of this application;

[0063] Figure 18 is a schematic flowchart of the vehicle scenario risk detection method provided in the embodiments of this application;

[0064] Figures 19 and 20 are schematic diagrams of two conflict detection rules provided in the embodiments of this application;

[0065] Figures 21A to 21C are schematic diagrams of a scenario where a modified existing scenario triggers scenario conflict detection and provides a conflict prompt, as provided in the embodiments of this application.

[0066] Figure 22 is a structural schematic diagram of a vehicle-mounted device, terminal device, or server provided in an embodiment of this application;

[0067] Figure 23 is a software structure block diagram of an in-vehicle device, terminal device, or server according to an embodiment of this application;

[0068] Figure 24 is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0069] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0070] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Additionally, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0071] In the various method embodiments of this application, the order of the sequence numbers does not imply the order of execution. The execution order should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0072] It is understood that in this application, descriptions such as "under the circumstances," "if," "when," and "if..." can be used interchangeably. Furthermore, these descriptions all refer to the corresponding actions that will be taken under certain objective circumstances, and are not time-limited, nor do they require any judgment action during implementation, nor do they imply any other limitations.

[0073] It is understood that some optional features in the embodiments of this application can be implemented independently in certain scenarios without relying on other features, such as the current solution on which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus given in the embodiments of this application can also implement these features or functions, which will not be elaborated here.

[0074] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referred to each other. In the various embodiments of this application, and in the various implementation methods / methods / implementations within each embodiment, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments and between the various implementation methods / methods / implementations within each embodiment are consistent and can be mutually referenced. The technical features in different embodiments and the various implementation methods / methods / implementations within each embodiment can be combined according to their inherent logical relationships to form new embodiments, implementation methods, methods, or implementation approaches. The embodiments described below do not constitute a limitation on the scope of protection of this application.

[0075] First, let me explain some of the concepts involved in this application.

[0076] 1. ECA: Event-condition-action (ECA) is a rule or logical structure used to define a specific action to be performed when a specific event occurs and certain conditions are met.

[0077] 2. Triggering conditions: also known as triggering information, equivalent to "events" or "conditions" in ECA.

[0078] If a scene includes multiple triggering conditions, one of the triggering conditions is equivalent to an "event" in an ECA, and the other triggering conditions are equivalent to "conditions" in an ECA. If a scene includes only one triggering condition, that triggering condition is equivalent to an "event" in an ECA.

[0079] 3. Action information: Equivalent to "action" in ECA.

[0080] In this embodiment of the application, the triggering condition is used to trigger the execution of action information, that is, when the triggering condition is met, the action information is executed.

[0081] 4. Scenes to be Created: Before a scene is successfully saved / added to a vehicle, it is called a scene to be created. A scene to be created can also be called the currently edited scene or a scene in edit mode.

[0082] 5. Created Scene: When a scene is successfully saved / added to a vehicle, it is called a created scene.

[0083] Vehicle manufacturers are opening up vehicle capabilities to users, allowing them to create scenarios based on their preferences, driving habits, and needs. For example, users can create scenarios in a custom way, add scenarios shared by community users as their own via share codes, or select scenarios of interest from an officially recommended scenario marketplace.

[0084] In some embodiments, users can create scenes through an interface provided by the display screen of the in-vehicle device. Alternatively, users can create scenes through a vehicle-related application (App) on a terminal device (such as a mobile phone or tablet).

[0085] In-vehicle equipment, also known as vehicle infotainment systems, can be installed in the vehicle's center console. It's a shorthand for in-vehicle entertainment products that enable communication between people and the vehicle, between the vehicle and the outside world, or between vehicles. Responding to user actions such as clicking, swiping, and touching on the in-vehicle device's display screen, or in response to voice commands, the device can display corresponding content or provide relevant functions, such as playing audio and video.

[0086] The following example illustrates the process of creating a scene using the interface provided by the display screen in the vehicle's equipment.

[0087] For example, Figures 1A to 1J illustrate the process of a user creating a scene in a customized manner. First, the user enters interface 11 shown in Figure 1A, and then clicks the "Custom Creation" option 111 in interface 11. In response to clicking the "Custom Creation" option 111, the in-vehicle device displays interface 12 shown in Figure 1B. The user can add trigger conditions through the "Add Conditions" option 121 in interface 12, and add action information through the "Add Task" option 122 in the interface shown in Figure 1B.

[0088] For example, after a user clicks the "Add Condition" option 121 in interface 12 shown in Figure 1B, the in-vehicle device displays interface 13 as shown in Figure 1C. Interface 13 includes cards 131. Card 131 shows seven options: Seat, Doors & Windows, Lights, Driving Control, Environment, Energy, and Connectivity. Each option corresponds to a subsystem of the vehicle, which is the basic framework of the vehicle and responsible for fulfilling various functional requirements. For example, the "Seat" subsystem can perform the same functions as the vehicle's seats, such as seat unfolding, seat ventilation, and seat heating. The "Doors & Windows" subsystem can perform functions related to doors and windows, such as door opening, door closing, window opening, and window closing. Each subsystem includes one or more objects; for example, the door and window subsystem includes four objects: doors, windows, door locks, and children. Different functions are defined for each object, and users can select and combine these functions. For example, if a user clicks the "Child Lock" option 131a, in response to this click, the in-vehicle device displays interface 14 as shown in Figure 1D. Interface 14 includes card 141. Users can select different functions by sliding up and down on card 141. For example, after the user selects "second row left side" and "open", and clicks "OK" control 141a, the vehicle device displays interface 15 as shown in Figure 1E.

[0089] Next, referring to Figure 1E, the user clicks the "Add Task" option 122. In response to this action, the in-vehicle device displays interface 16 as shown in Figure 1F, which includes card 161. The user clicks the "Window" option 161a in card 161, and the in-vehicle device displays interface 17 as shown in Figure 1G, which also includes card 171. By sliding up and down on card 171, the user can select and combine functions. For example, after selecting "Second Row Left Side" and "Open," and clicking the "OK" control 171a, the in-vehicle device displays interface 18 as shown in Figure 1H. The user can modify the scene name. For example, referring to interface 19 in Figure 1I, the user changes the default scene name "Scene 1" to "Open Window When Second Row Left Child Lock is Open." Then, the user clicks the "Save" control 191a in interface 19, triggering the in-vehicle device to save the scene shown in Figure 1I. If the in-vehicle device successfully saves the scene shown in Figure 1I, interface 20 as shown in Figure 1J will be displayed. At this time, the scene "Opening the window when the second-row left child lock is open" shown on interface 20 is a created scene. It should be understood that before the in-vehicle device successfully saves the "Opening the window when the second-row left child lock is open" scene, the scene is called a scene to be created.

[0090] Figures 2A to 2D illustrate the process of a user creating a scene by adding a sharing code. First, the user enters interface 21 shown in Figure 2A (interface 21 is the same as interface 11 shown in Figure 1A). Then, the user clicks the "Add Sharing Code" option 211. In response to this click, the in-vehicle device displays interface 22 as shown in Figure 2B. Interface 22 includes a card 221. The user enters the sharing code "XXXX" of a scene shared by another user in the community into card 221 and clicks the "OK" control 221a. The in-vehicle device then displays interface 23 as shown in Figure 2C. The user clicks the "Add" control 231 in interface 23. In response, the in-vehicle device adds the "Second Row Left Window Opens for 5 Seconds and Closes" scene as the user's own scene. Once the "Second Row Left Window Opens for 5 Seconds and Closes" scene is successfully added, the in-vehicle device displays interface 24 as shown in Figure 2D. At this point, the "Second Row Left Window Opens for 5 Seconds and Closes" scene is considered created. It should be understood that before the "second row left window opens and closes after 5 seconds" scenario is successfully added to the vehicle equipment, the scenario is called the scenario to be created.

[0091] Figures 3A to 3C illustrate the process of a user creating a scene by adding an officially recommended scene. First, the user enters interface 31 shown in Figure 3A (interface 31 is the same as interface 11 shown in Figure 1A and interface 21 shown in Figure 2A). By swiping up and down on interface 31, the user can select options within it. For example, if the user clicks the "Children Getting Out of the Car" option 311 in the recommended scenes, the in-vehicle device displays interface 32 as shown in Figure 3B. Interface 32 shows the officially recommended "Children Getting Out of the Car" scene. The user then clicks the "Add" control 321 in interface 32. In response to this click, the in-vehicle device adds the "Children Getting Out of the Car" scene as the user's own scene. Once the "Children Getting Out of the Car" scene is successfully added, the in-vehicle device displays interface 33 as shown in Figure 3C, indicating that the "Children Getting Out of the Car" scene has been created. It should be understood that before the in-vehicle device successfully adds the "Children Getting Out of the Car" scene, the scene is referred to as a scene to be created.

[0092] Users can create scenarios using any of the methods described above or other methods not mentioned earlier (such as voice commands). During scenario creation, users may configure vehicle functions in ways that are unreasonable. For example, one scenario might be to activate seat ventilation when the driver's seat is occupied, while another might be to activate seat heating. Since ventilation and heating of seat components are mutually exclusive, the vehicle might not activate either when the driver's seat is occupied. Therefore, unreasonable scenarios can lead to a poor user experience, and may even pose safety risks or disrupt the vehicle's infotainment system.

[0093] In view of this, this application provides a relevant technical solution that improves the user experience during scene creation by detecting conflicts between scenes to be created and already created scenes and providing conflict alerts, thereby enhancing the user's sense of intelligence when using the vehicle's infotainment system. Furthermore, by modifying conflicting scenes according to the conflict alerts, users can better avoid safety risks and mechanical malfunctions caused by conflicts between scenes.

[0094] For example, Figures 4A and 4B illustrate a scenario diagram for triggering scenario conflict detection and providing conflict prompts. Assume a user has already created the "Open window when second-row left child lock is open" scenario (Figure 1J) and the "Close second-row left window after 5 seconds" scenario (Figure 2D), and wants to add the "Child getting out of the car" scenario (Figure 4A is the same as the scenario shown in Figure 3B) as their own scenario. Referring to Figure 4A, the user clicks the "Add" control 321 in interface 32, triggering conflict detection between the "Child getting out of the car" scenario, the "Open window when second-row left child lock is open" scenario, and the "Close second-row left window after 5 seconds" scenario. Since there is a conflict between the three scenarios, after the user clicks the "Add" control 321, the in-vehicle device displays interface 40 as shown in Figure 4B. Interface 40 includes a card 401, and the content of the prompt box 401a in card 401 is a prompt message, which allows the user to understand the conflict situation. Furthermore, based on the prompt message, the user can modify the scenario configuration to avoid conflicts between scenarios. For example, a user can click the "Return to Modify" control 401b. In response to the click of the "Return to Modify" control 401b, the vehicle-mounted device will display the interface 32 shown in Figure 4A, where the user can modify the trigger conditions and / or action information.

[0095] Figures 5A to 5C illustrate another scenario where conflict detection and conflict alerts are triggered. Referring to interface 51 in Figure 5A, the "Suspension Height Adjustment Greater Than 40 Yards" scenario shown in interface 51 is a scenario already created by the user, and the user is creating the "Suspension Height Adjustment Less Than 40 Yards" scenario shown in interface 52 in Figure 5B. The user clicks the "Save" control 521 in Figure 5B, triggering conflict detection between the "Suspension Height Adjustment Greater Than 40 Yards" and "Suspension Height Adjustment Less Than 40 Yards" scenarios. Because there is a conflict between the two scenarios, after the user clicks the "Save" control 521 in Figure 5B, the in-vehicle device displays interface 53 as shown in Figure 5C. Interface 53 includes a card 531, and the content of the prompt box 531a in card 531 is a prompt message, which allows the user to understand the conflict situation. Furthermore, based on the prompt message, the user can modify the scenario configuration to avoid conflicts between scenarios. For example, a user can click the "Return to Modify" control 531b. In response to this click, the vehicle-mounted device will display interface 52 as shown in Figure 5B, where the user can modify the triggering conditions and / or action information. The system architecture and method provided in this application will be described in detail below, using the scenario of triggering conflict detection and providing conflict alerts as described above.

[0096] Figure 6 is a schematic diagram of a system architecture provided in this application. Referring to Figure 6, the system architecture includes a vehicle 610 and a server 620, which can communicate with each other. The server 620 can execute the methods provided in this application, such as method 700 described below. Alternatively, the vehicle 610, such as the on-board equipment in the vehicle 610, can execute the methods provided in this application. Or, the methods provided in this application can be executed jointly by the vehicle 610 and the server 620.

[0097] In some embodiments, the method provided in this application may also be executed by a terminal device (such as a mobile phone or tablet), or by a terminal device communicating with server 620 and server 620 jointly executing the method provided in this application.

[0098] For example, server 620 can be a physical server or a cloud server. This application does not specifically limit the form of server 620.

[0099] Figure 7 is a schematic flowchart of the vehicle scenario risk detection method provided in this application. The following explanation uses the example of method 700 being executed by a server to illustrate each step of method 700.

[0100] S710, acquiring the first scene of the vehicle.

[0101] In this application, obtaining a scene can also be described as obtaining the script (or script information) of a scene. For example, obtaining the first scene can also be described as obtaining the script of the first scene.

[0102] S720, determine whether there is a conflict between the first scenario and at least one second scenario of the vehicle.

[0103] The first scenario is the scenario to be created. The first scenario includes at least one first trigger condition and at least one first action information. At least one first action information is executed when all at least one first trigger condition is met. It should be understood that the at least one first trigger condition is the trigger condition for the first scenario, and the at least one first action information is the action information for the first scenario.

[0104] At least one second scenario is a created scenario. A second scenario includes at least one second trigger condition and at least one second action information; at least one second action information is executed when all at least one second trigger condition is met. It should be understood that at least one second trigger condition is a trigger condition for the second scenario, and at least one second action information is action information for the second scenario.

[0105] It should be understood that the embodiments of this application do not limit the method of creating the first scenario and the at least one second scenario. For example, the first scenario or any second scenario can be created by user customization, by adding a share code, or by adding from officially recommended scenarios. The at least one second scenario can be all scenarios that the user has currently created, or it can be a portion of the scenarios that the user has currently created.

[0106] This application does not limit the timing of obtaining the first scene in its embodiments. In some embodiments, the first scene can be obtained when the user triggers the addition or saving of the first scene.

[0107] For example, the first scenario could be the "child getting out of the car" scenario shown in Figure 4A, where at least one first trigger condition is "the left side of the second row window is closed," and at least one first action information is "the left side of the second row child lock is opened." The at least one second scenario could be the "opening the window when the left side of the second row child lock is open" scenario shown in Figure 1J and the "closing the left side of the second row window after 5 seconds" scenario shown in Figure 2D. For the "opening the window when the left side of the second row child lock is open" scenario shown in Figure 1J, the at least one second trigger condition is "the left side of the second row child lock is opened," and the at least one second action information is "the left side of the second row window is opened." For the "closing the left side of the second row window after 5 seconds" scenario shown in Figure 2D, the at least two trigger conditions are "the left side of the second row window is opened," and the at least one second action information is "delay of 0 minutes and 5 seconds" and "the left side of the second row window is closed." Referring to Figure 4A, the user clicking the "Add" control 321 can trigger the server to retrieve the first scenario.

[0108] For example, the first scenario could be the "suspension height adjustment below 40 km / h" scenario shown in Figure 5B, where at least one first trigger condition is "vehicle speed below 40 km / h" and at least one first action information is "suspension height high (i.e., adjust the suspension height higher)". The at least one second scenario could be the "suspension height adjustment above 40 km / h" scenario shown in Figure 5A, where at least one second trigger condition is "vehicle speed above 40 km / h" and at least one first action information is "suspension height low (i.e., adjust the suspension height lower)". Referring to Figure 5B, when the user clicks the "Save" control 521, the server can retrieve the first scenario.

[0109] In some embodiments, in S720, the server can determine whether a conflict exists between the first scenario and the at least one second scenario based on the script of the first scenario, the script of the at least one second scenario, and conflict detection rules. Conflict detection rules represent the method used to determine conflicts between scenarios and can also be called conflict rule definitions. These conflict detection rules can be pre-stored in the server.

[0110] S730, if there is a conflict between the first scene and the at least one second scene, output a first conflict prompt message.

[0111] It is understood that the first conflict warning information indicates a conflict between the first scenario and the at least one second scenario. After the vehicle or terminal device obtains the first conflict warning information, it can display the first conflict warning information on the display screen.

[0112] Those skilled in the art will understand that the first conflict prompt information obtained by the vehicle (e.g., in-vehicle equipment) or terminal device is a code, and the first conflict prompt information displayed on the screen is the user interface information corresponding to the code. Furthermore, when method 700 is executed by the in-vehicle equipment or terminal device, the first conflict prompt information can be user interface information, such as the content in the prompt box 401a shown in Figure 4B.

[0113] In some embodiments, the first conflict alert information includes information about the existence of a conflict and / or suggestions for resolving the conflict.

[0114] For example, see the prompt box 401a shown in Figure 4B. The content of the prompt box 401a is the first conflict prompt information. The conflict information is that "the current configuration scenario has a repeated execution conflict with the scenarios of "opening the window when the second row left child lock is open" and "closing the second row left window after 5 seconds". The suggestion to resolve the conflict is "please adjust".

[0115] For example, see the prompt box 531a shown in Figure 5C. The content of the prompt box 531a is the first conflict prompt information. The conflicting information is that "the current configuration scenario and the "suspension height adjustment greater than 40 yards" scenario have frequent suspension adjustments in a short period of time during execution". The suggestion to resolve the conflict is "please adjust".

[0116] Optionally, the first conflict warning message also indicates a risk of mechanical failure.

[0117] For example, referring to the prompt box 531a shown in Figure 5C, the first prompt message in prompt box 531a is "There is a risk of mechanical failure".

[0118] In some embodiments, if there is a conflict between the first scene and the at least one second scene, the user-triggered save / add first scene fails.

[0119] According to the vehicle scenario risk detection method provided in this application, by detecting conflicts between scenarios and providing conflict prompts during the scenario creation process, the user experience during scenario creation can be improved, and the user's sense of intelligence in using the vehicle system can be enhanced.

[0120] The S720 will be described in detail below.

[0121] In some embodiments, conflicts between scenarios include loop conflicts.

[0122] Accordingly, S720 may include: determining whether there is a loopback conflict between the first scenario and at least one second scenario of the vehicle.

[0123] A loop conflict indicates that the execution of at least one first action information leads to the execution of at least one second action information, and the execution of the second action information leads to the execution of the first action information. It should be understood that the target first action information is some or all of the first action information in the at least one first action information.

[0124] In other words, if the fulfillment of the triggering condition of the first scenario causes the system to enter an infinite loop, that is, to repeatedly execute the action information in the first scenario and the action information in the second scenario, it indicates that there is a loop conflict between the first scenario and the at least one second scenario.

[0125] For example, the first scenario is the "child getting out of the car" scenario shown in Figure 4A, and at least one second scenario is the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J and the "closing the second-row left window after 5 seconds" scenario shown in Figure 2D. The execution of the action information in the "child getting out of the car" scenario satisfies the trigger condition for the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J, thus executing the action information for the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J. The execution of the action information in the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J, in turn, satisfies the trigger condition for the "closing the second-row left window after 5 seconds" scenario shown in Figure 2D, thus executing the action information for the "closing the second-row left window after 5 seconds" scenario shown in Figure 2D. The execution of the action information in the "closing the second-row left window after 5 seconds" scenario shown in Figure 2D satisfies the trigger condition for the "child getting out of the car" scenario shown in Figure 4A, thus executing the action information in the "child getting out of the car" scenario shown in Figure 4A. Therefore, if the triggering condition for the "child getting out of the car" scenario is met, the action information from the three scenarios will be executed in a loop, following the order of "opening the window when the second-row left child lock is on" scenario and "closing the second-row left window after 5 seconds". In this case, a loop conflict is considered to exist between the "child getting out of the car" scenario and the "opening the window when the second-row left child lock is on" and "closing the second-row left window after 5 seconds" scenarios.

[0126] Loop conflicts can lead to execution errors or execution disorder. According to the solution provided in the embodiments of this application, by detecting whether there is a loop conflict between the first scenario and at least one second scenario and providing a conflict prompt, users can modify the scenario settings in a timely manner based on the conflict prompt to avoid the occurrence of loop conflicts.

[0127] In one implementation, determining whether there is a loop conflict between a first scene and at least one second scene of the vehicle includes: identifying action information-trigger condition pairs in the first scene and at least one second scene, which consist of action information and trigger conditions belonging to different scenes; determining whether the identified at least one action information-trigger condition pair includes a negatively associated action information-trigger condition pair; if the at least one action information-trigger information pair does not include a negatively associated action information-trigger information pair, determining that there is a loop conflict between the first scene and at least one second scene.

[0128] In this context, a negative association between an action information and a trigger condition means that executing the action information causes the trigger condition to be unmet. Conversely, a positive association means that executing the action information causes the trigger condition to be met.

[0129] In this implementation, the relationships between action information and triggering conditions can be pre-marked and stored according to the service dimension (equivalent to subsystems on a vehicle, such as seat subsystems or door and window subsystems). These relationships are essentially the relationships between Actions and Events / Conditions. The relationships include associated Actions and Events / Conditions, as well as the association types between them, including positive and negative associations.

[0130] For example, referring to Figure 8, since the Action "Switch to P gear" is executed, the Event "When switched to P gear" is satisfied, so the Action "Switch to P gear" and the Event "When switched to P gear" are positively correlated. Since the Action "Switch to P gear" is executed, the Condition "Currently in D gear" is not satisfied, so the Action "Switch to P gear" and the Condition "Currently in D gear" are negatively correlated.

[0131] For example, "Set temperature 20℃" as an Action and "When temperature > 15℃" as an Event are positively correlated.

[0132] Combining the "child getting out of the car" scenario shown in Figure 4A, the "opening the window when the second row left child lock is opened" scenario shown in Figure 1J, and the "closing the second row left window after 5 seconds" scenario shown in Figure 2D, for example, for the "door and window" subsystem, the association between Action and Event includes the association shown in Table 1, and the association between Action and Condition includes the association shown in Table 2.

[0133] Table 1

[0134] Table 2

[0135] Based on the association between Action and Event / Condition, the action information-trigger condition pairs identified in the first scene and at least one second scene, and the backhaul conflict detection rules, it can be determined whether a loop conflict exists between the first scene and at least one second scene. The backhaul conflict detection rules can be understood as follows: if there is a negatively correlated action information-trigger condition pair among the identified action information-trigger condition pairs, then there is no loop conflict; otherwise, a loop conflict exists.

[0136] Assuming the first scenario is the "child getting out of the car" scenario shown in Figure 4A, and at least one second scenario is the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J and the "closing the second-row left window after 5 seconds" scenario shown in Figure 2D, then the identified action information-trigger condition pairs, consisting of action information and trigger conditions belonging to different scenarios, are shown in Figure 9. Since all three action information-trigger condition pairs shown in Figure 9 are positively correlated, meaning there are no negatively correlated action information-trigger condition pairs, there is a loop conflict between the first scenario and at least one second scenario.

[0137] Upon detecting a loopback conflict, the server can output a first conflict warning message. Based on this message, the vehicle or terminal device displays the corresponding user interface, such as interface 40 as shown in Figure 4B. Users can modify the scene to be created based on the content of the warning box 401a in interface 40, thus avoiding conflicts between scenes.

[0138] In some embodiments, conflicts between scenarios include conflicts involving repeated execution.

[0139] Accordingly, S720 may include: determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario.

[0140] Repeated execution conflict means that the action information for the same object is executed multiple times within a preset control time interval.

[0141] Action information for the same object includes, for example: opening and closing a music app; turning on and off the radio; raising and lowering the suspension; opening and closing the driver's side window; and heating and ventilating the passenger seat.

[0142] The aforementioned action information for the same object includes action information from the same non-mechanical control and action information from the same mechanical control. In one example, if the same non-mechanical control action information is executed multiple times within a preset control time interval, the user is allowed to create a first scene. If the same mechanical control action information is executed multiple times within a preset control time interval, the user is not allowed / prohibited from creating a first scene.

[0143] In this embodiment, allowing a user to create a first scenario can be understood as the vehicle successfully saving / adding the first scenario based on a user-triggered save / add. Disallowing / prohibiting a user from creating a first scenario can be understood as the vehicle failing to successfully save / add the first scenario based on a user-triggered save / add.

[0144] If the same mechanical control action information is executed multiple times within a preset control time interval, i.e., frequently controlling the same machine within a time period shorter than the preset control time interval, it may cause mechanical failure and affect the machine's lifespan. For example, frequently raising and lowering the suspension within a short period of time may cause suspension failure. In this embodiment, by detecting whether there is a repeated execution conflict between the first scene and the at least one second scene and providing a conflict warning, the user can adjust the scene settings in a timely manner to avoid repeated execution conflicts, thereby preventing mechanical failures caused by repeated execution conflicts.

[0145] In one implementation, determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario includes: obtaining multiple execution time intervals associated with third action information, and determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario based on the multiple execution time intervals.

[0146] Among them, the execution time interval associated with an action information indicates that the action information is executed after a delay of the execution time interval, and the third action information is the action information for the same object in the first scene and the at least one second scene, and the third action information includes at least two different action information.

[0147] For example, if the first scenario is the "suspension height adjustment greater than 40 yards" scenario shown in Figure 5A, and at least one second scenario is the "suspension height adjustment less than 40 yards" scenario shown in Figure 5B, then the third action information is the action information in Figure 5A and the action information in Figure 5B, and the execution time interval between the action information in Figure 5A and the action information in Figure 5B is 0.

[0148] For example, if the first scenario is the scenario shown in Figure 2D, and at least one second scenario is the scenario shown in Figure 1J, then the third action information is "the left side of the second row of windows is closed" in Figure 2D and the action information in Figure 1J. The execution time interval associated with "the left side of the second row of windows is closed" in Figure 2D is 5 seconds, and the execution time interval associated with the action information in Figure 1J is 0.

[0149] In one example, determining whether there is a duplicate execution conflict between a first scenario and at least one second scenario based on the multiple execution time intervals includes: determining whether there is a duplicate execution conflict between the first scenario and at least one second scenario based on the multiple execution time intervals and a preset control time interval; if the average of the multiple execution time intervals is greater than the preset control time interval, determining that there is a duplicate execution conflict between the first scenario and at least one second scenario.

[0150] In the above scheme, if the average of multiple execution time intervals is greater than the preset control time interval, it indicates that the control time interval of the object corresponding to the third action information is greater than the preset control time interval; if the average of multiple execution time intervals is less than or equal to the preset control time interval, it indicates that the object corresponding to the third action information is frequently controlled to execute related action information within the preset control time interval. The following example, with a preset control time interval of 150 seconds, illustrates the above scheme.

[0151] For example, the first scenario is the "suspension height adjustment greater than 40 yards" scenario shown in Figure 5A, and at least one second scenario is the "suspension height adjustment less than 40 yards" scenario shown in Figure 5B. Since the execution time intervals of these multiple scenarios are all 0, it is considered that there is a duplicate execution conflict between the first scenario and at least one second scenario.

[0152] For example, the first scenario is the "suspension height adjustment greater than 40 yards" scenario shown in Figure 5A, and at least one second scenario is the "suspension height adjustment less than 40 yards with a 100-second delay" scenario shown in Figure 10. The third action information consists of the action information in the "suspension height adjustment greater than 40 yards" scenario shown in Figure 5A and the "suspension height high" information in the "suspension height adjustment less than 40 yards with a 100-second delay" scenario shown in Figure 10. Since the execution time interval associated with the action information in the "suspension height adjustment greater than 40 yards" scenario shown in Figure 5A is 0, and the execution time interval associated with "suspension height high" information in the "suspension height adjustment less than 40 yards with a 100-second delay" scenario shown in Figure 10 is 100 seconds, the average execution time interval associated with the two third action information is 100 seconds, which is less than the preset control time interval. Therefore, it is considered that there is a duplicate execution conflict between the first scenario and at least one second scenario.

[0153] For example, the first scenario is the "suspension height adjustment with a 100-second delay when the speed is less than 40 yards" scenario shown in Figure 10, and at least one second scenario is the "suspension height adjustment with a 240-second delay when the speed is greater than 40 yards" scenario shown in Figure 11. The third action information consists of "suspension height high" in the "suspension height adjustment with a 100-second delay when the speed is less than 40 yards" scenario shown in Figure 10 and "suspension height low" in the "suspension height adjustment with a 240-second delay when the speed is greater than 40 yards" scenario shown in Figure 11. The execution time interval associated with "suspension height high" in the "suspension height adjustment with a 100-second delay when the speed is less than 40 yards" scenario shown in Figure 10 is 100 seconds, and the execution time interval associated with "suspension height low" in the "suspension height adjustment with a 240-second delay when the speed is greater than 40 yards" scenario shown in Figure 11 is 240 seconds. The average execution time interval associated with the two third action information is 170 seconds, which is greater than the preset control time interval. Therefore, it is considered that there is no duplicate execution conflict between the first scenario and at least one second scenario.

[0154] If a duplicate execution conflict is detected, the server can output a first conflict warning message. Based on this message, the vehicle or terminal device displays the corresponding user interface, such as interface 53 as shown in Figure 5C. Users can avoid conflicts between scenes by modifying the scene to be created based on the content in the prompt box 531a in interface 53.

[0155] In one possible implementation, in the event of a conflict of repeated execution, the first conflict warning message also indicates a risk of mechanical failure.

[0156] For example, referring to Figure 5C, the prompt box 531a includes the information indicating a risk of mechanical failure: "There is a risk of mechanical failure."

[0157] According to this prompt, users can modify the scene settings to avoid potential mechanical failures.

[0158] In summary, the vehicle scenario risk detection method provided in this application can detect conflicts between scenarios during the scenario creation process, such as loop conflicts and repeated execution conflicts. When conflicts are detected between scenarios, a conflict notification can inform the user, allowing them to modify the scenario to be created and eliminate the conflicts. Based on this solution, the user experience during scenario creation can be improved, enhancing the user's perception of the intelligence of the vehicle's infotainment system.

[0159] This application also provides a system architecture as shown in Figure 12. The system architecture shown in Figure 12 will be described below, and the method 700 described above will be further explained in conjunction with the system architecture shown in Figure 12.

[0160] Figure 12 is a schematic diagram of another system architecture provided in this application. Referring to Figure 12, the system architecture includes a scene orchestration unit 1210 and a scene engine 1220.

[0161] The scene arrangement unit 1210 is used for: (1) providing an editing interface, where users can create scenes and modify scenes to be created based on the editing interface; (2) sending scenes (i.e., scene scripts) to the scene engine 1220 at appropriate times; (3) receiving conflict detection results from the scene engine 1220 and prompting the results to the user, such as receiving the first prompt information and displaying the first prompt information to the user.

[0162] In one implementation, the scene engine 1220 receives a scene sent by the scene orchestration unit 1210 and performs scene conflict detection by default. In another implementation, when sending a scene to the scene engine 1220, the scene orchestration unit 1210 also sends a conflict detection request, and the scene engine 1220 responds to the conflict detection request and performs conflict detection based on the received scene.

[0163] The scene engine 1220 is used to detect conflicts between scenes and send the conflict detection results to the scene orchestration unit 1210, such as sending the first prompt message.

[0164] It should be noted that the first prompt message sent by the scene engine 1220 is a code, and the first prompt message displayed by the scene orchestration unit 1210 is the user interface corresponding to the code.

[0165] In some embodiments, the scene orchestration unit 1210 may be deployed in the vehicle 610 shown in FIG6.

[0166] In some embodiments, the scene engine 1220 can be deployed on the server 620 shown in FIG6, and method 700 can be executed.

[0167] In some embodiments, the scene engine 1220 may include a scene risk detection unit 1221 and a rule base 1222.

[0168] The scene risk detection unit 1221 can be used to: (1) parse the script of the scene from the scene orchestration unit 1210; (2) perform conflict detection in combination with predefined detection rules; and (3) feed back the detection results to the scene orchestration unit 1210.

[0169] Rule base 1222: Can be configured in advance to store ECA rule definitions and conflict detection rules.

[0170] Figure 13 is a schematic flowchart illustrating the vehicle scenario risk detection method provided in this application, based on the system architecture shown in Figure 12. The method 1300 shown in Figure 13 will be described below.

[0171] S1301, the scene orchestration unit sends the first scene to the scene risk detection unit.

[0172] S1302, the scene risk detection unit receives the first scene from the scene orchestration unit.

[0173] In some embodiments, when the scene orchestration unit sends the first scene, it also sends the at least one second scene. Accordingly, the scene risk detection unit receives the at least one second scene.

[0174] In some embodiments, the at least one second scenario is stored in a server, and the scenario risk detection unit can obtain the at least one second scenario from the server.

[0175] The timing for sending the first scene is the same as the timing for acquiring the first scene described in S710, which can be referred to in S710. The timing for sending the at least one second scene is the same as the timing for sending the first scene.

[0176] Assuming the first scenario is the "child getting out of the car" scenario shown in Figure 4A, in one example, the first scenario sent by the scenario orchestration unit is as follows:

[0177] "scenarioName":"Child disembarking",

[0178] S1303, the scenario risk detection unit sends a request message to the rule base, which is used to request ECA rule definitions and conflict detection rules.

[0179] S1304, the rule base receives the request message from the scenario risk detection unit.

[0180] S1305, the rule base sends ECA rule definitions and conflict detection rules to the scenario risk detection unit.

[0181] Specifically, in response to the request information in S1304, the rule base sends ECA rule definitions and conflict detection rules to the scenario risk detection unit.

[0182] For example, the ECA rule definition includes the relationship between Action and Event shown in Table 1 and the relationship between Action and Condition shown in Table 2. The conflict rule definition includes the postback conflict detection rules described above.

[0183] For example, the ECA rule definition includes the content shown in Table 3. The conflict rule definition includes repetitive execution conflict detection rules. For instance, a repetitive execution conflict detection rule might state: if the average of multiple execution time intervals associated with the third action information is greater than a preset control time interval, then there is a repetitive execution conflict between the first scenario and at least one second scenario; otherwise, there is no repetitive execution conflict between the first scenario and at least one second scenario. For details on repetitive execution conflict detection rules, please refer to the previously described methods for detecting repetitive execution conflicts.

[0184] Table 3

[0185] S1306, the scenario risk detection unit receives ECA rule definitions and conflict detection rules from the rule base.

[0186] S1307, the scenario risk detection unit detects whether there is a conflict between the first scenario and the at least one second scenario according to the ECA rule definition and conflict detection rules.

[0187] For details on this step, please refer to the explanation of S720 above; it will not be repeated here.

[0188] S1308, the scenario risk detection unit generates a first prompt message based on the detection of whether there is a conflict between the first scenario and the at least one second scenario.

[0189] For example, the first prompt information may include the detection result, conflict type, conflict's ECA capability, conflict description information, and suggested solutions. The detection result, conflict type, conflict's ECA capability, conflict description information, and suggested solutions can be seen in Table 4, for example.

[0190] Table 4

[0191] For example, taking the first scenario as the "child getting out of the car" scenario shown in Figure 4A, and at least one second scenario as the "opening the window when the second-row left child lock is open" scenario shown in Figure 1J and the "closing the second-row left window after it has been open for 5 seconds" scenario shown in Figure 2D, the first prompt information is as follows:

[0192] S1309, the scene risk detection unit sends the first prompt information to the scene orchestration unit.

[0193] S1310, the scene orchestration unit receives the first prompt information from the scene risk detection unit.

[0194] S1311, the scene arrangement unit displays the first prompt information to the user.

[0195] According to the vehicle scenario risk detection method provided in this application, by detecting loop conflicts and repeated execution conflicts between scenarios and providing conflict prompts during the creation of vehicle scenarios, the user experience during scenario creation can be improved, and the user's sense of intelligence in using the vehicle system can be enhanced.

[0196] The preceding text described a scheme for risk detection between scenarios. In one design, conflict detection and warnings can be provided during the creation of a vehicle scenario. For example, during the creation of any of the second scenarios described earlier, i.e., for the second scenario to be created, the system can detect whether there are any conflicts within the second scenario. If there are no conflicts within the second scenario to be created, the second scenario to be created is saved / added, and at this point, the second scenario to be created is considered created. If there are conflicts within the second scenario to be created, the user can modify the second scenario to eliminate the conflicts, thus obtaining the created second scenario.

[0197] For example, Figures 14A to 14D illustrate a scenario diagram for triggering scenario conflict detection and providing conflict prompts. Referring to Figure 14A, interface 1400 shows the "Second Row Seating" scenario that the user is currently creating, in which the trigger condition "Passenger Seat Seat" and the action information "Passenger Seat Moved to the Back" have been added. The user clicks the "Add Task" option 1400a. In response to the user's click on the "Add Task" option 1400a, the in-vehicle device displays interface 1401 as shown in Figure 14B. Interface 1401 includes card 1401-1. The user clicks the "Seat Position" option 1401-1a in card 1401-1, and the in-vehicle device displays interface 1402 as shown in Figure 14C. Interface 1402 includes card 1402-1. The user can select and combine functions by sliding up and down on card 1402-1. For example, the user selects "Second Row Right Zero Gravity" and "Expand," and then clicks the "OK" control 1402-1a. The user's click on the "OK" control 1402-1a triggers a conflict detection process between the pending trigger conditions / actions and the already added trigger conditions / actions in the "Second Row Seating" scenario. Because there is a conflict between the pending and added trigger conditions / actions in the "Second Row Seating" scenario, the in-vehicle device displays interface 1403 as shown in Figure 14D. Interface 1403 includes a card 1403-1, and the content of the prompt box 1403-1a in card 1403-1 is a prompt message, which allows the user to understand the conflict situation.

[0198] Furthermore, based on the prompts, users can modify the scene configuration to avoid conflicts within the scene. For example, a user can click the "Cancel" control 1403-1b. In response to clicking the "Cancel" control 1403-1b, the vehicle-mounted device will display the interface 1400 shown in Figure 14A. The user can then re-add action information by clicking the "Add Task" option 1400a in the interface 1400.

[0199] For example, Figures 15A and 15B illustrate another scenario diagram for triggering scenario conflict detection and providing conflict prompts. Referring to Figure 15A, interface 1500 shows the "Second Row Left Child Lock" scenario that the user is currently creating. This scenario has already added the trigger condition "Second Row Left Child Lock Open" and two action information entries "Second Row Left Window Open" and "Second Row Left Window Close." The user clicks the "Save" control 1500a, triggering conflict detection between the added trigger conditions and / or action information in the "Second Row Left Child Lock" scenario. Because there is a conflict between the trigger conditions and / or action information in the "Second Row Left Child Lock" scenario, the in-vehicle device displays interface 1501 as shown in Figure 15B. Interface 1501 includes a card 1501-1, and the content of the prompt box 1501-1a in card 1501-1 is a prompt message, allowing the user to understand the conflict situation.

[0200] Furthermore, based on the prompts, users can modify scene configurations to avoid conflicts within the scene. For example, a user can click the "Return to Modify" control 1501-1b. In response to this click, the in-vehicle device will display interface 1503 as shown in Figure 15C. Interface 1503 is identical to interface 1500. For instance, if a user wants to modify the action information "Second row of windows on the left side closed," they can click option 1503a to make the modification.

[0201] For example, Figures 16A to 16C illustrate another scenario diagram for triggering scenario conflict detection and providing conflict prompts. Referring to Figure 16A, when a user clicks control 1600a in interface 1600, in response to the click of control 1600a, the in-vehicle device displays interface 1601 as shown in Figure 16B. The "Relax in the Car" scenario shown in interface 1601 is the officially recommended scenario. When the user clicks the "Add" control 1601a, conflict detection is triggered between the trigger conditions and / or action information already added in the "Relax in the Car" scenario. Because there is a conflict between the trigger conditions and / or action information in the "Relax in the Car" scenario, the in-vehicle device displays interface 1602 as shown in Figure 16C. Interface 1602 includes card 1602-1, and the content of the prompt box 1602-1a in card 1602-1 is a prompt message, which allows the user to know the conflict situation.

[0202] Furthermore, based on the prompts, users can modify the scene configuration to avoid conflicts within the scene. For example, a user can click the "Return to Modify" control 1602-1b. In response to clicking the "Return to Modify" control 1602-1b, the vehicle-mounted device will display interface 1601 as shown in Figure 16B, where the user can modify the action information.

[0203] It should be noted that the trigger condition in the "Get on the bus and relax" scenario is user-triggered, that is, the trigger condition of the "Get on the bus and relax" scenario is met when the user clicks control 1601b.

[0204] The following example illustrates the method for detecting conflicts within a scene, using the example of detecting whether there are conflicts within scene A to be created. It should be understood that scene A to be created can be a scene that occurs during the creation of any of the second scenes described above.

[0205] Figure 17 is a schematic flowchart of the vehicle scenario risk detection method provided in this application. The following explanation uses the execution of method 1700 by a server as an example to illustrate each step of method 1700.

[0206] S1710, during the creation of scenario A, obtain the first information and the second information.

[0207] The first information is information that has been added to the first scene, and the second information is information that is to be added to the first scene. The first information includes a fourth trigger condition and / or a fourth action information. When the fourth trigger condition is met, the fourth action information is executed. The second information includes a fifth trigger condition or a fifth action information.

[0208] For example, scenario A is the "second row seating" scenario being created as shown in Figure 14A. The first information is the trigger condition "passenger seat taken" and the action information "passenger seat moved to the back" that have been added to the "second row seating" scenario. The second information is the action information "second row right zero gravity unfolding" that has been added to the "second row seating" scenario as shown in Figure 14C.

[0209] It should be noted that Figure 14A shows the case where the information added to the scene consists of a trigger condition and an action information. In practice, the information added to the scene can be an action information, a trigger condition, or both. Similarly, Figure 14C shows the case where the information to be added to the scene is an action information. In reality, the information to be added to the scene can also be a trigger condition.

[0210] In some embodiments, in response to a user's action of determining to add second information as a trigger condition or action information for scenario C, the server acquires the first information and the second information. For example, in response to a user clicking the "OK" control 1402-1a as shown in Figure 14C, the server acquires the first information and the second information.

[0211] S1720, determine whether there is a conflict between the first information and the second information.

[0212] S1730, if there is a conflict between the first information and the second information, output the second conflict prompt information.

[0213] It is understood that the second conflict warning message indicates a conflict between the first and second pieces of information. After the vehicle or terminal device receives the second conflict warning message, it can display the message on the screen.

[0214] Those skilled in the art will understand that the second conflict warning information obtained by the vehicle or terminal device is a code, and the second conflict warning information displayed on the screen is the user interface information corresponding to the code.

[0215] In some embodiments, the second conflict alert information includes information about the existence of a conflict and / or suggestions for resolving the conflict.

[0216] For example, see the prompt box 1403-1a shown in Figure 14D. The content of the prompt box 1403-1a is the second conflict prompt information. The conflicting information is "There is a risk of squeezing when the second row right zero gravity seat is unfolded and the front passenger seat is moved to the back". The suggestion to resolve the conflict is "Adjustment is recommended".

[0217] In some embodiments, if there is a conflict between the first information and the second information, the user-triggered determination to add the second information as a trigger condition or action information for scenario C fails.

[0218] According to the vehicle scenario risk detection method provided in this application, by detecting and alerting users to conflicts within a scenario during the scenario creation process, the user experience during scenario creation can be improved, and the user's sense of intelligence in using the vehicle system can be enhanced.

[0219] The following is a detailed description of S1720.

[0220] In some embodiments, S1720 specifically includes: determining that there is a conflict between the first information and the second information if one or more of the following conditions are met:

[0221] (1) The fifth action information cannot be executed if the fourth triggering condition is met;

[0222] (2) The fourth triggering condition and the fifth triggering condition are mutually exclusive;

[0223] (3) The execution of the fourth action information makes the fifth action information unexecutable.

[0224] For example, the fourth trigger condition is "the front passenger seat is moved to the back", and the fifth action information is "the second row right zero gravity unfolds". When "the front passenger seat is moved to the back" is met, "the second row right zero gravity unfolds" cannot be executed. Therefore, there is a conflict between the first and second information.

[0225] For example, the fourth trigger condition is "the second row left window is open" and the fifth trigger condition is "the second row left window is closed". Since the above two trigger conditions are mutually exclusive, that is, the above two trigger conditions cannot be met at the same time, there is a conflict between the first information and the second information.

[0226] For example, the fourth action information is "move the front passenger seat to the back" in interface 1400 shown in Figure 14A, and the fifth action information is "second row right zero gravity unfold" in interface 1402 shown in Figure 14C. Since the execution of "move the front passenger seat to the back" makes "second row right zero gravity unfold" impossible to execute, there is a conflict between the first and second information.

[0227] In one implementation, the dependency relationship between action information and the state of the dependent object of the action information can be predefined. If the object corresponding to the fourth triggering condition is the dependent object of the fifth action information, and the dependency relationship between the fourth triggering condition and the fifth action information is a negative dependency, then it is determined that there is a conflict between the fourth triggering condition and the fifth action information.

[0228] The dependencies include positive and negative dependencies. A negative dependency between an action and the state of its dependent object means that the action cannot be executed when the vehicle is in the state of the dependent object. A positive dependency between an action and the state of its dependent object means that the action can be executed when the vehicle is in the state of the dependent object.

[0229] The object corresponding to the fourth trigger condition refers to the object associated with the fourth trigger condition. For example, if the fourth trigger condition is "move the front passenger seat to the back", then the object corresponding to the fourth trigger condition is the front passenger seat. Similarly, if the fourth trigger condition is "open the second-row left window", then the object corresponding to the fourth trigger condition is the second-row left window.

[0230] For example, Table 5 shows an example of the correspondence between actions (i.e., action information), dependent objects (the objects that the action information depends on), the states of dependent objects, and the dependencies.

[0231] Table 5

[0232] Referring to Table 5, the "second row zero-gravity deployment" depends on the front passenger seat. When the front passenger seat is in the "last" position, the "second row zero-gravity deployment" cannot be executed. Therefore, if the fourth trigger condition is "front passenger seat moved to the last position" and the fifth action information is "second row right zero-gravity deployment", there is a conflict between the first and second information.

[0233] In one implementation, the dependency relationship between action information and the state of the objects that depend on the action information can be predefined. If the state after the fourth action information is executed makes the dependency relationship between the fifth action information and the state after the fourth action information is executed negative, then it is determined that there is a conflict between the fourth action information and the fifth action information.

[0234] For example, the correspondence shown in Table 5 can be predefined, and the content shown in Table 6 can be predefined.

[0235] Table 6

[0236] Referring to Table 6, the execution of "moving the front passenger seat to the back" makes the front passenger seat state "back". Referring to Table 5, the front passenger seat being back is negatively dependent on "second row right zero gravity unfold". Therefore, if the fourth action information is "moving the front passenger seat to the back" and the fifth action information is "second row right zero gravity unfold", then there is a conflict between the first and second information.

[0237] In some embodiments, S1720 specifically includes: determining whether the fourth action information and the fifth action information are action information for the same object; if the fourth action information and the fifth action information are action information for the same object, determining that there is a conflict between the first information and the second information; or, if the fourth action information and the fifth action information are different action information for the same object, and the execution time interval between the fourth action information and the fifth action information is less than a preset control time interval, then determining that there is a conflict between the first information and the second information.

[0238] For example, if the fourth and fifth action information are both action information related to the suspension, such as both being to raise the suspension, then it is determined that there is a conflict between the first and second information.

[0239] For example, the fourth action information is to raise the suspension, and the fifth action information is to lower the suspension, and the fifth action information is set to be executed 100 seconds after the fourth action information is executed (that is, the execution time interval between the fourth and fifth action information is 100 seconds). Then, if the preset control time interval is greater than 100 seconds, it is determined that there is a conflict between the first and second information.

[0240] The aforementioned action information for the same object includes action information from the same non-mechanical control and action information from the same mechanical control. In one example, if the execution time interval of the same non-mechanical control action information is less than a preset control time interval, the user is allowed to add a fifth action information. If the execution time interval of the same mechanical control action information is less than a preset control time interval, the user is not allowed / prohibited from adding a fifth action information. This avoids mechanical failures caused by repeated execution within a short period of time.

[0241] Optionally, the second conflict warning message also indicates a risk of mechanical failure.

[0242] The previous section described a scheme that triggers a conflict detection between the first and second pieces of information when adding second information. Unlike the scheme described earlier, in one design, the server can determine whether a conflict exists in scenario A based on the user's action of creating scenario A.

[0243] That is, in response to a user's action to create scenario A, the server can determine whether scenario A has a conflict. Scenario A includes at least two triggering conditions and at least one action information; the at least one action information is executed when both triggering conditions are met. Alternatively, scenario A includes at least one triggering condition and at least two action information; the at least two action information is executed when the at least one triggering condition is met. Both the action information and the triggering conditions mentioned above are information that has already been added to scenario A.

[0244] Scene A can be created in any of the ways described above, such as by creating scene A in a custom way, adding scene A shared by other users as your own scene via a share code, or adding scene A recommended by the official website as your own scene.

[0245] For example, scenario A could be the "second row left child lock" scenario shown in Figure 15A, and the user operation to create scenario A could be the user clicking the "save" control 1500a as shown in Figure 15A.

[0246] For example, scenario A could be the "Get on the bus and relax" scenario shown in Figure 16B, and the user operation to create scenario A could be the user clicking the "Add" control 1601a as shown in Figure 16B.

[0247] In some embodiments, determining whether a conflict exists in scenario A includes: determining that a conflict exists in scenario A if scenario A satisfies one or more of the following: (1) there is at least one triggering condition in scenario A that makes at least one action information unexecutable; (2) there are mutually exclusive triggering conditions in scenario A; (3) the execution of one action information in scenario A causes the other action information to become unexecutable.

[0248] For example, in scenario A, one of the trigger conditions is "the front passenger seat is moved to the back" and one of the action information is "the second row right zero gravity unfolds". Since "the front passenger seat is moved to the back" makes "the second row right zero gravity unfolds" impossible to execute, there is a conflict in scenario A.

[0249] For example, scenario A includes the triggering conditions "second row left window open" and "second row left window closed". Since the two triggering conditions are mutually exclusive, meaning that the two triggering conditions cannot be met at the same time, scenario A has a conflict.

[0250] For example, scenario A is the "get in the car and relax" scenario shown in Figure 16B. Since the execution of "moving the front passenger seat to the back" in this scenario makes it impossible to execute "the second row right side zero gravity unfolding", there is a conflict in scenario A.

[0251] Regarding how to determine whether there is a conflict between the triggering condition and the action information, as well as whether there is a conflict between the action information and the action information, you can refer to the methods for judging the conflict between the fourth triggering condition and the fifth action information, as well as the methods for judging the conflict between the fourth action information and the fifth action information, which will not be repeated here.

[0252] In some embodiments, determining whether a conflict exists in scenario A includes: if scenario A includes multiple action information for the same object, or if scenario A includes multiple action information for the same object and the average execution time interval between the multiple action information is less than a preset control time interval, then it is determined that a conflict exists in scenario A.

[0253] For example, scenario A is the "second row left child lock" scenario shown in Figure 16A. Since this scenario includes two action information for the second row left window, it is determined that scenario A has a conflict.

[0254] For example, scenario A includes two actions: raising the suspension and lowering the suspension. The suspension is set to lower after 100 seconds of raising (i.e., the execution time interval between the two actions is 100 seconds). If the preset control time interval is greater than 100 seconds, then scenario A is determined to have a conflict.

[0255] The aforementioned action information for the same object includes action information from the same non-mechanical control and action information from the same mechanical control. In one example, if the execution time interval of the same non-mechanical control action information is less than a preset control time interval, the user is allowed to save / add scene A. If the execution time interval of the same mechanical control action information is less than a preset control time interval, the user is not allowed / prohibited from saving / adding scene A. This avoids mechanical failures caused by repeated execution within a short period of time.

[0256] Optionally, the second conflict warning message also indicates a risk of mechanical failure.

[0257] Figure 18 is a schematic flowchart illustrating the vehicle scenario risk detection method provided in this application, based on the system architecture shown in Figure 12. Method 1800 is a specific example based on method 1700, and method 1800 shown in Figure 18 will be described below.

[0258] S1810, the scene orchestration unit sends scene A to the scene risk detection unit.

[0259] Sending Scene A means sending the trigger conditions and action information that have already been added to Scene A, as well as the trigger conditions and action information that are to be added to Scene A.

[0260] Sending scenario A could be triggered by the user adding the second piece of information described above, or by the user saving or adding scenario A.

[0261] For example, in response to the user clicking the "OK" control 1402-1a as shown in Figure 14C, the scene orchestration unit sends scene A to the scene risk detection unit.

[0262] For example, in response to the user clicking the "Save" control 1500a as shown in Figure 15A, the scene orchestration unit sends scene A to the scene risk detection unit.

[0263] For example, in response to the user clicking the "Add" control 1601a as shown in Figure 16B, the scene orchestration unit sends scene A to the scene risk detection unit.

[0264] S1820, the scene risk detection unit receives scene A from the scene orchestration unit.

[0265] In one example, the first scene sent by the scene orchestration unit is as follows (see Figures 14A to 14C):

[0266] S1830, the scenario risk detection unit sends a request message to the rule base, which is used to request ECA rule definitions and conflict detection rules.

[0267] S1840, the rule base sends ECA rule definitions and conflict detection rules to the scenario risk detection unit.

[0268] Specifically, in response to the request information in S1830, the rule base sends ECA rule definitions and conflict detection rules to the scenario risk detection unit.

[0269] For example, the ECA rule definition includes actions (i.e., action information), dependent objects (the objects that the action information depends on), the states of dependent objects, and the correspondence between dependencies, as well as the correspondence between objects, actions, and their post-execution states. For example, the correspondence between actions, dependent objects (the objects that the action information depends on), the states of dependent objects, and dependencies includes the content shown in Table 5, and the correspondence between objects, actions, and their post-execution states includes the content shown in Table 6.

[0270] Conflict detection rules include, for example: Conflict detection rule (1) If there is action information and triggering condition with negative dependency in the scene, then there is a conflict in the scene; Conflict detection rule (2) If there is action information in the scene that makes the state after execution negatively dependent on another action information, then there is a conflict in the scene.

[0271] For example, Figures 19 and 20 illustrate the two conflict detection rules mentioned above.

[0272] For example, referring to Figures 14D and 16C, the scene hit conflict detection rule (2) determines that a conflict exists in the scene.

[0273] S1850, the scenario risk detection unit detects whether there is a conflict between the first scenario and the at least one second scenario, according to the ECA rule definition and conflict detection rules.

[0274] For details on this step, please refer to the explanation of S1720 above; it will not be repeated here.

[0275] S1860, the scene risk detection unit generates a second prompt message based on the detection of whether there is a conflict in scene A.

[0276] For example, the second prompt information may include the detection result, conflict type, conflict ECA capability, conflict description information, and suggested solutions. The detection result, conflict type, conflict ECA capability, conflict description information, and suggested solutions can be found in Table 4 above.

[0277] For example, in a conflict detection scenario triggered by the user clicking the "OK" control 1402-1a as shown in Figure 14C, the second prompt message is as follows:

[0278] S1870, the scene risk detection unit sends a second prompt message to the scene orchestration unit.

[0279] S1880, the scene arrangement unit displays a second prompt to the user.

[0280] According to the vehicle scenario risk detection method provided in this application, by performing conflict detection and providing conflict prompts during the creation of vehicle scenarios, the user experience during scenario creation can be improved, and the user's sense of intelligence in using the vehicle system can be enhanced.

[0281] It should be noted that when a user modifies the trigger conditions or action information in an existing scene, it is also considered that the user has created a scene, and the user's operation will trigger conflict detection within the scene. For example, referring to Figure 21A, the user can modify the action information "move the second row right zero gravity seat to the back" by clicking option 2100a in interface 2100. For example, after the user clicks control 2100a, the in-vehicle device displays interface 2101 as shown in Figure 21B. Interface 2101 includes card 2101-1. After the user selects "second row right zero gravity" and "expand" in card 2101-1 and clicks the "OK" control 2101-1a, conflict detection is triggered between "expand the second row right zero gravity seat" and other information in the scene. Referring to Figure 21C, since "expand the second row right zero gravity seat" conflicts with "move the front passenger seat to the back", the in-vehicle device displays interface 2102, and the information in the prompt box 2102-1a in interface 2102 is a prompt message. Users can learn about the conflict based on the prompts, and then modify the information in the scene accordingly to eliminate the conflict.

[0282] It should be understood that the user interface and method flowcharts involved in the embodiments of this application are only to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the embodiments of this application. Based on the above examples, those skilled in the art can obviously make various equivalent modifications or changes. For example, some steps in the above process (method embodiments) may be unnecessary, or new steps may be added, etc. Alternatively, any combination of two or more of the above embodiments may be used. Such modifications, changes, or combinations also fall within the scope of the embodiments of this application.

[0283] It should also be understood that the methods, situations, categories, and classifications of embodiments in this application are for the convenience of description only and should not constitute a special limitation. Various methods, categories, situations, and features in embodiments can be combined without contradiction.

[0284] It should also be understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0285] It should also be understood that the above description of the embodiments of this application focuses on highlighting the differences between the various embodiments. Any similarities or differences not mentioned can be referred to each other. For the sake of brevity, they will not be repeated here.

[0286] According to the above method embodiments, various devices (including servers) can be divided into functional modules. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules 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; other division methods may be used in actual implementation.

[0287] It should be noted that the relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0288] The vehicle-mounted device, terminal device, or server provided in this application embodiment may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the actions of the vehicle-mounted device, terminal device, or server. The storage module can be used to support the storage of program code and data. The communication module can be used to support communication between the vehicle-mounted device, terminal device, or server and other devices.

[0289] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can 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. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other devices.

[0290] This application provides a vehicle scene risk detection device, which is used to perform the steps involved in the vehicle scene risk detection method provided in this application.

[0291] For example, the device may be a server, a terminal device, or a vehicle-mounted device.

[0292] This application provides a vehicle scenario risk detection system, which is used to perform the steps involved in the vehicle scenario risk detection method provided in this application.

[0293] For example, the system may include a server and an in-vehicle device. For instance, the server may perform the operations performed by the server in the aforementioned method embodiments, and the in-vehicle device may perform the operations performed by the in-vehicle device in the aforementioned method embodiments.

[0294] Figure 22 is a schematic diagram of the structure of an in-vehicle device, terminal device, or server provided in an embodiment of this application. This in-vehicle device, terminal device, or server can perform the operations executed in any of the foregoing method embodiments.

[0295] As shown in Figure 22, the vehicle-mounted device, terminal device or server 2200 may include a processor 2210, a memory 2220, a communication module 2230, a sensor module 2240 and a display screen 2250.

[0296] Processor 2210 may include one or more processing units. For example, processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0297] The memory 2220 is used to store program code and data. In this embodiment, the processor 2210 can execute the program code stored in the memory 2220 to manage the vehicle-mounted device, terminal device, or server 2200.

[0298] The communication module 2230 may include one or more of the following: audio devices, radio frequency circuits, Bluetooth chips, wireless fidelity (Wi-Fi) chips, and near-field communication (NFC) modules, and can enable interaction between the vehicle-mounted device, terminal device, or server 2200 and other devices in a variety of different ways.

[0299] The sensor module 2240 may include a gyroscope sensor 180B, a barometric pressure sensor 180C, an accelerometer sensor 180, a distance sensor, etc.

[0300] The display screen 2250 can display text, images, or videos from the human-computer interaction interface, such as the scenes and prompts provided in the embodiments of this application. The display screen 2250 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), a quantum dot light-emitting diode (QLED), or the like.

[0301] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the vehicle-mounted device, terminal device, or server 2200. In other embodiments of this application, the vehicle-mounted device, terminal device, or server 2200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0302] The vehicle-mounted equipment, terminal equipment, or server 2200 shown in Figure 22 can be, but is not limited to, being mounted on. Operating system, etc.

[0303] For example, the following describes an in-vehicle device, terminal device, or server 2200 equipped with... Taking the operating system as an example, the software structure of the vehicle-mounted device, terminal device, or server 2200 will be illustrated.

[0304] Figure 23 is a software structure block diagram of the vehicle-mounted device, terminal device or server 2200 according to an embodiment of this application.

[0305] The software structure of the vehicle-mounted equipment, terminal equipment, or server 2200 can adopt a layered architecture. The layered architecture can divide the software into several layers, each with a clear role and division of labor; the layers can communicate with each other through software interfaces.

[0306] In some embodiments, it can be The system is divided into four layers, from top to bottom: application layer, application framework layer, Android runtime (...). The runtime and system libraries, as well as the kernel layer, are all part of the application layer. The application layer can include a series of application packages.

[0307] As shown in Figure 23, the application package may include applications such as calendar, calling, navigation, Bluetooth, and music.

[0308] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0309] As shown in Figure 23, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0310] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0311] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0312] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0313] The phone manager is used to provide communication functions for in-vehicle devices, terminal devices, or server 2200. For example, it manages call status (including connection and disconnection).

[0314] File Explorer provides applications with various resources, such as icons, images, layout files, video files, and more.

[0315] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating the device, and flashing indicator lights.

[0316] The runtime includes the core libraries and the virtual machine. The runtime is responsible for scheduling and management of the Android system.

[0317] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0318] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0319] The system library can include multiple functional modules, such as: surface manager, media libraries, 3D graphics processing libraries (e.g., Open Graphics Library for Embedded Systems, OpenGL ES) and 2D graphics engines (e.g., Skia Graphics Library, SGL).

[0320] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0321] The media library supports playback and recording of various audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, Moving Picture Experts Group Audio Layer III (MP3), Advanced Audio Coding (AAC), Adaptive Multi-rate (AMR), Joint Photographic Experts Group (JPG), and Portable Network Graphics (PNG).

[0322] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0323] A 3D graphics engine is a graphics engine for 3D drawing.

[0324] The kernel layer is the layer between hardware and software. The kernel layer contains at least display drivers, audio drivers, and sensor drivers.

[0325] This application also provides a chip system, as shown in FIG24, which includes at least one processor 2401 and at least one interface circuit 2402. The processor 2401 and the interface circuit 2402 can be interconnected via lines. For example, the interface circuit 2402 can be used to receive signals from other devices. As another example, the interface circuit 2402 can be used to send signals to other devices (e.g., the processor 2401). Exemplarily, the interface circuit 2402 can read instructions stored in memory and send the instructions to the processor 2401. When the instructions are executed by the processor 2401, the various steps performed by the server or vehicle-mounted device in the above embodiments can be executed. Optionally, the chip system may also include other discrete devices, which are not specifically limited in this application.

[0326] This application also provides an apparatus included in an in-vehicle device, which has the function of implementing the in-vehicle device behavior of any of the above embodiments. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes at least one module or unit corresponding to the above function.

[0327] This application also provides an apparatus included in a server, which has the function of implementing the server behavior of any of the above embodiments. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes at least one module or unit corresponding to the above function.

[0328] It should also be understood that the division of units in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, all units in the device can be implemented entirely through software calls from processing elements; all units can be implemented entirely in hardware; or some units can be implemented through software calls from processing elements, while others are implemented in hardware. For example, each unit can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as a program in memory, and its function can be called and executed by a processing element within the device. Here, the processing element can also be called a processor, which can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above units can be implemented through integrated logic circuits in the processor element or through software calls from processing elements. In one example, a unit in any of the above devices can be one or more integrated circuits configured to implement the methods described above, such as one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these forms of integrated circuits. As another example, when a unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Furthermore, these units can be integrated together to implement a system-on-a-chip (SOC).

[0329] This application also provides a server, which includes a processor and a memory. The memory is used to store instructions, and the processor is used to read the instructions to execute any of the above-described method embodiments.

[0330] This application also provides an in-vehicle device, which includes a processor and a memory. The memory is used to store instructions, and the processor is used to read the instructions to execute any of the above-described method embodiments.

[0331] This application also provides a terminal device, which includes a processor and a memory. The memory is used to store instructions, and the processor is used to read the instructions to execute any of the above-described method embodiments.

[0332] This application also provides a computer-readable storage medium for storing computer programs or instructions, which, when executed, cause the steps performed by the in-vehicle device, server, or terminal device in any of the embodiments provided in this application to be executed. Exemplarily, the computer-readable medium may be a read-only memory (ROM) or a random access memory (RAM), and this application does not limit this.

[0333] This application also provides a computer program product including instructions that, when executed, cause the steps performed by the vehicle-mounted device, server, or terminal device in any of the above embodiments to be performed.

[0334] This application also provides a chip, including: a processor for calling and running a computer program from a memory, such that the steps performed by the vehicle-mounted device, server, or terminal device in any of the above embodiments are executed.

[0335] Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0336] This application embodiment can divide the above-mentioned vehicle-mounted equipment, server, or terminal equipment into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0337] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. 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. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

[0339] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0340] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope 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 method for detecting vehicle scene risks, characterized in that, include: The vehicle's first scene is obtained. The first scene is a scene to be created. The first scene includes at least one first trigger condition and at least one first action information. The at least one first action information is executed when all at least one first trigger condition is met. Determine whether there is a conflict between the first scenario and at least one second scenario of the vehicle, wherein the at least one second scenario is an already created scenario, and the second scenario includes at least one second trigger condition and at least one second action information, and executes the at least one second action information when all at least one second trigger condition is met; If there is a conflict between the first scenario and the at least one second scenario, a first conflict warning message is output.

2. The method as described in claim 1, characterized in that, Determining whether there is a conflict between the first scenario and at least one second scenario of the vehicle includes: Determine whether there is a loop conflict between the first scenario and the at least one second scenario. The loop conflict means that the execution of the target first action information in the at least one first action information leads to the execution of the target second action information in the at least one second action information, and the execution of the target second action information leads to the execution of the target first action information.

3. The method as described in claim 2, characterized in that, Determining whether a loop conflict exists between the first scenario and the at least one second scenario includes: Identify action information-trigger condition pairs in the first scenario and the at least one second scenario, which consist of action information and trigger conditions belonging to different scenarios; Determine whether the identified at least one action information-trigger condition pair includes a negatively associated action information-trigger condition pair. A negatively associated action information-trigger condition pair indicates that the execution of the action information causes the trigger condition to be unsatisfied. If the at least one action information-trigger condition pair does not include a negatively associated action information-trigger condition pair, it is determined that there is a loop conflict between the first scenario and the at least one second scenario.

4. The method as described in claim 1, characterized in that, Determining whether there is a conflict between the first scenario and the at least one second scenario includes: Determine whether there is a repetitive execution conflict between the first scenario and the at least one second scenario, wherein the repetitive execution conflict means that action information for the same object is executed multiple times within a preset control time interval.

5. The method as described in claim 4, characterized in that, Determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario includes: Multiple execution time intervals associated with third action information are obtained. An execution time interval associated with one action information indicates that the action information is executed after a delay of the execution time interval. The third action information is action information for the same object in the first scenario and the at least one second scenario. The third action information includes at least two different action information. Based on the multiple execution time intervals, determine whether there is a duplicate execution conflict between the first scenario and the at least one second scenario.

6. The method as described in claim 5, characterized in that, Determining whether there is a duplicate execution conflict between the first scenario and the at least one second scenario based on the plurality of execution time intervals includes: Based on the plurality of execution time intervals and the preset control time interval, it is determined whether there is a repeated execution conflict between the first scenario and the at least one second scenario; If the average of the multiple execution time intervals is greater than the preset control time interval, it is determined that there is a repeated execution conflict between the first scenario and the at least one second scenario.

7. The method as described in claim 5 or 6, characterized in that, The first conflict warning message indicates a risk of mechanical failure.

8. The method according to any one of claims 1-7, characterized in that, The first conflict notification includes information about the existence of a conflict and / or suggestions for resolving the conflict.

9. The method according to any one of claims 1-8, characterized in that, Before determining whether a conflict exists between the first scenario and at least one second scenario of the vehicle, the method further includes: During the creation of the second scene, first information and second information are obtained. The first information is information that has been added to the first scene, and the second information is information to be added to the first scene. The first information includes a fourth trigger condition and / or a fourth action information. When the fourth trigger condition is met, the fourth action information is executed. The second information includes a fifth trigger condition or a fifth action information. Determine whether there is a conflict between the first information and the second information; If there is a conflict between the first information and the second information, a second conflict prompt message will be output.

10. The method as described in claim 9, characterized in that, Determining whether there is a conflict between the first information and the second information includes: A conflict is determined to exist between the first information and the second information if one or more of the following conditions are met: The fifth action information cannot be executed if the fourth triggering condition is met, the fourth triggering condition and the fifth triggering condition are mutually exclusive, or the execution of the fourth action information makes the fifth action information unexecutable.

11. The method as described in claim 9, characterized in that, When the first information includes the fourth triggering condition, determining whether there is a conflict between the first information and the second information includes: Determine whether the fourth action information and the fifth action information are action information targeting the same object; If the fourth action information and the fifth action information are action information targeting the same object, it is determined that there is a conflict between the first information and the second information; or... If the fourth action information and the fifth action information are different action information for the same object, and the execution time interval between the fourth action information and the fifth action information is less than the preset control time interval, it is determined that there is a conflict between the first information and the second information.

12. The method according to any one of claims 1-8, characterized in that, Before determining whether a conflict exists between the first scenario and at least one second scenario of the vehicle, the method further includes: In response to the user action that creates the second scenario, determine whether there is a conflict in the second scenario.

13. The method as described in claim 12, characterized in that, Determining whether a conflict exists in the second scenario includes: The second scenario is determined to be conflicting if one or more of the following conditions are met: The second scenario has at least one triggering condition that makes at least one action information unexecutable, the second scenario has mutually exclusive triggering conditions, or the execution of one action information in the second scenario causes the other action information to become unexecutable.

14. The method as described in claim 12, characterized in that, Determining whether a conflict exists in the second scenario includes: Determine whether the second scenario includes multiple action information targeting the same object; If the second scenario includes multiple action information for the same object, or if the second scenario includes multiple action information for the same object and the average execution time interval between the multiple action information is less than the preset control time interval, it is determined that there is a conflict in the second scenario.

15. A vehicle scenario risk detection device, characterized in that, The apparatus includes units for performing the steps of the method as described in any one of claims 1-14.

16. A server, characterized in that, The server includes a processor and a memory, the memory being used to store instructions, and the processor being used to read the instructions to perform the method as described in any one of claims 1-14.

17. A vehicle-mounted device, characterized in that, The vehicle-mounted device includes a processor and a memory, the memory being used to store instructions, and the processor being used to read the instructions to perform the method as described in any one of claims 1-14.

18. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory being used to store instructions, and the processor being used to read the instructions to execute the method as described in any one of claims 1-14.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed, cause the method as described in any one of claims 1-14 to be performed.

20. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, such that the method as described in any one of claims 1-14 is performed.

21. A computer program product, characterized in that, It includes computer program instructions, which, when executed, cause the method as described in any one of claims 1-14 to be performed.

Images