Intelligent cabin cross-domain interaction conflict arbitration method and system

Abstract

The application discloses an intelligent cockpit cross-domain interaction conflict arbitration method and system, relates to the field of vehicle cockpits, and comprises the following steps: receiving a multi-source control request; the multi-source control request is respectively disassembled into the smallest non-disassembled function atom, and a standardized label is attached to each function atom; collecting a vehicle real-time scene state; according to the standardized label of the function atom and the scene state, the dynamic priority of each function atom is calculated through a multi-factor dynamic priority calculation model; global cross-domain dependence and conflict analysis is performed on all function atoms to identify the conflict and coupling relationship between the function atoms; according to the dynamic priority and the conflict and coupling relationship, a unified arbitration decision is made on the conflicting function atoms to generate an execution strategy; the execution strategy is issued to an executor, and an execution feedback returned by the executor is received.

Description

Technical Field

[0001] This application relates to the field of vehicle cockpits, and more particularly to intelligent cockpit cross-domain interaction conflict arbitration methods, intelligent cockpit cross-domain interaction conflict arbitration systems, electronic devices, storage media, and vehicle cockpits. Background Technology

[0002] 1. Currently, most intelligent cockpits employ the following technical approaches to handle interaction conflicts:

[0003] 1) The intelligent cockpit cross-domain interaction conflict arbitration system and the functional domain-level intelligent cockpit cross-domain interaction conflict arbitration system are used as the arbitration granularity, for example, setting overall priorities for "window control function", "air conditioning control function" and "door lock control function"; 2) The intelligent cockpit cross-domain interaction conflict arbitration system and the interaction method-level intelligent cockpit cross-domain interaction conflict arbitration system are used as the arbitration objects, for example, agreeing that "physical buttons take precedence over voice, and voice takes precedence over touch screen"; 3) The intelligent cockpit cross-domain interaction conflict arbitration system determines the final execution request through the static priority table of the intelligent cockpit cross-domain interaction conflict arbitration system; 4) When a conflict occurs, a simple strategy of "high priority over low priority" or "later request over earlier request" is adopted; 5) The arbitration scope is mainly limited to the cockpit domain, and rarely includes cross-domain requests from the intelligent driving domain, body domain, power domain, etc.; 6) There is no clear mapping relationship between safety level and arbitration decision.

[0004] 2. Core problems with existing technologies for intelligent cockpit cross-domain interaction conflict arbitration systems:

[0005] 1) The arbitration granularity is too coarse, making it impossible to distinguish actions with different risk levels under the same function; 2) The priority rules are static and fixed, making them unable to adapt to dynamic vehicle conditions; 3) It only supports simple coverage and lacks the ability to manage conflicts throughout the entire process; 4) It cannot be adapted to cross-domain collaborative control under the central computing platform; 5) Arbitration is separated from functional safety, resulting in a high risk of single point of failure. Summary of the Invention

[0006] The purpose of this invention is to provide a method for arbitrating cross-domain interaction conflicts in an intelligent cockpit, an intelligent cockpit cross-domain interaction conflict arbitration system, an electronic device, a storage medium, and a vehicle cockpit, thereby solving at least one of a number of technical problems.

[0007] Core technical challenges: 1. How to reduce traditional functional domain-level arbitration to the smallest indivisible functional atomic-level arbitration; 2. How to differentiate the handling of atomic actions based on their safety, reversibility, execution stage, and cross-domain dependencies; 3. How to dynamically adjust priorities when vehicle operating conditions, driving scenarios, and risk states change; 4. How to unify arbitration requests from the cockpit domain, intelligent driving domain, body domain, and power domain under a central computing platform; 5. How to balance safety, real-time performance, user experience, and fault controllability during the arbitration process.

[0008] This invention provides the following solution: According to a first aspect of the invention, a method for arbitrating cross-domain interaction conflicts in an intelligent cockpit is provided, comprising:

[0009] Q1: Receive multi-source control requests;

[0010] Q2: Decompose multi-source control requests into the smallest indivisible functional atoms and attach a standardized label to each functional atom;

[0011] Q3: Collect real-time vehicle scene status;

[0012] Q4: Based on the standardized labels of functional atoms and the scene state, calculate the dynamic priority of each functional atom using a multi-factor dynamic priority calculation model;

[0013] Q5: Perform global cross-domain dependency and conflict analysis on all functional atoms to identify the conflict and coupling relationships between functional atoms;

[0014] Q6: Based on dynamic priority and conflict and coupling relationships, make unified arbitration decisions on conflicting functional atoms to generate execution strategies;

