Distributed vehicle-mounted client state subscription and control method and device, and electronic equipment

Abstract

The application relates to a distributed vehicle-mounted client state subscription and control method and device and electronic equipment, the method comprising the following steps: a vehicle-mounted SDK initiates registration and binding requests to a server in sequence, the server performs role support, access quantity and equipment qualification verification in sequence, allocates a unique identity for the client after the verification, and establishes a binding relationship between the client and the server; the vehicle-mounted SDK generates a first function available level in combination with the identity and a preset function identity; when a control instruction is issued by a business layer, the vehicle-mounted SDK first verifies the available level, generates a domain control command object after the verification, converts the domain control command object into a standard protocol request through a corrosion layer, and sends the standard protocol request to the server, the server routes the request to a corresponding execution end for execution, state changes are distributed by the SDK in multiple dimensions, associated function execution is cross-domain linkage, and cross-domain collaborative state subscription and control are achieved. Through the above setting, the efficiency of vehicle function control can be improved.

Description

Technical Field

[0001] This invention relates to the field of automotive communication technology, and in particular to a distributed in-vehicle client status subscription and control method, device, and electronic device. Background Technology

[0002] With the intelligent upgrade of special vehicles such as smart RVs and campers, the vehicle control system needs to simultaneously support the access of multiple types of terminals and coordinate the control of multiple subsystems such as the vehicle body, power supply, and climate. This continuously increases the requirements for the scalability and consistency of the system architecture. Existing vehicle client SDKs mostly adopt a design that directly exposes the underlying communication protocol. The business layer needs to parse the protocol data itself. When the protocol is iterated, all business code on all terminals needs to be modified synchronously, resulting in high maintenance costs. At the same time, there is a lack of a unified multi-client access and permission control mechanism. The permission configuration is rigid and cannot adapt to the differentiated positioning and dynamic operation scenarios of multiple terminals. Status acquisition relies on timed polling, which has poor real-time performance and high resource consumption. Multiple terminals are prone to status asynchrony problems. Cross-domain linkage logic is scattered and implemented independently on each terminal. The rules are inconsistent and the amount of redundant development is large, which makes it difficult to meet the development needs of distributed multi-terminal vehicle control. Summary of the Invention

[0003] This invention relates to a distributed vehicle client status subscription and control method, apparatus, and electronic device, which can improve the efficiency of vehicle function control.

[0004] The technical solution proposed in this invention includes a distributed vehicle client state subscription and control method, the method comprising: The vehicle SDK sends registration and binding requests to the server in sequence. The server performs role support verification, role access quantity verification, and device qualification verification on the registration request in sequence. After all verifications are passed, a unique identity is assigned to the client and a binding relationship is established between the client and the server. The vehicle SDK obtains the priority order of the corresponding registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status and vehicle status based on the identity identifier and preset function identifier, and performs multi-level progressive verification to generate the availability level of the first function. When the business layer transmits vehicle control commands, the vehicle SDK first retrieves the availability level of the first function for permission verification. After the verification is successful, a domain control command object is generated, which is converted into a standard protocol request by the anti-corrosion layer and sent to the server. The server routes the standard protocol request to the corresponding execution end for execution. The state changes generated by the vehicle hardware are distributed in multiple dimensions through the vehicle SDK. The server or the main control side executes the cross-domain linkage logic associated with the first function to realize cross-domain collaborative vehicle state subscription and control.

[0005] Preferably, the vehicle SDK adopts a layered and decoupled architecture, which is divided into SDK-API layer, SDK-Runtime layer and protocol contract layer from top to bottom. The vehicle SDK pre-divides the functions of the vehicle system into three domain modules according to business responsibilities: core business domain, support domain and platform domain. Each domain module provides one or more interfaces for status observation, query refresh or control operation according to its responsibilities. The business layer only interacts with the vehicle SDK through the domain interface and is unaware of the underlying communication protocol and connection management logic.

[0006] Preferably, the anti-corrosion layer is deployed in the SDK-Runtime layer of the vehicle SDK, and a bidirectional mapping rule between the underlying communication protocol and the upper domain model is pre-configured: in the inbound direction, the protocol status data, protocol event data, and protocol capability data pushed by the server are mapped into domain status objects, domain event objects, and functional capability objects, respectively; in the outbound direction, the domain control command objects initiated by the business layer are mapped into standard protocol request data, so that changes in the underlying protocol do not affect the stability of the upper business interface.

[0007] Preferably, the multi-level progressive verification targets the first function and executes them sequentially from high to low priority. If a preceding verification fails, the corresponding usability level is directly output, and subsequent verifications are not executed. The verification steps and results are as follows: Registration status verification; if it fails, output the UNAVAILABLE level, indicating complete inaccessibility. Binding status verification; if it fails, output the UNAVAILABLE level. Role permission verification; if it fails, output "UNAVAILABLE" level. Hardware configuration verification; if it fails, output the UNAVAILABLE level. Protocol compatibility check; if it fails, output UNAVAILABLE level. If the network status check fails, output a READ_ONLY level indicating that only the local cache status can be read. Vehicle status verification: If the vehicle is in motion and the function needs to be operated while stationary, output READ_ONLY level; If all checks pass, the output will be a READ_WRITE rating, indicating readability and writability. When the registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, vehicle status, or server capability configuration changes, the vehicle SDK triggers a re-evaluation of the queried or subscribed function and provides the updated results to the business layer.

[0008] Preferably, when the business layer subscribes to vehicle status through the vehicle SDK, the business layer initiates a status subscription request through the domain use case interface of the SDK-API layer. The vehicle SDK returns a reactive state stream object of the corresponding domain to the business layer. The status update message pushed by the server is encoded and decoded and sent to the anti-corrosion layer, converted into a standardized domain state object and updated in the local state repository of the vehicle SDK. Then, the status update is distributed to the subscribers in the terminal through the reactive state stream. The server pushes the status update to the clients that meet the authorization and subscription conditions respectively.

[0009] Preferably, the state changes generated by the vehicle hardware are distributed in multiple dimensions through the domain event bus of the vehicle SDK; the domain event bus supports three subscription dimensions: full event subscription, specific type event subscription, and specific domain event subscription; the domain event carries the domain information of the event source, and when cross-domain linkage is involved, the server or the main control side executes the preset cross-domain linkage logic.

[0010] Preferably, the client registration process is based on a registration state machine to execute state transitions. Initially, it is in an unregistered state. After the vehicle SDK initiates a registration request, it enters the registration in progress state. If the server fails the verification, it enters the failure state and returns the corresponding rejection reason. If the verification passes, it enters the registered state, and the server assigns a unique identity identifier. The registered state transitions to the expired state when the server revokes the registration identity, explicitly determines that the registration identity has expired, or the identity credentials are invalid. Both the failure state and the expired state fall back to the unregistered state, supporting the re-initiation of registration requests.

[0011] Preferably, the client binding process is based on a binding state machine to perform state transitions: after successful registration, the initial state is unbound; after the vehicle SDK initiates a binding request, the process enters the binding state; if the verification fails due to server rejection, network error, or authentication failure, the process enters the failed state; if the verification passes, the process enters the bound state, establishing a binding relationship between the client and the server and obtaining binding credentials for subsequent authentication and connection recovery; the bound state transitions to the expired state in scenarios such as server-side unbinding, invalid binding credentials, server-side resetting of the binding relationship, or ownership change, supporting the re-initiation of binding requests.

[0012] To achieve the above technical solution, this application also includes a distributed vehicle client status subscription and control device, applied to vehicles containing multiple types of vehicle clients. The device includes a business layer, a vehicle SDK, and a server: the business layer initiates status subscription requests and vehicle control requests, and receives status updates distributed by the vehicle SDK; the vehicle SDK performs registration binding, functional availability verification, protocol and domain data conversion, and status distribution within the terminal; the server performs client access verification and binding relationship management, routes control requests to the corresponding execution terminal, and pushes status updates to eligible clients; cross-domain linkage is executed by the server or the main control side.

[0013] To achieve the above technical solution, this application also includes an electronic device, including a memory, a processor, and a computer program stored on the memory, wherein the processor is configured to run the computer program to execute a distributed vehicle client state subscription and control method.

