Data isolation transmission method and system for two-wheeled vehicle safety domain and cockpit domain

Abstract

The application discloses a kind of two-wheeled vehicle safety domain and cabin area data isolation transmission method and system, the method includes the following steps: establishing safety domain read-only output channel and cabin area authorization request channel, the data to be published of safety domain is packaged as publishing object, the access behavior of cabin area is packaged as request object, calculate risk score, drive safety domain to convert between each state;When signature is valid, source is legal, replay count is zero and access frequency is lower than recovery threshold in continuous recovery window, enter recovery observation state, and exit isolation in stages according to the order of general state object, extended state object and third-party service object.The technical scheme is adopted, by setting phased exit isolation strategy, under the premise of guaranteeing the continuous visibility of safety domain key information, effectively isolating the risk behaviors such as unauthorized, forgery, replay and high-frequency access, and taking into account the high safety and high availability of two-wheeled vehicle control system.

Description

Technical Field

[0001] This invention belongs to the field of information security and cross-domain communication technology, and relates to a data isolation transmission method and system for the safety domain and cockpit domain of a two-wheeled vehicle. Background Technology

[0002] In the dual-domain controller architecture of two-wheeled vehicles, the safety domain is responsible for generating and managing braking-related states, drive-related limitation states, risk events, and key diagnostic results, while the cockpit domain is responsible for human-machine interaction functions such as instrument display, navigation prompts, media interaction, communication interconnection, and third-party application access. The two domains need to exchange data, but it is crucial to prevent the cockpit domain from making unauthorized writes, forging requests, or abnormally high-frequency accesses to the safety domain.

[0003] Existing technologies typically provide protection from a single direction, such as cross-domain gateways, message signing, replay protection, whitelist filtering, and anomaly blocking. However, in the two-wheeled vehicle scenario, if only a binary "pass / deny" processing method is used, it is often difficult to balance the continuous visibility of critical security information with the timely isolation of high-risk objects. Especially when navigation, helmet connectivity, mobile phone connectivity, and third-party applications coexist, resource competition, unauthorized access, and abnormal recovery fluctuations are more likely to occur between the security domain and the cockpit domain.

[0004] Therefore, a dual-domain data isolation transmission scheme that balances security, availability, and recoverability is needed, so that the communication boundary between the security domain and the cockpit domain has achievable technical features such as asymmetric channel constraints, field-level controllability, state machine isolation, minimum interaction set degradation, and recovery hysteresis. Summary of the Invention

[0005] The purpose of this invention is to address the aforementioned problems in existing technologies by proposing a data isolation transmission method and system for the safety domain and cabin domain of a two-wheeled vehicle.

[0006] To achieve the above objectives, the basic solution of the present invention is: a data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle, comprising the following steps:

[0007] S1. Establish a read-only output channel for the security domain and an authorization request channel for the cockpit domain. The read-only output channel for the security domain publishes objectified state data to the cockpit domain, while the authorization request channel for the cockpit domain submits field-level access requests.

[0008] S2, encapsulate the security domain data to be published into a publication object, the publication object including object identifier, object version, field mask, timestamp, monotonic sequence number, signature value and policy label;

[0009] The cockpit domain access behavior is encapsulated as a request object, which includes a field list, purpose identifier, source identifier, session token, access frequency count, and time window identifier;

[0010] S3, based on illegal field rules, signature verification results, replay detection results, source legality and access frequency, jointly determine the requests in the cockpit domain and obtain a risk score;

[0011] S4, based on the risk score, drive the security domain to switch between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state;

[0012] In the field isolation state, unauthorized fields are rejected from being forwarded; in the minimum interaction set isolation state, the minimum interaction set is only published to the cockpit domain.

[0013] S5, within the continuous recovery window, when the signature is valid, the source is legitimate, the replay count is cleared, and the access frequency is lower than the recovery threshold, the driver security domain enters the recovery observation state, and exits isolation in stages according to the order of general state objects, extended state objects, and third-party service objects.

[0014] The working principle and beneficial effects of this basic solution are as follows: This technical solution constructs a dual-channel asymmetric access architecture between the security domain and the cockpit domain. It ensures that the data in the security domain is not tampered with through the read-only output channel and realizes controllable management of access behavior in the cockpit domain through the authorization request channel.

[0015] Encapsulating data and requests into standardized objects enhances system scalability and verifiability. A joint judgment mechanism comprehensively scores multi-dimensional anomalies, enabling state-driven dynamic isolation control. A five-state transition mechanism—normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state, and recovery observation state—balances real-time protection with communication continuity.

[0016] By implementing a phased exit isolation strategy in the recovery observation state, false recovery and oscillations caused by the temporary elimination of anomalies are prevented, thus improving the robustness of the system. This invention effectively isolates risky behaviors such as unauthorized access, forgery, replay, and high-frequency access while ensuring the continuous visibility of critical information in the security domain, thus balancing the high security and high availability of the two-wheeled vehicle control system.

[0017] Furthermore, the security domain read-only output channel and the cockpit domain authorization request channel adopt an asymmetric access strategy, specifically:

[0018] The read-only output channel of the security domain only allows unidirectional publication of status data;

[0019] The cockpit domain authorization request channel only allows field access to be initiated in the form of a request object, and does not allow direct writing to sensitive control fields.

[0020] The security domain's read-only output channel is explicitly limited to supporting only one-way data publishing, and the cockpit domain's authorization request channel is limited to supporting only field-level request access. Direct writing to sensitive control fields is prohibited, thereby eliminating the risk of unauthorized writes from the cockpit domain to the security domain at the architectural level and enhancing the access boundary control capabilities between the two domains.

[0021] Furthermore, the purpose identifier of the request object is used to distinguish at least one or more of the following: instrument display, navigation prompts, maintenance reminders, media interaction, and third-party application calls;

[0022] Forwarding of a corresponding field is only permitted when the field list, purpose identifier, source identifier, and session token simultaneously meet the rule base matching conditions, which include:

[0023] The list of fields carried in the request object must be within the range of field masks allowed in the rule base for the combination of object ID, purpose ID, and source ID;

[0024] The purpose identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and source ID;

[0025] The source identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and purpose ID;

[0026] The session token in the request object must be valid in the security domain and consistent with the token status requirements in the rule base.

