A dual-domain hierarchical decoupling method and system

Abstract

The application discloses a kind of dual-domain layered decoupling method and system, suitable for two-wheel vehicle dual-domain controller architecture, for solving the problem of interface coupling between safety control domain and intelligent cabin domain, overreach access and cabin exception to safety control domain propagation. The method sets decoupling intermediate layer between safety control domain and intelligent cabin domain, converts wheel speed, inclination, brake state, fault code and risk level and other original safety data into standardized safety objects through data object model;Through permission white list, joint determination is carried out according to calling party, target object, interface, permission type, vehicle operating state, token condition and access frequency condition;Through interface arranger, dispatch, check or intercept cross-domain call;Through exception isolation module, switch to minimum interface set state or isolation state according to exception type, number and duration, so as to maintain basic instrument display and safety alarm output, and inhibit the propagation of cabin exception to safety control domain.

Description

Technical Field

[0001] This invention relates to the fields of electronic and electrical architecture for two-wheeled vehicles, dual-domain controllers, system security isolation, and cross-domain call control technology, and particularly to a hierarchical decoupling method and system for the safety control domain and the intelligent cockpit domain. Background Technology

[0002] As two-wheeled vehicles evolve towards intelligence and connectivity, they typically possess functions such as power control, braking control, attitude perception, fault diagnosis, navigation, voice interaction, media entertainment, and device interconnection. In existing solutions, safety control functions and intelligent cockpit functions are often deployed on the same controller or directly coupled through numerous point-to-point interfaces. When these functions are continuously superimposed, problems such as uncontrolled interface numbers, expanded scope of upgrade impacts, unauthorized access to security parameters by third-party applications, and the propagation of cockpit anomalies to the safety control side can easily arise. This is especially true for two-wheeled vehicles, which experience rapid tilt angle changes, limited stability margins, and high safety control priorities. If anomalies in the cockpit domain affect the safety control chain, it can easily lead to driving risks. Therefore, a technical solution is needed that achieves cross-domain decoupling, controlled access, and anomaly isolation at the system architecture level. Summary of the Invention

[0003] To address the problems of existing technologies, this invention proposes a technical solution that establishes a decoupling intermediate layer between the security control domain and the intelligent cockpit domain. This decoupling intermediate layer forms a controlled closed loop for cross-domain calls through a combination of object models, permission whitelists, interface orchestrators, anomaly isolation, and joint judgment rules. Compared to existing solutions that only perform interface forwarding or simple authentication, this invention first converts the raw security data output from the security control domain into standardized security objects, then performs access judgment based on the object, caller, interface, permission type, vehicle operating status, token conditions, and access frequency, and performs hierarchical isolation when the anomaly level changes, thereby simultaneously achieving security, scalability, and platform reusability.

[0004] This invention provides a dual-domain hierarchical decoupling method, the method comprising:

[0005] Establish a unified data object model, obtain the raw security data output by the security control domain, and convert the raw security data into standardized security objects according to preset object fields and preset mapping rules. The standardized security objects include at least object identifier, object type, object value, data source, timestamp, validity period and permission tag.

[0006] Configure a permission whitelist, which stores access control policies that limit the access permissions of different callers to the standardized security object and its corresponding interface. The access control policies include at least the caller identity, target object identifier, target interface, permission type, vehicle operating status conditions, token conditions, and access frequency conditions.

[0007] The interface orchestrator receives cross-domain call requests from the intelligent cockpit domain, extracts the target object, target interface, permission type, caller identity and token information from the cross-domain call request, and makes a joint determination based on the access control policy, current vehicle operating status, token conditions and access frequency conditions.

[0008] When the joint determination meets the release conditions, the standardized security object corresponding to the cross-domain call request is scheduled, and the object identifier, object type, object value range, data source, timestamp, validity period and permission tag of the standardized security object are verified. The standardized security object that passes the verification is delivered to the authorized display layer, interaction service layer or application orchestration layer in the intelligent cockpit domain. When the joint determination does not meet the release conditions, the cross-domain call request is intercepted and logged.

[0009] Monitor the abnormal state of the cross-domain call request during execution, determine the abnormal level according to the abnormal type, number of abnormalities and duration of abnormality, and based on the abnormal level and the current running state of the decoupling middle layer, switch the running state of the decoupling middle layer from the normal state to the minimum interface set state, or from the normal state or the minimum interface set state to the isolation state when an abnormality is detected.

[0010] Preferably, the joint determination based on the access control policy, current vehicle operating status, token condition, and access frequency condition includes:

[0011] After confirming that the caller's identity matches the caller's identity in the access control policy, it is determined whether the target object exists, whether the target interface belongs to the preset interface list, whether the permission type is allowed, whether the current vehicle operating status meets the vehicle operating status conditions, whether the token information meets the token conditions, and whether the access frequency of the cross-domain call request does not exceed the access frequency limit set by the access frequency conditions.

[0012] When all of the above conditions are met, the cross-domain call request is determined to meet the allow conditions; when any condition is not met, access is denied and a log is recorded including the caller's identity, target object, target interface, reason for denial, and time of occurrence.

[0013] Preferably, the step of converting the raw security data into a standardized security object includes:

[0014] Map the wheel speed to the speed field in the wheel speed object or state summary object according to the preset wheel speed range;

[0015] The tilt angle is mapped to an attitude field according to a preset tilt angle range, and a risk event object is generated when the tilt angle exceeds a preset tilt angle threshold;

[0016] Map the braking status to a braking field according to the enumeration rules of no braking, normal braking, and emergency braking;

[0017] Map fault codes to fault fields or alarm fields according to a preset fault level table;

[0018] The risk level output by the safety control domain, or the risk level determined according to preset risk rules based on wheel speed, tilt angle, braking status and fault code, is encapsulated as one or more of the following: risk event object, status summary object, instrument display object or alarm object.

[0019] Preferably, when the joint determination meets the release conditions, scheduling the standardized security object corresponding to the cross-domain call request includes:

[0020] The risk event object is delivered to the alarm entry in the smart cockpit domain, the status summary object is delivered to the instrument summary, and the object allowed by the permission whitelist is delivered to the presentation layer, the interaction service layer, or the application orchestration layer.

[0021] This invention provides a dual-domain hierarchical decoupling system, including a security control domain, an intelligent cockpit domain, and a decoupling intermediate layer disposed between the security control domain and the intelligent cockpit domain; the decoupling intermediate layer includes at least:

[0022] The data object model module is used to establish a unified data object model, obtain the raw security data output by the security control domain, and convert the raw security data into standardized security objects according to preset object fields and preset mapping rules.

[0023] The permission whitelist module is used to configure the permission whitelist, which stores access control policies that limit the access permissions of different callers to the standardized security object and its corresponding interface.

[0024] The interface orchestrator module is used to receive cross-domain call requests from the intelligent cockpit domain, extract the target object, target interface, permission type, caller identity and token information from the cross-domain call request, combine the access control policy, current vehicle operating status, token conditions and access frequency conditions to make a joint judgment, and schedule, verify or intercept the cross-domain call request according to the joint judgment result.

[0025] The exception isolation module is used to monitor the abnormal state of the cross-domain call request during execution, determine the exception level according to the exception type, number of exceptions and duration of exception, and, based on the exception level and the current running state of the decoupling middle layer, switch the running state of the decoupling middle layer from the normal state to the minimum interface set state, or from the normal state or the minimum interface set state to the isolation state when an exception is detected.

[0026] Preferably, the raw safety data includes at least one or more of wheel speed, camber angle, braking status, fault codes, and risk levels; the standardized safety objects include at least risk event objects, status summary objects, instrument display objects, and alarm objects.

[0027] Preferably, the permission whitelist module uses an object-caller-permission type mapping matrix to record the access control policy;

[0028] Each record in the mapping matrix includes at least the object identifier, interface identifier, caller identity, permission type, vehicle operating status conditions, token conditions, access frequency limit, and interface priority;

[0029] The permission types include read-only permission, conditional read-only permission, restricted write permission, debug permission, and prohibit permission;

[0030] The caller includes at least the presentation layer, the interaction service layer, the application orchestration layer, and third-party applications. The restricted write and debug permissions are only permitted when the vehicle is stationary or in maintenance mode, the token is valid, and the cross-domain call request is within a preset authorization time window. The restricted write permission is used for controlled writing of configuration objects, diagnostic objects, display strategy objects, or non-real-time parameter request objects in the decoupled intermediate layer, excluding direct writing of power output parameters, braking execution parameters, attitude stability control parameters, and fault protection thresholds. The access control policy, by default, prohibits third-party applications from reading security objects, writing control parameters, and accessing high-bandwidth debug interfaces.

[0031] Preferably, when performing joint determination, the interface orchestrator module, after confirming the identity matching of the caller, determines whether the target object exists, whether the target interface belongs to the preset interface list, whether the permission type is allowed, whether the current vehicle operating status meets the vehicle operating status conditions, whether the token information meets the token conditions, and whether the access frequency of the cross-domain call request does not exceed the access frequency limit set by the access frequency conditions; when all of the above determinations are met, the cross-domain call request is allowed; when any determination is not met, the cross-domain call request is intercepted and logged.