[0014] The beneficial effects of this invention are as follows: First, by constructing a unified client access control system through registration binding and triple access verification, standardized access management of multiple types of terminals is achieved, ensuring access security from the source, while controlling system load and access quantity, and improving operational stability. Second, multi-level progressive dynamic capability assessment covers multiple dimensions such as identity, permissions, hardware, and operating environment, achieving dynamic adaptation of functional availability levels, taking into account differentiated permissions for multiple terminals, hardware adaptation for multiple vehicle models, and driving safety constraints. Third, the anti-corrosion layer design decouples business semantics from underlying protocols, isolating the impact of protocol changes on upper-layer services, and significantly reducing system maintenance costs. Fourth, a unified state distribution and cross-domain linkage mechanism improves the real-time performance of state synchronization and consistency across multiple terminals, and convergence linkage rules avoid redundant development. Overall, a highly cohesive and loosely coupled distributed control system is constructed, significantly improving system scalability and operational efficiency. Attached Figure Description

[0015] Figure 1 This is a structural block diagram of an electronic device.

[0016] Figure 2 This is a flowchart of a distributed in-vehicle client state subscription and control method.

[0017] Figure 3 This is a structural block diagram of a distributed vehicle-mounted client state subscription and control device.

[0018] Reference numerals in the attached figures: 100, electronic device; 11, processor; 12, memory; 200, distributed vehicle client status subscription and control device; 21, business layer; 22, vehicle SDK; 23, server. Detailed Implementation

[0019] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in specific embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0021] It should be noted that the terms "first," "second," and similar terms used in this application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, "a" or "one," and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. "A plurality of" indicates at least two. Unless otherwise stated, terms such as "front," "back," "left," "right," "lower," and / or "upper" are for illustrative purposes only and are not limited to a location or spatial orientation. Terms such as "comprising" or "including" indicate that the elements or objects preceding "comprising" encompass the elements or objects listed following "comprising" or "including" and their equivalents, and do not exclude other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0022] The singular forms “a,” “an,” and “the” used in this application specification and appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] The distributed vehicle client state subscription and control method provided in this embodiment can be executed in electronic device 100 or similar device. Figure 1 This is a hardware structure block diagram of an electronic device 100 that implements an embodiment of this application. For example... Figure 1 As shown, the electronic device 100 may include one or more ( Figure 1 (Only one is shown) Memory 12 and processor 11. The electronic device 100 is a control terminal for vehicle functions, which is used to call multiple functions in the vehicle, thereby improving the control efficiency of vehicle functions.

[0024] The memory 12 stores program instructions, such as application software programs and modules, like the distributed vehicle client status subscription and control method in this embodiment. The processor 11 executes the program instructions stored in the memory 12. By running the computer program stored in the memory 12, it can perform various functional applications and data processing, that is, realize the synchronous invocation and control of multiple vehicle functions.

[0025] The processor 11 may include, but is not limited to, a processing device such as a microcontroller unit (MCU) or a field programmable gate array (FPGA).

[0026] Those skilled in the art will understand that Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100 described above. For example, the electronic device 100 may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0027] like Figure 2 As shown, this invention discloses a distributed vehicle client state subscription and control method, the method comprising: S1 sends registration and binding requests to the server sequentially via the vehicle SDK. The server performs role support verification, role access quantity verification, and device qualification verification on the registration request in sequence. After all verifications are passed, a unique identity is assigned to the client and a binding relationship is established between the client and the server.

[0028] The above steps are used to complete the legitimate identity verification and session establishment of the vehicle terminal. After the vehicle terminal is powered on, the built-in vehicle SDK first sends a registration request and a binding request to the server in sequence. The registration request is used to confirm the legitimacy of the terminal's identity and access qualifications, and the binding request is used to establish the binding relationship between the client and the server.

[0029] The registration request carries the terminal's preset client role information and device hardware information. Upon receiving this information, the server performs three checks in a fixed order. The first check is role support verification. The server maintains a pre-maintained list of client roles supported by the system and verifies whether the currently requested role type is within the supported range. Its purpose is to intercept incompatible terminal types from the source, preventing subsequent communication and business logic anomalies. The second check is role access quantity verification. The server counts the number of terminals successfully accessing under the same role in real time and compares it with the preset maximum access limit per role. Its purpose is to control the concurrent access of similar terminals, preventing excessive system load and control command conflicts caused by too many terminals, thus ensuring system stability. The third check is device qualification verification. The server verifies whether the device meets the access standards for the corresponding role based on the hardware specifications, system version, and security authentication status uploaded by the terminal. Its purpose is to ensure the reliability and security of accessing terminals and avoid control risks caused by unauthorized device access.

[0030] After completing the above three verifications, the server assigns a globally unique identifier to the terminal. This identifier serves as the terminal's unique identity credential within the system and is used throughout all subsequent interactive control processes. After registration, the vehicle SDK initiates a binding request to the server. Following session negotiation and identity authentication, a stable two-way communication session is established between the client and server for subsequent data interaction such as status subscription and command issuance. This setup enables standardized access control for multiple types and numbers of clients, improving the access security and operational stability of electronic devices. Simultaneously, the allocation of a unique identifier provides the identity foundation for subsequent permission assessment, command tracing, and targeted status pushes, a necessary prerequisite for the orderly operation of electronic devices.

[0031] The S2 vehicle SDK obtains the priority order of the corresponding registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, and vehicle status based on the identity identifier and preset function identifier, and performs multi-level progressive verification to generate the availability level of the first function.

[0032] The above settings enable dynamic permission adaptation for vehicle functions. After registration and binding are completed, the vehicle SDK can perform multi-level progressive verification on the specified first function based on the assigned identity identifier and the system's preset function identifier, generating the corresponding availability level. The function identifier is a system-predefined unique index corresponding to a single vehicle function. For example, air conditioning control, battery status viewing, and ambient lighting adjustment each correspond to an independent function identifier, used to accurately locate the specific function to be evaluated. The first function is the target vehicle function currently being verified.

[0033] The verification is performed in a fixed priority order according to registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, and vehicle status. It adopts a progressive judgment logic, that is, if the previous verification fails, the corresponding availability level is directly output and subsequent verifications are not performed, thereby reducing invalid calculations and improving judgment efficiency. Each verification dimension has its own focus: Registration and binding status verification confirms the client's current identity legitimacy and session validity, serving as the basic threshold for function access. Terminals that have not completed legitimate access do not have any function access permissions. Role permission verification is based on the client role corresponding to the identity identifier, matching the preset allowed access role range for that function to achieve differentiated permission control for different types of terminals. For example, small displays only have status viewing permissions, not control permissions. Hardware configuration verification determines whether the corresponding function physically exists based on the actual hardware configuration of the vehicle, automatically adapting the function range for different vehicle models to avoid the problem of displaying a control entry point when the vehicle does not have the corresponding hardware. Network status verification determines the communication connection status between the SDK and the server. When the network is disconnected, the terminal can only read the historical status cached locally and cannot issue real-time control commands. Vehicle status verification combines the vehicle's driving / parking status to restrict functions that require stationary operation, ensuring operational safety during driving.

[0034] The final verification output corresponds to the availability level of the function, guiding the function display and operation permission control at the business layer. Simultaneously, when the status of any verification dimension changes, the system automatically triggers a full reassessment of all functions and pushes the updated results to the business layer, ensuring that the permission status is always synchronized with the actual scenario. Through these settings, multi-dimensional dynamic permission adaptation based on identity, hardware, and operating environment can be achieved. This not only meets the needs of differentiated permission management across multiple terminals but also adapts to the security restrictions of different vehicle models, hardware configurations, and driving scenarios. The progressive verification logic also improves the efficiency of permission judgment and avoids unnecessary computational overhead.

[0035] When the business layer transmits vehicle control commands, the vehicle SDK first retrieves the availability level of the first function for permission verification. After the verification is successful, a domain control command object is generated, which is converted into a standard protocol request by the anti-corrosion layer and sent to the server. The server routes the standard protocol request to the corresponding execution end for execution. The state changes generated by the vehicle hardware are distributed in multiple dimensions through the vehicle SDK. The server or the main control side executes the cross-domain linkage logic associated with the first function to realize cross-domain collaborative vehicle state subscription and control.