[0027] Different application scenarios (such as instrument display, navigation, maintenance, media, and third-party applications) are distinguished by purpose identifiers, and matched in conjunction with field lists, purpose, source, and session tokens to achieve differentiated authorization control for different business scenarios, prevent third-party applications or unauthorized modules from abusing security domain data, and improve the context security adaptation capability of communication.

[0028] Furthermore, the illegal field rules are implemented using a combined index of object ID + field mask + purpose ID + source ID + token status, and are configured for different vehicle models, computing platforms, and third-party access strategies, specifically as follows:

[0029] Organize all publicly accessible fields in the security domain and assign a unique field ID and mask bit position to each field;

[0030] Define all possible usage identifiers (instrument display, navigation prompts, maintenance reminders, media interaction, third-party application calls, etc.);

[0031] Define all possible source identifiers (instrumentation, navigation, mobile phone connectivity, helmet Bluetooth, third-party apps, etc.);

[0032] Establish a basic rule template, which includes default allowed access relationships;

[0033] Different vehicle models have different electronic and electrical architectures and sets of available fields;

[0034] Adjust the scope of sensitive fields according to the safety level requirements of the vehicle model;

[0035] Token status requirements: Third-party applications must be in an authenticated and authorized state; they cannot use an unauthenticated state.

[0036] Field scope restrictions: Third-party applications can only access non-sensitive fields (such as speed and battery level) and cannot access control fields;

[0037] Frequency limit: The access frequency limit for third-party applications is lower than that for system native modules;

[0038] Session timeout: Third-party applications have shorter session timeouts (e.g., 30 seconds vs. 5 minutes for native modules);

[0039] Purpose identifier restrictions: Third-party applications may only use the "Third-party application call" purpose identifier and may not impersonate other purposes;

[0040] All configurations are merged to generate a complete rule base table. The rule base table is organized using a composite index, with the index keys being: vehicle ID, object ID, field mask, purpose ID, source ID, and token status. The rule base is compiled into binary format for easy lookup in the security domain. Whitelist rules are constructed using a composite index of object ID, field mask, purpose ID, source ID, and token status, supporting flexible configuration for multiple vehicle models, multiple computing platforms, and third-party access policies.

[0041] Furthermore, the specific steps for signature verification are as follows:

[0042] Extract the session token from the request object and find the corresponding session key;

[0043] Calculate HMAC-SHA256 using the variable fields in the key pair request object, including the field list, purpose ID, source ID, and time window ID:

[0044] HMAC-SHA256(K, M) = SHA256( (K' ⊕ opad)||SHA256((K' ⊕ ipad)||M) ),

[0045] HMAC-SHA256 is a hash message authentication code based on SHA256; K is the original key, M is the message content, K' is the adjusted key, ipad is 0x36 repeated 64 times, opad is 0x5C repeated 64 times, C is a hexadecimal number; || represents the string concatenation function.

[0046] The calculation result is compared with the signature (digital signature) field attached to the request object to determine:

[0047] If the two match, the signature verification passes.

[0048] If the two are inconsistent, the signature verification fails, and the number of signature verification failure events in the current detection window, SigFail, is incremented by 1.

[0049] It is simple to operate and easy to use.

[0050] Furthermore, the replay detection is based on a joint determination of two factors: monotonic sequence number, timestamp window, and random number, specifically:

[0051] Extract the monotonic_seq (monotonic sequence number) and session_token (most recent sequence number) from the request object;

[0052] Maintain a session_token mapping table in memory;

[0053] If the monotonic sequence number is less than or equal to the recorded sequence number, then replay the attack, and increment Replay by 1.

[0054] If the monotonic sequence number is greater than the recorded sequence number, update the record and pass the replay test;

[0055] Optional auxiliary method: Combine with timestamps for duplicate detection within a time window;

[0056] When duplicate or expired packets are detected, the corresponding objects are not sent to the cockpit domain for display.

[0057] Replay detection based on at least two of the following: monotonic sequence number, timestamp window, and random number can effectively identify duplicate or expired packets, promptly block replay attacks, ensure the timeliness and authenticity of data sent to the cockpit domain, and improve the anti-attack capability of the communication link.

[0058] Furthermore, the risk score is calculated based on the number of illegal field hits, the number of signature verification failures, the replay count, the number of times the frequency exceeds the threshold, and the number of times the source is abnormal.

[0059] RiskScore = 2×IllegalField + 2×SigFail + 2×Replay + 1×OverFreq +2×SourceMismatch,

[0060] Among them, each variable represents the number of times the corresponding abnormal event is hit within the current detection window, RiskScore represents the risk score, IllegalField represents the illegal field, SigFail represents the signature failure, Replay represents the replay, OverFreq represents the frequency being too high, and SourceMismatch represents the source mismatch;

[0061] The first threshold triggers the early warning monitoring state, and the second threshold triggers the minimum interaction set isolation state.

[0062] For access to sensitive fields, the system can directly enter the field isolation state or the minimum interaction set isolation state without accumulating through the second threshold.

[0063] By setting a first threshold and a second threshold to trigger the early warning monitoring state and the minimum interaction set isolation state respectively, a tiered response can be achieved; access to sensitive fields supports direct entry into the isolation state, improving the response speed to high-risk behaviors.

[0064] Furthermore, based on the aforementioned risk score, the security domain is driven to transition between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state, and recovery observation state, specifically as follows:

[0065] When the risk score is greater than 0 but does not exceed the first threshold, the system switches from normal state to early warning monitoring state.

[0066] When the risk score reaches or exceeds the second threshold, the system directly switches from the normal state to the minimum interaction set isolation state.

[0067] When a request hits a sensitive field rule, it switches directly from the normal state to the field isolation state.

[0068] When signature verification fails consecutively or the replay count reaches a preset threshold, the system directly switches from the normal state to the minimum interaction set isolation state.

[0069] When the risk score drops to 0 and there are no abnormalities in multiple consecutive detection windows, the system returns to normal status from the early warning monitoring state.

[0070] When the risk score reaches or exceeds the second threshold, the system switches from the early warning monitoring state to the minimum interaction set isolation state.

[0071] When a request hits a sensitive field rule, the system switches directly from the alert monitoring state to the field isolation state.