[0032] Preferably, the abnormal states monitored by the abnormal isolation module include at least unauthorized access, call timeout, interface storm, cumulative authentication failure exceeding the limit, cockpit domain restart anomaly, and high bandwidth service congestion.

[0033] Preferably, in the minimum interface set state, the decoupling intermediate layer only allows the basic instrument display interface, the basic alarm output interface, and the minimum necessary state object output interface to continue to work, and blocks the restricted write interface, the high bandwidth debugging interface, and the non-necessary object access interface.

[0034] In the isolated state, the decoupling middle layer blocks cross-domain calls from a preset list of non-critical interfaces. This list includes restricted write interfaces, high-bandwidth debugging interfaces, batch log upload interfaces, media data interfaces, third-party application object access interfaces, and other interfaces pre-marked as not belonging to the basic instrument display interface and basic alarm output interface. The decoupling middle layer rejects cross-domain data requests from non-critical applications and high-bandwidth services and sends a degradation instruction to the intelligent cockpit domain to cause the intelligent cockpit domain to suspend non-critical applications or high-bandwidth services.

[0035] The anomaly isolation module is also used to: enter the recovery state after the anomaly is resolved, and perform link self-check, object synchronization and permission reconstruction in the recovery state. Only after the link self-check, object synchronization and permission reconstruction are all passed will the running state of the decoupled intermediate layer be restored to the normal state.

[0036] Compared with existing technologies, the present invention has at least the following beneficial effects: First, by standardizing objects and layering interfaces, the point-to-point coupling between the security control domain and the intelligent cockpit domain is significantly reduced; second, by using object-caller-interface-state-token-frequency joint access determination, unauthorized access is restricted and boundary verifiability is improved; third, by using a hierarchical degradation mechanism of minimum interface set state and isolated state, cockpit anomalies are suppressed from propagating to the security control domain; fourth, by using link self-checking, object synchronization, and permission reconstruction in the recovery state, the risks of dirty data injection and blind recovery after anomaly resolution are reduced; fifth, by using a vehicle-independent object model and policy configuration method, the reusability of the dual-domain architecture across different vehicle models and different computing power platforms is improved; sixth, by retaining basic instrument displays and safety alarm outputs, the minimum set of safety functions required for driving can still be maintained under abnormal operating conditions. Attached Figure Description

[0037] Figure 1 This is a structural diagram of the hierarchical decoupling system of the present invention.

[0038] Figure 2 This is a schematic diagram of the permission whitelist matrix of the present invention.

[0039] Figure 3This is a diagram showing the abnormal isolation mode switching of the present invention.

[0040] Figure 4 This is a diagram illustrating the conversion of safety data to visible objects in the cockpit according to the present invention.

[0041] Figure 5 This is a flowchart of the present invention. Detailed Implementation

[0042] The inventive concept of this invention will be described below.

[0043] As two-wheeled vehicles evolve towards intelligence, their electronic and electrical architecture is gradually shifting towards a domain-centralized approach. In a dual-domain controller architecture, vehicles simultaneously perform two distinct types of tasks: one is real-time, high-safety-level control tasks such as power, braking, and attitude perception; the other is computationally intensive, rapidly iterating cockpit services such as navigation, voice control, and third-party applications. Traditional architectures typically handle cross-domain communication by using point-to-point direct connections at the lower-level interfaces or through simple gateways for message pass-through. This design leads to heavy coupling between domains. The continuous accumulation of cockpit domain functions not only risks an uncontrolled increase in the number of cross-domain interfaces, but more seriously, if a software anomaly, bus congestion, or unauthorized access by a third-party application occurs on the cockpit side, it can easily directly impact the underlying safety control link. Two-wheeled vehicles have limited physical stability margins and rapid tilt angle changes; even minor delays or anomalies in the control link can trigger serious driving risks.

