Instruction generation method and vehicle

Abstract

The application discloses an instruction generation method and a vehicle, and belongs to the technical field of intelligent networking. By introducing a dynamic and on-demand loading protocol stack management mechanism, on-demand calling of the protocol stack is realized instead of full-amount resident. Before being connected with a mobile device or before identifying a protocol type supported by the mobile device, a candidate protocol stack is stored in a non-volatile storage unit, without occupying running memory. After identification is completed and a target protocol stack is determined, the target protocol stack is loaded, that is, the required target protocol stack is called into memory. Thus, all protocol stacks do not need to be pre-loaded and kept in a ready state for compatibility with multiple protocols, resource occupation and resource conflicts caused by simultaneous resident of multiple protocol stacks in memory are avoided, and the vehicle system can efficiently support multiple digital key protocols on a single hardware platform.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to an instruction generation method and a vehicle in the field of intelligent connected vehicle technology. Background Technology

[0002] With the development of automotive intelligence, digital key technology has become a standard feature in vehicles. Currently, multiple digital key standards coexist in the market, including the CCC (Car Connectivity Consortium) standard, the ICCE (Intelligent Car Connectivity Industry Ecosystem Alliance) standard, the ICCOA (Intelligent Car Connectivity Open Alliance) standard, and proprietary protocols from various automakers. Different mobile device manufacturers support different types of protocols, and to ensure compatibility with multiple protocols, vehicles typically need to be equipped with independent hardware modules for each protocol or have multiple protocol stacks resident in the system.

[0003] The solution of having multiple protocol stacks running continuously leads to the continuous occupation of system memory and processor resources. When multiple protocol stacks run simultaneously and compete for the same hardware resources, the system response latency increases, affecting the stability of the digital key function. For the solution that adopts static fixed management of protocol stacks, the supported protocol types are pre-defined during system deployment. Faced with the uncertainty of connected devices in actual use, the system always keeps all protocol stacks in a ready state, resulting in low resource utilization.

[0004] The aforementioned issues make it difficult to achieve both multi-protocol compatibility and efficient utilization of system resources on a single hardware platform. Vehicles face the dual constraints of hardware cost and system complexity in order to realize multi-standard digital key functionality. Summary of the Invention

[0005] This application provides an instruction generation method and a vehicle that can balance multi-protocol compatibility and efficient utilization of system resources. The technical solution is as follows: On the one hand, an instruction generation method is provided, the method comprising: When connected to a mobile device, the target protocol stack is determined from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device. Load the target protocol stack; The target protocol stack is used to convert protocol instructions from the mobile device to generate target control instructions.

[0006] On one hand, an instruction generation apparatus is provided, the apparatus comprising: The protocol stack determination module is used to determine the target protocol stack from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device when connected to a mobile device. The loading module is used to load the target protocol stack; The conversion module is used to convert the protocol instructions from the mobile device through the target protocol stack to generate target control instructions.

[0007] On one hand, a vehicle is provided, the vehicle including one or more processors and one or more memories, the one or more memories storing at least one piece of program code, the program code being loaded and executed by the one or more processors to implement the instruction generation method.

[0008] On one hand, a computer-readable storage medium is provided, wherein at least one piece of program code is stored in the computer-readable storage medium, the program code being loaded and executed by a processor to implement the instruction generation method. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the implementation environment of an instruction generation method provided in an embodiment of this application; Figure 2 This is a flowchart of an instruction generation method provided in an embodiment of this application; Figure 3 This is a flowchart of another instruction generation method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a target vehicle provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an instruction generation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0011] In the following text, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features reflected. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0012] In the application of digital key technology, due to the coexistence of CCC, ICCE, ICCOA standards and various automakers' proprietary protocols, vehicle systems need to be compatible with multiple protocol types. In related technologies, vehicle systems often have multiple resident protocol stacks or use statically managed protocol stacks, resulting in continuous occupation of system memory and processor resources. Furthermore, when multiple protocol stacks run simultaneously and contend for the same hardware resources, the vehicle system's response latency increases, affecting the stability of the digital key function. Therefore, achieving multi-protocol compatibility and efficient system resource utilization on a single hardware platform presents a challenge.

[0013] For example, when a user approaches a vehicle with a mobile device that supports the CCC standard, the device's protocol type needs to be identified. In resource-constrained embedded systems, because all candidate protocol stacks are resident, even if the currently connected device uses only a single protocol standard, other protocol stacks still consume system resources. Specifically, when the processor load is high, the protocol stacks contend for communication interface resources, leading to delays in protocol instruction parsing, untimely user operation responses, and the vehicle system's inability to dynamically adjust the protocol stack loading strategy based on real-time resource status, resulting in resource waste and functional instability.

[0014] If these issues are not addressed, the inefficient use of system resources will lead to decreased performance of the digital key function in multi-tasking environments, increasing the risk of functional failure. Limited compatibility with multiple protocols necessitates system redeployment when adding new protocol standards, increasing development and maintenance complexity. In the long run, this will constrain the reliability and market adaptability of vehicle intelligent functions.

[0015] Based on this, the technical solutions provided in the embodiments of this application are proposed.

[0016] The implementation environment of the embodiments of this application is described below. See also... Figure 1 The instruction generation method provided in this application embodiment runs on the operating system of the vehicle system controller. The operating system includes a multi-layer architecture, which includes a bottom driver layer 101, a protocol adaptation layer 102, and a dynamic loading layer 103.

[0017] The underlying driver layer 101 is used to uniformly process protocol instructions and radio frequency resources.

[0018] Protocol adaptation layer 102 is used as an abstraction layer to establish standardized business interfaces. Whether it is CCC, ICCE, or a proprietary protocol, it can interact with upper-layer applications through standardized business interfaces.

[0019] The dynamic loading layer 103 is used to compile protocol stacks of different standards into independent dynamic libraries or lightweight modules. The corresponding protocol stack is loaded only when a signal from a specific mobile phone manufacturer, cloud command, or user APP selection is detected, rather than being resident in memory at the same time.

[0020] After introducing the implementation environment of the embodiments of this application, the technical solutions provided by the embodiments of this application are described below. (See also...) Figure 2 Taking the controller of the vehicle system as an example, the method includes the following steps.

[0021] 201. When connected to a mobile device, the controller determines the target protocol stack from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device.

[0022] In this context, "mobile device" refers to a smart terminal carried by the user, such as a smartphone or smartwatch. It connects to the vehicle system wirelessly and sends protocol commands to enable functions like digital keys. Protocol identification refers to the process by which the vehicle, when establishing or attempting to establish a connection with a mobile device, analyzes the signals or data packets sent by the mobile device to determine the communication protocol type or digital key standard supported by the device. The protocol type represents the specific rules and formats followed by the communication and data exchange between the mobile device and the vehicle system, such as the CCC standard, ICCE standard, ICCOA standard, or proprietary protocols of various automakers. A candidate protocol stack refers to a collection of multiple protocol stack modules pre-stored or available for loading in the vehicle. Each protocol stack corresponds to one or more specific protocol types and is used to handle data communication for that protocol. The target protocol stack refers to the protocol stack selected from multiple candidate protocol stacks and prepared for loading and execution when connecting to a specific mobile device, based on the protocol types supported by that mobile device.

[0023] 202. The controller loads the target protocol stack.

[0024] Loading refers to the process of transferring the determined target protocol stack from the storage unit into the system memory and making it runnable. Due to the limited resources of the vehicle system, the loading in the technical solution provided in this application is performed on demand. That is, not all candidate protocol stacks are kept resident in memory when the vehicle system starts up, but rather the target protocol stack corresponding to that protocol type is loaded into memory only after connecting to the mobile device and identifying the protocol types supported by the mobile device, thus enabling it to process protocol instructions from the mobile device.

[0025] 203. The controller uses the target protocol stack to convert the protocol instructions from the mobile device and generate target control instructions.

[0026] Protocol instructions refer to commands or data sent by mobile devices to the vehicle system via specific protocols, such as unlocking commands, start commands, and authorization commands. Target control commands are standardized commands generated by the vehicle system after receiving and converting protocol instructions, and sent to internal vehicle actuators (such as door controllers and engine start modules) to achieve corresponding functional operations.

[0027] The technical solution provided in this application introduces a dynamic, on-demand protocol stack management mechanism, enabling on-demand invocation of the protocol stack instead of it being fully resident. Before connecting to a mobile device or identifying the protocol types supported by the mobile device, candidate protocol stacks are stored in non-volatile memory, not occupying runtime memory. After identification and determination of the target protocol stack, the target protocol stack is loaded, that is, the required target protocol stack is loaded into memory. Therefore, it is unnecessary to pre-load and keep all protocol stacks in a ready state for compatibility with multiple protocols, avoiding resource consumption and conflicts caused by multiple protocol stacks residing in memory simultaneously. This allows the vehicle system to efficiently support multiple digital key protocols on a single hardware platform.