[0072] When signature verification fails consecutively or the replay count reaches a preset threshold, the system switches from the early warning monitoring state to the minimum interaction set isolation state.

[0073] When a request object hits a sensitive field rule, the security domain directly changes from the normal state or the early warning monitoring state to the field isolation state.

[0074] When signature verification fails consecutively or the replay count reaches a preset threshold, the security domain directly enters the minimum interaction set isolation state.

[0075] The recovery observation state requires that the following conditions be met for at least N consecutive detection cycles: the request source is legitimate, the signature verification is passed, the replay count is cleared, the number of illegal field hits is zero, and the access frequency is lower than the recovery threshold.

[0076] The minimum interaction set includes at least two of the following: speed, fault light status, risk level, control-limited status, and operating mode, excluding braking torque commands, ABS parameters, TCS parameters, and diagnostic write control fields.

[0077] Refine the triggering conditions for state transitions, including sensitive field hits, consecutive signature failures, or replay count exceeding limits, to ensure that abnormal behavior can quickly trigger the corresponding isolation state; clarify the legal conditions for restoring the observation state to avoid the system being unable to recover for a long time due to occasional anomalies.

[0078] Furthermore, the phased exit from isolation includes:

[0079] The first phase involves restoring the object to its normal state.

[0080] The second phase involves restoring the extended state object.

[0081] The third phase involves restoring services to third-party clients.

[0082] If a source anomaly, replay anomaly, or access to a sensitive field occurs again at any stage, the system will fall back to the field isolation state or the minimum interaction set isolation state.

[0083] Communication is restored step by step in the order of general state objects, extended state objects, and third-party service objects. If an exception is triggered again in any stage, the system will fall back to the isolation state, thereby avoiding the security risks of a one-time recovery and enhancing the controllability of the recovery process in complex and abnormal scenarios.

[0084] The present invention also provides a data isolation transmission system for the safety domain and cabin domain of a two-wheeled vehicle based on the method described herein, comprising:

[0085] The object encapsulation signature unit is used to encapsulate the data to be published in the security domain into a publication object containing an object identifier, object version, field mask, timestamp, monotonic sequence number, signature value, and policy label;

[0086] The request object parsing unit is used to receive the request object submitted by the cockpit domain and parse the field list, purpose identifier, source identifier, session token, and access frequency count;

[0087] The rule determination unit is used to calculate the risk score based on whitelist field rules, sensitive field rules, signature verification results, time window verification results, replay detection results, source legality, and access frequency.

[0088] The state machine management unit is used to drive the switching between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state based on the risk score;

[0089] The recovery management unit is used to restore in stages according to the order of general state objects, extended state objects, and third-party service objects when the continuous recovery window meets the legality conditions.

[0090] This system forms a complete data isolation and transmission system architecture through the collaborative work of the object encapsulation signature unit, request object parsing unit, rule judgment unit, state machine management unit, and recovery management unit. It has high cohesion, low coupling, and engineering implementation capabilities, and is suitable for embedded environments in two-wheeled vehicles.

[0091] Furthermore, the rule determination unit includes a whitelist field rule base and a sensitive field rule base. The whitelist field rule base is used to limit the read-only access scope at the object level and field level, and the sensitive field rule base is used to limit control fields that are prohibited from being written to.

[0092] By separating the whitelist field rule base and the sensitive field rule base, we can manage the read-only access scope and the write-prohibited control field separately, which facilitates rule maintenance and policy expansion and improves the configurability and security of the system.

[0093] Furthermore, the state machine management unit works in conjunction with the minimum interaction set cache, and only outputs the minimum interaction set object to the cockpit domain in the minimum interaction set isolation state;

[0094] The recovery management unit performs signature validity verification, source legitimacy verification, and replay count verification for each recovery stage during the recovery observation state.

[0095] The state machine management unit works in conjunction with the minimum interaction set cache to ensure that only necessary security information is output in the minimum interaction set isolation state, avoiding information leakage or control interference; the recovery management unit performs signature, source, and replay verification on each stage in the recovery observation state to ensure that the recovery process is secure and controllable and to prevent the reintroduction of anomalies. Attached Figure Description

[0096] Figure 1This is a flowchart illustrating the data isolation and transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to the present invention.

[0097] Figure 2 This is a schematic diagram of the hierarchical isolation state machine and the recovery hysteresis process of the data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to the present invention.

[0098] Figure 3 This is a whitelist field, sensitive field, and policy mapping diagram of the data isolation transmission method between the safety domain and the cockpit domain of two-wheeled vehicles according to the present invention;

[0099] Figure 4 This is a timing diagram of the abnormal interception, isolation, and recovery of the data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to the present invention. Detailed Implementation

[0100] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0101] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0102] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0103] This invention discloses a data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle, which solves the problems of insufficient creative identification points, insufficient isolation granularity, unstable recovery logic, and insufficient support for implementation details in existing dual-domain communication schemes. It realizes inter-domain data exchange with controllable direction, controllable fields, controllable uses, hierarchical isolation of anomalies, downgraded retention of key information, and hysteresis recovery process.

[0104] like Figure 1As shown, the data isolation transmission method between the safety domain and the cockpit domain of a two-wheeled vehicle includes the following steps:

[0105] S1. Establish a read-only output channel for the security domain and an authorization request channel for the cockpit domain. The read-only output channel for the security domain publishes objectified state data to the cockpit domain, while the authorization request channel for the cockpit domain submits field-level access requests.

[0106] S2, encapsulate the security domain data to be published into a publication object, the publication object including object identifier, object version, field mask, timestamp, monotonic sequence number, signature value and policy label;

[0107] The cockpit domain access behavior is encapsulated as a request object, which includes a field list, purpose identifier, source identifier, session token, access frequency count, and time window identifier;

[0108] The field mask in the published object identifies the set of fields that the current object is allowed to be read by the cockpit domain. The policy tag identifies the object's security level, cache duration, and whether it is included in the minimum interaction set. A JSON / Key-Value + binary structure-like representation is used for ease of understanding and implementation, as shown in Table 1.

[0109] Table 1 Specific Data Format

[0110]

[0111] S3, based on illegal field rules, signature verification results, replay detection results, source legality and access frequency, jointly determine the requests in the cockpit domain and obtain a risk score;