[0015] Q7: Send the execution strategy to the executor and receive the execution feedback returned by the executor.

[0016] Furthermore, the multi-source control requests are decomposed into the smallest indivisible functional atoms, including:

[0017] Map a single user interaction request to a single functional atom;

[0018] The cross-domain composite control request is broken down into multiple independent functional atoms. The composite control request includes the automatic parking preparation request, which is broken down into the folding rearview mirror atom, the window lock atom, and the mute prompt atom.

[0019] Furthermore, the multi-factor dynamic priority calculation model includes:

[0020] The calculation methods include: a calculation method combining basic priority and scenario correction; a calculation method using multi-factor weighted scoring; a calculation method combining hierarchical priority and threshold preemption; and a discrete decision-making method based on a rule engine.

[0021] Supports at least one calculation method.

[0022] Furthermore, a global cross-domain dependency and conflict analysis is performed on all functional atoms, including:

[0023] Mutual exclusion and conflict relationships within the same actuator; correlation relationships within the same safety consequence chain; subordinate relationships between master and slave atoms; relationships between preconditions and barrier conditions for actions; and timing synchronization window relationships for cross-domain actions.

[0024] Identify at least one relationship.

[0025] Furthermore, based on dynamic priorities and conflict and coupling relationships, a unified arbitration decision is made for conflicting functional atoms, including:

[0026] When a high-priority safe atom preempts a low-priority atom, if the low-priority atom has an interruptible attribute, the execution of the low-priority atom is terminated.

[0027] The corresponding low-priority atomic cache will retain its execution progress and context information.

[0028] Furthermore, including:

[0029] Multi-source control requests include control requests from at least two of the following domains: cockpit domain, intelligent driving domain, body domain, and power domain. The control requests originate from at least one of the following methods: physical buttons, voice interaction, touch interaction, gesture interaction, remote control via mobile phone, domain-triggered events, and cloud events.

[0030] Standardized labels include security level, interruptible flag, rollback flag, mergeable flag, execution phase, time constraint, and dependency constraint;

[0031] The scene status includes at least one of the following: vehicle speed, gear position, rain / wading status, driver assistance status, automatic parking status, and occupant status.

[0032] The input factors of the multi-factor dynamic priority calculation model include safety level factors, real-time risk factors, vehicle operating condition factors, input source factors, execution stage factors, timeliness factors, cross-domain dependency factors, and fault state factors.

[0033] It also includes updating the state of functional atoms based on execution feedback for priority recalculation and conflict re-arbitration.

[0034] According to a second aspect of the present invention, a smart cockpit cross-domain interaction conflict arbitration system is provided, comprising:

[0035] The access request module is used to receive multi-source control requests, which include control requests from at least two domains: cockpit domain, intelligent driving domain, body domain, and power domain.

[0036] The Atom Decomposition and Labeling Module is used to decompose multi-source control requests into the smallest indivisible functional atoms and attach standardized labels to each functional atom.

[0037] Scene perception module, used to collect real-time scene status of the vehicle;

[0038] The dynamic priority calculation module is used to calculate the dynamic priority of each functional atom based on the standardized label and scene state of the functional atom through a multi-factor dynamic priority calculation model.

[0039] The cross-domain dependency analysis module is used to perform global cross-domain dependency and conflict analysis on all functional atoms, and to identify the conflict and coupling relationships between functional atoms.

[0040] The arbitration decision module is used to make unified arbitration decisions on conflicting functional atoms based on dynamic priorities and conflict and coupling relationships, and generate execution strategies.

[0041] The execution feedback module is used to send the execution strategy to the executor and receive the execution feedback returned by the executor, and update the state of the functional atom according to the execution feedback.

[0042] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0043] The memory stores a computer program that, when executed by a processor, causes the processor to perform steps such as a method for cross-domain arbitration of intelligent cockpit interaction conflicts.

[0044] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs steps such as a method for cross-domain arbitration of intelligent cockpit interaction conflicts.

[0045] According to a fifth aspect of the present invention, a vehicle cabin is provided, comprising:

[0046] Electronic devices, steps for implementing methods such as cross-domain conflict arbitration in smart cockpit interactions;

[0047] The processor runs programs, and when the programs are running, they execute steps such as methods for cross-domain arbitration of conflicts in smart cockpit interactions from data output by electronic devices.

[0048] Storage medium used to store programs that, when running, execute steps such as cross-domain methods for resolving conflicts in smart cockpit interactions based on data output from electronic devices.

[0049] The above solution achieves the following beneficial technical effects:

[0050] This application refines the arbitration granularity down to the functional atom, making security control more precise: instead of sorting the "functional domain" as a whole, it arbitrates the smallest indivisible action atom, thus distinguishing actions of different risk levels under the same function and avoiding a one-size-fits-all approach.

[0051] This application uses dynamic priority calculation, which is more in line with real driving scenarios: it incorporates factors such as vehicle condition, risk level, input source, execution stage, time constraints, and cross-domain dependencies into the priority calculation, so that the priority is dynamically updated as the scenario changes, thereby automatically selecting a more reasonable execution object under different conditions.

[0052] This application establishes a cross-domain unified control framework to adapt to the evolution of the central computing platform: it converts control requests from the cockpit domain, intelligent driving domain, body domain, and power domain into a unified atomic model, and makes global decisions within the same arbitration framework, thereby improving multi-domain collaborative capabilities.

[0053] This application significantly reduces the security risks and state chaos caused by execution conflicts: by introducing atomic-level labels, dependency constraints and execution phase identification, it can avoid erroneous interruption of uninterruptible actions, erroneous delay of high-risk actions and erroneous disassembly of cross-domain compound actions.

[0054] This application provides a unified foundation for subsequent closed-loop processing and safety degradation: first, it completes "unified atomic modeling + dynamic priority calculation + cross-domain adjudication", and then seamlessly connects with the conflict closed-loop processing mechanism and functional safety degradation mechanism. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of a cross-domain dynamic arbitration system architecture for intelligent cockpit functional atoms provided in a specific embodiment of the present invention.

[0056] Figure 2 This is a schematic diagram illustrating the structure of a single functional atom attribute of an atomic tag provided in a specific embodiment of the present invention.

[0057] Figure 3 This is a schematic diagram illustrating the cross-domain process for the interaction conflict arbitration of an intelligent cockpit provided in a specific embodiment of the present invention.

[0058] Figure 4 This is a flowchart of a cross-domain interaction conflict arbitration method for intelligent cockpits provided by one or more embodiments of the present invention.

[0059] Figure 5 This is a structural diagram of a smart cockpit cross-domain interaction conflict arbitration system provided by one or more embodiments of the present invention.

[0060] Figure 6 This is an electronic device structural block diagram of an intelligent cockpit cross-domain interaction conflict arbitration method provided in one or more embodiments of the present invention. Detailed Implementation

[0061] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Figure 4 This is a flowchart of a cross-domain interaction conflict arbitration method for intelligent cockpits provided by one or more embodiments of the present invention.

[0063] like Figure 4 The cross-domain interaction conflict arbitration method for intelligent cockpits shown includes:

[0064] Q1: Receive multi-source control requests;

[0065] Q2: Decompose multi-source control requests into the smallest indivisible functional atoms and attach a standardized label to each functional atom;

[0066] Q3: Collect real-time vehicle scene status;

[0067] Q4: Based on the standardized labels of functional atoms and the scene state, calculate the dynamic priority of each functional atom using a multi-factor dynamic priority calculation model;

[0068] Q5: Perform global cross-domain dependency and conflict analysis on all functional atoms to identify the conflict and coupling relationships between functional atoms;

[0069] Q6: Based on dynamic priority and conflict and coupling relationships, make unified arbitration decisions on conflicting functional atoms to generate execution strategies;

[0070] Q7: Send the execution strategy to the executor and receive the execution feedback returned by the executor.

[0071] In this embodiment, the multi-source control request is decomposed into the smallest indivisible functional atom, including:

[0072] Map a single user interaction request to a single functional atom;

[0073] The cross-domain composite control request is broken down into multiple independent functional atoms. The composite control request includes the automatic parking preparation request, which is broken down into the folding rearview mirror atom, the window lock atom, and the mute prompt atom.

[0074] In this embodiment, the multi-factor dynamic priority calculation model includes:

[0075] The calculation methods include: a calculation method combining basic priority and scenario correction, a calculation method combining multi-factor weighted scoring, a calculation method combining hierarchical priority and threshold preemption, and a discrete decision-making method based on a rule engine. At least one calculation method is supported.

[0076] In this embodiment, a global cross-domain dependency and conflict analysis is performed on all functional atoms, including:

[0077] Identify at least one of the following relationships: mutual exclusion and conflict relationships within the same actuator, association relationships within the same safety consequence chain, subordinate relationships between master and slave atoms, relationships between preconditions and barrier conditions for actions, and temporal synchronization window relationships for cross-domain actions.