[0044] To address the aforementioned systemic contradictions, the core concept of this invention lies in abandoning the traditional interface forwarding approach and shifting to an object-based defensive isolation architecture. At the communication boundary between the security control domain and the intelligent cockpit domain, a decoupled intermediate layer with independent scheduling and verification capabilities is introduced. This intermediate layer does not directly transport underlying bus data between the two domains, but rather acts as the sole legitimate proxy for cross-domain requests, reconstructing the cross-domain interaction order through three layers of logic: data masking, multi-dimensional authentication, and state machine degradation. The intelligent cockpit domain no longer directly accesses raw wheel speed, tilt angle, and other control messages, but instead obtains standardized objects transformed by the intermediate layer, such as risk event objects or state summary objects. This data semantic transformation fundamentally severs the upper-layer application's dependence on underlying hardware addresses and dedicated control protocols, reducing the system's security exposure. Simultaneously, cross-domain authentication is no longer limited to single caller authentication, but constructs a joint judgment matrix that includes the object, caller, interface, permission type, current vehicle operating status, token conditions, and access frequency. Even if a third-party application gains normal operating permissions on the cockpit side, its requests to read security objects, write low-level control parameters, or make calls under inappropriate driving conditions will be directly intercepted by the middle layer.

[0045] The present invention will be further described below with reference to the accompanying drawings, but the present invention is not limited to the following embodiments.

[0046] Example 1: Normal Operation Scenario. The safety control domain continuously collects wheel speed, tilt angle, braking status, and fault codes, and outputs them to the unified input terminal of the decoupled intermediate layer via domain interface proxy 114. The data object model module 131 normalizes and semantically encapsulates the raw data to form risk event objects and status summary objects. The interface orchestrator module 133, based on whitelist rules, outputs the allowed display status summary objects to the display layer 121 of the intelligent cockpit domain, and outputs alarm objects to the interaction service layer 122 for voice or visual prompts. In this scenario, third-party applications cannot directly read safety objects, raw bus messages, or directly access the control parameter write interface.

[0047] Example 2: Unauthorized Access Scenario. A third-party application in the intelligent cockpit domain attempts to call the control parameters of the security control domain to write the interface. The interface orchestrator module 133 first identifies the caller's identity, and then detects the object, target interface, permission type, and token information corresponding to the call request. Since the request does not meet the permission whitelist module 132's allowance conditions, the interface orchestrator module 133 denies access, logs the request, and reports the anomaly count. When the anomaly level reaches the first-level anomaly condition, the decoupling middle layer's operating state switches to the minimum interface set state, retaining only basic instruments, basic alarms, and the minimum necessary state objects.

[0048] Example 3: Continuous Anomaly Scenario. If cumulative call timeouts exceed limits, authentication failures continue, the number of requests per unit time exceeds the rate threshold, or an interface storm occurs in the cockpit domain, the anomaly isolation module 134 will escalate the anomaly level and further switch from the minimum interface set state to the isolation state. In the isolation state, interface calls in the preset non-critical interface list are blocked, cross-domain data requests from non-critical applications and high-bandwidth services are rejected, the decoupling middleware sends a degradation instruction to the intelligent cockpit domain, and the safety control domain continues to independently execute power control and safety control logic, thereby preventing anomaly propagation.

[0049] Example 4: Recovery Scenario. After the anomaly is resolved, the anomaly isolation module 134 triggers the recovery state, performing self-checks on link connectivity, object synchronization status, permission whitelist version, interface orchestration queue, and interface rate limit parameters. The system only restores the complete interface relationships when the link self-check, object synchronization, and permission reconstruction all pass.

[0050] Example 5: Cross-vehicle reuse scenario. For different vehicle models, the same decoupled middleware layer and interface orchestration logic can be reused, with adjustments only made to the object model mapping rules, whitelist matrix, risk level table, access frequency limit, and alarm display strategy based on vehicle model differences. This maintains consistency in core security boundaries while reducing platform development costs.

[0051] Combination Figure 1The diagram shows a hierarchical decoupling system architecture. The overall architecture of this system consists of three main functional blocks: a security control domain, a decoupling intermediate layer deployed at the core of the architecture, and an intelligent cockpit domain.

[0052] Within the security control domain on the left, its internal hierarchy, from top to bottom, comprises the 111 Sensing Acquisition Layer, 112 Control Strategy Layer, 113 Security Service Layer, and 114 Domain Interface Proxy. The 114 Domain Interface Proxy serves as the data output boundary for the security control side. It establishes a communication connection with the unified input terminal of the decoupled intermediate layer via a unidirectional solid arrow (as shown in the diagram). This unified input terminal then distributes the raw security data to the 131 Data Object Model Module and provides the cross-domain execution status to the 133 Interface Orchestrator Module and the 134 Anomaly Isolation Module.