[0112] S4, based on the risk score, drive the security domain to switch between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state;

[0113] In the field isolation state, unauthorized fields are refused to be forwarded; in the minimum interaction set isolation state, the minimum interaction set is only published to the cockpit domain.

[0114] S5, within the continuous recovery window, when the signature is valid, the source is legitimate, the replay count is cleared, and the access frequency is lower than the recovery threshold, the driver security domain enters the recovery observation state, and exits isolation in stages according to the order of general state objects, extended state objects, and third-party service objects.

[0115] Generate an audit log, which must include at least the request identifier, object identifier, field information, timestamp, source identifier, state transition result, and action result.

[0116] This invention decouples security domain output and cockpit domain requests through asymmetric dual-channel architecture, avoiding the ambiguity of security boundaries caused by a unified bus or unified message entry point. By replacing simple blocking logic with a hierarchical isolation state machine, exception handling is upgraded from a "forward or not" process to a computable flow of "early warning—field isolation—minimum interaction set isolation—recovery observation".

[0117] In this embodiment, the security domain uses an STM32H750 vehicle safety controller MCU with a built-in hardware HMAC encryption module; the cockpit domain is the instrument cluster cockpit controller, using an STM32F407 chip. Cross-domain data exchange between the security domain and the cockpit domain is achieved via the vehicle's CAN FD bus, with a bus baud rate set to 2 Mbit / s. The security domain sends out encapsulated and signed service messages using CAN FD extended frames; the cockpit domain's read request messages are also transmitted based on CAN FD frames, carrying a purpose identifier, source identifier, session token, and a list of fields to be read within the payload.

[0118] This method, through a minimum interaction set mechanism, retains the display of critical safety information even under high-risk conditions, improving overall vehicle availability. Furthermore, it avoids frequent fluctuations during the recovery process by using a recovery window and a phased recovery sequence. The configurable design of whitelist fields, sensitive fields, frequency thresholds, and recovery sequence tables makes this invention more suitable for different vehicle models, computing platforms, and interconnected peripherals within the two-wheeled vehicle industry.

[0119] In a preferred embodiment of the present invention, the security domain read-only output channel and the cockpit domain authorization request channel employ an asymmetric access strategy, specifically:

[0120] The security domain read-only output channel only allows unidirectional publication of status data;

[0121] The cockpit domain authorization request channel only allows field access to be initiated in the form of a request object, and does not allow direct writing to sensitive control fields.

[0122] In a preferred embodiment of the present invention, the purpose identifier of the request object is used to distinguish at least one or more of instrument display, navigation prompts, maintenance reminders, media interaction, and third-party application calls;

[0123] Forwarding of a corresponding field is only permitted when the field list, purpose identifier, source identifier, and session token simultaneously meet the rule base matching conditions, which include:

[0124] The list of fields carried in the request object must be within the range of field masks allowed in the rule base for the combination of object ID, purpose ID, and source ID;

[0125] The purpose identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and source ID;

[0126] The source identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and purpose ID;

[0127] The session token in the request object must be valid in the security domain and consistent with the token status requirements in the rule base.

[0128] Different application scenarios (such as instrument display, navigation, maintenance, media, and third-party applications) are distinguished by purpose identifiers, and matched in conjunction with field lists, purpose, source, and session tokens to achieve differentiated authorization control for different business scenarios, prevent third-party applications or unauthorized modules from abusing security domain data, and improve the context security adaptation capability of communication.

[0129] In a preferred embodiment of the present invention, such as Figure 3 As shown, the illegal field rules are implemented using a combined index of object ID + field mask + purpose ID + source ID + token status. Configurations are made for different vehicle models, computing platforms, and third-party access strategies, specifically as follows:

[0130] Organize all publicly accessible fields in the security domain and assign a unique field ID and mask bit position to each field;

[0131] Define all possible usage identifiers (instrument display, navigation prompts, maintenance reminders, media interaction, third-party application calls, etc.);

[0132] Define all possible source identifiers (instrumentation, navigation, mobile phone connectivity, helmet Bluetooth, third-party apps, etc.);

[0133] Establish a basic rule template, which includes default allowed access relationships;

[0134] Different vehicle models have different electronic and electrical architectures and sets of available fields;

[0135] Adjust the scope of sensitive fields according to the safety level requirements of the vehicle model;

[0136] Token status requirements: Third-party applications must be in the "authenticated + authorized" state and cannot use the "unauthenticated" state;

[0137] Field scope restrictions: Third-party applications can only access non-sensitive fields (such as speed and battery level) and cannot access control fields;

[0138] Frequency limit: The access frequency limit for third-party applications is lower than that for system native modules;

[0139] Session timeout: Third-party applications have shorter session timeouts (e.g., 30 seconds vs. 5 minutes for native modules);

[0140] Purpose identifier restrictions: Third-party applications may only use the "Third-party application call" purpose identifier and may not impersonate other purposes;

[0141] All configurations are merged to generate a complete rule base table. The rule base table is organized using a composite index, with the index keys being: vehicle ID, object ID, field mask, purpose ID, source ID, and token status. The rule base is compiled into binary format for easy lookup within security domains.

[0142] The whitelist field rules are implemented using a combined index of object ID, field mask, purpose ID, source ID, and token status, and can be configured for different vehicle models, computing power platforms, and third-party access strategies.

[0143] Sensitive field rules include setting write-prohibition policies for one or more of the following: braking torque command, ABS parameters, TCS parameters, attitude correction parameters, and internal diagnostic write control fields of the safety domain.

[0144] In a preferred embodiment of the present invention, the specific steps of signature verification are as follows:

[0145] Extract the session token from the request object and find the corresponding session key;

[0146] Calculate HMAC-SHA256 using the variable fields in the key pair request object, including the field list, purpose ID, source ID, and time window ID:

[0147] HMAC-SHA256(K, M) = SHA256( (K' ⊕ opad)||SHA256((K' ⊕ ipad)||M) ),

[0148] HMAC-SHA256 is a hash message authentication code based on SHA256; K is the original key, M is the message content, K' is the adjusted key, ipad is 0x36 repeated 64 times, opad is 0x5C repeated 64 times, C is a hexadecimal number; || represents the string concatenation function.

[0149] The calculation result is compared with the signature (digital signature) field attached to the request object to determine:

[0150] If the two match, the signature verification passes.

[0151] If the two are inconsistent, the signature verification fails, and the number of signature verification failure events in the current detection window, SigFail, is incremented by 1.

[0152] In a preferred embodiment of the present invention, the replay detection is based on a joint determination of at least two of the following: monotonic sequence number, timestamp window, and random number, specifically:

[0153] Extract the monotonic_seq (monotonic sequence number) and session_token (most recent sequence number) from the request object;

[0154] Maintain a session_token mapping table in memory;

[0155] If the monotonic sequence number is less than or equal to the recorded sequence number, then replay the attack, and increment Replay by 1.

[0156] If the monotonic sequence number is greater than the recorded sequence number, update the record and pass the replay test;

[0157] Optional auxiliary method: Combine with timestamps for duplicate detection within a time window;

[0158] When duplicate or expired packets are detected, the corresponding objects are not sent to the cockpit domain for display.

[0159] In a preferred embodiment of the present invention, the risk score is calculated based on the number of illegal field hits, the number of signature verification failures, the replay count, the number of times the frequency exceeds the threshold, and the number of times the source is abnormal.

[0160] RiskScore = 2×IllegalField + 2×SigFail + 2×Replay + 1×OverFreq +2×SourceMismatch,

[0161] Among them, each variable represents the number of times the corresponding abnormal event is hit within the current detection window, RiskScore represents the risk score, IllegalField represents the illegal field, SigFail represents the signature failure, Replay represents the replay, OverFreq represents the frequency being too high, and SourceMismatch represents the source mismatch;

[0162] The first threshold triggers the early warning monitoring state, and the second threshold triggers the minimum interaction set isolation state (the first threshold is preferably 2, and the second threshold is preferably 5).

[0163] For access to sensitive fields, the system can directly enter the field isolation state or the minimum interaction set isolation state without accumulating through the second threshold.

[0164] In a preferred embodiment of the present invention, such as Figure 2 As shown, based on risk scoring, the security domain is driven to transition between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state, and recovery observation state, specifically as follows:

[0165] When the risk score is greater than 0 but does not exceed the first threshold, the system switches from normal state to early warning monitoring state.

[0166] When the risk score reaches or exceeds the second threshold, the system directly switches from the normal state to the minimum interaction set isolation state.

[0167] When a request hits a sensitive field rule, it switches directly from the normal state to the field isolation state.

[0168] When signature verification fails consecutively or the replay count reaches a preset threshold, the system directly switches from the normal state to the minimum interaction set isolation state.

[0169] When the risk score drops to 0 and there are no abnormalities in multiple consecutive detection windows, the system returns to normal status from the early warning monitoring state.

[0170] When the risk score reaches or exceeds the second threshold, the system switches from the early warning monitoring state to the minimum interaction set isolation state.

[0171] When a request hits a sensitive field rule, the system switches directly from the alert monitoring state to the field isolation state.

[0172] When signature verification fails consecutively or the replay count reaches a preset threshold (e.g., 3 times), the system switches from the early warning monitoring state to the minimum interaction set isolation state.

[0173] When a request object hits a sensitive field rule, the security domain directly changes from the normal state or the early warning monitoring state to the field isolation state.

[0174] When signature verification fails consecutively or the replay count reaches a preset threshold (e.g., 3 times), the security domain directly enters the minimum interaction set isolation state.

[0175] To restore the observation state, at least N consecutive detection cycles (e.g., 5 detection cycles) must meet the following conditions: the request source is legitimate, the signature verification passes, the replay count is cleared, the number of illegal field hits is zero, and the access frequency is lower than the recovery threshold.

[0176] The minimum interaction set must include at least two of the following: speed, fault light status, risk level, control-limited status, and operating mode, excluding braking torque commands, ABS parameters, TCS parameters, and diagnostic write control fields.

[0177] In a preferred embodiment of the present invention, such as Figure 4 As shown, the phased exit from quarantine includes:

[0178] The first phase involves restoring the object to its normal state.

[0179] The second phase involves restoring the extended state object.

[0180] The third phase involves restoring services to third-party clients.

[0181] If a source anomaly, replay anomaly, or access to a sensitive field occurs again at any stage, the system will fall back to the field isolation state or the minimum interaction set isolation state.

[0182] For example, in a normal publishing and access request scenario, the security domain periodically generates VehicleState and RiskState objects. The object encapsulation and signature unit adds object identifiers, object versions, field masks, timestamps, monotonic numbers, and signature values ​​before publishing them externally through the security domain's read-only output channel. The cockpit domain navigation service constructs a request object with the request fields speed, mode, and limitState. The purpose identifier is navigation hints, the source identifier is the built-in navigation application, and the session token is a valid token generated from the most recent handshake. The rule determination unit confirms that the fields, purpose, source, and token all meet the rule base requirements, and the access frequency is within the allowed range. Therefore, it only forwards the authorized fields and creates a pass / fail audit record.

[0183] Unauthorized access to sensitive fields. A third-party application requests the `brakeTorqueCmd` and `absParam` fields. Although its session token is valid, the system directly transitions from the normal state to the field isolation state because the field list matches the sensitive field rule base, refusing to forward the requested fields. If the application continues to request attitude correction parameters or diagnostic write control fields within a continuous window, the risk score continues to rise, and the application enters the minimum interaction set isolation state.

[0184] Signature failure and replay anomaly scenarios. When the isolated transmission engine receives a publish object with an expired timestamp, a duplicate monotonic sequence number, and a mismatched signature, the signature verification and anti-replay unit simultaneously reports the signature failure count and replay count to the state machine management unit. When the number of consecutive failures reaches the second threshold, the system directly enters the minimum interaction set isolation state and stops forwarding other objects except for the minimum interaction set to the cockpit domain.

[0185] Recovery observation and phased recovery scenario. After troubleshooting, if within N consecutive detection cycles the source is legitimate, the signature is valid, the number of illegal field hits is zero, the replay count is zeroed, and the access frequency is below the recovery threshold (e.g., 10 times), the system enters recovery observation state and initiates phased recovery. First, the general state fields in VehicleState and RiskState are restored; if stability is maintained, the extended fields in PowerState and DiagSummary are restored; finally, third-party service objects are restored. If any source anomaly, replay anomaly, or unauthorized request recurs in any stage, the system immediately reverts to the field isolation state or the minimum interaction set isolation state.