[0028] It should be noted that steps 201-203 above are a simplified explanation of the instruction generation method provided in the embodiments of this application. The instruction generation method provided in the embodiments of this application will be described in more detail below with some examples. See [link to relevant documentation]. Figure 3 Taking the controller as the executing entity as an example, the method includes the following steps.

[0029] 301. The controller determines the protocol types supported by the mobile device.

[0030] In one possible implementation, the controller scans the broadcast data of the mobile device based on target scanning parameters and extracts protocol feature information from the broadcast data. The controller then determines the types of protocols supported by the mobile device based on this protocol feature information.

[0031] Target scanning parameters refer to a set of configuration parameters used to guide the wireless communication module in scanning broadcast data. Their function is to determine the scanning range, frequency, duration, etc., to optimize the efficiency and accuracy of capturing protocol feature information. These target scanning parameters can include scanning interval, scanning window, scanning type (e.g., active or passive scanning), and can also be dynamically adjusted according to preset scanning strategies or the current system state. For example, in specific scenarios, certain frequency bands or specific types of broadcast packets may be prioritized for scanning. Broadcast data from mobile devices refers to wireless signal data packets containing their own information or service information, periodically or event-triggered in a wireless communication environment. Broadcast data carries key identification information and capability declarations of the mobile device and is the basis for protocol identification. Broadcast data can be sent in the form of Bluetooth Low Energy (BLE) broadcast packets, Wi-Fi beacon frames, NFC (Near Field Communication) tag information, etc., and can include information such as device name, service UUID (Universally Unique Identifier), manufacturer-specific data, and protocol version number. Scanning refers to the process of listening to and capturing broadcast data sent by surrounding mobile devices through a wireless communication module. It is the first step in obtaining the protocol characteristic information of mobile devices, ensuring that the system can perceive the communication intentions and capabilities of nearby devices. This scanning process can be performed by a dedicated wireless communication chip or module, such as a Bluetooth module performing BLE scanning, or a Wi-Fi module performing SSID scanning, and can employ various modes such as periodic scanning, event-triggered scanning, or continuous scanning. Protocol characteristic information refers to data fragments or patterns extracted from the broadcast data of mobile devices that can uniquely or significantly identify the type or version of the communication protocol they support. Its function is to provide a direct basis for protocol type determination, transforming the raw broadcast data into structured information that the system can understand and match. Protocol characteristic information may include specific service UUIDs, manufacturer IDs, protocol version fields, device type identifiers, etc., or it may be the result obtained by parsing, pattern matching, or hash calculation of specific byte sequences in broadcast data packets. Extraction refers to the process of parsing and filtering the captured mobile device broadcast data to identify and separate the protocol characteristic information. Its function is to refine the raw broadcast data, which may contain redundant information, into data suitable for protocol identification. The extraction process can involve a packet parser analyzing the structure of broadcast data frames and locating specific fields, or it can use regular expression matching, predefined template matching, or machine learning-based pattern recognition algorithms to identify protocol features.Determining the protocol types supported by a mobile device refers to the process by which the system judges the communication protocol standard (such as CCC, ICCE, ICCOA, or a specific proprietary protocol) followed by the mobile device based on extracted protocol feature information. Its purpose is to provide a clear basis for subsequently selecting a suitable target protocol stack from multiple candidate protocol stacks. This determination process can involve comparing the extracted protocol feature information with a pre-stored protocol feature library to find matches, or it can use methods such as decision trees, rule engines, or lookup tables to directly map the protocol feature information to the corresponding protocol type.

[0032] The above implementation method solves the problem of how traditional digital key systems can accurately and efficiently extract protocol feature information from the raw signals emitted by mobile devices to determine the supported protocol types when facing multi-protocol compatibility. By scanning the broadcast data of mobile devices based on target scanning parameters and extracting protocol feature information, the communication capabilities of mobile devices can be proactively and accurately perceived, avoiding blind guessing or reliance on preset configurations. Based on this, the extracted protocol feature information determines the protocol types supported by the mobile device, providing a reliable basis for selecting the most matching target protocol stack from multiple candidate protocol stacks. This pre-emptive protocol identification mechanism can dynamically adjust the protocol stack loading strategy according to the actual situation of the mobile device, thereby avoiding unnecessary protocol stack resident behavior, reducing the continuous occupation of system memory and processor resources, and improving system response speed and the stability of digital key functions.

[0033] For example, the controller configures the scanning parameters of the Bluetooth module. For instance, the target scanning parameters can be set to: a scanning interval of 100 milliseconds, a scanning window of 50 milliseconds, and an active scanning type. The Bluetooth module continuously scans for surrounding BLE broadcast data based on the target scanning parameters. When a mobile device enters the vehicle's communication range and begins broadcasting, the controller captures the BLE broadcast packets sent by that mobile device. Upon receiving the BLE broadcast packets, the controller parses them. For example, the controller identifies the service UUID field in the BLE broadcast packets. If the BLE broadcast packets contain a specific service UUID defined by the CCC Alliance (e.g., 0xFEAA), the CCC service UUID can be extracted as protocol feature information. If the BLE broadcast packets contain a specific service UUID defined by the ICCE Alliance (e.g., 0xFEBB), the controller extracts the ICCE service UUID as protocol feature information. Furthermore, manufacturer-specific data fields in the BLE broadcast packets may also contain protocol version numbers or manufacturer-defined protocol identifiers, which can also be extracted as protocol feature information. Upon extracting these protocol feature information, the controller compares them with a preset protocol feature library. For example, the controller maintains a mapping table: CCC service UUID corresponds to CCC protocol type, ICCE service UUID corresponds to ICCE protocol type, and a specific vendor ID plus a specific data field corresponds to a private protocol type. By querying this mapping table, the protocol types supported by the mobile device can be determined. For example, if the extracted value is a CCC service UUID, it indicates that the mobile device supports the CCC protocol type.

[0034] To provide a clearer explanation of the technical solutions provided in the embodiments of this application, the method for determining target scanning parameters in the above embodiments will be described below.

[0035] In one possible implementation, the controller determines the signal strength of the mobile device. If the signal strength of the mobile device meets a preset condition, the controller adjusts the scanning parameters to shorten the scanning interval to less than the normal scanning interval, thus obtaining the target scanning parameters. If the signal strength of the mobile device does not meet the preset condition, the controller uses the scanning parameters corresponding to the normal scanning interval as the target scanning parameters.

[0036] Determining the signal strength of a mobile device refers to real-time sensing of the physical connection quality between the mobile device and the current system, providing a basis for subsequent adjustments to the scanning strategy. This signal strength can be obtained in various ways. For example, it can be measured by the RSSI (Received Signal Strength Indicator) value of the broadcast signal from the mobile device. Bluetooth Low Energy devices typically carry RSSI information during broadcasts, allowing the receiver to determine signal strength. Alternatively, signal quality can be indirectly assessed by analyzing the bit error rate (BER) or signal-to-noise ratio (SNR) of the received mobile device data packets, thus inferring signal strength. Preset conditions are thresholds or ranges used to determine whether the signal strength is sufficient to support efficient scanning. These preset conditions can be a fixed RSSI threshold, for example, considering the signal strength to meet the preset condition when the RSSI is higher than -70dBm. Alternatively, the preset condition can be a dynamically adjusted RSSI threshold, for example, adaptively adjusted based on ambient noise levels or historical connection quality. Adjusting scanning parameters refers to dynamically changing the configuration of scanning behavior based on signal strength to optimize scanning efficiency and resource consumption. For example, in Bluetooth scanning, the scan parameters can be modified... interval and scan window Parameters, where scan interval The time interval between the start of two scans is defined, scan window The duration of each scan is defined. In other wireless communication protocols, the channel scan period, scan duration, or list of channels scanned can also be adjusted. Shortening the scan interval to less than the regular scan interval aims to increase the scan frequency when signal strength is good, thereby capturing broadcast data from mobile devices more quickly. For example, the scan... interval Reduced from the default 100ms to 50ms while maintaining scan window The scan interval can remain unchanged or be appropriately increased. Alternatively, multiple short scans can be performed consecutively within a specific time period instead of waiting for longer intervals. The regular scan interval is the scan frequency used by the system in default or low-power mode, typically used to conserve resources when the presence of uncertain devices or weak signals is unknown. For example, it could be the default scan interval recommended in the Bluetooth BLE specification, such as 100ms or 160ms. It could also be a standard scan interval set to balance power consumption and response speed when there are no specific optimization requirements. The target scan parameters are a dynamically adjusted set of parameters used to actually perform broadcast data scans. This parameter set may include adjusted scan parameters. interval and scan window Alternatively, it can be a configuration object that encapsulates a series of parameters such as scan cycle, scan duration, and scan mode (active / passive).