[0078] In this embodiment, based on dynamic priority and conflict and coupling relationships, a unified arbitration decision is made for conflicting functional atoms, including:

[0079] When a high-priority safe atom preempts a low-priority atom, if the low-priority atom has an interruptible attribute, the execution of the low-priority atom is terminated.

[0080] The corresponding low-priority atomic cache will retain its execution progress and context information.

[0081] In this embodiment, it includes:

[0082] Multi-source control requests include control requests from at least two of the following domains: cockpit domain, intelligent driving domain, body domain, and power domain. The control requests originate from at least one of the following methods: physical buttons, voice interaction, touch interaction, gesture interaction, remote control via mobile phone, domain-triggered events, and cloud events.

[0083] Standardized labels include security level, interruptible flag, rollback flag, mergeable flag, execution phase, time constraint, and dependency constraint;

[0084] The scene status includes at least one of the following: vehicle speed, gear position, rain / wading status, driver assistance status, automatic parking status, and occupant status.

[0085] The input factors of the multi-factor dynamic priority calculation model include safety level factors, real-time risk factors, vehicle operating condition factors, input source factors, execution stage factors, timeliness factors, cross-domain dependency factors, and fault state factors.

[0086] It also includes updating the state of functional atoms based on execution feedback for priority recalculation and conflict re-arbitration.

[0087] In this embodiment, it also includes:

[0088] When a fault is detected in the arbitration module, communication link, or execution feedback link, differentiated degradation processing is performed on the functional atom according to the fault level and the security level of the functional atom. Among them, the security-critical atom is executed through the minimum executable bypass path.

[0089] Specifically, in one embodiment, a smart cockpit interaction arbitration and conflict management method is disclosed, including: a cross-domain interaction conflict arbitration step, a conflict closed-loop processing step, and an arbitration downgrade step under fault conditions; the cross-domain interaction conflict arbitration step includes defining functional atoms to realize cross-domain interaction conflict arbitration; the conflict closed-loop processing step includes using functional atoms as processing units to perform interaction conflict management; the arbitration downgrade step under fault conditions includes using functional atoms as processing units to perform interaction fault arbitration management.

[0090] This application enables the achievement of the goal of cross-domain arbitration of interactive conflicts, and together with the arbitration downgrade step under failure and / or the cross-domain interactive conflict arbitration step, comprehensively ensures the stable interaction of the intelligent cockpit.

[0091] For example, in one specific embodiment, a method for cross-domain arbitration and fault degradation in a smart cockpit is disclosed, including:

[0092] P1: Receives multi-source control requests, breaks down the multi-source control requests into the smallest indivisible functional atoms, and attaches standardized attribute tags to each functional atom. The attribute tags include security level, interruptible flag, rollback flag, mergeable flag, execution stage, and time constraint.

[0093] P2: When the system is running normally, calculate the dynamic priority of each functional atom based on the attribute tags of the functional atoms and the real-time scene status of the vehicle, perform global cross-domain dependency and conflict analysis on all functional atoms, and execute a unified arbitration decision.

[0094] P3: When a system fault is detected, the severity level of the fault is determined. Based on the fault level and the safety level of the functional atom, a two-dimensional hierarchical degradation decision matrix is ​​used to perform differentiated degradation processing on different functional atoms, providing the minimum executable bypass path for safety-critical functional atoms to ensure that the execution of safety-critical actions is not interrupted.

[0095] For example, in one specific embodiment, a cross-domain arbitration and conflict closure method for intelligent cockpits is disclosed, including:

[0096] T1: Receives multi-source control requests, breaks down the multi-source control requests into the smallest indivisible functional atoms, and attaches standardized attribute tags to each functional atom. The attribute tags include security level, interruptible flag, rollback flag, mergeable flag, execution stage, and time constraint.

[0097] T2: When the system is running normally, calculate the dynamic priority of each functional atom based on the attribute tags of the functional atoms and the real-time scene status of the vehicle, perform global cross-domain dependency and conflict analysis on all functional atoms, and execute a unified arbitration decision.

[0098] T3: When an arbitration decision results in a conflict, based on the attribute label and execution stage of the conflicting functional atom, select differentiated closed-loop processing actions for the conflicting atom, record the conflict processing trajectory, and after the conflict is resolved, restore and re-evaluate the cached atom, and perform resume, compensation, or invalidation and discard processing.

[0099] For example, in one specific embodiment, a smart cockpit interaction arbitration and conflict management method is disclosed, including:

[0100] Y1: Receives multi-source control requests, breaks down the multi-source control requests into the smallest indivisible functional atoms, and attaches standardized attribute tags to each functional atom. The attribute tags include security level, interruptible flag, rollback flag, mergeable flag, execution stage, and time constraint.

[0101] Y2: When the system is running normally, calculate the dynamic priority of each functional atom based on the attribute tags of the functional atoms and the real-time scene status of the vehicle, perform global cross-domain dependency and conflict analysis on all functional atoms, and execute a unified arbitration decision.

[0102] Y3: When arbitration decisions result in conflict, based on the attribute tags and execution stages of the conflicting functional atoms, select differentiated closed-loop processing actions for the conflicting atoms, record the trajectory of conflict processing, and after the conflict is resolved, restore and re-evaluate the cached atoms, and perform resume, compensation, or invalidation and discard processing.

[0103] Y4: When a system fault is detected, the severity level of the fault is determined. Based on the fault level and the safety level of the functional atom, a two-dimensional hierarchical degradation decision matrix is ​​used to perform differentiated degradation processing on different functional atoms, providing the minimum executable bypass path for safety-critical functional atoms to ensure that the execution of safety-critical actions is not interrupted.

[0104] This embodiment may further include multi-source control requests, including control requests from at least two domains among the cockpit domain, intelligent driving domain, body domain, and power domain. The control requests may originate from at least one of physical buttons, voice interaction, touch interaction, gesture interaction, remote control via mobile phone, domain-triggered events, and cloud events.

[0105] Furthermore, it includes the calculation of dynamic priorities, which is achieved through a multi-factor dynamic priority calculation model. The input factors of the model include safety level factors, real-time risk factors, vehicle operating condition factors, input source factors, execution stage factors, timeliness factors, cross-domain dependency factors, and fault state factors.

[0106] This further includes global cross-domain dependency and conflict analysis, including identifying at least one of the following relationships:

[0107] Mutual exclusion and conflict relationships within the same actuator, association relationships within the same safety consequence chain, subordinate relationships between master and slave atoms, precondition / barrier conditions for actions, and timing synchronization window relationships for cross-domain actions.

[0108] Further, it includes closed-loop processing actions, including at least one of interruption, caching, resumption, rollback, and merging, wherein:

[0109] Interrupt action: Used to stop the current execution flow of a low-priority interruptible atom;

[0110] Cache action: Used to write interrupted atoms into the recovery buffer, preserving their execution progress, context information, and recovery conditions;

[0111] Resume action: Used to resume the execution of cached atoms from the point of interruption after the conflict is resolved;

[0112] Reverse rollback action: Used to perform reverse compensation action on reversible atoms that have been partially affected, so that the target object is restored to its state before the conflict.

[0113] Merge action: Used to merge multiple atoms with consistent target objects, compatible directions, and similar timeliness into a single execution atom.

[0114] Furthermore, this includes the execution phases of functional atoms, including the pre-execution phase, the execution phase, the commit phase, and the effective phase, with different conflict handling strategies corresponding to different execution phases:

[0115] In the pre-execution phase, rearrangement, merging, or cancellation of functional atoms are permitted;

[0116] During the execution phase, atoms with interruptible properties are allowed to be interrupted and cached;

[0117] During the submission phase, only preemption of safety-critical atoms is allowed, and interruption operations by non-safety-critical atoms are not permitted.

[0118] In the already effective phase, reverse compensation processing is performed on atoms with rollback attributes first.

[0119] Further, it includes reassessment, which involves performing at least one of the following checks on cached functional atoms: timeliness validity check, current scenario adaptability check, dynamic priority recalculation, and target state consistency check, to determine whether the atom is still suitable for the current vehicle operating state.

[0120] Further, it includes the severity level of the fault, including minor fault level, moderate fault level, and severe fault level; and the safety level of the functional atom, including safety critical level, safety related level, comfort function level, and entertainment function level.

[0121] Further, it includes a two-dimensional hierarchical degradation decision matrix, which is a decision matrix with fault severity level as the row and functional atom security level as the column. Each matrix unit corresponds to a differentiated execution strategy, which includes at least one of normal execution, bypass execution, frozen execution, delayed execution, and failure discard.

[0122] Furthermore, it includes a minimum executable bypass path, which is a dedicated short link designed for safety-critical atoms. This path has the characteristics of fewer dependent modules and a short decision link, and can bypass faulty modules in the main arbitration link to ensure that the execution of safety-critical actions is not interrupted.

[0123] Furthermore, once the fault is resolved, a gradual recovery strategy is implemented, restoring the execution capabilities of each function in the order of safety-critical functions, safety-related functions, comfort functions, and entertainment functions, to avoid introducing system instability through a one-time recovery.