[0053] The decoupled middleware layer contains four core control modules arranged in parallel: 131 Data Object Model, 132 Permission Whitelist, 133 Interface Orchestrator, and 134 Anomaly Isolation Module. These four modules collectively construct a secure proxy gateway for cross-domain communication and, based on their functional attributes, form clear unidirectional data delivery or control links with the four business layers within the right-hand intelligent cockpit domain. As shown by the solid arrows in the diagram, the 131 Data Object Model directs the converted data to the 121 Presentation Layer; the 132 Permission Whitelist's control policies apply to the 122 Interaction Service Layer; the 133 Interface Orchestrator's scheduling results are output to the 123 Application Orchestration Layer; and the 134 Anomaly Isolation Module outputs necessary degradation or isolation action commands to the 124 Device Adaptation Layer.

[0054] In the reverse cross-domain call chain, access requests initiated by the intelligent cockpit domain do not directly reach the security control domain. Instead, they are received by the decoupled intermediate layer and, after joint verification by the permission whitelist and interface orchestrator, a decision is made to allow or block them. This control logic is consistent with... Figure 1 The hierarchical boundaries between the security control domain, the decoupling middle layer, and the smart cockpit domain are shown. The security control domain, through the 114 domain interface proxy, only outputs data that can be objectified after entering the decoupling middle layer. All cross-domain interaction commands issued by the smart cockpit domain are forcibly intercepted in the middle layer and must pass the joint permission verification of whitelist rules and orchestrator before they are granted access.

[0055] Figure 2 This demonstrates the specific configuration logic of the permission whitelist matrix. The matrix uses a two-dimensional cross-mapping method to establish the access permission status of different callers for specific controlled objects or interfaces. The left column of the matrix lists the accessed entity resources, covering data encapsulations such as wheel speed objects, risk level objects, and fault code objects, as well as underlying control links such as control parameter write interfaces and high-bandwidth debugging interfaces. The top of the matrix displays the initiating entities of cross-domain interactions, including the presentation layer caller, the interaction service layer, and third-party applications.

[0056] The symbols within the cross cells clearly define the corresponding access control policies. A checkmark (√) indicates the call path is allowed, while an × indicates it is absolutely prohibited. Based on the specific mapping relationship in the matrix, the presentation layer caller has access permission to the wheel speed object, risk level object, and fault code object; the interaction service layer is allowed to access the wheel speed object and risk level object, but not the fault code object; third-party applications' access requests to the aforementioned security objects and control interfaces are all marked as prohibited, thus being completely isolated at the architectural level.

[0057] For the underlying, highly sensitive control chain, the matrix shows that all callers' access to the control parameter write interface is configured to be prohibited. For the high-bandwidth debugging interface, the matrix assigns a symbol △ with conditional constraints to the interaction service layer. This symbol represents a dynamically restricted permission, explicitly stating that the interaction service layer is only allowed to implement cross-domain calls to the debugging interface if all three conditions are simultaneously met: the vehicle is confirmed to be in maintenance mode, it is within a compliant timing window, and a valid security token is provided.

[0058] Combination Figure 3 The abnormal isolation mode switching logic shown decouples the middle layer and constructs a dynamic degradation and closed-loop recovery mechanism based on a fourth-order state machine.

[0059] The system's normal operating baseline is set to the 510 normal state. When the security monitoring link first detects an unauthorized access attempt, call timeout, or token expiration during cross-domain interaction, the system immediately triggers the first-level security degradation response. The state machine transitions from the 510 normal state to the 520 minimum interface set state along the unidirectional solid arrow to shrink the exposure surface.

[0060] During the operation of the 520 minimum interface set state, if the system further detects that the degradation trend of the current communication link has not been suppressed, specifically manifested as persistent abnormal conditions, communication interface storms, high bandwidth service congestion, or the number of occurrences of Level 1 and Level 2 anomalies reaching the second counting threshold within the second time window, then a Level 2 degradation action is triggered. The state machine then switches from the 520 minimum interface set state to the right to the 530 isolation state, implementing the highest level of cross-domain blocking.

[0061] As the risk conditions are identified and mitigated, and after meeting the prerequisites of anomaly resolution and passing self-checks, the decoupling intermediate layer transitions from the 530 isolated state to the 540 recovery state for safety buffering and reconstruction. Until all aspects of the link environment are confirmed to be correct, as indicated by the return arrow at the bottom of the diagram and the indicator showing a return to the normal state after recovery, the decoupling intermediate layer finally reverts from the 540 recovery state back to the initial 510 normal state.

[0062] Combination Figure 4The process of converting safety data into objects visible in the cockpit is shown. The starting point of this data link is the 610 raw safety data block on the left, which gathers basic physical parameters and execution feedback such as 611 wheel speed, 612 tilt angle and 613 braking status directly generated by the underlying sensors or control units.