[0037] Through the above implementation method, the scanning mode can be flexibly switched according to the actual connection status of the mobile device, achieving a dynamic balance between scanning efficiency and system resource consumption. Under conditions of good signal strength, mobile device information can be captured quickly and accurately, thereby accelerating the protocol identification process and improving the response speed and user experience of the digital key function. Under conditions of poor signal strength, unnecessary frequent scanning is avoided, reducing system power consumption and processor load, and ensuring stable operation in complex environments. This intelligent scanning parameter management mechanism improves the overall efficiency and resource utilization of the instruction generation method, providing a better solution for vehicles to implement multi-standard digital key functions.

[0038] 302. When connected to a mobile device, the controller determines the target protocol stack from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device.

[0039] In one possible implementation, when connected to a mobile device, the controller matches the protocol type with the corresponding protocol types of each of the plurality of candidate protocol stacks to obtain a protocol type matching result. Based on the protocol type matching result, the controller determines the candidate protocol stack corresponding to the protocol type from the plurality of candidate protocol stacks as the target protocol stack.

[0040] Each candidate protocol stack corresponds to one or more specific protocol types and contains all the functional components required to implement that protocol, such as a protocol parser and a data converter. These candidate protocol stacks can exist in the system's storage medium as independent files, libraries, or service modules, awaiting loading and activation. Matching refers to the process of comparing and associating the identified mobile device protocol type with the protocol types declared to be supported by each candidate protocol stack. Its purpose is to determine whether a candidate protocol stack can handle the communication of the current mobile device. Matching can be achieved through direct string comparison, hash value comparison, or by querying a predefined protocol compatibility list. For example, a mapping table between protocol types and candidate protocol stacks can be maintained, and the corresponding protocol stack can be quickly found by querying this table. The protocol type matching result is the output of the matching process, used to indicate which candidate protocol stacks match the identified protocol type. The protocol type matching result can be a boolean value (indicating whether a match exists), a list of matching candidate protocol stacks, or an identifier indicating the best match, serving as a decision-making basis for subsequently determining the target protocol stack. Determining the target protocol stack refers to selecting one or more protocol stacks from multiple candidate stacks based on protocol type matching results. This selection process provides the correct processing logic and resources for subsequent protocol instruction conversion. The determination process typically involves selecting a candidate protocol stack that perfectly matches the protocol type, or, if multiple compatible protocol stacks exist, selecting one based on preset priorities or system policies.

[0041] Through the above implementation method, the target protocol stack can be selected from multiple candidate protocol stacks based on the actual protocol type of the mobile device. This determination mechanism based on protocol type matching solves the problem of avoiding loading unnecessary protocol stacks in a multi-protocol coexistence environment, thereby ensuring the accuracy and compatibility of subsequent instruction conversion. Furthermore, since only the target protocol stack matching the mobile device's protocol type is loaded, instead of all protocol stacks being kept in the root directory, this reduces the consumption of system memory and processor resources, improves resource utilization, and avoids resource contention and system response latency that may result from multiple protocol stacks running simultaneously, thereby enhancing the stability of the digital key function and the user experience.

[0042] For example, if the mobile device is determined to support the CCC protocol, the controller compares this identified CCC protocol type with the protocol types supported by a pre-defined list of candidate protocol stacks. For instance, the controller might maintain a protocol stack registry, recording the unique identifier of each candidate protocol stack and the protocol types it supports. The controller iterates through this registry, comparing the CCC protocol type with the protocol types in each registry entry. If a candidate protocol stack (e.g., identified as a CCC protocol stack) is found to support a protocol type that perfectly matches the CCC protocol type, the controller generates a protocol type matching result, indicating that the CCC protocol stack is a match. Based on this matching result, the controller identifies the CCC protocol stack as the target protocol stack. Subsequently, all protocol instruction processing for this mobile device will be performed through this identified CCC protocol stack, while other mismatched protocol stacks will not be loaded or activated.

[0043] 303. The controller determines the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack.

[0044] System resource status refers to the current usage of hardware and software resources in the vehicle system, including but not limited to CPU utilization, memory usage, storage space availability, and network bandwidth. Resource requirements refer to the minimum or expected consumption of system resources (such as CPU, memory, and storage) by the target protocol stack under different operating modes. Operating mode refers to the specific configuration or state adopted by the target protocol stack during loading and operation. Different operating modes correspond to different resource consumption and functional performance, such as full-featured mode, low-power mode, and simplified mode.

[0045] In one possible implementation, the controller compares the system resource status with a resource status threshold to obtain a resource status comparison result. Based on this resource status comparison result and the resource requirements of the target protocol stack, the controller determines the operating mode of the target protocol stack from multiple preset operating modes, with different preset operating modes corresponding to different resource consumption.

[0046] The system resource status refers to a quantitative description of the current available computing, storage, and network resources of the system. For example, the system resource status may include CPU utilization, memory usage, storage device read / write speeds, and network bandwidth usage. The system resource status can be obtained in real-time through the operating system's application programming interface (API), such as by reading system performance counters or querying system process information. Alternatively, the system resource status can be periodically collected by a monitoring agent deployed in the controller, and the collected data can be aggregated or averaged to reflect resource usage trends over a period of time. The resource status threshold is a pre-set reference value used to determine whether the system resource status meets specific conditions. This threshold can be statically configured based on design requirements, hardware configuration, or historical operating data, for example, by loading it through a configuration file during system initialization. Alternatively, the resource status threshold can be dynamically adjusted, for example, adaptively adjusting based on the system's long-term average load or user-defined performance goals to better adapt to changes in the system's operating environment. The resource status comparison result is an indication value generated after logically judging the system's resource status against the resource status threshold. This result can be a simple Boolean value, such as "resources are sufficient" or "resources are insufficient," indicating whether the system's resources exceed or fall below a certain critical point. Alternatively, the comparison result can be a multi-level enumeration value, such as "very sufficient," "sufficient," "neutral," "tight," or "very tight," corresponding to different resource status ranges, thus providing a more refined resource status assessment.

[0047] The resource requirements of the target protocol stack refer to the minimum or optimal utilization of system resources such as CPU, memory, and network bandwidth when the target protocol stack performs its functions. These requirements are typically related to the complexity of the target protocol stack, the amount of data it processes, and the functional modes it supports. These resource requirements can be evaluated and preset during the protocol stack design phase. For example, a full-featured protocol stack may require higher memory and CPU utilization, while a simplified protocol stack may only require lower resources. Furthermore, these resource requirements can also be dynamically measured and recorded by running the target protocol stack in a test environment and monitoring its resource usage. The multiple preset operating modes are a series of operational states defined for the target protocol stack, each corresponding to a different set of functions, performance levels, and resource consumption. For example, there could be "full-featured mode," "low-power mode," "simplified mode," or "standby mode." These preset operating modes can be predefined in the protocol stack configuration or code, or flexibly configured through configuration files. As another implementation approach, the parameters of these preset operating modes can also be dynamically generated or optimized using machine learning models based on historical data and system states. Determining the operating mode of the target protocol stack involves selecting the most suitable mode from multiple preset modes based on the current system resource status and the specific resource requirements of the target protocol stack, in order to balance functionality, performance, and resource consumption. This determination of the operating mode can be achieved through lookup tables or decision trees, mapping the resource status comparison results and the resource requirements of the target protocol stack to a specific operating mode. Alternatively, rule-based expert systems or optimization algorithms can be used to dynamically select the optimal operating mode by comprehensively considering multiple factors (such as resource utilization, response time, and power consumption).

[0048] Through the above implementation methods, by combining the resource status comparison results with the resource requirements of the target protocol stack, the most suitable mode can be dynamically selected from multiple preset operating modes. This dynamic adaptation mechanism makes the operation of the protocol stack no longer static and fixed, but can be flexibly adjusted according to the actual resource carrying capacity of the system. When system resources are sufficient, a high-performance mode can be selected to provide the best user experience. When system resources are scarce, a low-resource consumption mode can be switched to ensure the stable operation of core functions and avoid system response delays and functional instability caused by resource contention. This improves the utilization efficiency of system resources, solves the problem of resource waste and system performance degradation caused by multiple resident protocol stacks or static management in traditional solutions, and achieves a balance between multi-protocol compatibility and efficient utilization of system resources.

[0049] To provide a clearer explanation of the above implementation methods, the following describes two methods for determining the operating mode of the target protocol stack from multiple preset operating modes based on the resource status comparison result and the resource requirements of the target protocol stack.

[0050] Method 1: If the resource status comparison result indicates that the system resource status meets the first condition, the controller, based on the resource requirements of the target protocol stack, determines a first operating mode that matches the resource requirements from among the multiple preset operating modes, and uses this as the operating mode for the target protocol stack. If the resource status comparison result indicates that the system resource status meets the second condition, the controller determines a second operating mode from among the multiple preset operating modes with a lower resource consumption than the first operating mode, and uses this as the operating mode for the target protocol stack.