[0186] Table 2-5 provides the following: a table of field rules, examples of sensitive field representations, examples of threshold and state transition representations, and examples of recovery order representations.

[0187] Table 2. Example of read-only field mapping to usage

[0188] object name Readable fields Permitted use Remark VehicleState speed, mode, limitState Instrument display and navigation prompts Belongs to general state objects RiskState faultLamp, riskLevel, warningCode Risk warnings, instrument displays Can be included in the minimum interaction set PowerState soc, range, chargeState Energy display Phase 2 of recovery enabled DiagSummary faultClass, faultTime Maintenance reminder It is not open to third parties by default. RiderState helmetLink, callHint, mediaState Human-computer interaction Isolated from security control fields

[0189] Table 3. Examples of Sensitive Control Fields and Processing Strategies

[0190] Sensitive fields Default policy First hit action Consecutive hits upgrade action brakeTorqueCmd Write prohibited Enter field isolation state Enter the minimum interaction set isolation state absParam Write prohibited Enter field isolation state Enter the minimum interaction set isolation state tcsParam Write prohibited Enter field isolation state Enter the minimum interaction set isolation state attitudeCorrect Write prohibited Enter field isolation state Maintain the minimum set of interactions and write it to the audit. diagWriteCtrl Write prohibited Enter field isolation state Trigger recovery window reset

[0191] Table 4 Examples of Risk Scoring, Thresholds, and State Transitions

[0192] Event Item Scoring method Example threshold Entering the state illustrate Illegal field hit +2 each time Continuous windows ≥1 Field isolation state Sensitive fields can be triggered directly. Signature verification failed +2 each time ≥2 consecutive failures Minimal Interaction Set Isolated State High-risk events Replay count +2 each time ≥2 within the window Minimal Interaction Set Isolated State Joint determination of monotonic sequence number and time window Access frequency exceeds threshold +1 each time 10-second window ≥ 3 times Early warning monitoring status Can be overlaid with other events Source abnormal +2 each time The first hit scores. Field isolation state Source whitelist mismatch

[0193] Table 5. Examples of Recovery Order and Recovery Conditions

[0194] Recovery phase Restore object Prerequisites for recovery rollback conditions Phase 1 VehicleState and RiskState are common fields. The signature is valid for N consecutive cycles, the source is legitimate, and the replay count is reset to zero. Another source error or unauthorized field request occurred. Phase 2 PowerState and DiagSummary extended fields Phase 1 is running stably and the frequency is below the recovery threshold. Another verification failure or replay error occurred. Phase 3 Third-party service recipients Phase 2 is stable and third-party application tokens are valid. Sensitive field access or overclocking requests reappear

[0195] The present invention also provides a data isolation transmission system for the safety domain and cabin domain of a two-wheeled vehicle based on the method described herein, comprising:

[0196] The object encapsulation signature unit is used to encapsulate the data to be published in the security domain into a publication object containing an object identifier, object version, field mask, timestamp, monotonic sequence number, signature value, and policy label;

[0197] The request object parsing unit is used to receive the request object submitted by the cockpit domain and parse the field list, purpose identifier, source identifier, session token, and access frequency count;

[0198] The rule determination unit is used to calculate the risk score based on whitelist field rules, sensitive field rules, signature verification results, time window verification results, replay detection results, source legality, and access frequency.

[0199] The state machine management unit is used to drive the switching between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state based on the risk score;

[0200] The recovery management unit is used to restore in stages according to the order of general state objects, extended state objects, and third-party service objects when the continuous recovery window meets the legality conditions.

[0201] The recovery window can be implemented using a fixed time window, a fixed periodic count, or a combination of both. The recovery window also requires that the count of illegal fields be zeroed, signature verification pass continuously, the replay count be zeroed, and the frequency count fall below the recovery threshold.

[0202] Preferably, the rule determination unit includes a whitelist field rule base and a sensitive field rule base. The whitelist field rule base is used to limit the read-only access scope at the object level and field level, and the sensitive field rule base is used to limit control class fields that are prohibited from being written.

[0203] By separating the whitelist field rule base and the sensitive field rule base, we can manage the read-only access scope and the write-prohibited control field separately, which facilitates rule maintenance and policy expansion and improves the configurability and security of the system.

[0204] The specific whitelist field rule base and sensitive field rule base are stored independently within the security domain MCU. Rule configuration is performed in two ways: First, factory pre-calibration, where the host computer calibration tool writes the vehicle model-matched field access permissions and sensitive control field interception rules to Flash via the UART calibration interface. After writing, a CRC checksum is generated, and the rules are loaded after the device powers on and verifies the CRC. Second, offline cold update, where the rules are overwritten and updated via the calibration tool after the vehicle is powered off. Hot updates during runtime are not supported to avoid the risk of dynamic tampering. During device power-on initialization, the rule determination unit reads the two rule bases from Flash into the RAM cache, generating an object-readable field mapping table and a sensitive field interception lookup table corresponding to Tables 2 and 4. If the Flash rule CRC check fails, the system automatically loads the built-in default basic rules and simultaneously records the fault code and stores it in local storage.

[0205] In a preferred embodiment of the present invention, the state machine management unit works in collaboration with the minimum interaction set cache, and outputs the minimum interaction set object only to the cockpit domain in the minimum interaction set isolation state;

[0206] The recovery management unit performs signature validity verification, source legitimacy verification, and replay count verification for each recovery stage during the recovery observation state.

[0207] The system time base is provided by a 1ms hardware timer inside the MCU, and a fixed-duration sliding window is used to count various abnormal events. Whenever an illegal field access, signature failure, replay attack, source mismatch, or access frequency exceeding the limit occurs, the current system timestamp is recorded and stored in a circular array. Segmented recovery uses a fixed 100ms judgment period. Only after N consecutive complete cycles (e.g., N=5, totaling 500ms) are all checked without any abnormalities is a recovery phase initiated. If an abnormality is reproduced in any cycle, the circular abnormality count array is immediately cleared and the recovery observation window is reset.