[0063] The aforementioned raw data is directed to the centrally deployed 620 standard object mapper via the normalized mapping path shown in the diagram. Within this mapping node, the heterogeneous control bus messages at the lower level are stripped of their hardware coupling attributes and undergo semantic-level reorganization and encapsulation, thereby transforming them into standardized data entities that can be uniformly invoked by upper-level logic modules. Specifically, these are represented by the 621 risk event object and the 622 state summary object in the diagram.

[0064] After standardization, a whitelist delivery mechanism is introduced on the right side of this link. Encapsulated 621 risk event objects and 622 status summary objects must pass through this permission verification checkpoint. Only if they comply with the cross-domain access policy are they allowed to cross the system security boundary and reach the rightmost 630 cockpit visible object domain. Ultimately, these controlled incoming objects are instantiated on the cockpit side as interface elements for the front-end application layer to read and display, i.e., the output is the 631 alarm entry and 632 instrument summary shown in the diagram.

[0065] A "domain" is a logical or physical collection of functions and resources in the process of system control architecture evolving towards centralization. Its core logic is to integrate dispersed subsystems or control units onto a specific centralized computing platform according to task attributes, real-time requirements, and functional safety levels. In specific technical implementations, a complete domain is mainly defined through the following three dimensions: logical aggregation of functions and tasks, i.e., classifying tasks with similar attributes according to the high relevance of control objectives; independent hardware and software operating environments, i.e., each domain relies on core hardware that matches its task characteristics as physical computing power support, and is equipped with matching underlying software; and clear resource and permission boundaries, i.e., different domains are decoupled and isolated at the underlying computing and storage resources, and cross-domain data and instruction calls must be conducted through a clearly defined inter-domain communication network, thereby constructing physical and logical boundaries and preventing non-real-time or low-security-level tasks from illegally occupying core control resources.

[0066] The safety control domain carries the core safety and driving control logic of the vehicle, specifically handling power output control, braking system control, vehicle attitude risk assessment, and related safety output tasks. For requests that may affect the vehicle's power, braking, or attitude safety, the intelligent cockpit domain must not directly access the actuator control interface of the safety control domain; such requests can only be submitted to the decoupled middleware layer as restricted write or configuration requests, and the decoupled middleware layer performs pre-verification based on the permission whitelist, vehicle operating status, token conditions, and access frequency. Even if the pre-verification passes, the safety control domain still acts as the final safety confirmation entity, deciding whether to execute based on the actual vehicle conditions such as current vehicle speed, braking status, fault status, riding mode constraints, and side stand status.

[0067] The intelligent cockpit domain handles non-real-time, high-concurrency information processing and human-machine interaction loads. It primarily handles connected and information-related tasks such as HMI display, navigation and voice interaction, upper-layer application services, OTA system upgrades, and log data management. Within the system's control permissions, the intelligent cockpit domain is strictly configured to not have hardware driver permissions to directly execute high-risk actions. For any operations that may interfere with vehicle power or braking performance, such as switching riding modes or adjusting energy recovery levels, this domain is limited to generating restricted write requests or configuration requests, with pre-verification performed by a decoupled middleware layer.

[0068] like Figure 5 As shown, this embodiment provides a dual-domain hierarchical decoupling method applicable to the dual-domain controller architecture of two-wheeled vehicles. This method is executed by a decoupling intermediate layer set between the safety control domain and the smart cockpit domain.

[0069] First, in step S101, the decoupling intermediate layer obtains the raw safety data output from the safety control domain. This raw safety data may include one or more of wheel speed, tilt angle, braking status, fault codes, and risk levels. The decoupling intermediate layer converts this raw safety data into standardized safety objects according to preset object fields and preset mapping rules. These standardized safety objects include an object identifier, object type, object value, data source, timestamp, validity period, and permission tag, thus eliminating the need for the intelligent cockpit domain to directly read the raw control messages from the safety control domain.

[0070] In step S102, the middleware configuration permission whitelist is decoupled. The permission whitelist stores access control policies, which include caller identity, target object identifier, target interface, permission type, vehicle operating status conditions, token conditions, and access frequency conditions. Through this permission whitelist, access permissions for different callers to different standardized security objects and their corresponding interfaces are pre-defined.

[0071] In step S103, when the intelligent cockpit domain initiates a cross-domain call request, the interface orchestrator receives the request and extracts the target object, target interface, permission type, caller identity, and token information from the request. The interface orchestrator combines the access control policy in the permission whitelist, the current vehicle operating status, token conditions, and access frequency conditions to jointly determine the cross-domain call request.