[0036] In the above steps, when the business layer transmits vehicle control commands to the vehicle SDK, the vehicle SDK first performs a pre-verification check of the availability level execution permission for the corresponding first function. Only when the availability level meets the control requirements is the command allowed to continue being issued, thus preventing unauthorized operations. After successful verification, the vehicle SDK generates a standardized domain control command object. This object describes the control commands using business domain semantics, without including details of the underlying communication protocol. The business layer only needs to initiate control based on the business semantics, without needing to be aware of the underlying implementation. Subsequently, the command is converted into a standard protocol request conforming to the protocol specification by the anti-corrosion layer and sent to the server. After receiving the protocol request, the server parses it and converts it into the corresponding CAN bus signal, which is then transmitted to the target vehicle hardware to execute the control action, completing the final implementation of the command.

[0037] After control execution is complete, the state change data generated by the vehicle hardware is transmitted back along the original link and distributed in multiple dimensions through the vehicle SDK. Other business domains with preset linkage relationships to the first function automatically execute the corresponding cross-domain linkage logic upon receiving the state change notification, completing multi-system collaborative control. For example, after triggering the rest mode, related systems such as lighting and air conditioning automatically adjust to the corresponding states, eliminating the need for individual user intervention. Through the above settings, a complete control loop is constructed. This ensures the legality and security of control operations through pre-access permission verification, and decouples business processes from protocols through domain-specific instruction design, reducing the impact of underlying protocol changes on upper-layer business processes. Simultaneously, the unified and converged cross-domain linkage logic avoids inconsistencies caused by each terminal independently implementing linkage rules, improving system consistency and user experience in a multi-terminal environment.

[0038] As one implementation method, the vehicle SDK adopts a layered and decoupled architecture, which is divided into SDK-API layer, SDK-Runtime layer and protocol contract layer from top to bottom. The vehicle SDK pre-divides the functions of the vehicle system into three domain modules according to business responsibilities: core business domain, support domain and platform domain. Each domain module provides one or more interfaces for status observation, query refresh or control operation according to its responsibilities. The business layer only interacts with the vehicle SDK through the domain interface and is unaware of the underlying communication protocol and connection management logic.

[0039] The above setup can be applied to multi-terminal vehicle control systems for special vehicles such as campervans. In this system, various client terminals, including the front cabin main control screen, rear cabin control screen, audio-visual entertainment equipment, and small status displays, all integrate the vehicle SDK. Each terminal communicates with the vehicle server through the vehicle SDK, enabling vehicle status subscription and control command issuance. The layered decoupling architecture and domain-based module division can achieve decoupling between interfaces and implementations through vertical layering, and can also achieve reuse and convergence of business logic through horizontal domain division. This solves the technical problems of high coupling of existing vehicle SDK protocols, dispersed business implementations, and large amounts of repetitive development required for new terminal access.

[0040] The in-vehicle SDK adopts a top-down, three-layered, decoupled architecture: the SDK-API layer, the SDK-Runtime layer, and the protocol / contract layer. The boundaries and responsibilities of these three layers are clearly defined, and the implementation details of the lower layers are completely transparent to the upper layers. The SDK-API layer is the only publicly exposed interaction point of the in-vehicle SDK. Centered on business semantics, all exposed capabilities are encapsulated at the business domain level, without including any underlying communication protocols, connection management parameters, or logic. This layer adheres to the principles of ease of use and stability for business users. Business developers only need to call the corresponding interfaces based on vehicle business logic, without needing to understand the underlying communication mechanisms. At the same time, this layer's interfaces remain relatively stable and will not change frequently with adjustments to the underlying protocols, thereby improving the stability of the upper-layer business code.

[0041] The SDK-Runtime layer is the internal implementation layer of the in-vehicle SDK. All core logic, data processing, connection management, and other functions are encapsulated and implemented within this layer, making them completely invisible to upper-layer business logic. This layer carries all the core computation and processing logic of the SDK and serves as the intermediary hub connecting the upper-layer business interface and the lower-layer communication protocol. Modifications, optimizations, and iterations of its internal logic will not affect the upper-layer business layer unless the definition of the external interface is changed.

[0042] The protocol contract layer is located at the bottom layer of the SDK architecture. It is used to define the unified specifications for communication between the vehicle SDK and the server, including data format, interaction process, message type, etc. It is the agreed foundation for the two to achieve bidirectional data interaction. The determination of this layer is based on the consistency requirements of cross-terminal communication, ensuring that the SDK and the server can complete the sending, receiving and parsing of data according to unified rules, avoiding communication anomalies caused by protocol mismatch, and also reserving standardized adjustment space for subsequent protocol upgrades.

[0043] In existing technologies, automotive SDKs expose the underlying protocols to the business layer. If the underlying CAN protocol or communication protocol is upgraded or adjusted, the business application code of all terminals needs to be modified synchronously, increasing maintenance costs. However, through the layered decoupling design described above, the impact of protocol changes is completely confined to the protocol contract layer and the SDK-Runtime layer. During changes at the underlying level, the business layer can adapt to the protocol upgrade without any code adjustments, thereby improving system maintainability and reducing the modification costs associated with protocol iterations. Simultaneously, clear layer boundaries allow for parallel development of each layer. After the interface layer is defined, business development and underlying implementation can proceed simultaneously without interference, effectively improving overall development efficiency.

[0044] It should be noted that in this application, the vehicle SDK pre-divides the vehicle's in-vehicle system functions into three domain modules based on business responsibilities: core business domain, support domain, and platform domain. Each domain module corresponds to a set of vehicle functions with similar business responsibilities. This division method allows for module splitting based on the boundaries of the in-vehicle system's business responsibilities, rather than by hardware modules or communication protocols. This ensures that the module division of the vehicle SDK aligns with the actual business logic, reducing the understanding and usage costs for business developers and achieving unified convergence of business logic. The core business domain corresponds to business modules directly related to user experience and core vehicle functions, covering vehicle functions that users can directly perceive and operate, such as body control, power management, climate control, lighting control, safety alarms, and entertainment systems. This represents the set of functions with the most frequent user interaction. The support domain consists of modules that are applied to the core business domain and provide auxiliary business capabilities. These modules are responsible for implementing cross-domain scene linkage, scheduled tasks, message notifications, and other functions, providing support for the collaborative operation of the core business domain. They are key modules for achieving multi-system collaborative control. The platform domain corresponds to the system-level basic capability modules, providing underlying general capabilities such as client registration and binding, system upgrades, and log management. It provides system-level support for all upper-layer business domains, but does not directly provide business functions to end users.

[0045] All the aforementioned domain modules provide a unified interaction mode, including two standardized interfaces: a state observation interface and a control operation interface. The state observation interface is used to acquire and subscribe to vehicle state data for the corresponding domain, while the control operation interface is used to issue control commands to the corresponding domain. All domain modules follow the same interface design specifications, differing only in the specific state data structure and control command parameters. This standardized interaction reduces the learning and usage costs for the business layer. Once developers master the usage of one domain, they can quickly reuse it for all other domains, avoiding the need to relearn different calling logics for different functions, thus facilitating future expansion of new vehicle features.

[0046] Furthermore, based on the aforementioned layered architecture and domain-based module design, the business layer interacts with the vehicle SDK only through the domain interfaces of the SDK-API layer, without needing to be aware of the underlying communication protocol details, connection management logic, data conversion and processing, and other internal implementations. When setting up the terminal UI and business logic, the business layer only needs to consider the semantics of the business domain itself. For example, it can call the power domain interface to obtain the battery status and issue charging control commands, or call the lighting domain interface to adjust the ambient light brightness. It does not need to know what the CAN signal ID corresponding to these commands is, how the data format is defined, or what protocol is used to communicate with the server at the underlying level. This avoids the problem of a large amount of repetitive development work when different terminals are connected, and also avoids the problem of inconsistent business rules between different terminals.

[0047] As one implementation method, the anti-corrosion layer is deployed in the SDK-Runtime layer of the vehicle SDK, and a bidirectional mapping rule between the underlying communication protocol and the upper domain model is pre-configured: in the inbound direction, the protocol status data, protocol event data, and protocol capability data pushed by the server are mapped into domain status objects, domain event objects, and functional capability objects, respectively; in the outbound direction, the domain control command objects initiated by the business layer are mapped into standard protocol request data, so that changes in the underlying protocol do not affect the stability of the upper business interface.