[0124] Furthermore, it includes maintaining the state transition of each functional atom throughout its entire lifecycle, including the new state, pending execution state, conflict determination state, execution state, interrupted state, cached state, pending recovery state, rollback state, merged state, completed state, and expired state.

[0125] Furthermore, it includes recording the entire process trajectory and security audit logs, including conflict handling trajectory, degradation handling trajectory, and atomic state transition trajectory, for use in fault tracing, review, and functional safety compliance auditing.

[0126] Figure 5 This is a structural diagram of a smart cockpit cross-domain interaction conflict arbitration system provided by one or more embodiments of the present invention.

[0127] like Figure 5 The intelligent cockpit cross-domain interaction conflict arbitration system shown includes:

[0128] The access request module is used to receive multi-source control requests, which include control requests from at least two domains: cockpit domain, intelligent driving domain, body domain, and power domain.

[0129] The Atom Decomposition and Labeling Module is used to decompose multi-source control requests into the smallest indivisible functional atoms and attach standardized labels to each functional atom.

[0130] Scene perception module, used to collect real-time scene status of the vehicle;

[0131] The dynamic priority calculation module is used to calculate the dynamic priority of each functional atom based on the standardized label and scene state of the functional atom through a multi-factor dynamic priority calculation model.

[0132] The cross-domain dependency analysis module is used to perform global cross-domain dependency and conflict analysis on all functional atoms, and to identify the conflict and coupling relationships between functional atoms.

[0133] The arbitration decision module is used to make unified arbitration decisions on conflicting functional atoms based on dynamic priorities and conflict and coupling relationships, and generate execution strategies.

[0134] The execution feedback module is used to send the execution strategy to the executor and receive the execution feedback returned by the executor, and update the state of the functional atom according to the execution feedback.

[0135] In this embodiment, it also includes:

[0136] The bypass execution module is used to provide a minimal executable bypass path for safety-critical atoms when a system fault is detected, bypassing the main arbitration link to issue execution commands;

[0137] The security audit module is used to record the atomic safety level, fault level, execution strategy, and handling reasons during the arbitration process for traceability and review.

[0138] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0139] In one specific embodiment, control requests from different interaction sources and different vehicle domains are first mapped to one or more functional atoms. Then, dynamic priority calculation is performed based on atom labels, vehicle scene features, and cross-domain dependencies. Unified arbitration is performed on conflicting atoms, and the arbitration result is sent to the target actuator or downstream control module.

[0140] like Figure 1The cross-domain dynamic arbitration system architecture shown, oriented towards the functional atoms of the intelligent cockpit, may include at least:

[0141] 1. Access request module, used to receive control requests from the following sources: physical buttons, voice interaction, touch interaction, gesture interaction, remote control via mobile phone, intelligent driving domain trigger events, vehicle body domain control events, power domain control events, cloud service or policy events;

[0142] 2. The Atom Decomposition and Labeling Module is used to convert control requests into functional atoms and attach atomic tags to each functional atom. Preferred atomic tags include: atom_id; atom_type; target_object; operation_semantics; source_domain; source_mode; safety_level; interruptible_flag; reversible_flag; mergeable_flag; execution_stage; deadline; and dependency_constraint.

[0143] 3. Scene perception module, used to perceive and output the current vehicle operating scene, including but not limited to: vehicle speed; gear position; rain / wading status; driver assistance status; automatic parking status; driver attention status; door / window / rearview mirror status; and occupant status.

[0144] 4. A dynamic priority calculation module, used to calculate the dynamic priority of each functional atom based on the atom tag and scene information. Preferably, the dynamic priority can be determined by the following dimensions: P=f(S,R,C,M,E,T,D,F);

[0145] Wherein, S: safety level factor; R: real-time risk factor; C: vehicle operating condition factor; M: input source / interaction mode factor; E: execution phase factor; T: timeliness factor; D: cross-domain dependency factor; F: fault state factor.

[0146] Preferably, the system does not use a fixed single-value priority, but supports: basic priority + scenario correction amount; multi-factor weighted scoring; a combination of hierarchical priority and threshold preemption; and discrete decision-making based on a rule engine.

[0147] 5. Cross-domain dependency analysis module, used to construct dependency relationships between different atoms, including: conflict relationships between the same target executor; chain relationships of the same security consequences; master-slave atom relationships; precondition and barrier condition relationships; and timing synchronization window relationships.