[0051] The resource status comparison result is an indication obtained by comparing the system resource status with preset resource status thresholds. The resource status comparison result can be a Boolean value, such as "threshold met" or "threshold not met," or an enumerated value, such as "sufficient resources," "moderate resources," or "scarce resources." The first condition refers to the system resource status meeting the conditions required for normal or high-performance operation of the protocol stack, usually meaning sufficient system resources. For example, the first condition can be defined as the system CPU utilization being below a certain preset percentage (e.g., 80%) and the amount of free memory exceeding a certain absolute value (e.g., 500MB). Multiple preset operating modes refer to different operating states that the protocol stack can switch between, each corresponding to different resource consumption and functional characteristics. These modes can include "full-featured mode" (high resource consumption, optimal performance), "simplified mode" (moderate resource consumption, some functions limited or slightly lower performance), and "low-power mode" (lowest resource consumption, only core functions are retained). The first operating mode is the operating mode that matches the resource requirements of the target protocol stack when resources are sufficient, usually a full-featured or performance-priority mode. For example, the first operating mode could be "full-featured mode," providing complete protocol parsing, instruction conversion, and security verification functions to ensure the best user experience. The second condition refers to a situation where the system resource status does not meet the first condition, typically indicating that system resources are strained or limited. For example, the second condition could be defined as the system CPU utilization exceeding a preset percentage (e.g., 80%), or the amount of free memory falling below a certain absolute value (e.g., 500MB). The second operating mode is a mode that consumes less resources than the first operating mode when resources are scarce; it is usually a simplified or low-power mode. For example, the second operating mode could be a "simplified mode," loading only the core parsing module of the protocol stack and disabling some non-critical functions, such as detailed logging or advanced security features.

[0052] Through the above implementation method, the protocol stack's operating mode can be intelligently selected based on the availability of system resources. When resources are sufficient, the protocol stack is ensured to operate at optimal performance, providing a complete functional experience. When resources are limited, it proactively switches to a lower resource consumption mode to alleviate system resource pressure and avoid system response delays caused by resource contention. This solves the problem of not being able to flexibly balance ensuring functional implementation and reducing resource consumption when system resources fluctuate, thus improving the stability of the digital key function and the efficiency of system resource utilization.

[0053] To provide a clearer explanation of the above implementation methods, the following describes how, in the above implementation methods, when the resource status comparison result indicates that the system resource status meets the second condition, a second operating mode with a lower resource consumption than the first operating mode is determined from the plurality of preset operating modes.

[0054] In one possible implementation, if the resource status comparison result indicates that the system resource status meets the second condition, the controller determines the current available resource balance based on the system resource status. The controller then selects from the plurality of preset operating modes an operating mode whose resource demand does not exceed the current available resource balance and whose resource consumption is lower than that of the first operating mode, as the second operating mode.

[0055] In this context, the resource status comparison result indicating that the system's resource status meets the second condition means that the system is currently in a resource-constrained or strained state. The current available resource balance refers to the amount of remaining resources that can still be allocated and used under the condition of resource strain. One implementation approach is to calculate the current CPU idle percentage, available memory size, and remaining disk space after determining that the second condition is met, and then use these indicators collectively or individually as the current available resource balance. For example, available memory balance can be obtained directly by subtracting used memory from total memory. Another implementation approach is to define a resource balance function that takes system resource status parameters such as CPU utilization, memory usage, and I / O load as input and outputs a comprehensive resource balance score or a specific numerical value. For example, when CPU utilization reaches 80%, the available resource balance may be assessed as low. When memory usage reaches 90%, the available resource balance may be assessed as extremely low. Multiple preset operating modes are different operating states predefined for the target protocol stack, each corresponding to a different set of functions, performance levels, and resource consumption. When selecting a second operating mode, two conditions must be met simultaneously: first, the resources required by this mode cannot exceed the remaining resources currently available to the system (i.e., the current available resource balance); second, the resource consumption of this mode must be lower than that of the full-featured or high-performance first operating mode, in order to save resources. One implementation approach is to maintain a preset list of operating modes, each containing its corresponding resource requirements (such as CPU, memory, network bandwidth, etc.) and resource consumption. When determining the second operating mode, this list is traversed, filtering out all modes whose resource requirements are less than or equal to the current available resource balance and whose resource consumption is lower than that of the first operating mode. If multiple modes meet the conditions, a final selection can be made based on preset priorities (e.g., prioritizing the mode with the lowest resource consumption or prioritizing the mode with the most complete functionality). Another implementation approach is to use a rule-based decision engine. A series of rules are pre-defined, such as "If the available memory balance is less than X MB, select mode A. If the CPU idle rate is less than Y%, select mode B." These rules ensure that the resource requirements of the selected mode are within the current available resource balance and that its resource consumption is lower than that of the first operating mode.

[0056] Through the above implementation method, when system resources are scarce, the available resource balance can be quantified based on the real-time system resource status. Based on this, the system can intelligently select an operating mode from multiple preset operating modes that both meets the current available resource constraints and effectively reduces resource consumption. This operating mode selection mechanism avoids blindly loading high-resource-consuming modes under resource-constrained conditions, which could lead to system overload or instability. It also ensures that the digital key function operates in an optimized manner even under resource constraints, thus solving the problem of inaccurate operating mode selection in resource-constrained scenarios and improving the utilization efficiency of system resources and the stability of the digital key function.

[0057] Optionally, after using the second operating mode as the operating mode of the target protocol stack, the following steps can also be performed.

[0058] In one possible implementation, the controller continuously monitors the system resource status. When the system resource status meets the first condition, the controller switches the operating mode of the target protocol stack from the second operating mode back to the first operating mode.

[0059] Continuous monitoring of system resource status refers to the uninterrupted or periodic acquisition and evaluation of available computing resources (such as CPU utilization, memory usage, storage I / O, network bandwidth, etc.). Its purpose is to provide real-time resource status feedback, which is the foundation for dynamic resource management and adaptive adjustment of operating modes. For example, key indicators such as CPU load and memory usage can be queried periodically through API interfaces provided by the operating system. In Linux systems, system resource information can be obtained by reading files such as ` / proc / stat` and ` / proc / meminfo`, and periodically sampled and analyzed. Alternatively, a resource monitoring agent can be deployed at the system level. This agent collects and summarizes various resource data at fixed time intervals (e.g., every second, every five seconds) and then reports this data to the controller for unified processing and analysis. The first condition is a preset standard or set of criteria used to determine whether system resources are sufficient or meet high-performance operating requirements. When the system resource status meets the first condition, it means that the system has the capability to support a higher-performance protocol stack operating mode. Switching the target protocol stack from the second operating mode back to the first operating mode refers to upgrading the protocol stack, currently running with low resource consumption (second operating mode), to a higher-performance, potentially more resource-intensive operating mode (first operating mode) after system resource conditions improve. This ensures the protocol stack can fully utilize available system resources to provide optimal performance to meet business needs. Specifically, the switching operation may include reloading certain modules or configuration parameters of the protocol stack. For example, in the second operating mode, the protocol stack may have disabled certain advanced features or used simplified processing logic. Switching to the first operating mode will re-enable these features or load high-performance modules containing more complex algorithms, larger buffers, etc. Furthermore, specific control commands can be sent to the protocol stack to adjust its internal operating parameters. For example, increasing the number of processing threads, expanding the packet buffer size, enabling more complex encryption / decryption algorithms or data compression mechanisms, thereby improving its processing capacity and response speed.

[0060] Through the above implementation, when the protocol stack runs in the low-resource-consumption second operating mode, by continuously monitoring the system resource status, and when system resources are sufficiently restored and the first condition is met, the protocol stack's operating mode can be switched back from the second operating mode to the high-performance first operating mode in a timely manner. This dynamic switching mechanism allows the protocol stack to make full use of currently available system resources, avoiding resource waste and performance bottlenecks caused by running in a low-performance mode when resources are plentiful. This enables the digital key function to operate stably when system resources are scarce and to quickly improve performance after resources are restored, providing the best user experience. Thus, a dynamic balance is achieved between resource utilization and system processing performance, improving the overall adaptability and efficiency of the system.

[0061] Method 2: The controller obtains the current environment context parameters, which represent the environmental state of the communication environment in which the mobile device is located. Based on the system resource state, the resource requirements of the target protocol stack, and the environment context parameters, the controller determines the operating mode of the target protocol stack from multiple preset operating modes. Different preset operating modes correspond to different resource consumption.