[0208] The minimum interaction set cache is a circular cache within the MCU's on-chip RAM, storing only two basic objects: VehicleState and RiskState. The cache is refreshed synchronously with the vehicle's 10ms scheduling cycle. When the system switches to the minimum interaction isolation state, the message filtering module iterates through the messages to be sent, allowing only messages with the frame ID corresponding to the minimum interaction set, and directly discarding PowerState, DiagSummary, and third-party service object messages, while simultaneously recording message truncation audit logs. The cache permanently retains the speed, faultLamp, riskLevel, and warningCode fields, and permanently blocks the sensitive control fields absParam, tcsParam, attitudeCorrect, and diagWriteCtrl, consistent with the handling rules in Table 3.

[0209] Within the recovery observation window, the recovery management unit independently performs three types of parallel checks for Phases 1, 2, and 3: First, signature validity check: all request messages in the cockpit domain undergo HMAC verification again, with no signature failure records. Second, source legitimacy check: the session token and source identifier match the device's pre-stored legal whitelist, with no source mismatch events. Third, replay count check: the replay anomaly count in the sliding window is reset to zero, with no duplicate monotonic sequence number messages. The current recovery phase can only be maintained if all three checks pass; if any check fails, the recovery count is cleared, and the system reverts to the field isolation state or minimum interaction isolation state. Each time a field release, message truncation, system state switch, or message verification failure operation is completed, the rule determination unit generates a structured audit log. The log includes a timestamp, session token, source identifier, accessed field, action, current system status, and real-time risk score. The audit log is stored cyclically in the security domain's Flash log partition, with a maximum storage of 10,000 entries; when storage space overflows, the oldest log is overwritten. When the system enters the field isolation state or the minimum interaction isolation state, the security domain generates the corresponding vehicle fault code and sends it to the cockpit instrument panel via the CAN FD bus, illuminating the risk warning light on the instrument panel. If the system maintains a deep isolation state for a long period of time, the fault code is synchronously uploaded to the vehicle terminal storage, which facilitates the maintenance equipment to read the log and trace the abnormal access behavior. The verification results of each stage of the recovery observation window are synchronously written to the audit log, which fully records the timing information of recovery access and abnormal rollback, and is used for after-sales safety audit and investigation.

[0210] The specific embodiments described herein are merely illustrative examples of the present invention. Those skilled in the art can make various modifications or additions to the described embodiments or use similar methods to substitute them, without departing from the technology of the present invention or exceeding the scope defined by the appended claims.

[0211] In the embodiments of this application, terms such as "fixed," "fixed connection," and "fixed connection" refer to common fixing methods in the prior art, such as welding, riveting, and screws. "Rotary connection" refers to common rotary connection methods in the prior art, such as hinges and bearing rotation. If electrical components are provided, the functions, control, and power supply methods of all electrical components are common technical means in the prior art. This application has not improved them and they are not within the protection scope of this application. Therefore, this application will not elaborate on them.

[0212] Furthermore, the selection of materials and strength limitations for all components in this application can be made and arranged by those skilled in the art based on the site environment and the requirements of relevant national or industry standards, and are not within the scope of protection of this application. Therefore, this application will not elaborate on these points.

Claims

1. A method for data isolation transmission between the safety domain and the cabin domain of a two-wheeled vehicle, characterized in that, Includes the following steps: S1. Establish a read-only output channel for the security domain and an authorization request channel for the cockpit domain. The read-only output channel for the security domain publishes objectified state data to the cockpit domain, while the authorization request channel for the cockpit domain submits field-level access requests. S2, encapsulate the security domain data to be published into a publication object, the publication object including object identifier, object version, field mask, timestamp, monotonic sequence number, signature value and policy label; The cockpit domain access behavior is encapsulated as a request object, which includes a field list, purpose identifier, source identifier, session token, access frequency count, and time window identifier; S3, based on illegal field rules, signature verification results, replay detection results, source legality and access frequency, jointly determine the requests in the cockpit domain and obtain a risk score; S4, based on the risk score, drive the security domain to switch between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state; In the field isolation state, unauthorized fields are rejected from being forwarded; in the minimum interaction set isolation state, the minimum interaction set is only published to the cockpit domain. S5, within the continuous recovery window, when the signature is valid, the source is legitimate, the replay count is cleared, and the access frequency is lower than the recovery threshold, the driver security domain enters the recovery observation state, and exits isolation in stages according to the order of general state objects, extended state objects, and third-party service objects.

2. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, The security domain read-only output channel and the cockpit domain authorization request channel adopt an asymmetric access strategy, specifically: The read-only output channel of the security domain only allows unidirectional publication of status data; The cockpit domain authorization request channel only allows field access to be initiated in the form of a request object, and does not allow direct writing to sensitive control fields.

3. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, The purpose identifier of the request object is used to distinguish at least one or more of the following: instrument display, navigation prompts, maintenance reminders, media interaction, and third-party application calls; Forwarding of a corresponding field is only permitted when the field list, purpose identifier, source identifier, and session token simultaneously meet the rule base matching conditions, which include: The list of fields carried in the request object must be within the range of field masks allowed in the rule base for the combination of object ID, purpose ID, and source ID; The purpose identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and source ID; The source identifier in the request object must have been registered and authorized in the rule base for the combination of object ID and purpose ID; The session token in the request object must be valid in the security domain and consistent with the token status requirements in the rule base.

4. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, The illegal field rules are implemented using a combined index of object ID + field mask + purpose ID + source ID + token status. Configuration is available for different vehicle models, computing platforms, and third-party access strategies, specifically as follows: Organize all publicly accessible fields in the security domain and assign a unique field ID and mask bit position to each field; Define all possible usage identifiers; Define all possible source identifiers; Establish a basic rule template, which includes default allowed access relationships; Different vehicle models have different electronic and electrical architectures and sets of available fields; Adjust the scope of sensitive fields according to the safety level requirements of the vehicle model; Token status requirements: Third-party applications must be in an authenticated and authorized state; they cannot use an unauthenticated state. Field scope restriction: Third-party applications can only access non-sensitive fields and cannot access control fields; Frequency limit: The access frequency limit for third-party applications is lower than that for system native modules; Session timeout: Third-party applications have shorter session timeouts; Purpose identifier restrictions: Third-party applications may only use the "Third-party application call" purpose identifier and may not impersonate other purposes; All configurations are merged to generate a complete rule base table. The rule base table is organized using a composite index, with the index keys being: vehicle ID, object ID, field mask, purpose ID, source ID, and token status. The rule base is compiled into binary format for easy lookup within security domains.

5. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, The specific steps for signature verification are as follows: Extract the session token from the request object and find the corresponding session key; Calculate HMAC-SHA256 using the variable fields in the key pair request object, including the field list, purpose ID, source ID, and time window ID: HMAC-SHA256(K, M) = SHA256( (K' ⊕ opad) || SHA256((K' ⊕ ipad) || M) ), HMAC-SHA256 is a hash message authentication code based on SHA256; K is the original key, M is the message content, K' is the adjusted key, ipad is 0x36 repeated 64 times, opad is 0x5C repeated 64 times, C is a hexadecimal number; || represents the string concatenation function. The calculation result is compared with the signature (digital signature) field attached to the request object to determine: If the two match, the signature verification passes. If the two are inconsistent, the signature verification fails, and the number of signature verification failure events in the current detection window, SigFail, is incremented by 1.

6. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 5, characterized in that, The replay detection is based on a joint determination of two factors: monotonic sequence number, timestamp window, and random number. Specifically: Extract the monotonic_seq (monotonic sequence number) and session_token (most recent sequence number) from the request object; Maintain a session_token mapping table in memory; If the monotonic sequence number is less than or equal to the recorded sequence number, then replay the attack, and increment Replay by 1. If the monotonic sequence number is greater than the recorded sequence number, update the record and pass the replay test; Optional auxiliary method: Combine with timestamps for duplicate detection within a time window; When duplicate or expired packets are detected, the corresponding objects are not sent to the cockpit domain for display.

7. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, The risk score is calculated based on the number of illegal field hits, the number of signature verification failures, the replay count, the number of times the frequency exceeds the threshold, and the number of times the source is abnormal. RiskScore = 2×IllegalField + 2×SigFail + 2×Replay + 1×OverFreq + 2×SourceMismatch, Among them, each variable represents the number of times the corresponding abnormal event is hit within the current detection window, RiskScore represents the risk score, IllegalField represents the illegal field, SigFail represents the signature failure, Replay represents the replay, OverFreq represents the frequency being too high, and SourceMismatch represents the source mismatch; The first threshold triggers the early warning monitoring state, and the second threshold triggers the minimum interaction set isolation state. For access to sensitive fields, the system can directly enter the field isolation state or the minimum interaction set isolation state without accumulating through the second threshold.

8. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 1, characterized in that, Based on the risk score, the security domain is driven to transition between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state, and recovery observation state, specifically as follows: When the risk score is greater than 0 but does not exceed the first threshold, the system switches from normal state to early warning monitoring state. When the risk score reaches or exceeds the second threshold, the system directly switches from the normal state to the minimum interaction set isolation state. When a request hits a sensitive field rule, it switches directly from the normal state to the field isolation state. When signature verification fails consecutively or the replay count reaches a preset threshold, the system directly switches from the normal state to the minimum interaction set isolation state. When the risk score drops to 0 and there are no abnormalities in multiple consecutive detection windows, the system returns to normal status from the early warning monitoring state. When the risk score reaches or exceeds the second threshold, the system switches from the early warning monitoring state to the minimum interaction set isolation state. When a request hits a sensitive field rule, the system switches directly from the alert monitoring state to the field isolation state. When signature verification fails consecutively or the replay count reaches a preset threshold, the system switches from the early warning monitoring state to the minimum interaction set isolation state. When a request object hits a sensitive field rule, the security domain directly changes from the normal state or the early warning monitoring state to the field isolation state. When signature verification fails consecutively or the replay count reaches a preset threshold, the security domain directly enters the minimum interaction set isolation state. The recovery observation state requires that the following conditions be met for at least N consecutive detection cycles: the request source is legitimate, the signature verification is passed, the replay count is cleared, the number of illegal field hits is zero, and the access frequency is lower than the recovery threshold. The minimum interaction set includes at least two of the following: speed, fault light status, risk level, control-limited status, and operating mode, excluding braking torque commands, ABS parameters, TCS parameters, and diagnostic write control fields.

9. The data isolation transmission method between the safety domain and the cabin domain of a two-wheeled vehicle according to claim 8, characterized in that, The phased exit from quarantine includes: The first phase involves restoring the object to its normal state. The second phase involves restoring the extended state object. The third phase involves restoring services to third-party clients. If a source anomaly, replay anomaly, or access to a sensitive field occurs again at any stage, the system will fall back to the field isolation state or the minimum interaction set isolation state.

10. A data isolation transmission system for the safety domain and cabin domain of a two-wheeled vehicle based on the method of any one of claims 1-9, characterized in that, include: The object encapsulation signature unit is used to encapsulate the data to be published in the security domain into a publication object containing an object identifier, object version, field mask, timestamp, monotonic sequence number, signature value, and policy label; The request object parsing unit is used to receive the request object submitted by the cockpit domain and parse the field list, purpose identifier, source identifier, session token, and access frequency count; The rule determination unit is used to calculate the risk score based on whitelist field rules, sensitive field rules, signature verification results, time window verification results, replay detection results, source legality, and access frequency. The state machine management unit is used to drive the switching between normal state, early warning monitoring state, field isolation state, minimum interaction set isolation state and recovery observation state based on the risk score; The recovery management unit is used to restore in stages according to the order of general state objects, extended state objects, and third-party service objects when the continuous recovery window meets the legality conditions.

11. The data isolation transmission system for the safety domain and cabin domain of a two-wheeled vehicle according to claim 10, characterized in that, The rule determination unit includes a whitelist field rule base and a sensitive field rule base. The whitelist field rule base is used to limit the read-only access scope at the object level and field level, and the sensitive field rule base is used to limit control class fields that are prohibited from being written.

12. The data isolation transmission system for the safety domain and cabin domain of a two-wheeled vehicle according to claim 10, characterized in that, The state machine management unit works in conjunction with the minimum interaction set cache, and only outputs the minimum interaction set object to the cockpit domain in the minimum interaction set isolation state. The recovery management unit performs signature validity verification, source legitimacy verification, and replay count verification for each recovery stage during the recovery observation state.

Images