[0072] In step S104, the interface orchestrator determines whether the cross-domain call request meets the release conditions. If the joint determination result is that the release conditions are met, the process proceeds to step S105; if the joint determination result is that the release conditions are not met, the process proceeds to step S106.

[0073] In step S105, the interface orchestrator schedules the standardized security object corresponding to the cross-domain call request and verifies the object identifier, object type, object value range, data source, timestamp, validity period, and permission tag of the standardized security object. After the verification is successful, the decoupled middleware delivers the standardized security object to the authorized presentation layer, interaction service layer, or application orchestration layer in the intelligent cockpit domain.

[0074] In step S106, when a cross-domain call request does not meet the allow conditions, the interface orchestrator intercepts the cross-domain call request and records logs including the caller's identity, target object, target interface, reason for rejection, and time of occurrence.

[0075] In step S107, the decoupling middleware continuously monitors the abnormal states of cross-domain call requests during execution and determines the abnormality level based on the abnormality type, number of abnormalities, and duration of abnormalities. When an abnormality is detected, the decoupling middleware switches the operating state from the normal state to the minimum interface set state, or from the normal state or the minimum interface set state to the isolated state, based on the abnormality level and the current operating state. Therefore, abnormalities such as unauthorized calls, interface storms, call timeouts, or high-bandwidth service congestion in the intelligent cockpit domain will not directly propagate to the security control domain, and the security control domain can still maintain basic instrument displays, security alarm outputs, and necessary security control functions.

[0076] In summary, the above description is merely a preferred embodiment of the present invention and is not intended to limit the actual scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A dual-domain hierarchical decoupling method, characterized in that, The method includes: Establish a unified data object model, obtain the raw security data output by the security control domain, and convert the raw security data into standardized security objects according to preset object fields and preset mapping rules. The standardized security objects include at least object identifier, object type, object value, data source, timestamp, validity period and permission tag. Configure a permission whitelist, which stores access control policies that limit the access permissions of different callers to the standardized security object and its corresponding interface. The access control policies include at least the caller identity, target object identifier, target interface, permission type, vehicle operating status conditions, token conditions, and access frequency conditions. The interface orchestrator receives cross-domain call requests from the intelligent cockpit domain, extracts the target object, target interface, permission type, caller identity and token information from the cross-domain call request, and makes a joint determination based on the access control policy, current vehicle operating status, token conditions and access frequency conditions. When the joint determination meets the release conditions, the standardized security object corresponding to the cross-domain call request is scheduled, and the object identifier, object type, object value range, data source, timestamp, validity period and permission tag of the standardized security object are verified. The standardized security object that passes the verification is delivered to the authorized display layer, interaction service layer or application orchestration layer in the intelligent cockpit domain. When the joint determination does not meet the release conditions, the cross-domain call request is intercepted and logged. Monitor the abnormal state of the cross-domain call request during execution, determine the abnormal level according to the abnormal type, number of abnormalities and duration of abnormality, and based on the abnormal level and the current running state of the decoupling middle layer, switch the running state of the decoupling middle layer from the normal state to the minimum interface set state, or from the normal state or the minimum interface set state to the isolation state when an abnormality is detected.

2. The method according to claim 1, characterized in that, The joint determination based on the access control policy, current vehicle operating status, token condition, and access frequency condition includes: After confirming that the caller's identity matches the caller's identity in the access control policy, it is determined whether the target object exists, whether the target interface belongs to the preset interface list, whether the permission type is allowed, whether the current vehicle operating status meets the vehicle operating status conditions, whether the token information meets the token conditions, and whether the access frequency of the cross-domain call request does not exceed the access frequency limit set by the access frequency conditions. When all of the above conditions are met, the cross-domain call request is determined to meet the allow conditions; when any condition is not met, access is denied and a log is recorded including the caller's identity, target object, target interface, reason for denial, and time of occurrence.

3. The method according to claim 1, characterized in that, The process of converting the raw security data into standardized security objects includes: Map the wheel speed to the speed field in the wheel speed object or state summary object according to the preset wheel speed range; The tilt angle is mapped to an attitude field according to a preset tilt angle range, and a risk event object is generated when the tilt angle exceeds a preset tilt angle threshold; Map the braking status to a braking field according to the enumeration rules of no braking, normal braking, and emergency braking; Map fault codes to fault fields or alarm fields according to a preset fault level table; The risk level output by the safety control domain, or the risk level determined according to preset risk rules based on wheel speed, tilt angle, braking status and fault code, is encapsulated as one or more of the following: risk event object, status summary object, instrument display object or alarm object.