[0062] The current environmental context parameters refer to various indicators that reflect the communication environment of the mobile device. Their function is to provide external environmental information for decision-making regarding the protocol stack's operating mode, thereby enabling a more comprehensive assessment of current operating conditions. For example, the signal strength index (RSSI) between the mobile device and the vehicle can be obtained through the vehicle's built-in wireless signal strength detection module. Furthermore, network performance indicators such as wireless channel utilization, packet loss rate, or latency can be monitored to assess the congestion level or stability of the communication environment. Determining the target protocol stack's operating mode from multiple preset modes based on system resource status, the target protocol stack's resource requirements, and environmental context parameters aims to dynamically select the most suitable protocol stack operating mode for the current scenario by comprehensively considering three dimensions: internal system resources, the protocol stack's own requirements, and the external communication environment. This ensures that the protocol stack can meet functional requirements and achieve optimal resource allocation under different conditions. For example, a multi-dimensional decision table or rule set can be pre-established, taking system resource status, the target protocol stack's resource requirements, and environmental context parameters as input, and outputting the corresponding preset operating mode. Alternatively, decision-making can be made using models based on machine learning or artificial intelligence. By training the model, it can predict and select the optimal operating mode based on real-time system resource status, the resource requirements of the target protocol stack, and environmental context parameters.

[0063] Through the above implementation methods, when determining the operating mode of the target protocol stack, not only are the internal resource status of the system and the resource requirements of the protocol stack itself considered, but also the environmental context parameters of the communication environment in which the mobile device is located are further introduced. This multi-dimensional decision-making mechanism can more comprehensively and accurately assess the current operating conditions, thereby selecting the protocol stack operating mode most suitable for the current scenario. This solves the problem of mismatch between the operating mode and actual needs caused by ignoring external environmental factors in traditional solutions, and improves the adaptability, operational stability, and reliability of the digital key function in complex and ever-changing communication environments. At the same time, by dynamically adjusting the operating mode, more refined resource management and optimized utilization can be achieved while ensuring functional performance, avoiding unnecessary resource waste, thus better balancing multi-protocol compatibility and efficient utilization of system resources on a single hardware platform.

[0064] To provide a clearer explanation of the above implementation methods, the following describes how the operating mode of the target protocol stack is determined from multiple preset operating modes based on the system resource status, the resource requirements of the target protocol stack, and the environmental context parameters.

[0065] In one possible implementation, the controller determines at least one candidate operating mode from a plurality of preset operating modes based on the environmental context parameters and the resource requirements of the target protocol stack. The controller then determines an operating mode that matches the system resource state from the at least one candidate operating mode.

[0066] The environmental context parameter represents the environmental state of the communication environment in which the mobile device is located, encompassing external factors that affect the communication performance between the mobile device and the vehicle. This environmental context parameter may include, but is not limited to, physical layer or link layer metrics such as signal strength, signal-to-noise ratio, interference level, communication distance, and relative speed between the mobile device and the vehicle. Alternatively, the environmental context parameter may also include more macroscopic environmental information such as geographic location (e.g., whether the mobile device is indoors, outdoors, or in an underground parking lot), weather conditions (e.g., rain and snow may affect wireless signal propagation), and the complexity of the surrounding radio environment (e.g., Wi-Fi hotspot density, number of Bluetooth devices).

[0067] Through the above implementation methods, by incorporating environmental context parameters into the process of determining the operating mode, multi-dimensional and phased intelligent decision-making can be achieved based on the actual communication environment of the mobile device, combined with the specific needs of the target protocol stack and the status of system resources. This allows the operating mode of the target protocol stack to better adapt to changes in the external environment, avoiding performance degradation or resource waste caused by inappropriate mode selection in specific environments. Consequently, the adaptability, stability, and resource utilization efficiency of the digital key function in complex and ever-changing communication scenarios are improved, enhancing the reliability and efficiency of the instruction generation process.

[0068] To provide a clearer explanation of the above implementation methods, the following describes how the method for determining at least one candidate operating mode from the multiple preset operating modes based on the environmental context parameters and the resource requirements of the target protocol stack is described in the above implementation methods.

[0069] In one possible implementation, the controller determines at least one first candidate operating mode that matches the resource requirements of the target protocol stack from a plurality of preset operating modes. Based on the environment context parameters, the controller determines at least one second candidate operating mode supported by the environment context parameters from the at least one first candidate operating mode, and uses this as the candidate operating mode.

[0070] The process involves several steps. First, based on the resource requirements of the target protocol stack, at least one first candidate operating mode matching these requirements is selected from multiple preset operating modes. This initial screening is based on the hardware resources needed for the target protocol stack to run, such as CPU utilization, memory consumption, and power consumption. Second, based on environmental context parameters, at least one second candidate operating mode supported by these environmental context parameters is selected from the first candidate operating modes. This second candidate operating mode serves as a second-layer filtering condition, in addition to the first-layer screening, by introducing the communication environment status of the mobile device. One implementation involves pre-setting compatibility rules or lists between environmental context parameters and operating modes. For example, when strong interference is detected in the communication environment, some high-bandwidth operating modes with high signal quality requirements may be considered unstable and excluded. In environments with weak signal strength, more robust but potentially less efficient operating modes may be preferred. The first candidate operating modes are evaluated one by one based on the currently acquired environmental context parameters, and those supported by the environmental context parameters are retained as second candidate operating modes. Another implementation involves using environmental context parameters that may include, but are not limited to, signal strength, network congestion, device temperature, and battery level. Each environment context parameter can be assigned a corresponding threshold or range, and each preset operating mode can be defined to exhibit performance or applicability under different environment parameters. By comparing the current environment context parameters with these predefined rules, modes unsuitable for the current environment are eliminated from the first candidate operating modes, thus obtaining the second candidate operating modes.

[0071] The above implementation avoids the resource allocation mismatch that may result from single-dimensional matching, ensuring that the selected operating mode meets both the resource requirements of the target protocol stack and adapts to the current complex communication environment. This improves the operational reliability and resource utilization efficiency of the protocol stack in complex and ever-changing environments, thereby guaranteeing the stability of the digital key function and the user experience.

[0072] Optionally, the controller can also perform the following steps.

[0073] In one possible implementation, the controller receives a policy change instruction, which is issued from the cloud. In response to the policy change instruction, the controller re-executes the step of determining the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack.

[0074] The policy change command is a cloud-based command instructing adjustments to the protocol stack's operating mode. The controller can periodically request the cloud server to query for new policy change commands, for example, by polling at preset time intervals using protocols such as HTTP (Hypertext Transfer Protocol) / MQTT (Message Queuing Telemetry Transport). Alternatively, the cloud can proactively push policy change commands to the controller, for example, through message queue services or long-connection mechanisms, to notify the system immediately when the policy changes. Policy change commands can contain various information, such as specifying that a certain protocol stack should preferentially use low-power mode, disabling a certain protocol stack for a specific time period, or adjusting resource status thresholds. The step of re-executing the process of determining the operating mode of the target protocol stack based on system resource status and the resource requirements of the target protocol stack describes how to dynamically re-evaluate and adjust the protocol stack's operating mode after receiving a policy change command. This allows the controller to optimize or adjust the protocol stack's operating mode according to the latest policy requirements and the current system resource status. Receiving a policy change command can trigger an operating mode re-evaluation process. This operational mode reassessment process re-acquires the current system resource status (e.g., CPU utilization, memory usage, battery level, etc.) and, combined with any new policy parameters that may be included in the policy change instruction (e.g., new resource priorities, power limits, etc.), calls the loading module again to select the most suitable operational mode from multiple preset modes. Furthermore, the response mechanism can be non-blocking; that is, upon receiving an instruction, it is placed in a processing queue and processed asynchronously by a dedicated scheduling module. The scheduling module will initiate the operational mode re-determination process at an appropriate time based on the instruction's priority and the current system load.

[0075] Through the above implementation method, the ability to intervene externally and dynamically adjust is achieved by introducing policy change commands issued from the cloud. This allows the protocol stack's operating mode to no longer be limited to locally preset static logic, but to be updated in real time according to the latest policies issued from the cloud. The step of obtaining policy change commands establishes an information exchange channel between the system and the cloud, ensuring that the vehicle can receive the latest management policies or business adjustment requirements in a timely manner, thereby breaking the lag in policy updates of the local system. In response to the policy change command, the step of determining the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack is re-executed. By triggering a re-evaluation mechanism, the cloud policy is deeply integrated with the current system resource status. By re-executing the process of determining the operating mode, the operating mode of the protocol stack can be further optimized or adjusted according to the latest policy requirements and the current real-time resource usage. This dynamic reconfiguration capability ensures that when the policy changes, it can quickly switch from the old operating mode to a mode that meets the requirements of the new policy, thereby maximizing the utilization efficiency of system resources while ensuring the stability of the digital key function, and realizing refined and intelligent management of the protocol stack's operating status. For example, when a vehicle is parked for an extended period, the cloud can issue a command to switch to a low-power mode, effectively extending battery life. When the user frequently uses the digital key, it can switch to a high-performance mode to ensure response speed. This flexibility and adaptability enhances the user experience and energy efficiency of the digital key system.