[0148] 6. Arbitration decision module, used to determine the final execution order based on dynamic priority, dependency and execution stage, output: direct execution; delayed queuing; condition-triggered execution; enter closed-loop conflict handling; switch to fault-safe channel.

[0149] 7. The execution feedback module is used to receive the execution results from downstream processes and synchronize the execution status back to the atomic context, providing a basis for subsequent priority recalculation, execution resumption, and cross-domain linkage.

[0150] In another specific embodiment, the disclosure is as follows Figure 3 The interactive conflict arbitration process of the smart cockpit shown can realize a cross-domain process, which may include the following steps:

[0151] Step S1, Receive multi-source control requests: Receive multiple control requests from the cockpit domain, intelligent driving domain, body domain, powertrain domain, or external services.

[0152] Step S2, map control requests to functional atoms: break down each control request into one or more minimum indivisible functional atoms.

[0153] For example, "Open driver's side window 10%" is mapped to a single window opening atom; "Automatic parking preparation" can be broken down into multiple atoms such as "folding rearview mirror atom", "locking window atom", and "mute prompt atom".

[0154] Step S3: Attach semantic tags and execution context to the atoms: Attach information such as security level, execution stage, reversibility, interruptibility, source domain, target object, and time constraints to each atom.

[0155] Step S4: Collect scene status and calculate dynamic priority: Based on the real-time vehicle status and atomic attributes, generate the dynamic priority of each atom.

[0156] Step S5: Construct conflict and dependency relationships, and identify the following: whether they act on the same executor; whether they are mutually exclusive; whether they can be parallelized; whether there is a sequential dependency; and whether they belong to the same cross-domain composite task.

[0157] Step S6, perform unified arbitration: based on dynamic priority and dependency, adjudicate atoms with conflicting or coupled relationships, and output the target execution plan.

[0158] Step S7, issue execution results and update according to feedback: issue control commands and update atomic states after execution feedback is returned, for subsequent arbitration.

[0159] The embodiments of this application bring about beneficial technical effects:

[0160] 1) Atomic decomposition brings "refined security judgment"; because the arbitration object changes from the functional domain to the smallest action atom, the system can distinguish actions of different security levels in the same function.

[0161] 2) Dynamic priority enables “scenario-adaptive decision-making”; since the priority is determined by both the real-time scenario and atomic attributes, the system can automatically switch arbitration strategies between normal and emergency scenarios.

[0162] 3) Cross-domain dependency analysis brings "global consistency control"; by analyzing dependencies in a unified framework, conflicts, jitters and inconsistencies in the final state caused by independent decisions in different domains can be avoided.

[0163] 4) The execution feedback loop brings "sustainable scheduling capability"; the feedback result updates the atomic context in reverse, so that the system does not make a one-time decision, but can continuously perform dynamic recalculation and coordination.

[0164] Figure 6 This is an electronic device structural block diagram of an intelligent cockpit cross-domain interaction conflict arbitration method provided in one or more embodiments of the present invention.

[0165] like Figure 6 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0166] The memory stores a computer program that, when executed by a processor, causes the processor to perform steps of a cross-domain interaction conflict arbitration method for intelligent cockpits.

[0167] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a smart cockpit cross-domain interaction conflict arbitration method.

[0168] This application also provides a vehicle cabin, including:

[0169] Electronic devices used to implement steps for cross-domain interaction conflict arbitration methods in smart cockpits;

[0170] The processor runs a program that, when running, executes the steps of the intelligent cockpit cross-domain interaction conflict arbitration method based on data output from electronic devices.

[0171] Storage medium for storing programs that, when running, execute steps of a smart cockpit cross-domain interaction conflict arbitration method for data output from electronic devices.

[0172] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0173] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0174] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0175] Electronic devices can also obtain reset commands corresponding to storage media. These reset commands are provided by the supplier, and the reset commands for different storage media can be the same or different, which is not limited here.

[0176] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0177] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0178] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0179] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0180] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for arbitrating cross-domain interactive conflicts in an intelligent cockpit, characterized in that, include: Q1: Receive multi-source control requests; Q2: Decompose the multi-source control request into the smallest indivisible functional atom and attach a standardized label to each functional atom; Q3: Collect real-time vehicle scene status; Q4: Based on the standardized labels of the functional atoms and the scene state, calculate the dynamic priority of each functional atom using a multi-factor dynamic priority calculation model; Q5: Perform global cross-domain dependency and conflict analysis on all functional atoms to identify the conflict and coupling relationships between functional atoms; Q6: Based on the dynamic priority and the conflict and coupling relationship, a unified arbitration decision is made on the conflicting functional atoms to generate an execution strategy; Q7: Send the execution strategy to the executor and receive the execution feedback returned by the executor.