4. The method according to claim 3, characterized in that, The step of scheduling the standardized security object corresponding to the cross-domain call request when the joint determination meets the release conditions includes: The risk event object is delivered to the alarm entry in the smart cockpit domain, the status summary object is delivered to the instrument summary, and the object allowed by the permission whitelist is delivered to the presentation layer, the interaction service layer, or the application orchestration layer.

5. A dual-domain hierarchical decoupling system, characterized in that, It includes a safety control domain, a smart cockpit domain, and a decoupling intermediate layer disposed between the safety control domain and the smart cockpit domain; the decoupling intermediate layer includes at least: The data object model module is used to establish a unified data object model, obtain the raw security data output by the security control domain, and convert the raw security data into standardized security objects according to preset object fields and preset mapping rules. The permission whitelist module is used to configure the permission whitelist, which stores access control policies that limit the access permissions of different callers to the standardized security object and its corresponding interface. The interface orchestrator module is used to receive cross-domain call requests from the intelligent cockpit domain, extract the target object, target interface, permission type, caller identity and token information from the cross-domain call request, combine the access control policy, current vehicle operating status, token conditions and access frequency conditions to make a joint judgment, and schedule, verify or intercept the cross-domain call request according to the joint judgment result. The exception isolation module is used to monitor the abnormal state of the cross-domain call request during execution, determine the exception level according to the exception type, number of exceptions and duration of exception, and, based on the exception level and the current running state of the decoupling middle layer, switch the running state of the decoupling middle layer from the normal state to the minimum interface set state, or from the normal state or the minimum interface set state to the isolation state when an exception is detected.

6. The system according to claim 5, characterized in that, The raw safety data includes at least one or more of wheel speed, camber angle, braking status, fault codes, and risk levels; the standardized safety objects include at least risk event objects, status summary objects, instrument display objects, and alarm objects.

7. The system according to claim 5, characterized in that, The permission whitelist module uses an object-caller-permission type mapping matrix to record the access control policy; Each record in the mapping matrix includes at least the object identifier, interface identifier, caller identity, permission type, vehicle operating status conditions, token conditions, access frequency limit, and interface priority; The permission types include read-only permission, conditional read-only permission, restricted write permission, debug permission, and prohibit permission; The caller includes at least the presentation layer, the interaction service layer, the application orchestration layer, and third-party applications. The restricted write and debug permissions are only permitted when the vehicle is stationary or in maintenance mode, the token is valid, and the cross-domain call request is within a preset authorization time window. The restricted write permission is used for controlled writing of configuration objects, diagnostic objects, display strategy objects, or non-real-time parameter request objects in the decoupled intermediate layer, excluding direct writing of power output parameters, braking execution parameters, attitude stability control parameters, and fault protection thresholds. The access control policy, by default, prohibits third-party applications from reading security objects, writing control parameters, and accessing high-bandwidth debug interfaces.

8. The system according to claim 5, characterized in that, When performing joint determination, the interface orchestrator module, after confirming the identity of the caller, determines whether the target object exists, whether the target interface belongs to the preset interface list, whether the permission type is allowed, whether the current vehicle operating status meets the vehicle operating status conditions, whether the token information meets the token conditions, and whether the access frequency of the cross-domain call request does not exceed the access frequency limit set by the access frequency conditions. When all of the above determinations are met, the cross-domain call request is allowed; when any determination is not met, the cross-domain call request is intercepted and logged.

9. The system according to claim 5, characterized in that, The abnormal states monitored by the abnormal isolation module include at least unauthorized access, call timeout, interface storm, cumulative authentication failure exceeding limits, cockpit domain restart anomaly, and high bandwidth service congestion.

10. The system according to claim 5, characterized in that, In the minimum interface set state, the decoupling intermediate layer only allows the basic instrument display interface, the basic alarm output interface, and the minimum necessary state object output interface to continue to work, and blocks the restricted write interface, the high bandwidth debugging interface, and the non-necessary object access interface. In the isolated state, the decoupling intermediate layer blocks cross-domain calls in the preset non-critical interface list. The preset non-critical interface list includes restricted write interfaces, high-bandwidth debugging interfaces, batch log upload interfaces, media data interfaces, third-party application object access interfaces, and other interfaces that are pre-marked as not belonging to the basic instrument display interfaces and basic alarm output interfaces. The decoupling middleware layer rejects cross-domain data requests from non-critical applications and high-bandwidth services, and sends a degradation instruction to the smart cockpit domain to cause the smart cockpit domain to suspend non-critical applications or high-bandwidth services.

Images