[0076] 304. The controller loads the target protocol stack in this operating mode.

[0077] In one possible implementation, the controller determines the protocol stack submodule corresponding to the operating mode in the target protocol stack based on the operating mode. The controller loads the protocol stack submodule into system memory and initializes it.

[0078] The operating mode refers to the working state of the protocol stack under specific system resource states or environmental context parameters. It defines the functional scope, performance indicators, and resource consumption of the protocol stack. The target protocol stack, when connected to a mobile device, is the specific protocol stack determined from multiple candidate protocol stacks based on the protocol type identified by the mobile device's protocol identification. The target protocol stack typically contains multiple functional modules, such as the physical layer, link layer, network layer, transport layer, and application layer, which work together to achieve complete communication functionality. A protocol stack submodule is the smallest functional unit in the target protocol stack that can be independently loaded, unloaded, or configured. A protocol stack submodule can be a specific layer of the protocol stack or a specific functional component within a layer. By subdividing the protocol stack into submodules, on-demand combination and fine-grained management of protocol stack functions can be achieved, avoiding the loading of unnecessary functions. Determining the protocol stack submodules corresponding to the operating mode in the target protocol stack aims to select only the necessary protocol stack submodules to support the currently determined operating mode from all functional modules of the target protocol stack. For example, if the operating mode is "low-power mode," only the core communication and security submodules may be selected, while unnecessary diagnostic or advanced function submodules may be omitted. Loading the protocol stack submodule into system memory refers to transferring the code and data of the determined protocol stack submodule from storage media (such as flash memory) to system memory (such as RAM), making it executable. The loading process can use dynamic link libraries (DLLs) or shared objects (SOs), or it can directly copy the binary code segment to a specified area of ​​memory. This allows for the allocation and release of memory resources on demand, avoiding memory waste caused by a full loading of the protocol stack. Initialization refers to the necessary configuration and preparation work performed on the protocol stack submodule after it is loaded into system memory, enabling it to run normally. Initialization includes, but is not limited to, allocating the data structures required for runtime, setting internal state variables, registering callback functions, establishing connections with other system components, and starting necessary background services. The initialization process ensures that the protocol stack submodule is in a known and stable working state before being called and executed.

[0079] Through the above implementation method, by loading protocol stack sub-modules in the target protocol stack on demand based on the operating mode, only the functional modules necessary to maintain the current operating mode can be loaded according to the actual resource status and functional requirements, avoiding unnecessary resource waste. This not only reduces system memory usage and processor overhead, improving system resource utilization efficiency, but also enables fine-grained resource management for different operating modes, thereby improving the stability, response speed, and overall performance of the digital key function in a multi-protocol environment.

[0080] 305. The controller uses the target protocol stack in this operating mode to convert the protocol instructions from the mobile device and generate target control instructions.

[0081] In one possible implementation, the controller parses the protocol instruction through the target protocol stack to obtain the protocol data carried by the instruction. The controller then converts the protocol data into intermediate format data and generates the target control instruction based on the intermediate format data.

[0082] The process involves parsing the protocol instructions using the target protocol stack to extract the core, meaningful protocol data carried by these instructions, tailored to different mobile device protocol types. One possible implementation is a protocol parser module within the target protocol stack. This module analyzes the received binary or text-formatted protocol instructions byte-by-byte or field-by-field according to predefined protocol specifications (e.g., CCC, ICCE), identifying the instruction type, parameter values, and operands, and encapsulating this information into structured protocol data. Alternatively, the target protocol stack can invoke a general instruction parsing service. This service dynamically loads corresponding parsing plugins or rules based on the protocol type, performing syntactic and semantic analysis on the protocol instructions to extract the payload as protocol data. Converting this protocol data to an intermediate format aims to standardize heterogeneous, protocol-specific protocol data, creating a unified, protocol-independent data representation for subsequent processing. For example, a general data structure or object model, such as JSON, XML, or a custom binary structure, can be defined as the intermediate format. The protocol data conversion module maps the parsed protocol data fields to the corresponding fields in the intermediate format based on the protocol type of the target protocol stack, thus unifying the data structure. Alternatively, a mechanism based on message queues or event buses can be used to encapsulate the protocol data into a message body with a unified header and standard data fields, serving as intermediate format data. Different protocol stacks, after parsing, fill the data into this standard message body, achieving data format standardization. Generating the target control command based on this intermediate format data aims to generate control commands with a unified interface that can be directly executed by the vehicle or other systems, based on the standardized intermediate format data. One implementation method is to predefine a set of standardized control command templates or API interfaces. The controller selects the corresponding control command template based on the business operation type (e.g., "unlock," "start engine," "query status") contained in the intermediate format data, and fills the template with the parameters from the intermediate format data to generate the target control command. Another implementation method is to maintain a control command mapping table that associates specific field values ​​in the intermediate format data with specific control command opcodes or function calls. When intermediate format data is received, the controller queries the control instruction mapping table and dynamically constructs or invokes the corresponding target control instruction based on the content of the intermediate format data.

[0083] The above implementation decouples protocol instruction parsing from control instruction generation, enabling upper-layer business logic to process data based on a unified intermediate format, thus simplifying system design and maintenance. It also enhances compatibility and scalability across different protocol standards. Even if a new digital key protocol emerges in the future, only the corresponding protocol stack parsing and conversion modules need to be updated or added, without modifying the core vehicle control logic, thereby improving system flexibility and adaptability. Furthermore, dynamic loading and runtime mode management ensure that the protocol instruction parsing and conversion process is efficient and stable, avoiding resource waste and system response delays.

[0084] To provide a clearer explanation of the above embodiments, the embodiments will be described in several parts below.

[0085] The first part involves the controller parsing the protocol instructions through the target protocol stack to obtain the protocol data carried by the instructions.

[0086] In one possible implementation, the controller identifies the protocol identification information contained in the protocol instruction through the target protocol stack. Based on the protocol identification information, the controller extracts the protocol data corresponding to the protocol identification information from the protocol instruction.

[0087] The process of identifying protocol identification information within protocol instructions via the target protocol stack involves analyzing received protocol instructions during the target protocol stack's loading and runtime in its current operating mode to determine the specific information carried by the instruction that identifies its type, format, or function. This identification process can be implemented in various ways. For example, it can use preset protocol parsing rules to perform pattern matching on specific fields of the protocol instruction (such as instruction headers, opcodes, or specific byte sequences) to identify the protocol identification information. Alternatively, it can utilize a state machine or parser to progressively parse the protocol instruction according to the data structures and syntax rules defined in the protocol specification, thereby locating and extracting the protocol identification information. Extracting protocol data corresponding to the protocol identification information from the protocol instruction means, after successfully identifying the identifier information, separating and obtaining the actual business data or control parameters from the remaining part of the protocol instruction according to the protocol specification or data structure definition indicated by the identifier information. For example, if the protocol identification information indicates that the instruction is a message of a specific type, the corresponding protocol data can be extracted from the instruction based on the field offsets and lengths defined for that message type. Alternatively, based on the protocol identification information, a pre-configured parsing module or function can be called to perform structured parsing of the payload portion of the instruction, thereby extracting the protocol data closely related to the identification information.

[0088] Through the above implementation method, by identifying protocol identification information in the protocol instructions within the target protocol stack in running mode, and extracting the corresponding protocol data based on this identification information, the accuracy and robustness of protocol parsing are improved. This enables efficient and accurate acquisition of the required data even when faced with instructions containing various types of protocol identification information sent by different mobile devices. This provides a reliable data source for subsequent instruction conversion and the generation of target control instructions, thereby ensuring the stability and reliability of the digital key function and avoiding system response delays or functional failures caused by data parsing errors.

[0089] For example, a mobile device sends a digital key command to a vehicle via the Bluetooth Low Energy (BLE) protocol. When the target protocol stack receives a BLE protocol command, it identifies the protocol identification information contained in the command. This identification information could be a specific opcode or a combination of a service UUID and a feature UUID. The target protocol stack can have a pre-defined parsing module containing recognition rules for different opcodes or UUID combinations. When the opcode of the protocol command is identified as an "unlock" command, the controller determines the protocol identification information. Based on this "unlock" opcode, the target protocol stack extracts the protocol data corresponding to the opcode from the payload portion of the protocol command, according to the definition of the "unlock" command data format in the BLE protocol specification. This data could be, for example, a data packet containing a user authentication token and a timestamp. Alternatively, if the protocol command is based on a custom proprietary protocol, the protocol identification information could be a fixed frame header or a version number field. The target protocol stack can be configured with a parser that can determine the structure and length of subsequent data fields based on the frame header or version number, thereby extracting protocol data such as vehicle ID, user ID, and operation type.