[0048] In the above setup, the anti-corrosion layer has a two-way mapping mechanism, which can solve the defects of existing vehicle SDKs that directly expose the underlying protocol and have a high degree of coupling between business logic and protocol. By setting up a dedicated semantic conversion layer inside the SDK, the underlying communication protocol and the upper domain model can be completely decoupled.

[0049] The SDK-API layer is the stable external business interface layer, which needs to maintain the constancy of interface definitions and business semantics, and cannot contain volatile protocol conversion logic. The protocol contract layer is a pure communication specification definition layer, which only stipulates the data format, interaction process, and message structure, and does not assume the responsibility of business semantic conversion. The SDK-Runtime layer, as the internal implementation layer, carries all core processing logic that is not exposed externally, and is the intermediate hub connecting the upper-layer business interface and the lower-layer communication protocol. Deploying the anti-corrosion layer in the SDK-Runtime layer can completely encapsulate the protocol conversion logic in the internal implementation, and also allows the anti-corrosion layer to directly call the basic capabilities of the same layer such as encoding and decoding and connection management without cross-layer interaction, thereby improving the data processing efficiency of the vehicle SDK and the cohesion of the internal architecture.

[0050] The anti-corrosion layer is pre-configured with bidirectional mapping rules between the underlying communication protocol and the upper-layer domain model, covering two complete data flows: inbound data push and outbound command issuance. All mapping rules are loaded during the SDK initialization phase. During operation, the appropriate mapping method or degradation processing method can be selected according to the protocol capabilities agreed upon by both communicating parties, and the adjustment process does not affect the definition and use of the upper-layer interface at all. Bidirectional mapping is the core capability of the anti-corrosion layer. Its essence is to establish a one-to-one correspondence conversion rule between two semantic systems. The underlying communication protocol focuses on communication efficiency and hardware compatibility, and its field naming and data structure conform to the CAN bus signal and communication message specifications. The upper-layer domain model focuses on business logic, and its field naming and data structure conform to the business responsibility division of the vehicle system, and are completely independent of hardware implementation and communication methods. The anti-corrosion layer is used to seamlessly convert between these two semantic systems, allowing the upper and lower layers to evolve independently according to their respective rules without interference.

[0051] The inbound direction corresponds to the scenario where the server pushes data to the SDK. This means the data enters from the underlying protocol side, is converted by the anti-corrosion layer, and then output as domain objects that can be directly used by the upper layer. Specifically, this involves three types of data mapping and conversion. The first type is the mapping from protocol state data to domain state objects. Protocol state data is the state update message encapsulated according to the WireProtocol specification after the server parses the original CAN bus signals. Its field naming and data format strictly follow the communication protocol conventions. For example, battery-related states use protocol fields such as `soc` and `charge_power`. The meaning of these fields directly corresponds to the hardware signals and lacks encapsulation of business semantics, making it unusable by the business layer. The anti-corrosion layer uses a preset state mapper to map these protocol fields one by one into standardized domain state objects. These domain state objects use field naming and data structures that conform to business semantics. For example, the `soc` field in the protocol is mapped to `battery level`, and the `charging` field is mapped to `isCharging`. The anti-corrosion layer retains the business state and its validity information provided by the server, without performing business state reasoning within the anti-corrosion layer. This allows the final output domain state object to be directly used by the business layer without secondary parsing and processing.

[0052] The second category is the mapping from protocol event data to domain event objects. Protocol event data consists of event-type messages pushed by the server, such as alarm triggers and mode switching notifications. Their format and type are strongly bound to the communication protocol, lacking a unified business semantic definition. The anti-corruption layer converts these into standardized domain event objects through an event mapper, unifying the event type definition, payload structure, and trigger semantics, allowing upper-layer business domains to subscribe to and process events based on a unified event standard.

[0053] The third category is the mapping from protocol capability data to functional capability objects. Protocol capability data is configuration data related to functional availability issued by the server, corresponding to information such as vehicle hardware configuration and function permission configuration, and the format follows the protocol specification. The anti-corrosion layer converts it into standardized functional capability objects through the capability mapper, which correspond one-to-one with the functional items of the upper-layer domain module, providing a standardized data foundation for judging the functional availability of the upper layer.

[0054] The outbound direction corresponds to the scenario where the SDK sends control commands to the server. This means the data originates from the upper-layer domain and, after being converted by the anti-corrosion layer, is output as request data conforming to the protocol specifications. When the business layer initiates a control operation through the domain interface, a domain control command object is generated. This object is entirely built based on business semantics. For example, a command to set the air conditioner temperature only needs to carry the target temperature value as a business parameter and does not contain any underlying protocol-related information. Business developers only need to pass in the parameters according to the business logic, without needing to understand the underlying details such as the CAN signal ID, data encoding method, and message structure corresponding to the command. The anti-corrosion layer, through a preset command mapper, maps the domain control command object into standard protocol request data, completing a series of processes such as field encoding, message encapsulation, and protocol identifier filling according to the WireProtocol specification, generating a protocol message that can be directly sent to the server.

[0055] Through the aforementioned bidirectional mapping mechanism for inbound and outbound traffic, the anti-corruption layer ensures that changes to the underlying protocol do not affect the stability of the upper-layer business interfaces. All protocol-level changes are completely confined within the anti-corruption layer of the SDK-Runtime layer. Protocol adaptation can be completed simply by adjusting the mapping rules. The domain interfaces of the SDK-API layer remain completely stable, and the code of the upper-layer business applications can adapt to protocol upgrades without any modifications, thereby reducing system maintenance costs and the scope of impact of protocol iterations. Simultaneously, the anti-corruption layer supports the normal execution of a layered, decoupled architecture; it also outputs standardized domain objects that achieve perfect semantic alignment with the state observation interfaces and control operation interfaces of each domain module. Each domain module can directly implement business logic based on standardized domain objects without repeatedly handling protocol parsing, ensuring the consistency of semantics across all domain module interfaces and improving the cohesion and reusability of domain modules.

[0056] As one implementation method, multi-level progressive verification targets the first function and executes them sequentially from high to low priority. If a preceding verification fails, the corresponding usability level is directly output, and subsequent verifications are not executed. The verification steps and results are as follows: Registration status verification; if it fails, output the UNAVAILABLE level, indicating complete inaccessibility. Binding status verification; if it fails, output the UNAVAILABLE level. Role permission verification; if it fails, output "UNAVAILABLE" level. Hardware configuration verification: if it fails, output UNAVAILABLE level; Protocol compatibility verification: if it fails, output UNAVAILABLE level. If the network status check fails, output a READ_ONLY level indicating that only the local cache status can be read. Vehicle status verification: If the vehicle is in motion and the function needs to be operated while stationary, output READ_ONLY level; If all checks pass, the output will be a READ_WRITE rating, indicating readability and writability. When the registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, vehicle status, or server capability configuration changes, the vehicle SDK triggers a re-evaluation of the queried or subscribed function and provides the updated results to the business layer.

[0057] In the above settings, "multiple first functions" refers to a specific vehicle function uniquely identified by a preset function identifier, such as air conditioning temperature adjustment, battery status monitoring, pop-up mechanism control, and ambient light brightness adjustment. The function identifier is a predefined unique index of the function, corresponding one-to-one with the function items of each module in the vehicle SDK. The verification is executed by the vehicle SDK's capability assessment module, running within the SDK-Runtime layer. The core inputs to the verification include the unique identifier assigned by the client, the function identifier to be evaluated, and the real-time status data collected by the system across various dimensions. The final output of the verification is the availability level corresponding to the first function, serving as the basis for determining the permissions for business layer function display and control operations. The verification follows a progressive logic, executing checks from highest to lowest priority. If a previous check fails, the corresponding availability level is directly output, and subsequent checks are not executed. This priority-based progressive verification not only conforms to the order of business logic but also terminates invalid calculations early, improving evaluation efficiency and avoiding unnecessary system overhead.