2. The intelligent cockpit cross-domain interaction conflict arbitration method according to claim 1, characterized in that, The step of decomposing the multi-source control request into the smallest indivisible functional atoms includes: Map a single user interaction request to a single functional atom; The cross-domain composite control request is decomposed into multiple independent functional atoms. The composite control request includes an automatic parking preparation request, which is decomposed into a folding rearview mirror atom, a window lock atom, and a mute prompt atom.

3. The intelligent cockpit cross-domain interaction conflict arbitration method according to claim 1, characterized in that, The multi-factor dynamic priority calculation model includes: The calculation methods include: a calculation method combining basic priority and scenario correction; a calculation method using multi-factor weighted scoring; a calculation method combining hierarchical priority and threshold preemption; and a discrete decision-making method based on a rule engine. Supports at least one calculation method.

4. The intelligent cockpit cross-domain interaction conflict arbitration method according to claim 1, characterized in that, The global cross-domain dependency and conflict analysis of all functional atoms includes: Mutual exclusion and conflict relationships within the same actuator; correlation relationships within the same safety consequence chain; subordinate relationships between master and slave atoms; relationships between preconditions and barrier conditions for actions; and timing synchronization window relationships for cross-domain actions. Identify at least one relationship.

5. The intelligent cockpit cross-domain interaction conflict arbitration method according to claim 1, characterized in that, The step of making a unified arbitration decision on conflicting functional atoms based on the dynamic priority and the conflict and coupling relationship includes: When a high-priority safe atom preempts a low-priority atom, if the low-priority atom has an interruptible attribute, the execution of the low-priority atom is terminated. The corresponding low-priority atomic cache is then used to retain its execution progress and context information.

6. The intelligent cockpit cross-domain interaction conflict arbitration method according to claim 1, characterized in that, include: The multi-source control request includes control requests from at least two of the following domains: cockpit domain, intelligent driving domain, body domain, and power domain. The control request originates from at least one of the following: physical button, voice interaction, touch interaction, gesture interaction, remote control via mobile phone, domain-triggered event, and cloud event. The standardized labels include security level, interruptible flag, rollback flag, mergeable flag, execution phase, time constraint, and dependency constraint; The scenario states include at least one of the following: vehicle speed, gear position, rain / wading status, driving assistance status, automatic parking status, and occupant status; The input factors of the multi-factor dynamic priority calculation model include safety level factors, real-time risk factors, vehicle operating condition factors, input source factors, execution stage factors, timeliness factors, cross-domain dependency factors, and fault state factors. It also includes updating the state of functional atoms based on execution feedback for priority recalculation and conflict re-arbitration.

7. A smart cockpit cross-domain interactive conflict arbitration system, characterized in that, include: The access request module is used to receive multi-source control requests, which include control requests from at least two domains among the cockpit domain, intelligent driving domain, body domain, and power domain. The atom decomposition and labeling module is used to decompose the multi-source control request into the smallest indivisible functional atom and attach a standardized label to each functional atom. Scene perception module, used to collect real-time scene status of the vehicle; The dynamic priority calculation module is used to calculate the dynamic priority of each functional atom based on the standardized label of the functional atom and the scene state through a multi-factor dynamic priority calculation model. The cross-domain dependency analysis module is used to perform global cross-domain dependency and conflict analysis on all functional atoms, and to identify the conflict and coupling relationships between functional atoms. The arbitration decision module is used to make unified arbitration decisions on conflicting functional atoms based on the dynamic priority and the conflict and coupling relationship, and generate an execution strategy. The execution feedback module is used to send the execution strategy to the executor, receive the execution feedback returned by the executor, and update the state of the functional atom according to the execution feedback.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the method for cross-domain arbitration of intelligent cockpit interaction conflicts as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the method for cross-domain arbitration of intelligent cockpit interaction conflicts as described in any one of claims 1 to 6.

10. A vehicle cabin, characterized in that, include: An electronic device for implementing the steps of the method for cross-domain arbitration of intelligent cockpit interaction conflicts as described in any one of claims 1 to 6; A processor that runs a program that, when the program is running, performs the steps of the method for cross-domain arbitration of intelligent cockpit interaction conflicts as described in any one of claims 1 to 6 from data output by an electronic device. A storage medium for storing a program that, when running, performs the steps of the cross-domain method for arbitrating intelligent cockpit interaction conflicts as described in any one of claims 1 to 6 on data output from an electronic device.

Images