[0090] The second part involves the controller converting the protocol data into an intermediate format and generating the target control command based on this intermediate format data, including: In one possible implementation, the controller reassembles the protocol data according to an intermediate format based on the protocol type corresponding to the target protocol stack, obtaining the intermediate format data. The controller then generates the target control instruction matching the service operation type based on the service operation type corresponding to the intermediate format data.

[0091] Intermediate format data is a predefined, standardized data structure independent of specific communication protocols. Its purpose is to unify heterogeneous protocol data output from different protocol stacks, enabling unified processing by upper-layer business logic. Intermediate format data can take various forms. For example, it can be a structured data format such as JSON (JavaScript Object Notation) or XML (Extensible Markup Language), defining uniform field names and data types to represent various business operations and parameters. It can also be a predefined binary data structure, where each field has a fixed offset and length to represent specific information. Reassembly refers to the process of mapping and converting the original protocol data into a unified intermediate format data according to its protocol type. The reassembly process involves parsing the original protocol data, extracting fields, converting data types, and reorganizing and encapsulating it according to the intermediate format specifications. For example, for protocol data representing an "unlock" operation, the reassembly process will fill the command identifier, device ID, security token, and other information into the corresponding "command type," "device identifier," and "authentication credential" fields in the intermediate format data, respectively. A service operation type refers to a classification of specific functions or behaviors identified from intermediate format data, representing the intent of a user or system to perform. For example, in digital key applications, service operation types may include "vehicle unlock," "vehicle lock," "engine start," "trunk open," and "authorization management." Service operation types can be determined directly by parsing preset "command" or "operation" fields in the intermediate format data, or by comprehensively judging and logically reasoning about multiple fields in the intermediate format data. A target control command refers to a standardized command ultimately sent to the vehicle control unit (such as the body controller or engine controller) to execute a specific operation. Target control commands are specific format data that can be recognized and executed by the vehicle's internal communication bus (such as CAN bus or Ethernet). The generation of target control commands requires consideration of the service operation type, combined with the vehicle's internal control logic and interface specifications. For example, a "vehicle unlock" service operation type may correspond to a specific CAN bus message ID and data payload, used to trigger the door unlocking mechanism.

[0092] Through the above implementation methods, by introducing intermediate format data, the standardization and unification of raw protocol data from different protocols are achieved, thereby decoupling the heterogeneity of the underlying protocols from the complexity of the upper-layer business logic, and improving the universality and compatibility of instruction conversion. Based on this, target control instructions are generated according to the clearly defined business operation types in the intermediate format data, making the target control instruction generation process more flexible and dynamically adaptable to specific business needs, avoiding the logical confusion and errors that may result from direct conversion. This layered and standardized processing mechanism not only improves the accuracy of instruction generation and the stability of the system, but also reduces the complexity of system maintenance and expansion, enabling the vehicle system to support multiple digital key standards and constantly changing business needs at a lower cost and with higher efficiency.

[0093] For example, the vehicle system has successfully connected to a mobile device that supports the CCC protocol, and the CCC protocol stack has been identified as the target protocol stack, which is loaded in the appropriate operating mode. When the mobile device sends a protocol command to "unlock the door," the CCC protocol stack receives and parses the command, extracting the raw CCC protocol data. This CCC protocol data might contain a specific command ID (e.g., 0x01 indicating unlock), a unique device identifier, and an encrypted security token. The controller, based on the CCC protocol type corresponding to the target protocol stack, reassembles this raw CCC protocol data according to a preset intermediate format. For example, the intermediate format could be defined as a JSON object containing fields such as "command," "device_id," and "security_token." The controller maps the command ID in the CCC protocol data to the "command" field (e.g., 0x01 maps to the string "UNLOCK"), the device unique identifier to the "device_id" field, and the security token to the "security_token" field, thereby generating a unified intermediate format data, such as: {"command":"UNLOCK","device_id":"ABC123XYZ","security_token":"SDFG456HJKL"}. Based on the "UNLOCK" service operation type represented by the "command" field in this intermediate format data, the controller queries a preset instruction mapping table or calls the corresponding instruction generation module to generate a target control instruction that matches the "UNLOCK" service operation type. For example, this target control instruction might be a specific CAN bus message with a message ID of 0x7E0 and a data payload of 0x01000000000000000. Once this CAN bus message is recognized by the vehicle's body control module, it can trigger a door unlocking action.

[0094] Optionally, based on the above implementation method, the protocol data can be reorganized according to an intermediate format. Before obtaining the intermediate format data, the following steps can also be performed.

[0095] In one possible implementation, the controller performs a security check on the protocol data. If the security check passes, the controller reassembles the protocol data according to an intermediate format to obtain the intermediate format data. If the security check fails, the controller rejects the protocol data.

[0096] Security verification refers to the process of verifying the integrity, authenticity, and legality of received protocol data. Its purpose is to ensure that the protocol data has not been tampered with, originates from a trusted source, and conforms to the expected format and logic. Implementation methods may include, but are not limited to: data integrity verification, such as calculating the checksum, cyclic redundancy check, or hash value of the protocol data and comparing it with the expected value to detect whether errors or tampering occurred during data transmission; data authenticity verification, such as verifying the digital signature or message authentication code carried by the protocol data to confirm that the data indeed comes from an authorized mobile device and prevent forged instructions; and data format and logic verification, such as checking whether the length, field type, and numerical range of the protocol data conform to predefined protocol specifications, and whether the operation represented by the data is legal in the current system state. Passing security verification indicates that the protocol data has successfully passed all preset security verification rules and is considered legal, complete, and trustworthy data. Failing security verification indicates that the protocol data fails to meet at least one security verification rule and may have problems such as tampering, forgery, format errors, or illegal operations. Rejecting protocol data means that when protocol data fails the security check, the controller does not continue to process the data, but discards it or performs error handling, such as logging or sending an error response to the mobile device, to prevent potential risks.

[0097] Through the above implementation method, a security verification mechanism for the protocol data is introduced before converting the protocol data into intermediate format data to generate the target control command. This mechanism, acting as a pre-processing threshold, filters out illegal, tampered, or abnormally formatted protocol data, preventing malicious commands from damaging the vehicle system. Reassembly is performed only after passing the security verification, ensuring that the subsequently generated intermediate format data and the final target control command are based on secure and reliable source data, thereby guaranteeing the accuracy of command execution and the security of system operation. Protocol data that fails the security verification is rejected, avoiding the blind processing of invalid or dangerous commands, reducing the risk of system crashes or logical errors due to processing abnormal data, and further enhancing the robustness of the digital key system in multi-protocol environments. Combined with the above scheme of parsing protocol commands into protocol data and converting the protocol data into intermediate format data to generate the target control command, the security and reliability of the entire command processing chain are enhanced, ensuring the stable operation of the digital key function.

[0098] It should be noted that the previous implementation was based on the example of one mobile device. When there are multiple mobile devices, the controller can also perform the following steps.

[0099] In one possible implementation, when connected to multiple mobile devices, the controller identifies the protocol of each mobile device to determine the protocol types supported by each device. Based on the protocol type corresponding to each mobile device, the controller determines the target protocol stack corresponding to each mobile device and loads each target protocol stack in the corresponding operating mode.

[0100] The above-described embodiments and the embodiments described in step 301 belong to the same inventive concept, and will not be repeated here.

[0101] 306. The controller outputs the target control command.

[0102] In one possible implementation, after generating the target control command, the controller invokes a standardized service interface that is compatible with the target control commands output by each of the multiple candidate protocol stacks. The controller then outputs the target control command through this standardized service interface.

[0103] In this context, calling the standardized business interface refers to triggering a predefined, uniformly regulated software interface after the target control command is generated. This interface specifies the data format, calling method, and functional behavior, allowing different modules or systems to interact through this unified interface without needing to understand the specific details of the underlying implementation. This standardized business interface can be an abstract class or interface that defines a set of method signatures. All output modules of the protocol stack implement these methods, thus providing a unified entry point. Alternatively, the standardized business interface can be a mechanism based on a message queue or event bus. The protocol stack encapsulates the target control command into standard-format messages or events, publishes them to the bus, and upper-layer business logic subscribes to and processes these standard messages or events.

[0104] The standard business interface's compatibility with the target control instructions output by multiple candidate protocol stacks means that regardless of which candidate protocol stack generates the target control instructions, their format, content, and semantics can be understood and processed by the standardized business interface, which can then provide these instructions externally in a unified manner. This can be achieved by including an adaptation layer or converter within the interface, which can uniformly convert specific format instructions output by different protocol stacks into the standard format defined by the interface. Alternatively, the standardized business interface can be designed from the outset to consider the instruction types and data structures that all candidate protocol stacks might output, and define a general data model that can cover all these cases. Through the standardized business interface, the output target control instructions allow upper-layer business logic to interact only with this one standardized interface, without needing to know which specific protocol stack the instructions originate from. The standardized business interface can directly pass the converted standard format target control instructions to upper-layer business modules, for example, through function calls, callback functions, or shared memory. Alternatively, the standardized business interface can write the target control instructions to a unified output buffer or message queue, from which upper-layer business modules read the instructions.