[0058] The above verification steps are arranged in descending order of priority. Each step has a clear verification objective, data source, and judgment rules, collectively forming a complete permission assessment system. Registration status verification confirms whether the client possesses a legitimate system access identity. This verification is based on the client's current registration status, determined by the preceding registration process and directly associated with the unique identity identifier assigned by the server. Only clients that have completed registration and possess a valid identity identifier have the basic qualification to access system functions. If the client has not completed registration or does not possess a valid identity identifier, i.e., the registration status does not meet the requirements, the UNAVAILABLE level is directly output, meaning that this function cannot be viewed or controlled. Binding status verification confirms whether a valid two-way communication session has been established between the client and the server. If the client has not completed binding or does not have a stable communication session, it cannot receive real-time status pushes from the server, nor can it issue control commands to the server; therefore, the UNAVAILABLE level is also output. Role-based permission verification is used to implement differentiated function permission management for different types of terminals. The execution logic of this verification is as follows: First, based on the client's unique identifier, query the client role bound to that identity, such as the front cabin main control screen role, rear cabin secondary screen role, small display screen role, audio-visual equipment role, etc.; then, obtain the preset set of allowed access roles corresponding to the function identifier of the current first function, and compare whether the current client role belongs to the allowed set. If the current role is not within the allowed access range, the UNAVAILABLE level is output. This verification is based on fine-grained permission allocation for roles, matching different function access ranges for terminals with different positioning. For example, the small display screen only has basic status viewing permissions and does not have core vehicle control permissions, and the audio-visual equipment only has access permissions for entertainment system-related functions, thereby adapting to the differentiated product positioning of multiple terminals, avoiding unauthorized operations at the architectural level, and also allowing permission configuration to be flexibly adjusted based on the verification object without modifying the business logic.

[0059] Hardware configuration verification is used to adapt to differences in hardware configurations across different vehicle models. This verification uses the vehicle's hardware configuration information, determined by the vehicle's factory settings, distributed by the server and stored locally in the SDK, to determine whether the vehicle is equipped with the physical hardware for a specific function. If the vehicle hardware corresponding to the current primary function does not exist or the vehicle configuration does not support the function, an "UNAVAILABLE" level is output. This verification can solve the adaptation problem of inconsistent hardware configurations across different vehicle models. The same in-vehicle SDK and business logic can adapt to different vehicle configurations without the need to develop separate business code for different hardware configurations. The system automatically hides unsupported function entries based on the actual vehicle hardware configuration, thereby improving the solution's vehicle model adaptability and scalability, and reducing the development and maintenance costs of multi-vehicle model adaptation.

[0060] Network status verification is used to differentiate functional availability in online and offline scenarios. This verification is based on the real-time network connection status between the vehicle SDK and the server, which is monitored and maintained in real-time by the vehicle SDK's connection management module. If the network is disconnected and real-time communication with the server is impossible, a READ_ONLY level is output, indicating that the function can only view historical status data cached locally and cannot send real-time control commands to the server. This verification implements service degradation in offline scenarios, ensuring that users can still view the last synchronized vehicle status when the network is disconnected, while prohibiting control operations in offline mode to avoid operational ambiguity and user confusion caused by command execution failures, thus balancing availability and operational accuracy in offline scenarios.

[0061] Vehicle status verification is used to enforce safe operation constraints in driving scenarios. This verification checks the vehicle's current driving or parked status and whether the first function has a preset safety rule that it can only be operated while stationary. If the vehicle is in motion, and the function is a safety-sensitive function that poses a safety risk when operated while in motion and requires stationary operation, a READ_ONLY level is output, prohibiting control operations while in motion. This verification ensures driving safety at the system level. For functions such as the control of the pop-up mechanism and tailgate, which pose safety hazards when operated while in motion, control permissions are automatically disabled while in motion, retaining only the ability to view the status, to avoid risks caused by inconsistent safety rules across different terminals. When all verifications pass, a READ_WRITE level is output, indicating that the function is fully available, and the business layer can both subscribe to real-time status data and issue control commands.

[0062] When registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, vehicle status, or server-side capability configuration changes, the vehicle SDK automatically triggers a full reassessment of all functions. For example, scenarios such as a network change from connected to disconnected, a vehicle change from parked to driving, client registration expiration, or the server issuing new function permission configurations will all automatically trigger the reassessment process. After the reassessment is complete, the SDK proactively pushes the updated function availability level results to the business layer. The business layer can dynamically adjust the UI display based on the latest results, such as graying out unavailable control buttons, hiding unsupported function entries, and updating function operation prompts. These settings facilitate real-time synchronization of function availability levels with actual operating scenarios, eliminating the need for the business layer to actively poll for permission status. This improves the real-time synchronization of permission status and simplifies the development logic of the business layer, thereby avoiding the performance overhead and status latency caused by polling.

[0063] Furthermore, the multi-level progressive verification mechanism, layered architecture, and domain-specific module division provide clear functional boundaries for capability assessment. Each functional identifier corresponds one-to-one with the functional items of the corresponding domain module, and the assessment results can be directly applied to the status observation interface and control operation interface of the corresponding domain, achieving seamless integration of access control and business interfaces. In addition, the two-way mapping mechanism of the anti-corrosion layer ensures that underlying data such as hardware configuration and vehicle status can be converted into standardized domain objects, providing a unified and stable input data source for capability assessment and avoiding the impact of underlying protocol changes on the stability of the assessment logic.

[0064] As one implementation method, when the business layer subscribes to vehicle status through the vehicle SDK, the business layer initiates a status subscription request through the domain use case interface of the SDK-API layer. The vehicle SDK returns a reactive state stream object of the corresponding domain to the business layer. The status update message pushed by the server is encoded and decoded and sent to the anti-corrosion layer, converted into a standardized domain state object and updated in the local state repository of the vehicle SDK. Then, the status update is distributed to the subscribers in the terminal through the reactive state stream. The server pushes the status update to the clients that meet the authorization and subscription conditions respectively.

[0065] In this embodiment, the business layer initiates a state subscription request through the domain use case interface of the SDK-API layer, which is the starting point of the entire state synchronization process. The domain use case interface corresponds to the state observation interface uniformly provided externally by each domain module. It is the standardized subscription entry point exposed by the vehicle SDK and corresponds one-to-one with each business domain of the vehicle system. For example, the power battery domain corresponds to the battery state subscription interface, the climate control domain corresponds to the air conditioning state subscription interface, and the lighting system domain corresponds to the lighting state subscription interface. When the business layer initiates a subscription, it only needs to call the state observation method of the corresponding domain based on business semantics. Through the above settings, following the domain-driven interface encapsulation principle, the subscription interface is fully aligned with the actual business logic, thus reducing the usage and understanding threshold for the business layer. Simultaneously with the subscription request, the SDK performs a pre-permission check based on the multi-level capability evaluation results. Only when the availability level of the corresponding function meets the read requirements will the subscription request take effect normally; if the function is completely unavailable, a corresponding prompt is directly returned to the business layer to avoid invalid subscription links. This design allows state subscription and permission control to form a natural synergy, ensuring the legitimacy of state access from the entry point.

[0066] Reactive state streams are asynchronous data stream carriers built on reactive programming principles. They possess core characteristics such as proactive data push, sequential delivery, flexible unsubscription, and support for traffic control, fundamentally differing from traditional single-query, single-call state acquisition modes. After the business layer obtains the state stream object, it can continuously receive state updates through a subscription listener. Whenever new state data is generated, it is automatically sent to the business layer. This setup solves the resource waste and update delay problems of traditional polling modes. Vehicle state changes are primarily propagated through proactive push, reducing invalid queries and computational processing compared to timed polling. This benefits both reducing network bandwidth overhead and terminal computing resource consumption, and improving the real-time performance of state updates.

[0067] Furthermore, the status update messages pushed by the server are encoded and decoded before being sent to the anti-corrosion layer, which is the first processing step after the status data enters the SDK from the server. The real-time status data of the vehicle is collected, parsed, and aggregated by the server from the vehicle's CAN bus, and then encapsulated into standardized status update messages according to the communication specifications agreed upon in the protocol contract layer. These messages are then actively pushed to all client terminals that have subscribed to the corresponding status. Upon receiving the messages, the connection management module of the vehicle SDK first hands them over to the codec at the same layer for deserialization processing, parsing the binary or serialized protocol messages into recognizable protocol status data. After decoding, the original protocol data is sent to the anti-corrosion layer deployed in the SDK-Runtime layer for business semantic conversion. The incoming protocol status data undergoes a series of conversions, including field renaming, data structure reorganization, and business logic adaptation, through preset status mapping rules, ultimately outputting standardized domain status objects that conform to business semantics. Through the above settings, the technical details of the underlying protocol, such as field naming, data encoding, and message structure, are completely shielded within the SDK implementation, ensuring that the output to the upper layer is always a stable and unified business state object. When the underlying CAN signal definition or communication protocol format is upgraded or changed, only the mapping rules within the anti-corrosion layer need to be adjusted to complete the adaptation, so that the subscription interface and state data structure of the SDK-API layer remain completely stable.