[0105] The above implementation method introduces a standardized business interface, decoupling the protocol stack output from the upper-layer business logic. This eliminates the need for upper-layer business logic to adapt to different protocol stack output formats, thereby reducing the complexity of system development and maintenance costs. Furthermore, it enhances the system's flexibility and scalability, ensuring that when adding new protocol standards, only the output of the new protocol stack is required to be compatible with the standardized business interface, without modifying the core business logic. This improves the stability and adaptability of the digital key system in multi-protocol compatible environments.

[0106] For example, the mobile device supports the CCC protocol and loads the corresponding target protocol stack based on the identification result. When the mobile device sends a "unlock door" protocol command, the loaded target protocol stack converts it into a target control command. To ensure that the vehicle's central control unit (CCU) or body control module (BCM) and other upper-level business logic can uniformly process these commands, a standardized business interface called IVehicleControl is invoked after the target control command is generated. This IVehicleControl interface defines standard methods such as unlockDoor(DoorID) and lockDoor(DoorID). Whether the "unlock door" command is generated by the CCC protocol stack or the ICCE protocol stack, it will be adapted by the output module of its respective protocol stack and the IVehicleControl::unlockDoor(FRONT_LEFT_DOOR) method will be called. The IVehicleControl interface outputs this standardized "unlock door" command to the vehicle's internal communication bus (e.g., CAN bus) or directly to the CCU / BCM. In this way, the CCU / BCM, as the upper-layer business logic, always receives control commands in a uniform format through the IVehicleControl interface, without needing to care about the specific source protocol of the commands.

[0107] The following is combined with Figure 4 The technical solutions provided in the embodiments of this application will be described.

[0108] See Figure 4After the vehicle system starts or initializes, the underlying driver layer is initialized, and protocol commands and radio frequency resources are processed uniformly. A protocol adaptation layer is loaded, establishing an abstraction layer for standardized business interfaces. The controller awaits trigger events. Upon detecting a mobile device signal, the target protocol type supported by the mobile device is identified. In response to a policy change command issued from the cloud, the corresponding target protocol type is determined. In response to a protocol type selection operation, the selected target protocol type is determined; the target protocol type includes CCC, ICCE, or a proprietary protocol. The controller loads the target protocol stack corresponding to the target protocol type, i.e., the protocol stack corresponding to CCC, ICCE, or the proprietary protocol. Additionally, in response to a weak RSSI for Bluetooth communication and UWB availability, the controller performs an environmental resource assessment to determine whether to load the UWB high-precision protocol stack or the Bluetooth low-precision lightweight protocol stack. The controller monitors system resources in real time. If system resource usage is too high, the controller triggers resource optimization, unloading currently inactive protocol stacks and retaining only active ones. Under normal system resource conditions, protocol data is converted into intermediate format data through standardized business interfaces. The intermediate format data undergoes security verification, and upon successful verification, it is converted into target control commands. The controller then sends the target control commands to the corresponding upper-layer business module. The controller then either ends the monitoring process or continues with the next round of listening.

[0109] Figure 5 This is a schematic diagram of the structure of an instruction generation device provided in an embodiment of this application. See also... Figure 5 The device includes: The protocol stack determination module 501 is used to determine the target protocol stack from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device when connected to a mobile device.

[0110] Load module 502 is used to load the target protocol stack.

[0111] The conversion module 503 is used to convert the protocol instructions from the mobile device through the target protocol stack to generate target control instructions.

[0112] It should be noted that the instruction generation apparatus provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the instruction generation apparatus and instruction generation method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0113] This application also provides a vehicle. Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0114] Typically, vehicle 600 includes one or more processors 601 and one or more memories 602.

[0115] Processor 601 may include one or more processing cores, such as a quad-core processor, a hexa-core processor, etc. Processor 601 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 601 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 601 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 601 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0116] The memory 602 may include one or more computer-readable storage media, which may be non-transitory. The memory 602 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 602 are used to store at least one computer program, which is executed by the processor 601 to implement the instruction generation method provided in the method embodiments of this application.

[0117] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on vehicle 600 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0118] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute an instruction generation method provided in the above embodiments.

[0119] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, it causes the computer to execute the above-described related method steps to implement the instruction generation method provided in the above embodiment.

[0120] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the instruction generation method provided in the above embodiment.

[0121] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0122] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating instructions, characterized in that, The method includes: When connected to a mobile device, the target protocol stack is determined from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device. Load the target protocol stack; The target protocol stack is used to convert protocol instructions from the mobile device to generate target control instructions.

2. The method according to claim 1, characterized in that, Loading the target protocol stack includes: Based on the system resource status and the resource requirements of the target protocol stack, the operating mode of the target protocol stack is determined; The target protocol stack is loaded in the described operating mode.

3. The method according to claim 2, characterized in that, The process of determining the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack includes: The system resource status is compared with the resource status threshold to obtain the resource status comparison result; Based on the resource status comparison results and the resource requirements of the target protocol stack, the operating mode of the target protocol stack is determined from multiple preset operating modes, and different preset operating modes correspond to different resource consumption.

4. The method according to claim 3, characterized in that, The step of determining the operating mode of the target protocol stack from multiple preset operating modes based on the resource status comparison result and the resource requirements of the target protocol stack includes: If the resource status comparison result indicates that the system resource status meets the first condition, based on the resource requirements of the target protocol stack, a first operating mode that matches the resource requirements is determined from the plurality of preset operating modes, and is used as the operating mode of the target protocol stack. If the resource status comparison result indicates that the system resource status meets the second condition, the current available resource balance is determined based on the system resource status; from the multiple preset operating modes, an operating mode whose resource demand does not exceed the current available resource balance and whose resource consumption is lower than the first operating mode is selected as the second operating mode.

5. The method according to claim 2, characterized in that, Before determining the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack, the method further includes: Obtain the current environment context parameters, which represent the environmental state of the communication environment in which the mobile device is located; The process of determining the operating mode of the target protocol stack based on the system resource status and the resource requirements of the target protocol stack includes: Based on the system resource status, the resource requirements of the target protocol stack, and the environmental context parameters, the operating mode of the target protocol stack is determined from multiple preset operating modes, and different preset operating modes correspond to different resource consumption.

6. The method according to claim 5, characterized in that, The step of determining the operating mode of the target protocol stack from multiple preset operating modes based on the system resource status, the resource requirements of the target protocol stack, and the environmental context parameters includes: Based on the environmental context parameters and the resource requirements of the target protocol stack, at least one candidate operating mode is determined from the plurality of preset operating modes; Based on the system resource status, the operating mode that matches the system resource status is determined from the at least one candidate operating modes.

7. The method according to claim 1, characterized in that, The step of converting protocol instructions from the mobile device through the target protocol stack to generate target control instructions includes: The target protocol stack is used to identify the protocol identification information contained in the protocol instructions; Based on the protocol identification information, extract the protocol data corresponding to the protocol identification information from the protocol instructions; Based on the protocol type corresponding to the target protocol stack, the protocol data is reorganized according to an intermediate format to obtain intermediate format data; Based on the business operation type corresponding to the intermediate format data, the target control instruction matching the business operation type is generated.

8. The method according to claim 7, characterized in that, Before reassembling the protocol data according to the intermediate format to obtain the intermediate format data, the method further includes: Perform security verification on the protocol data; If the security verification is passed, the step of reassembling the protocol data according to the intermediate format to obtain the intermediate format data is performed; If the security check fails, the protocol data is rejected.

9. The method according to claim 1, characterized in that, In the case of a connection to a mobile device, before determining the target protocol stack from multiple candidate protocol stacks based on the protocol type obtained by protocol identification of the mobile device, the method includes: The broadcast data of the mobile device is scanned based on the target scanning parameters, and protocol feature information is extracted from the broadcast data; The protocol type supported by the mobile device is determined based on the protocol feature information.

10. The method according to claim 9, characterized in that, Before scanning the broadcast data of the mobile device based on target scanning parameters and extracting protocol feature information from the broadcast data, the method further includes: Determine the signal strength of the mobile device; When the signal strength of the mobile device meets the preset conditions, the scanning parameters are adjusted so that the scanning interval is shortened to less than the normal scanning interval, thereby obtaining the target scanning parameters; If the signal strength of the mobile device does not meet the preset conditions, the scanning parameters corresponding to the regular scanning interval shall be used as the target scanning parameters.

11. The method according to claim 1, characterized in that, The method further includes: After generating the target control command, a standardized business interface is invoked, which is compatible with the target control commands output by each of the multiple candidate protocol stacks. The target control command is output through the standardized business interface.

12. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the instruction generation method as described in any one of claims 1 to 11.

Images