[0068] The local state repository is a state management module deployed in the SDK-Runtime layer. It stores the latest state snapshots of each business domain, maintains all active subscription relationships, and uniformly manages the distribution logic of state data. Domain state objects output by the anti-corruption layer are first updated in the state repository, overwriting historical state snapshots of the corresponding domain, ensuring that the latest vehicle state data is always stored locally. The local caching design allows the terminal to still read the last synchronized state data in offline scenarios where the network is disconnected and the server is not pushing data. This provides data support for offline service degradation and works in conjunction with the design of outputting the READ_ONLY availability level when the network is offline, providing a real data source for offline readable capabilities. Simultaneously, as a unified state distribution hub, the state repository ensures that all subscription requests for the same domain share the same state data source, avoiding duplicate data parsing and redundant storage in multi-subscription scenarios, effectively improving the internal operating efficiency and data consistency of the SDK.

[0069] Ultimately, the in-vehicle SDK distributes state updates to subscribers within the terminal via reactive state streams. After the state repository completes the state update, it proactively distributes the latest domain state object to all business layer components that have subscribed to that state via the corresponding domain's reactive state stream. In a multi-terminal distributed scenario, each client terminal accessing the system independently maintains its own SDK instance and local state repository. The server pushes the corresponding state updates to clients that meet the authorization and subscription conditions. The SDKs of each terminal execute completely consistent decoding, mapping, updating, and distribution processes. When the authorization and subscription conditions are consistent, the states of each terminal can gradually converge to the same state fact provided by the server, avoiding the inconsistency in state display caused by different polling times of each terminal in the traditional polling mode, thereby improving real-time performance.

[0070] As one implementation method, state changes generated by vehicle hardware are distributed in multiple dimensions through the domain event bus of the vehicle SDK; the domain event bus supports three subscription dimensions: full event subscription, specific type event subscription, and specific domain event subscription; the domain event carries the domain information of the event source, and when cross-domain linkage is involved, the server or the main control side executes the preset cross-domain linkage logic.

[0071] In the above arrangement, the domain event bus is deployed inside the SDK-Runtime layer of the vehicle-mounted SDK, which is the core communication module of the SDK internal implementation layer, and works in coordination with modules such as the state repository, the anti-corrosion layer, and the connection manager at the same layer. The domain event bus and the reactive state stream complement each other, and together form a complete vehicle-mounted data interaction system. The reactive state stream carries continuously changing state data, is oriented to scenarios such as state presentation and data caching, and always retains the latest state snapshot; while the domain event bus carries event notifications that occur instantaneously, is oriented to scenarios such as action triggering, alarm reminding, and linkage response, and completes distribution immediately after the event is triggered, without retaining persistent state snapshots. The complete circulation link of event data is deeply coordinated with the anti-corrosion layer architecture. After the vehicle hardware produces a state change, the original signal is transmitted to the server via the vehicle CAN bus. After the server completes signal analysis and event aggregation, it encapsulates the signal into a protocol event message in accordance with the specifications of the protocol contract layer, and actively pushes it to the client SDK; after the SDK receives the message, it undergoes encoding and decoding processing, and sends it to the anti-corrosion layer for inbound mapping, which converts the protocol event data into a standardized domain event object, and finally delivers it to the domain event bus for multi-dimensional distribution, so as to avoid the change of the underlying protocol from affecting the upper-layer event subscription logic.

[0072] In this implementation, full event subscription supports subscribing to all types of events generated across all domains within the system, suitable for scenarios such as log collection, full status monitoring, and system debugging. This dimension is designed to meet the needs of global monitoring, allowing system-level modules to fully acquire all event data for log archiving, troubleshooting, and operational status analysis. Specific event type subscription supports subscription based on event type, such as subscribing only to status change events, control result events, and exception notification events, without being restricted by the business domain. Filtering by type allows modules to receive only the event types they are interested in, reducing interference from irrelevant events and improving processing efficiency. Specific domain event subscription supports subscription based on business domain, such as subscribing only to events in the power battery domain, only to events in the lighting system domain, and only to events in the safety alarm domain. Each business domain only needs to subscribe to events relevant to its own domain, ensuring clear responsibilities and facilitating the independent maintenance of its own event subscription logic when expanding to new domains. Alarm events, as event types, are subscribed to by event type, supporting unified subscription of alarm events generated across all business domains, such as tire pressure alarms, CO concentration exceeding limits alarms, and low battery alarms. The purpose of this dimension is to isolate safety alarm events from various business domains, allowing the safety alert module to uniformly listen to and process all alarm information. This avoids issues such as inconsistent alert rules and missed alarms caused by alarm logic being scattered across different business domains, thus improving the reliability of in-vehicle safety alarms. Connection status events, also as event types, are subscribed to by event type, such as connection establishment, connection termination, successful reconnection, and connection timeout. This dimension provides the business layer with an independent entry point for connection status awareness. The business layer can update UI prompts and adjust business logic based on connection events, such as indicating offline status when the network is disconnected and switching to offline degradation mode. These different subscription dimensions, from global to segmented and from general to specific, form a tiered subscription system that meets the differentiated subscription needs of different scenarios while avoiding the performance overhead and logical interference caused by broadcasting all events.

[0073] Domain events carry an event identifier, the time of occurrence, and source domain information to identify the source of the event.

[0074] When cross-domain collaboration is involved, the server or main control side executes the corresponding processing according to the preset collaboration rules and pushes the processing results to the relevant clients.

[0075] As one implementation method, the client registration process is based on a registration state machine to execute state transitions. Initially, it is in an unregistered state. After the vehicle SDK initiates a registration request, it enters the registration in progress state. If the server fails the verification, it enters the failure state and returns the corresponding rejection reason. If the verification passes, it enters the registered state, and the server assigns a unique identity identifier. The registered state transitions to the expired state when the server revokes the registration identity, explicitly determines that the registration identity has expired, or the identity credentials are invalid. Both the failure state and the expired state fall back to the unregistered state, supporting the re-initiation of registration requests.

[0076] In the above setup, the client registration process is based on a registration state machine that executes state transitions. This registration state machine belongs to the registration and binding module under the vehicle SDK platform domain, runs within the SDK-Runtime layer, and collaborates with the server's access control module to complete the client's identity verification. The state machine follows the design principles of finite states, explicit transitions, and recoverable exceptions. All state transitions are triggered by explicit events, eliminating random state changes and ensuring the orderliness and stability of the registration process from an architectural perspective. The initial state of the state machine is unregistered. When the terminal powers on and the vehicle SDK completes initialization, it defaults to the unregistered state. Clients in this state have not yet submitted an identity request to the server and do not possess any system access rights; all function access requests will be intercepted by pre-verification. The core purpose of setting this initial state is to ensure system access security from the default state. Terminals that have not completed identity authentication have no system permissions by default, thus mitigating the risk of unauthorized access from the source.

[0077] Meanwhile, when the registration process is triggered by the business layer or within the SDK, the state machine first checks whether the current state is "unregistered." Only if the state is "unregistered" will a registration request be allowed. After the request is sent, the state machine automatically transitions the current state from "unregistered" to "registering." The "registering" state marks that a registration request has been sent and is waiting for a server response. In this state, the SDK actively intercepts duplicate registration requests to avoid multiple registration applications caused by repeated triggering on the same terminal, thus preventing processing pressure and state conflicts caused by receiving duplicate requests on the server.

[0078] If the server-side verification fails, the system enters a failure state and returns the corresponding rejection reason. After receiving a registration request, the server sequentially performs three access checks: role support verification, role access quantity verification, and device qualification verification. If any one of these checks fails, a registration failure response is returned to the SDK along with the corresponding rejection reason. Upon receiving the failure response, the SDK transitions its status from "registering" to "failed" and simultaneously forwards the rejection reason to the upper-layer business layer. Specifically, a failed role support verification means the requested role is not supported by the system; a failed role access quantity verification means the number of connected terminals for the same role has reached the system limit; and a failed device qualification verification means the terminal's hardware specifications, system version, or security certification do not meet the access standards. This configuration allows the business layer to display differentiated prompts to users for different failure scenarios, improving user-friendliness and reducing troubleshooting costs. The failure state is not the final state. After the preset failure handling logic, the state will automatically fall back to the unregistered state, allowing the terminal to re-initiate the registration request. This ensures recoverability in temporary abnormal scenarios, such as verification timeouts caused by network fluctuations or temporary quantity limits. The terminal can automatically or manually retry the registration.

[0079] In this implementation, upon successful verification, the client enters the registered state and is assigned a unique identity identifier by the server. After all three verifications pass, the server generates a globally unique identity identifier for the client and returns it to the SDK along with the registration success response. Upon receiving the success response, the SDK transitions its state from "registering" to "registered," and simultaneously persists the unique identity identifier assigned by the server. The registered state is the successful final state of the registration process, representing that the client has obtained a legally recognized access identity, serving as a prerequisite for subsequent binding processes and functional permission assessments. The unique identity identifier is deeply bound to the current registration state, and a multi-level capability assessment mechanism is in place. The first step, registration state verification, uses the current state of the state machine as the basis for judgment; only terminals in the registered state can proceed to subsequent binding, role permission, and other verification stages. Simultaneously, when the registration state transitions to "registered," a registration success event is published through the domain event bus. Relevant business modules can subscribe to this event to automatically trigger subsequent processes, such as automatically initiating binding requests, refreshing the functional permission list, and updating the terminal identity display, thus achieving decoupling and linkage between the registration process and other modules.

[0080] Meanwhile, the registered state is not permanent. When the server revokes a registration, explicitly determines that the registered identity has expired, or the identity credentials are invalid, the server will push an identity expiration notification to the SDK. When the network connection is interrupted, the connection recovery process handles the issue without directly changing the registration state. After the expiration condition is triggered, the state machine transitions the state from registered to expired. The expired state is designed to achieve dynamic lifecycle management of registered identities, avoiding the security risks caused by long-term expired identities remaining in the system, and ensuring the timeliness and security of system access identities. Similar to the failed state, the expired state is not final; after the state transition is complete, it will also revert to the unregistered state, supporting the terminal to re-initiate a registration request, thus achieving automatic recovery capability after identity expiration.

[0081] The registration state machine works closely with the aforementioned layered architecture, anti-corruption layer mapping, multi-level capability assessment, reactive state flow, and domain event bus. Belonging to the platform domain's registration binding module, the registration state machine operates within a domain module system divided by business responsibilities, with clear boundaries between its responsibilities and those of other business domains, adhering to the design principles of high cohesion and low coupling. The sending of registration requests and the receiving of responses both undergo bidirectional mapping between protocols and domains through the anti-corruption layer. The state machine only processes standardized domain-level registration results, unaffected by changes in the underlying communication protocol, ensuring the long-term stability of the registration logic. The real-time registration status maintained by the state machine serves as the first line of verification for multi-level capability assessment. Every change in the registration status automatically triggers a reassessment of all functions, achieving real-time synchronization of permission and identity status. The registration status itself can also be exposed to the business layer through reactive state flow. The business layer can subscribe to the state flow to perceive changes in the registration status in real time, eliminating the need for active polling and reducing development complexity. Each registration-related event generated during a state transition is distributed in multiple dimensions through the domain event bus, allowing other modules to subscribe and interact. This decouples the registration module from other functional modules and avoids hard dependencies between modules.

[0082] As one implementation method, the client binding process executes state transitions based on a binding state machine: after successful registration, the initial state is unbound; after the vehicle SDK initiates a binding request, the process enters the binding state; if verification fails due to server rejection, network error, or authentication failure, the process enters the failed state; if verification passes, the process enters the bound state, establishing a binding relationship between the client and the server and obtaining binding credentials for subsequent authentication and connection recovery; the bound state transitions to the expired state in scenarios such as server-side unbinding, invalid binding credentials, server-side resetting of the binding relationship, or ownership change, supporting the re-initiation of binding requests.

[0083] In the above setup, the binding state machine and the registration state machine both belong to the registration and binding module under the vehicle SDK platform domain. They run within the SDK-Runtime layer and work in conjunction with modules such as the connection manager, anti-corrosion layer, and domain event bus in the same layer. The binding and registration processes have a clear dependency relationship. The registration process resolves the client's identity legitimacy issue and obtains a globally unique identity identifier upon completion. The binding process establishes the binding relationship between the client and the server. Communication connections are established and restored by the connection management process, and real-time status pushes and control command interactions are completed through the currently valid connection. Registration and binding are separated into two independent state machines. Based on the difference in the lifecycle of identity and session, client identity has relatively long-term validity, while communication sessions change frequently due to network fluctuations, server upgrades, token expiration, and other factors. After decoupling, when a session fails, communication can be restored simply by re-executing the binding process, without needing to repeatedly initiate identity registration, thus reducing the identity verification pressure on the server.

[0084] Simultaneously, upon successful registration, the client initially enters an unbound state, which is the initial state of the binding state machine. Once the client completes registration and enters the registered state, the binding state machine automatically initializes to the unbound state. In this state, although the client possesses a legitimate identity, it has not yet established a valid binding relationship with the server, cannot receive real-time status pushes from the server, and cannot send real-time control commands to the server; it can only read locally cached historical state data. Setting unbound as the default state after registration clearly defines the hierarchical boundary between identity and session, and also reserves flexible binding triggering times for the business layer. This allows the business layer to choose automatic binding after registration or manual binding when real-time functionality is needed, thereby improving flexibility.

[0085] In this implementation, when the binding process is triggered within the business layer or SDK, the state machine first verifies whether the current registration status is valid and whether the binding status is unbound. Only when all conditions are met will a binding request be initiated to the server based on the unique identifier assigned by the server. After the request is sent, the state machine automatically transitions the current status from unbound to binding. The core function of the binding state is to mark that a session establishment request has been sent and is waiting for a server response. In this state, the SDK actively intercepts duplicate binding requests to avoid multiple session requests caused by repeated triggering from the same terminal, preventing redundant sessions and state conflicts on the server side, thereby improving the stability and orderliness of the binding process.

[0086] If verification fails due to server rejection, network errors, or authentication failure, the system will enter a failure state. After receiving a binding request, the server performs multi-dimensional verification of the client's identity, authentication token, and access permissions. Simultaneously, the SDK monitors the communication link status. Any anomaly in any link will trigger a binding failure, causing the state machine to transition from binding to a failure state, carrying the corresponding failure reason. In this setting, the following reasons and corresponding scenarios are included: server rejection corresponds to server-side permission anomalies such as client identity being deregistered or access permissions being revoked; network errors correspond to transport layer anomalies such as communication link disconnection or network timeout; authentication failure corresponds to security verification anomalies such as expired session token or signature verification failure. Through these settings, the business layer can adopt differentiated handling strategies for different anomaly scenarios. For example, automatic retries for network errors, re-acquiring the token for authentication failures, and prompting insufficient user permissions when the server rejects the request. This improves the user-friendliness of the interaction and reduces the difficulty of troubleshooting.

[0087] When verification passes, the client enters the bound state, establishing a binding relationship and obtaining binding credentials for subsequent authentication and connection recovery. Once all server-side verifications pass and the bidirectional communication link is established, the SDK receives a successful binding response, and the state machine transitions from the bound state to the bound state, simultaneously initializing session parameters and subscription relationships. The bound state indicates that the binding relationship between the client and server is valid, and communication connections can be established or restored based on binding credentials. Core business functions such as reactive state subscription and control command issuance must be executed normally in the bound state. This state is directly related to multi-level capability assessment. The second layer of binding state verification in multi-level verification uses the current state of the state machine as the basis for judgment. Only terminals in the bound state can pass the verification and enter subsequent assessment stages such as role permissions and hardware configuration. When the binding state changes from bound to another state, a full reassessment of all functions is automatically triggered, adjusting the function availability level in real time and achieving synchronous updates of permission status and session status.

[0088] The bound state transitions to the invalidated state in scenarios such as server-side unbinding, invalidation of binding credentials, server-side resetting of binding relationships, and ownership changes. When a specific session invalidation trigger event occurs, the server pushes a session invalidation notification to the SDK. The SDK identifies the connection interruption through the connection management process and performs connection recovery, preventing binding invalidation from being directly triggered by ordinary connection interruptions. These scenarios include: server-side unbinding (corresponding to the operation and maintenance scenario where the management backend actively disconnects the terminal connection); token expiration (corresponding to the security control scenario where the session security token expires); server-side resetting (corresponding to the system maintenance scenario of server restart and version upgrade); and ownership change (corresponding to the asset change scenario of vehicle user identity change and device permission transfer). This setting avoids the security risks and resource waste caused by residual invalidated sessions. Similar to the failed state, the invalidated state is not a final state. After the state transition is complete, it will fall back to the unbound state, supporting the terminal to re-initiate a binding request. In temporary failure scenarios such as network fluctuations, the SDK can also automatically trigger reconnection, restoring communication without manual intervention, significantly improving system availability and fault tolerance.

[0089] To achieve the above technical solution, this application also includes a distributed vehicle client status subscription and control device, applied to vehicles containing multiple types of vehicle clients. The device includes a business layer, a vehicle SDK, and a server: the business layer initiates status subscription requests and vehicle control requests, and receives status updates distributed by the vehicle SDK; the vehicle SDK performs registration binding, functional availability verification, protocol and domain data conversion, and status distribution within the terminal; the server performs client access verification and binding relationship management, routes control requests to the corresponding execution terminal, and pushes status updates to eligible clients; cross-domain linkage is executed by the server or the main control side.

[0090] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0091] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A distributed vehicle client state subscription and control method, characterized in that, include: The vehicle SDK sends registration and binding requests to the server in sequence. The server performs role support verification, role access quantity verification, and device qualification verification on the registration request in sequence. After all verifications are passed, a unique identity is assigned to the client and a binding relationship is established between the client and the server. The vehicle SDK obtains the priority order of the corresponding registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status and vehicle status based on the identity identifier and preset function identifier, and performs multi-level progressive verification to generate the availability level of the first function. When the business layer transmits vehicle control commands, the vehicle SDK first retrieves the availability level of the first function for permission verification. After the verification is successful, a domain control command object is generated, which is converted into a standard protocol request by the anti-corrosion layer and sent to the server. The server routes the standard protocol request to the corresponding execution end for execution. The state changes generated by the vehicle hardware are distributed in multiple dimensions through the vehicle SDK. The server or the main control side executes the cross-domain linkage logic associated with the first function to realize cross-domain collaborative vehicle state subscription and control.

2. The distributed vehicle client state subscription and control method according to claim 1, characterized in that, The in-vehicle SDK adopts a layered and decoupled architecture, which is divided into SDK-API layer, SDK-Runtime layer and protocol contract layer from top to bottom. The in-vehicle SDK pre-divides the functions of the in-vehicle system into three domain modules according to business responsibilities: core business domain, support domain and platform domain. Each domain module provides one or more interfaces for status observation, query refresh or control operation according to its responsibilities. The business layer only interacts with the in-vehicle SDK through the domain interface and is unaware of the underlying communication protocol and connection management logic.

3. The distributed vehicle client state subscription and control method according to claim 2, characterized in that, The anti-corrosion layer is deployed in the SDK-Runtime layer of the vehicle SDK and is pre-configured with bidirectional mapping rules between the underlying communication protocol and the upper-layer domain model: In the inbound direction, the protocol status data, protocol event data, and protocol capability data pushed by the server are mapped into domain status objects, domain event objects, and functional capability objects, respectively; In the outbound direction, the domain control command objects initiated by the business layer are mapped into standard protocol request data, so that changes in the underlying protocol do not affect the stability of the upper-layer business interface.

4. The distributed vehicle client state subscription and control method according to claim 3, characterized in that, The multi-level progressive verification targets the first function and executes them sequentially from high to low priority. If a preceding verification fails, the corresponding availability level is directly output, and subsequent verifications are not executed. The verification steps and results are as follows: Registration status verification; if it fails, output the UNAVAILABLE level, indicating complete inaccessibility. Binding status verification; if it fails, output the UNAVAILABLE level. Role permission verification; if it fails, output "UNAVAILABLE" level. Hardware configuration verification; if it fails, output the UNAVAILABLE level. Protocol compatibility check; if it fails, output UNAVAILABLE level. If the network status check fails, output a READ_ONLY level indicating that only the local cache status can be read. Vehicle status verification: If the vehicle is in motion and the function needs to be operated while stationary, output READ_ONLY level; If all checks pass, the output will be a READ_WRITE rating, indicating readability and writability. When the registration status, binding status, role permissions, hardware configuration, protocol compatibility, network status, vehicle status, or server capability configuration changes, the vehicle SDK triggers a re-evaluation of the queried or subscribed function and provides the updated results to the business layer.

5. The distributed vehicle client state subscription and control method according to claim 4, characterized in that, When the business layer subscribes to vehicle status through the vehicle SDK, it initiates a status subscription request through the domain use case interface of the SDK-API layer. The vehicle SDK returns a reactive state stream object of the corresponding domain to the business layer. The status update message pushed by the server is encoded and decoded and sent to the anti-corrosion layer, converted into a standardized domain state object and updated in the local state repository of the vehicle SDK. Then, the status update is distributed to the subscribers in the terminal through the reactive state stream. The server pushes the status update to the clients that meet the authorization and subscription conditions respectively.

6. The distributed vehicle client state subscription and control method according to claim 5, characterized in that, State changes generated by vehicle hardware are distributed in multiple dimensions through the domain event bus of the in-vehicle SDK; the domain event bus supports three subscription dimensions: full event subscription, specific type event subscription, and specific domain event subscription. Domain events carry information about the domain from which the event originates. When cross-domain collaboration is involved, the server or the main control side executes the preset cross-domain collaboration logic.

7. The distributed vehicle client state subscription and control method according to claim 6, characterized in that, The client registration process is based on a registration state machine to execute state transitions. It starts in an unregistered state, enters the registration process state after the vehicle SDK initiates a registration request, and enters the failure state if the server verification fails, and returns the corresponding rejection reason. If the verification passes, the user enters the registered state and is assigned a unique identity identifier by the server. If the registered status is revoked by the server, or if the registered status is found to be expired or the identity credentials are invalid, the user will be transferred to the expired state. Both the failed state and the expired state will revert to the unregistered state, and the user can re-initiate the registration request.

8. The distributed vehicle client state subscription and control method according to claim 7, characterized in that, The client binding process is based on a binding state machine to execute state transitions: after successful registration, the initial state is unbound. After the vehicle SDK initiates a binding request, it enters the binding state. If the verification fails due to server rejection, network error, or authentication failure, it enters the failed state. If the verification passes, it enters the bound state, establishes the binding relationship between the client and the server, and obtains binding credentials for subsequent authentication and connection recovery. In the bound state, the process transitions to the expired state in scenarios such as server-side unbinding, invalid binding credentials, server-side resetting of the binding relationship, or ownership change, and supports re-initiating the binding request.

9. A distributed vehicle client state subscription and control device, applied to a vehicle containing multiple types of vehicle clients, characterized in that, include: The business layer is used to initiate status subscription requests and vehicle control requests through the vehicle SDK, and to receive status updates distributed by the vehicle SDK. The vehicle SDK is used to initiate registration and binding requests to the server, verify the availability of target functions, convert vehicle control requests that pass verification into standard protocol requests and send them to the server, and convert and distribute status updates pushed by the server to subscribers within this terminal. The server is used to perform client access verification and binding relationship management, route standard protocol requests to the corresponding execution end, and push status updates to clients that meet the authorization and subscription conditions; among them, cross-domain linkage is executed by the server or the main control side.

10. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored on the memory, wherein the processor is configured to run the computer program to perform the distributed vehicle client state subscription and control method according to any one of claims 1 to 8.

Images