Equipment management method and device, vehicle, medium and program product

Abstract

The invention provides an equipment management method and device, a vehicle, a medium and a program product, and relates to the technical field of intelligent equipment or intelligent cockpit, and the method comprises the steps: obtaining equipment information corresponding to target equipment and actual loads corresponding to a plurality of candidate Bluetooth chips; determining a target chip from the plurality of candidate Bluetooth chips according to the device information of the target device and the actual loads respectively corresponding to the plurality of candidate Bluetooth chips; and establishing communication connection with the target equipment through the target chip. According to the invention, the Bluetooth connection of the intelligent device is dynamically allocated to the plurality of Bluetooth chips, so that load balancing can be realized, the resource utilization rate can be optimized, the problems of audio lagging, control instruction delay, connection disconnection and the like caused by overload of a single chip are reduced, and the connection stability and the communication quality are improved.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent device technology or intelligent cockpit technology, and more particularly to an equipment management method, device, vehicle, medium and program product. Background Technology

[0002] With the rapid development of IoT technology, the modern smart cockpit has evolved into a highly complex mobile communication hub. Vehicles can simultaneously establish and maintain stable Bluetooth connections with multiple smartphones, Bluetooth headsets, and their own peripheral devices. Summary of the Invention

[0003] This disclosure provides a device management method, apparatus, vehicle, medium, and program product for dynamically allocating Bluetooth chip resources to achieve efficient resource utilization and load balancing.

[0004] According to a first aspect of the present disclosure, a device management method is provided, comprising: Obtain the device information corresponding to the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips; The target chip is determined from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips. A communication connection is established between the target chip and the target device.

[0005] This disclosure obtains device information corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips; determines the target chip from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the multiple candidate Bluetooth chips; and establishes a communication connection between the target chip and the target device. In this way, by dynamically distributing the Bluetooth connection of a smart device across multiple Bluetooth chips, load balancing can be achieved, resource utilization can be optimized, and problems such as audio stuttering, control command delay, or connection disconnection caused by overload of a single chip can be reduced, thereby improving connection stability and communication quality.

[0006] In some possible implementations, the device information includes at least the device type of the target device. Determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the plurality of Bluetooth chips includes: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

[0007] This disclosure combines the demand load corresponding to the target device with the actual load corresponding to multiple candidate Bluetooth chips, and dynamically selects the target chip from multiple candidate Bluetooth chips. This allows the impact on the entire system after the connection is established to be anticipated before the connection is established, thereby making the optimal decision. This can effectively improve system stability and achieve refined management of resources and maximize utilization efficiency.

[0008] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips includes: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

[0009] This disclosure allows for the redirection of high-load demand devices to slave chips when the main chip is already under heavy load, thus ensuring the stability and quality of service of existing communication connections on the main chip. Furthermore, by setting thresholds, demand load and real-time load can be quickly assessed with low computational overhead, making it suitable for real-time operation in resource-constrained embedded systems and ensuring rapid decision-making.

[0010] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips further includes: The main chip is identified as the target chip in response to at least one of the following conditions: The required load corresponding to the target device is less than or equal to the first load threshold; The actual load corresponding to the main chip is less than or equal to the second load threshold. The actual load corresponding to the main chip is greater than the second load threshold, and the actual load corresponding to the slave chip is greater than the second load threshold.

[0011] This disclosure describes several scenarios in which the master chip is identified as the target chip. For lightweight tasks, this avoids unnecessary bandwidth allocation overhead, ensuring operational efficiency under normal conditions. When the master chip has sufficient resources, its superior performance is prioritized, providing users with the best connectivity experience. Furthermore, when both the master and slave chips are under high load, prioritizing the connection to the higher-performance master chip minimizes the risk of system crashes due to slave chip overload, enhancing the system's resilience and survivability.

[0012] In some possible implementations, the device information further includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the method further includes: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

[0013] This disclosure pre-screens candidate Bluetooth chips, eliminating potentially incompatible chips in advance, or prioritizing Bluetooth chips with a history of successful connections. This effectively reduces connection failures due to compatibility issues and ensures a successful connection, reduces unnecessary computational overhead when selecting the target chip, improves the overall decision-making efficiency of the system, and enhances the robustness and user experience of the system.

[0014] In some possible implementations, based on the Bluetooth protocol information corresponding to the target device, the plurality of candidate Bluetooth chips are selected from a plurality of Bluetooth chips, including: Based on the Bluetooth protocol information corresponding to the target device, determine the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips; If the number of Bluetooth chips that support the Bluetooth protocol information is greater than or equal to 2 among the plurality of Bluetooth chips, the Bluetooth chip that supports the Bluetooth protocol information is determined as the candidate Bluetooth chip.

[0015] This disclosure determines the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips. If there is more than one Bluetooth chip that meets the criteria, they are all identified as candidate Bluetooth chips, so that the target chip can be further decided based on the subsequent candidate Bluetooth chips. If there is only one, no further decision-making process is required, which ensures the optimal efficiency and logical simplification of the system in decision-making and achieves a good balance between system intelligence and resource consumption.

[0016] In some possible implementations, the method further includes: In response to the fact that only the first Bluetooth chip among the plurality of Bluetooth chips supports the Bluetooth protocol information, the first Bluetooth chip is identified as the target chip.

[0017] This disclosure determines the number of chips that support the Bluetooth protocol information among multiple Bluetooth chips. When only one chip is available, a series of steps such as load acquisition, comparison and selection are not required, saving processor computing resources and time, and speeding up the establishment of Bluetooth connections.

[0018] In some possible implementations, the candidate Bluetooth chips are selected from the multiple Bluetooth chips based on the historical pairing status between the target device and the multiple Bluetooth chips, including: In response to the historical binding status indicating that the target device and the plurality of Bluetooth chips do not have a historical binding relationship, all of the plurality of Bluetooth chips are identified as candidate Bluetooth chips; or, In response to the historical binding status indicating that the number of chips with historical binding relationships between the target device and the plurality of Bluetooth chips is greater than or equal to 2, the Bluetooth chips with historical binding relationships with the target device are determined as the candidate Bluetooth chips.

[0019] This disclosure identifies multiple candidate Bluetooth chips when the target device has no historical pairing relationship with any of the multiple Bluetooth chips, or when there is a large amount of data on Bluetooth chips that have historical pairing relationships with the target device. This allows for further decision-making regarding the target chip, enabling the target device to prioritize connecting to chips with historical pairing relationships. In this way, some Bluetooth service discovery and parameter negotiation processes can be skipped, and the connection can be quickly rebuilt using stored pairing information and connection parameters. This significantly reduces the time from discovery to availability, while greatly improving the connection success rate and stability.

[0020] In some possible implementations, the method further includes: When the historical binding status indicates that the target device has a historical binding relationship only with the second Bluetooth chip among the plurality of Bluetooth chips, the second Bluetooth chip is identified as the target chip.

[0021] When this disclosure determines that the target device has a unique historical binding relationship through the historical binding status of the second Bluetooth chip, it can directly connect to the target device through the second Bluetooth chip without any user operation. This eliminates some Bluetooth service discovery and parameter negotiation processes, improves connection efficiency, and achieves seamless connection, greatly enhancing user satisfaction.

[0022] In some possible implementations, the actual load corresponding to each of the multiple Bluetooth chips is obtained, including any of the following: Based on the service types corresponding to the plurality of Bluetooth chips, determine the actual load corresponding to each of the plurality of Bluetooth chips; Obtain the occupied bandwidth corresponding to each of the multiple Bluetooth chips, and determine the actual load corresponding to each Bluetooth chip based on the occupied bandwidth.

[0023] This disclosure provides two methods for determining the actual load, offering accurate data for load balancing. Determining the Bluetooth chip's actual load by service type incurs low computational overhead and offers fast response, making it suitable for systems with high real-time requirements but lower absolute accuracy requirements. Determining the Bluetooth chip's actual load by its bandwidth usage accurately reflects physical layer congestion, making it suitable for scenarios requiring fine-grained management. Users can flexibly choose or combine these methods based on their capabilities to meet the decision-making needs of different scenarios.

[0024] In some possible implementations, the actual load corresponding to each of the multiple Bluetooth chips is obtained, including: In response to the Bluetooth connection request from the target device, the actual load corresponding to each of the multiple Bluetooth chips is obtained.

[0025] This disclosure triggers the target chip's decision-making process only when a Bluetooth connection request from the target device is received. This allows the main control device to work only when the target device needs to connect, avoiding the need to maintain load monitoring threads for all chips. During the majority of idle time without connection requests, the system can maintain a low-power state, achieving a high degree of elasticity and on-demand allocation of system resources, and improving the overall resource utilization efficiency.

[0026] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip. The method for determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each candidate Bluetooth chip further includes: In response to establishing a communication connection between the chip and the target device, the step of determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips is periodically executed.

[0027] This disclosure allows the target chip's decision-making process to be executed periodically and automatically when there is a communication connection between the chip and the target device. In this way, the target device can adapt to the dynamic changes in the system environment. When the load of the high-performance main chip is reduced, the core hardware resources of the main chip can be fully utilized, avoiding the unreasonable situation of high-performance chips being idle while low-performance chips are overloaded, thus improving the utilization rate of high-value chips. At the same time, the migration process of chip connection does not require manual intervention from the user, which greatly improves intelligence and user satisfaction.

[0028] In some possible implementations, the device type of the target device is used to determine the demand load corresponding to the target device, wherein the larger the value of the demand load, the shorter the interval between cycles.

[0029] This disclosure sets the interval between cycles to follow the changes in demand load, with the interval becoming smaller as the demand load increases. This ensures that the communication connection of devices with high demand loads can be optimized immediately. It also reduces the frequency at which devices with low demand loads re-determine the target chip when the performance requirements for communication interaction are not high, thereby reducing the overall power consumption and computational overhead of the system and significantly optimizing the system's computing resources and power consumption.

[0030] According to a second aspect of the present disclosure, a device management apparatus is provided, comprising: The acquisition module is configured to acquire device information corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips; The determination module is configured to determine the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips respectively; The connection module is configured to establish a communication connection with the target device through the target chip.

[0031] In some possible implementations, the device information includes the device type of the target device, and the determining module is configured to: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

[0032] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; the determining module is configured to: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

[0033] In some possible implementations, the device information further includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the device management device is further configured to: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

[0034] According to a third aspect of the present disclosure, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the device management method described in the first aspect of the present disclosure.

[0035] According to a fourth aspect of the present disclosure, a vehicle is provided, including the electronic equipment provided in the third aspect of the present disclosure.

[0036] According to a fifth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the device management method described in the first aspect of the present disclosure.

[0037] According to a sixth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the device management method described in the first aspect of the present disclosure.

[0038] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: This disclosure obtains device information corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips; determines the target chip from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the multiple candidate Bluetooth chips; and establishes a communication connection between the target chip and the target device. In this way, by dynamically distributing the Bluetooth connection of a smart device across multiple Bluetooth chips, load balancing can be achieved, resource utilization can be optimized, and problems such as audio stuttering, control command delay, or connection disconnection caused by overload of a single chip can be reduced, thereby improving connection stability and communication quality.

[0039] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0041] Figure 1 This is a flowchart illustrating a device management method according to an exemplary embodiment.

[0042] Figure 2 This is a flowchart illustrating a device management method according to an exemplary embodiment.

[0043] Figure 3 This is a block diagram illustrating a device management apparatus according to an exemplary embodiment.

[0044] Figure 4 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0045] Figure 5 This is a block diagram illustrating a vehicle according to an exemplary embodiment. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0047] Among related technologies, Bluetooth technology, based on low-cost short-range wireless connectivity, is a special short-range wireless technology that establishes a communication environment for fixed and mobile devices. Bluetooth technology has become one of the core technologies for local area connectivity in fields such as smart homes, wearable devices, and in-vehicle devices.

[0048] For example, mobile phones and in-vehicle systems typically use a single Bluetooth chip to manage Bluetooth connections and communications for all smart devices. This centralized architecture is adequate when the number of devices is small. However, as the number of devices connected simultaneously increases and the demand for data transmission grows, a single Bluetooth chip can no longer meet the connectivity needs of smart devices to the main device. Furthermore, a single Bluetooth chip cannot support the various Bluetooth protocol versions supported by different devices.

[0049] In related technologies, some devices have adopted dual-Bluetooth chip and multi-Bluetooth chip architectures as backup resources. All devices are bound to the main chip by default. When the main chip cannot connect to a new device, the slave chip serves as a backup connection resource. However, when the main chip is under heavy load, the slave chip may remain idle, resulting in severely uneven resource allocation. Furthermore, the main chip experiences high conflict rates when handling multiple tasks simultaneously, leading to issues such as audio stuttering, control command delays, or connection drops, resulting in a poor user experience.

[0050] Reference Figure 1 , Figure 1 This is a flowchart illustrating a device management method according to an exemplary embodiment, such as... Figure 1As shown, the device management method can be applied to main control devices such as mobile terminals, vehicle-mounted devices, and smart device gateways. The main control device includes multiple Bluetooth chips, and the device management method includes the following steps.

[0051] In step S101, the device information corresponding to the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips are obtained.

[0052] In step S102, the target chip is determined from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips.

[0053] In step S103, a communication connection is established between the target chip and the target device.

[0054] For example, the target device refers to the managed Bluetooth device that currently seeks to establish a connection with the Bluetooth chip of the host device. The target device can be any IoT device in the user's room, such as a smart speaker, smart curtains, smart TV, smart lights, smart air conditioner, air purifier, etc. The target device can also be any IoT device used in the user's vehicle, such as a smart camera, remote vehicle control system, digital key, car speaker, etc. The target device can also be any device that the user can carry with them, such as a smartwatch, mobile phone, smart camping light, Bluetooth speaker, etc.

[0055] For example, device information may include the target device's device identifier, device type, service UUID (Universally Unique Identifier), Bluetooth signal strength, and other custom data such as the device's capability identifier.

[0056] For example, the device identifier is used to uniquely identify the target device, such as a MAC address or device name. The device type can be used to determine the payload capacity of the target device; for example, the device type could be a Bluetooth Low Energy device, an audio device (such as a speaker or headphones), or a high-speed data transmission device. The service UUID can be used to determine the type of service provided by the target device, such as providing audio, audio playback, or voice calls. The signal strength can be the RSSI value between the target device and various candidate Bluetooth chips.

[0057] For example, a Bluetooth chip is a Bluetooth communication module present in a device system. Examples include smart home gateways, high-end routers, in-vehicle infotainment systems, mobile phones, or multi-mode devices. Multiple Bluetooth chips can be multiple independent physical Bluetooth chips on the same gateway motherboard, or multiple logical entities virtualized on a multi-core or multi-connection Bluetooth system-on-a-chip. Multiple Bluetooth chips can operate simultaneously or in a time-sharing manner.

[0058] For example, multiple candidate Bluetooth chips can be all or at least some of a plurality of Bluetooth chips. Each Bluetooth chip has its own processing power, memory, supported Bluetooth protocols, and radio frequency resources. For instance, each Bluetooth chip supports one or more Bluetooth protocols; multiple Bluetooth chips can support the exact same Bluetooth protocols, partially the same Bluetooth protocols, or completely different Bluetooth protocols. The specifics can be determined based on actual needs and are not limited here.

[0059] For example, actual load refers to the workload or resource consumption of each candidate Bluetooth chip at a specific moment when data is collected. Specifically, data can be collected for each candidate Bluetooth chip to determine its actual load.

[0060] For example, the actual load can be determined based on the number of devices currently actively connected to the candidate Bluetooth chip; the actual load can also be determined based on the candidate Bluetooth chip's current data transmission rate, i.e., the total amount of uplink or downlink data transmission currently in progress. The more devices there are, the larger the total data transmission volume, and the greater the corresponding actual load.

[0061] For example, the actual load can be determined based on the type of service that the candidate Bluetooth chip is currently performing, such as the connected device playing music, making or receiving calls, or searching for devices. The actual load for making or receiving calls is obviously greater than the actual load for searching for devices.

[0062] For example, the actual load can also be determined by the resource usage of the candidate Bluetooth chip's internal processor and memory through hardware communication, which can directly determine the air interface channel used and the bandwidth occupied by the candidate Bluetooth chip.

[0063] For example, the target chip is determined based on the device information of the target device and the actual load corresponding to multiple candidate Bluetooth chips, and is the most suitable candidate Bluetooth chip to establish a communication connection with the target device.

[0064] For example, when the actual load of the first candidate Bluetooth chip is large, the second candidate Bluetooth chip with a smaller actual load can be selected as the target chip, and a communication connection can be established between the second candidate Bluetooth chip and the target chip; when the actual load of multiple candidate Bluetooth chips is small, the preset master chip can be selected as the target chip, and a communication connection can be established between the master chip and the target device.

[0065] For example, a communication connection refers to a stable link between a target chip and a target device for bidirectional data transmission at the Bluetooth protocol stack level. The process of establishing a communication connection between the target chip and the target device may include connection establishment, pairing, binding, and communication testing. After the communication connection is established, the target chip and the target device can perform data communication processes such as sending control commands and transmitting audio streams.

[0066] For example, when a target device requests to connect to a Bluetooth chip, its device information can be obtained, and the actual load of multiple candidate Bluetooth chips can be collected. Alternatively, the target device's device information can be obtained periodically, and the actual load of multiple candidate Bluetooth chips can be collected. Then, based on the target device's device information and the actual load of the multiple candidate Bluetooth chips, after a decision is made from the multiple candidate Bluetooth chips, the standard Bluetooth connection process with the target device is executed through the selected target chip.

[0067] For example, based on the device information of the target device and the actual load corresponding to the multiple candidate Bluetooth chips, the target chip can be determined. The target chip is the optimal solution among the multiple candidate Bluetooth chips and is most suitable for communicating with the target device.

[0068] For example, a decision-making strategy can prioritize meeting device load balancing needs. For instance, prioritizing the chip with the lightest current load can prevent overloading of a single chip.

[0069] For example, the decision-making strategy can also prioritize device compatibility requirements. For instance, if the target device is an audio device and a specified Bluetooth chip has a strategy for optimizing audio decoding, then that specified Bluetooth chip is selected first; if the signal strength (RSSI) between the target device and a certain chip is much higher than that of other chips, then the chip with the stronger signal is selected first to ensure connection quality.

[0070] For example, decision-making strategies can also be based on requirements such as business isolation, distributing high-bandwidth devices and low-bandwidth devices onto different chips to avoid mutual interference.

[0071] This disclosure obtains device information corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips; determines the target chip from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the multiple candidate Bluetooth chips; and establishes a communication connection between the target chip and the target device. In this way, by dynamically distributing the Bluetooth connection of a smart device across multiple Bluetooth chips, load balancing can be achieved, resource utilization can be optimized, and problems such as audio stuttering, control command delay, or connection disconnection caused by overload of a single chip can be reduced, thereby improving connection stability and communication quality.

[0072] This disclosure enhances the scalability of a system by increasing the number of Bluetooth chips in a device and using device management methods when the main control device is expected to connect to more smart devices or to support multiple versions of Bluetooth connection protocols. This is achieved by increasing the number of Bluetooth chips in the device and using device management methods, rather than pursuing the performance limits of a single chip.

[0073] In some possible implementations, the device information includes at least the device type of the target device. Determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the plurality of Bluetooth chips includes: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

[0074] For example, device type is used to infer the resource requirements of a target device. This can be categorized based on the target device's Bluetooth connectivity features. For instance, device type could include highly interactive audio devices or interactive input devices.

[0075] For example, device types can be categorized into audio devices, human-computer interaction devices, data synchronization devices, and low-speed sensors. Audio devices generate continuous high-bandwidth data streams, such as wireless headphones, smartphones, or tablets, primarily used for high-bandwidth functions like A2DP music playback and HFP hands-free calling. Human-computer interaction devices generate small amounts of data but have high real-time requirements, such as Bluetooth keyboards and touchpads (HID Profiles). Data synchronization devices may suddenly consume high bandwidth, such as dashcams and vehicle diagnostic tools. Low-speed sensors intermittently send extremely small data packets, requiring high power consumption and very low bandwidth, such as heart rate sensors in smartwatches and tire pressure monitoring systems in vehicles.

[0076] For example, demand load is used to characterize the amount of Bluetooth chip resources that a specific type of device is expected to consume during normal operation. Demand load is a quantitative metric used to predict the potential burden of a target device before a connection is established. Demand load can be an estimated value based on device type mapping, such as any value in the range of 0-10; demand load can also be represented by preset load levels, such as high load, medium load, low load, etc.

[0077] For example, the main control device's system can have a preset demand load lookup table, which can determine the demand load based on the device type. For instance, a smartphone, as an audio source, may simultaneously perform high-bandwidth Bluetooth audio transmission or real-time voice calls, consuming a large amount of resources, and its corresponding demand load is high; a wireless headset, as an audio receiver, mainly receives high-bandwidth audio streams, requiring high bandwidth, but usually does not initiate calls, and its corresponding demand load is medium; an HID (Human Interface Device) keyboard only sends tiny data packets when keys are pressed and is idle most of the time, and its corresponding demand load is low.

[0078] For example, based on the device type of the target device, the required load corresponding to the target device is determined. Then, the target chip can be dynamically determined from multiple candidate Bluetooth chips by combining the required load corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips.

[0079] For example, the load required by the target device can be determined based on the device information of the target device. If the load required by the target device is large, and the actual load of the first candidate Bluetooth chip is also large, the second candidate Bluetooth chip with a smaller actual load can be selected as the target chip. A communication connection can then be established between the second candidate Bluetooth chip and the target device to meet the load balancing requirements.

[0080] For example, among multiple candidate Bluetooth chips, there are master chips and slave chips. The function and performance of the master chip are usually better than those of the slave chip. If the target device requires a large load and the actual load of multiple candidate Bluetooth chips is large, the preset master chip can be determined as the target chip. A communication connection can be established between the master chip and the target device to achieve the optimal performance requirement of the target device connecting to the Bluetooth chip.

[0081] For example, if the load limit for the first candidate Bluetooth chip is 20 and the load limit for the second candidate Bluetooth chip is 10, when the target device connects to the main control device, the actual load of the first candidate Bluetooth chip is 10, and the actual load of the second candidate Bluetooth chip is 4. At this time, the actual load percentage of the first candidate Bluetooth chip is 50%, and the actual load percentage of the second candidate Bluetooth chip is 40%, meaning the second candidate Bluetooth chip is more idle. If the target device is a mobile phone, and the required load based on the device type is 7, but the second candidate Bluetooth chip cannot support the required load of the mobile phone, the first candidate Bluetooth chip can be selected as the target chip, and a communication connection can be established with the target device through the first candidate Bluetooth chip.

[0082] This disclosure combines the demand load corresponding to the target device with the actual load corresponding to multiple candidate Bluetooth chips, and dynamically selects the target chip from multiple candidate Bluetooth chips. This allows the impact on the entire system after the connection is established to be anticipated before the connection is established, thereby making the optimal decision. This can effectively improve system stability and achieve refined management of resources and maximize utilization efficiency.

[0083] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips includes: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

[0084] For example, the master chip is the Bluetooth chip designated or defaulted to perform the core tasks among multiple candidate Bluetooth chips, and can be pre-specified by the system designer during hardware design or software initialization. The slave chip is a Bluetooth chip that assists or serves as a backup to the master chip among multiple candidate Bluetooth chips. The slave chip can be used to take over new connections to the target device or migrate some existing connections between the master chip and the target device when the master chip is overloaded, malfunctions, or cannot support certain Bluetooth protocols, thereby distributing the load.

[0085] In some exemplary cases, the master chip is typically more powerful, has higher priority, and supports more protocols than the slave chip; in other exemplary cases, the master chip may have the same performance, higher priority, and number of supported protocols as the slave chip; in still other exemplary cases, the slave chip may also be a coprocessor used to support a specific Bluetooth protocol, while the master chip may not support that specific Bluetooth protocol.

[0086] For example, the first load threshold is a threshold used to determine the resource demand of the target device. The second load threshold is a threshold used to determine the actual load of the Bluetooth chip. The first and second load thresholds can be preset according to actual conditions.

[0087] For example, when the device type is a mobile phone or tablet that provides audio, the corresponding demand load is heavy; when the device type is headphones or speakers that play audio, the corresponding demand load is medium; and when the device type is a keyboard or mouse that provides human-computer interaction, the corresponding demand load is light. The first load threshold can be set to medium load, meaning that if the demand load corresponding to the target device is greater than the first load threshold, only heavy load occurs.

[0088] For example, when it is determined that the target device has a high demand load, the slave chip is identified as the target chip only when the actual load of the master chip is high and the actual load of the slave chip is low.

[0089] For example, when the main chip's service type is making and receiving calls, the corresponding actual load is 0.9, and when the slave chip's service type is outputting audio, the corresponding actual load is 0.6. The second load threshold can be set to 0.8. In this case, the actual load of the main chip is greater than 0.8, and the actual load of the slave chip is less than or equal to 0.8, thus the slave chip can be identified as the target chip.

[0090] For example, there can be only one master chip and one or more slave chips. In one example, with multiple slave chips, when the target device has a large load requirement, if the actual load of the master chip is large and the actual load of the slave chips is small, any one of the multiple slave chips can be selected as the target chip. Alternatively, the slave chip with the smallest actual load can be selected as the target chip, or the slave chip with the best performance can be selected as the target chip.

[0091] This disclosure allows for the redirection of high-load demand devices to slave chips when the main chip is already under heavy load, thus ensuring the stability and quality of service of existing communication connections on the main chip. Furthermore, by setting thresholds, demand load and real-time load can be quickly assessed with low computational overhead, making it suitable for real-time operation in resource-constrained embedded systems and ensuring rapid decision-making.

[0092] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips further includes: The main chip is identified as the target chip in response to at least one of the following conditions: The required load corresponding to the target device is less than or equal to the first load threshold; The actual load corresponding to the main chip is less than or equal to the second load threshold. The actual load corresponding to the main chip is greater than the second load threshold, and the actual load corresponding to the slave chip is greater than the second load threshold.

[0093] For example, if the load demanded by the target device is less than or equal to the first load threshold, the load required by the target device is relatively small, and the main chip can still be used to connect to the target device. Directly assigning lightweight tasks to the default main chip eliminates the need for complex load balancing mechanisms, making it the processing method with the lowest system overhead and simplest logic. Furthermore, even when the performance of the main chip is superior to that of the slave chip, it can still guarantee the communication quality when the target device connects to the Bluetooth chip.

[0094] For example, when the actual load corresponding to the main chip is less than or equal to the second load threshold, the actual load of the main chip is low. Even if the target device is a high-demand device, the main chip is still capable of handling this new high-demand task. In this case, the main chip is usually the most powerful component, and its performance advantages can be fully utilized.

[0095] For example, when the actual load corresponding to both the main chip and the slave chip exceeds the second load threshold, the actual loads of both the main chip and the slave chip are high. As the core Bluetooth chip of the system, the main chip typically has a more stable and reliable hardware design and driver, and is more resistant to overload. If a high-demand device is placed on an already heavily loaded slave chip, the slave chip may fail first, instantly throwing all the load back to the main chip, triggering a cascading system failure. Having the main chip handle the connection task of the target device makes the risk more manageable.

[0096] In some examples, the main chip can be identified as the target chip if the required load of the target device is less than or equal to the first load threshold and the actual load of the main chip is less than or equal to the second load threshold. In other examples, the main chip can be identified as the target chip if the required load of the target device is less than or equal to the first load threshold and the actual load of the main chip is greater than the second load threshold and the actual load of the slave chip is greater than the second load threshold.

[0097] Here, in contrast to the above embodiments, a specific case is proposed in which communication connection with the target device is prioritized through the main chip. This ensures the completeness of the decision logic for any connection request and realizes a decision-making closed loop covering all possible scenarios.

[0098] For example, if the second load threshold is set to 0.7, the actual load is 0.8 when the main chip's service type is making and receiving calls, and 0.7 when the slave chip's service type is outputting audio. If both the main chip and the slave chip exceed the second load threshold, the main chip can be identified as the target chip.

[0099] This disclosure describes several scenarios in which the master chip is identified as the target chip. For lightweight tasks, this avoids unnecessary bandwidth allocation overhead, ensuring operational efficiency under normal conditions. When the master chip has sufficient resources, its superior performance is prioritized, providing users with the best connectivity experience. Furthermore, when both the master and slave chips are under high load, prioritizing the connection to the higher-performance master chip minimizes the risk of system crashes due to slave chip overload, enhancing the system's resilience and survivability.

[0100] In some possible implementations, the device information further includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the method further includes: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

[0101] For example, Bluetooth protocol information refers to the Bluetooth protocols supported and required by the target device, including Bluetooth specifications, versions, and feature sets. Bluetooth protocol information is crucial for determining whether the target device and the Bluetooth chip can communicate. Bluetooth protocol information can be obtained from the target device's Bluetooth broadcast packets or query responses.

[0102] For example, Bluetooth protocols can include BLE (Bluetooth Low Energy), BR / ED classic Bluetooth, A2DP (Advanced Audio Distribution Profile), AVRCP (Audio / Video Control Transport Protocol), HFP (Hands-free Profile), and so on. Each Bluetooth protocol can have different versions, and different Bluetooth protocols can have different Bluetooth communication functions.

[0103] For example, historical pairing status can include states such as successful connection, unsuccessful connection, or no connection, as well as performance and quality data from successful pairings in the past. This can be used to characterize whether the target device has historical pairing relationships with multiple Bluetooth chips. This can be achieved by recording and updating the data in a local database after each connection between the Bluetooth chip and the device.

[0104] For example, the historical binding status between the target device and multiple Bluetooth chips can include: the target device has a historical binding relationship with a specified Bluetooth chip; the target device has a historical binding relationship with multiple Bluetooth chips; and the target device has no historical binding relationship with any of the multiple Bluetooth chips.

[0105] This disclosure pre-screens candidate Bluetooth chips, eliminating potentially incompatible chips in advance, or prioritizing Bluetooth chips with a history of successful connections. This effectively reduces connection failures due to compatibility issues and ensures a successful connection, reduces unnecessary computational overhead when selecting the target chip, improves the overall decision-making efficiency of the system, and enhances the robustness and user experience of the system.

[0106] In some possible implementations, based on the Bluetooth protocol information corresponding to the target device, the plurality of candidate Bluetooth chips are selected from a plurality of Bluetooth chips, including: Based on the Bluetooth protocol information corresponding to the target device, determine the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips; If the number of Bluetooth chips that support the Bluetooth protocol information is greater than or equal to 2 among the plurality of Bluetooth chips, the Bluetooth chip that supports the Bluetooth protocol information is determined as the candidate Bluetooth chip.

[0107] For example, when a Bluetooth chip supports the Bluetooth protocol information, the Bluetooth chip's hardware and software capabilities enable it to perform normal interactive communication with the Bluetooth version, protocol, or codec required by the target device.

[0108] For example, a user needs to connect a Bluetooth speaker using the A2DP protocol to a vehicle. The vehicle includes multiple chips: chip A, chip B, chip C, and chip D. Chips A and C support both A2DP and HFP protocols, chip B supports both AVRCP and HFP protocols, and chip D only supports the BLE protocol. Therefore, chips A and C, which support the A2DP protocol, can be identified as candidate Bluetooth chips. The target chip can then be determined based on the actual load on chips A and C.

[0109] This disclosure determines the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips. If there is more than one Bluetooth chip that meets the criteria, they are all identified as candidate Bluetooth chips, so that the target chip can be further decided based on the subsequent candidate Bluetooth chips. If there is only one, no further decision-making process is required, which ensures the optimal efficiency and logical simplification of the system in decision-making and achieves a good balance between system intelligence and resource consumption.

[0110] In some possible implementations, the method further includes: In response to the fact that only the first Bluetooth chip among the plurality of Bluetooth chips supports the Bluetooth protocol information, the first Bluetooth chip is identified as the target chip.

[0111] For example, the first Bluetooth chip is the only Bluetooth chip that supports the protocol required by the target device after Bluetooth protocol compatibility screening. Through the system's protocol compatibility check, after the check logic traverses all chips, the first Bluetooth chip refers to the only one identified that supports the Bluetooth protocol information corresponding to the target device.

[0112] For example, a user needs to connect a Bluetooth headset using the LC3 protocol audio codec to a vehicle. The vehicle contains multiple chips, chip A, chip B, and chip C. If chips A and C do not support the LC3 protocol, and only chip B does, chip B can be directly selected as the target chip. Subsequent complex multi-chip selection procedures may not be necessary; chip B can be directly instructed to establish a connection with the Bluetooth headset.

[0113] This disclosure determines the number of chips that support the Bluetooth protocol information among multiple Bluetooth chips. When only one chip is available, a series of steps such as load acquisition, comparison and selection are not required, saving processor computing resources and time, and speeding up the establishment of Bluetooth connections.

[0114] In some possible implementations, the Bluetooth protocol information includes multiple versions of the Bluetooth protocol. In response to the fact that none of the multiple Bluetooth chips support the first Bluetooth protocol, it is determined whether other Bluetooth protocols are supported among the multiple Bluetooth chips. Based on the candidate Bluetooth chips that support other Bluetooth protocols, the target chip is determined.

[0115] In some possible implementations, the candidate Bluetooth chips are selected from the multiple Bluetooth chips based on the historical pairing status between the target device and the multiple Bluetooth chips, including: In response to the historical binding status indicating that the target device and the plurality of Bluetooth chips do not have a historical binding relationship, all of the plurality of Bluetooth chips are identified as candidate Bluetooth chips; or, In response to the historical binding status indicating that the number of chips with historical binding relationships between the target device and the plurality of Bluetooth chips is greater than or equal to 2, the Bluetooth chips with historical binding relationships with the target device are determined as the candidate Bluetooth chips.

[0116] For example, historical pairing status indicates that the target device and the Bluetooth chip have a historical pairing relationship, which can indicate that the target device and the Bluetooth chip have successfully completed pairing and connection in the past, including the search process and the authentication process.

[0117] For example, a binding table between devices and the chip can be stored locally on the system. Each time a device successfully pairs with the Bluetooth chip, a record can be created in the binding table. Historical bindings may also store connection parameters, including pairing keys, connection parameter preferences, service discovery records, etc., to facilitate faster connection of target devices to the Bluetooth chip.

[0118] For example, when the system queries the historical binding relationship table and determines that the target device has no historical binding records, it can be determined that the target device is either connecting for the first time or has had its data cleared. At this point, to avoid missing any possible connection paths, all Bluetooth chips can be identified as candidate Bluetooth chips. Then, a subsequent load balancing algorithm is used to find the optimal connection path for it.

[0119] For example, a user intends to connect a new Bluetooth headset to their car. The system checks the historical records but finds no data. Both the master and slave chips in the car can be added to a candidate pool. By comparing their current loads, the chip with the lightest load is selected to complete the initial connection. After a successful connection, the system establishes a historical pairing record between the headset and the slave chip.

[0120] For example, when the system detects that a target device has successfully connected to two or more different Bluetooth chips in its history, the Bluetooth chips with successful connection records indicate good compatibility and stability with the target device, while the connection between Bluetooth chips without successful connection records and the target device may encounter problems such as poor signal or instability. The system will identify all Bluetooth chips with historical binding relationships with the target device as candidate Bluetooth chips. In this way, chips that have never successfully connected to the target device can be excluded, and the subsequent load balancing algorithm will select from the candidate Bluetooth chips.

[0121] For example, the user's phone may have connected to the main chip while in the driver's seat, and also connected to the slave chip when the main chip was under high load. The history will show that the phone has a binding relationship with both the main and slave chips. When the phone re-enters the vehicle, the system will directly identify the main and slave chips as candidate Bluetooth chips. Any other chips that may exist in the vehicle will be excluded from the candidate list.

[0122] This disclosure identifies multiple candidate Bluetooth chips when the target device has no historical pairing relationship with any of the multiple Bluetooth chips, or when there is a large amount of data on Bluetooth chips that have historical pairing relationships with the target device. This allows for further decision-making regarding the target chip, enabling the target device to prioritize connecting to chips with historical pairing relationships. In this way, some Bluetooth service discovery and parameter negotiation processes can be skipped, and the connection can be quickly rebuilt using stored pairing information and connection parameters. This significantly reduces the time from discovery to availability, while greatly improving the connection success rate and stability.

[0123] In some possible implementations, the method further includes: When the historical binding status indicates that the target device has a historical binding relationship only with the second Bluetooth chip among the plurality of Bluetooth chips, the second Bluetooth chip is identified as the target chip.

[0124] For example, the second Bluetooth chip is the only Bluetooth chip identified as having a binding relationship with the target device in the historical binding relationship query. The query results for the historical binding status between the target device and multiple Bluetooth chips can be determined through a device-chip binding relationship table. When there is exactly one binding record in the chip binding relationship table, the Bluetooth chip corresponding to that binding record is the second Bluetooth chip.

[0125] For example, if it is determined that only the second Bluetooth chip among multiple Bluetooth chips has a historical pairing relationship with the target device, the second Bluetooth chip can be directly identified as the target chip. Then, a command can be issued to connect directly to the target device through the second Bluetooth chip. The historical pairing relationship indicates that the second Bluetooth chip and the target device have already established a Bluetooth connection through Bluetooth service discovery and parameter negotiation, and the pairing information and connection parameters stored in the historical pairing relationship can be used to quickly establish a Bluetooth connection.

[0126] When this disclosure determines that the target device has a unique historical binding relationship through the historical binding status of the second Bluetooth chip, it can directly connect to the target device through the second Bluetooth chip without any user operation. This eliminates some Bluetooth service discovery and parameter negotiation processes, improves connection efficiency, and achieves seamless connection, greatly enhancing user satisfaction.

[0127] In some possible implementations, based on the Bluetooth protocol information corresponding to the target device and the historical pairing status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips. This includes: determining the number of chips among the multiple Bluetooth chips that support the Bluetooth protocol information based on the Bluetooth protocol information corresponding to the target device. In response to a number of chips among the multiple Bluetooth chips that support the Bluetooth protocol information being greater than or equal to 2, the Bluetooth chips that support the Bluetooth protocol information are identified as initial screening Bluetooth chips. When the historical pairing status indicates that the target device and none of the multiple Bluetooth chips have a historical pairing relationship, all of the multiple initial screening Bluetooth chips are identified as candidate Bluetooth chips; or, when the historical pairing status indicates that the number of chips among the multiple initial screening Bluetooth chips that have a historical pairing relationship with the target device is greater than or equal to 2, the initial screening Bluetooth chips that have a historical pairing relationship with the target device are identified as candidate Bluetooth chips.

[0128] In some possible implementations, the actual load corresponding to each of the multiple Bluetooth chips is obtained, including any of the following: Based on the service types corresponding to the plurality of Bluetooth chips, determine the actual load corresponding to each of the plurality of Bluetooth chips; Obtain the occupied bandwidth corresponding to each of the multiple Bluetooth chips, and determine the actual load corresponding to each Bluetooth chip based on the occupied bandwidth.

[0129] For example, the service type refers to the nature and category of the data communication task being processed by the Bluetooth chip. Different types of services have different chip resource usage models. For instance, synchronous audio streaming has continuous high bandwidth and low latency requirements, resulting in high and stable resource usage; human-computer interaction such as HID keyboard and mouse input has extremely low bandwidth and extremely low latency requirements.

[0130] For example, the type of service currently being performed by each Bluetooth chip can be identified by examining all established connections on each chip. Using a pre-defined mapping table of service types and load values, the actual load corresponding to each Bluetooth chip can be determined.

[0131] For example, the load value for synchronizing audio streaming is 0.6, the load value for making and receiving calls is 0.8, the load value for maintaining a connection is 0.1, and the load value for searching for devices is 0.5. These are just examples and are not the final load values.

[0132] For example, occupied bandwidth refers to the amount of data actually transmitted through the Bluetooth chip's radio frequency air interface per unit time. This is the most direct physical quantity for measuring the chip's communication load. It can be obtained through a counter provided by the Bluetooth chip's own driver or the underlying firmware, and is calculated by the system through periodic sampling.

[0133] For example, the uplink and downlink byte counts can be periodically read from the Bluetooth chip's driver interface. Based on the data increment and time interval between two samples, the current instantaneous bandwidth occupied is calculated. Here, the current bandwidth represents the change in data volume per unit time. The occupied bandwidth value can be compared to a preset maximum theoretical bandwidth of the chip to normalize it into an actual load value, or it can be directly used as a visual representation of the load.

[0134] For example, chip B has a maximum theoretical bandwidth of 2 Mbps, and the system measures that chip B's current total bandwidth usage is 1.5 Mbps. Then, the actual load on chip B can be calculated as (1.5 / 2.0) × 100% = 75% as follows.

[0135] This disclosure provides two methods for determining the actual load, offering accurate data for load balancing. Determining the Bluetooth chip's actual load by service type incurs low computational overhead and offers fast response, making it suitable for systems with high real-time requirements but lower absolute accuracy requirements. Determining the Bluetooth chip's actual load by its bandwidth usage accurately reflects physical layer congestion, making it suitable for scenarios requiring fine-grained management. Users can flexibly choose or combine these methods based on their capabilities to meet the decision-making needs of different scenarios.

[0136] In some possible implementations, the actual load corresponding to each of the multiple Bluetooth chips is obtained, including: In response to the Bluetooth connection request from the target device, the actual load corresponding to each of the multiple Bluetooth chips is obtained.

[0137] For example, a Bluetooth connection request is an event signal, which can be an internal event triggered by the system actively scanning and discovering a new device, a pairing request issued by the device, or a user operation triggered by the user in the human-computer interaction interface.

[0138] For example, when a Bluetooth headset enters pairing mode, it continuously sends broadcast packets containing its own information. The vehicle gateway's Bluetooth chip receives this broadcast and identifies it as a valid Bluetooth connection request. A user's action of clicking "Search for devices" on the vehicle's infotainment screen, selecting a device from the list, and then clicking "Connect" can also be identified as a Bluetooth connection request. The vehicle's infotainment system can also automatically generate a Bluetooth connection request based on automation policies, such as automatically reconnecting to previously used devices, and attempting to establish a connection with a device.

[0139] For example, when the master device receives a Bluetooth connection request from the target device, it triggers a process to determine the target chip. This process can involve pre-screening based on protocol compatibility and historical pairings to identify multiple candidate Bluetooth chips. Then, a query command is sent to each of these candidate chips to obtain their current actual load in real time. After collecting the real-time load data of all candidate chips, and considering the load requirements determined by the target device's device type, the final target chip is selected.

[0140] This disclosure triggers the target chip's decision-making process only when a Bluetooth connection request from the target device is received. This allows the main control device to work only when the target device needs to connect, avoiding the need to maintain load monitoring threads for all chips. During the majority of idle time without connection requests, the system can maintain a low-power state, achieving a high degree of elasticity and on-demand allocation of system resources, and improving the overall resource utilization efficiency.

[0141] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip. The method for determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each candidate Bluetooth chip further includes: In response to establishing a communication connection between the chip and the target device, the step of determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips is periodically executed.

[0142] For example, periodic execution refers to repeatedly running the complete or partial algorithm of the Bluetooth chip decision-making process at regular time intervals. This can be a fixed time period, such as executing the Bluetooth chip decision every 30 seconds or every minute. Alternatively, it can be an event-triggered period, such as triggering a re-decision for devices connected via the slave chip when the system detects that the load on the master chip has changed from high to low.

[0143] For example, when a user is in a car, their phone makes a call via the car's Bluetooth system. At this time, the main chip's actual load is very high. When the user makes a call, they intend to connect to the car's Bluetooth system via a Bluetooth headset. During the Bluetooth chip decision-making process, a load balancing algorithm successfully establishes a connection between the Bluetooth headset and the slave chip. For example, if the cycle is set to once every minute, the chip selection process is executed again after one minute. If the decision is still made to select the slave chip, meaning the call between the phone and the car's Bluetooth system is still ongoing, the chip selection process can continue for another minute. If the decision is made to select the main chip, meaning the call between the phone and the car's Bluetooth system may have ended and there are no other active services, a connection migration process can be automatically initiated, establishing a new audio connection between the main chip and the Bluetooth headset.

[0144] This disclosure allows the target chip's decision-making process to be executed periodically and automatically when there is a communication connection between the chip and the target device. In this way, the target device can adapt to the dynamic changes in the system environment. When the load of the high-performance main chip is reduced, the core hardware resources of the main chip can be fully utilized, avoiding the unreasonable situation of high-performance chips being idle while low-performance chips are overloaded, thus improving the utilization rate of high-value chips. At the same time, the migration process of chip connection does not require manual intervention from the user, which greatly improves intelligence and user satisfaction.

[0145] In some possible implementations, the device type of the target device is used to determine the demand load corresponding to the target device, wherein the larger the value of the demand load, the shorter the interval between cycles.

[0146] For example, the interval between cycles is the time interval between two consecutive decision processes that execute a communication connection to the same target device. Here, the duration of the interval between cycles is a system parameter that is configured according to changes in demand load, and is not fixed. For example, the interval might be set to 2 seconds for devices with high load demand, and 2 minutes for devices with low load demand.

[0147] For example, the required load of the target device can be determined based on the device type. Then, a corresponding cycle interval can be determined based on the required load of the target device, wherein devices with high load requirements can be set with shorter re-decision intervals, and devices with low load requirements can be set with longer intervals.

[0148] For example, devices with high load demands typically require higher-performance communication interactions, and the main chip is more likely to outperform the slave chip. By frequently re-evaluating the target chip, the communication connection for high-load devices can be optimized immediately. Devices with low load demands, connected through the main chip, can ensure better-performing communication interactions, improving the user experience. However, since low-load devices have lower performance requirements for communication interactions, the interval between cycles can be shortened to reduce computational resources, thereby lowering overall system power consumption and computational overhead.

[0149] This disclosure sets the interval between cycles to follow the changes in demand load, with the interval becoming smaller as the demand load increases. This ensures that the communication connection of devices with high demand loads can be optimized immediately. It also reduces the frequency at which devices with low demand loads re-determine the target chip when the performance requirements for communication interaction are not high, thereby reducing the overall power consumption and computational overhead of the system and significantly optimizing the system's computing resources and power consumption.

[0150] In some embodiments, taking an in-vehicle infotainment system as an example, the in-vehicle infotainment system includes a main chip and a slave chip. In related technologies, all smart devices are bound to the main chip of the in-vehicle infotainment system by default, while the slave chip is only used as a backup resource. It only attempts to connect to the smart device through the slave chip when the main chip is completely unable to handle the load or does not support the corresponding Bluetooth protocol.

[0151] Reference Figure 2 The diagram illustrates a flowchart of a device management method. It describes how a multi-dimensional decision model can be used to determine a suitable target chip for communication with the device, from both master and slave chips. The device management method includes the following steps.

[0152] S201. Obtain device information corresponding to the target device, including the device type of the target device, the Bluetooth protocol information corresponding to the target device, and the historical binding status of the target device with multiple Bluetooth chips.

[0153] For example, the device type can be determined by the device address prefix of the target device, which can be classified based on the target device's Organizationally Unique Identifier (OUI). For instance, a device with an OUI prefix of 00:1A:7D is a mobile phone. The device type can also be matched by the target device's Service UUID; for example, 0x110A indicates an A2DP Sink device, and 0x110C indicates an HID device.

[0154] For example, the Bluetooth Class of Device (CoD) field information of the target device can also be used, combined with the service UUID, to identify the device type of the target device. For instance, 0x0404 indicates a speaker device, which could be a headset with a microphone or a speaker. Then, a GATT connection can be established with the device to obtain its service UUID. If the HSP service exists, this is a typical headset characteristic. By combining the CoD and the service UUID, the device type of the target device can be accurately determined to be a Bluetooth headset with call functionality.

[0155] S202. Analyze the above content using a multidimensional decision-making model.

[0156] S2021. Based on the Bluetooth protocol information corresponding to the target device, query the different protocol stacks supported by the master and slave chips respectively, and return the chip support status through the first function interface.

[0157] For example, if both the master and slave chips support the Bluetooth protocol of the target device, the return value is 3; if only the master chip supports the Bluetooth protocol of the target device, the return value is 1; if only slave chip 1 supports the Bluetooth protocol of the target device, the return value is 2; if neither the master nor slave chip supports the Bluetooth protocol of the target device, the return value is 0.

[0158] Specifically, if only the master chip supports the technology, it can be designated as the target chip; if only the slave chip supports it, it can be designated as the target chip. If neither the master nor slave chip supports the target device's Bluetooth protocol, it may reject the target device's connection request.

[0159] S2022. Based on the historical binding status of the target device with multiple Bluetooth chips, it can be determined whether the target device has a historical binding relationship with the master and slave chips, and the historical binding status is returned through the second function interface.

[0160] For example, if the target device has a historical binding relationship with the master chip, it can return 1; if the target device has a historical binding relationship with the slave chip, it can return 2; if the target device has a historical binding relationship with both the master and slave chips, it can return 3; if the target device has no historical binding relationship with either the master or slave chips, it can return 0.

[0161] Specifically, when the target device only has a historical binding relationship with the master chip, the master chip can be identified as the target chip; when the target device only has a historical binding relationship with the slave chip, the slave chip can be identified as the target chip. When the target device has a historical binding relationship with both the master and slave chips, or has no historical binding relationship with either, the target chip can be further identified based on the load of the master and slave chips.

[0162] For example, without considering historical pairing states, device reconnection might be migrated to a new chip, resulting in additional pairing work when not absolutely necessary. For instance, a multidimensional decision model might determine that a target device can connect to either Bluetooth chip 1 or Bluetooth chip 2. If, without considering pairing states, a target device is arbitrarily connected to a Bluetooth chip that is already paired with another Bluetooth chip, this could lead to repeated authentication, pairing, and other pairing processes.

[0163] S2023: Dynamically collect the actual load values ​​of the master and slave chips, and feed back the actual load values ​​of the master and slave chips respectively through the third function interface.

[0164] For example, when the target device requests a connection, the actual load values ​​of the master and slave chips can be dynamically collected. Specifically, this can be achieved through communication between the hardware and the master and slave chips, returning an assessment of the radio frequency load on the air interface channel and occupied bandwidth.

[0165] For example, the acquisition cycle of the chip's actual load can be dynamically adjusted based on the target device's required load. For instance, when the target device's required load is low, the interval between cycles is 1 second; when the target device's required load is high, the interval between cycles is 200 ms.

[0166] For example, the actual load on the master and slave chips can be determined by the currently active service type of the chip. Bluetooth chip service scenarios can include calls, audio playback, maintaining connection, no connection, device search, low-power broadcast search, etc. Load thresholds can be set, and corresponding load values ​​can be preset for each service type. For example, the load value for calls is 0.8, for audio playback is 0.6, for device search is 0.3, for low-power broadcast search is 0.2, for maintaining connection is 0.2, and for no connection is 0.1. The set load threshold is 0.5.

[0167] For example, if the load value exceeds the threshold, it returns true; if it does not exceed the threshold, it returns false. Specifically, when a Bluetooth chip's currently active service type is calling and playing audio, and the corresponding load value exceeds the set load threshold, the third function interface will return true, indicating that the Bluetooth chip's state is busy.

[0168] S2024. Based on the device type of the target device, the required load of the target device can be determined, and the required load of the target device can be fed back through the fourth function interface.

[0169] For example, device types can be categorized as communication devices, human-computer interaction devices (HID devices), devices with microphones, etc. The required load of the target device can be assessed based on preset load levels, categorized as heavy load, medium load, and light load. Specifically, the required load for communication devices is heavy load, the required load for HID devices is light load, and the required load for headsets with microphones is medium load.

[0170] For example, the fourth function can return true when the demand load is heavy, and false when the demand load is light or medium.

[0171] S203. Based on the analysis results, the load balancing function is used to feed back the target chip that best matches the target device to the operator.

[0172] For example, the functionality and performance of the master chip are usually superior to those of the slave chip. If the target device requires a large load, and both the master and slave chips have a large actual load, a preset master chip can be selected as the target chip, and a communication connection can be established between the master chip and the target device.

[0173] For example, if the target device requires a small load and the actual load of both the master and slave chips is large, the preset master chip can be determined as the target chip, and a communication connection can be established between the master chip and the target device.

[0174] For example, if the actual load of both the master and slave chips is small, or if the actual load of the master chip is small and the actual load of the slave chip is large, the preset master chip can be determined as the target chip regardless of the required load of the target device, and a communication connection can be established between the master chip and the target device.

[0175] For example, if the actual load of the main chip is large and the actual load of the slave chip is small, regardless of the required load of the target device, the preset slave chip can be determined as the target chip, and a communication connection can be established with the target device through the slave chip.

[0176] For example, if the actual load of the main chip is large and the actual load of the slave chip is small, and the demand of the target device is small, the preset main chip can be determined as the target chip, and a communication connection can be established between the main chip and the target device.

[0177] In some implementations, the target chip can be identified from the master and slave chips by the device type of the target device, the actual load value of the master and slave chips, and the support of the master and slave chips for the Bluetooth protocol version of the target device.

[0178] This disclosure achieves load balancing by combining device type with real-time chip load assessment, enabling collaborative resource scheduling between master and slave chips. Connection migration triggered by periodic load sampling optimizes connection strategies. Compared to single-chip solutions, the master-slave chips of this disclosure support seamless migration and hybrid deployment across different protocol stack versions. Furthermore, the dynamic resource scheduling of this disclosure optimizes resource utilization compared to static allocation schemes.

[0179] Reference Figure 3 , Figure 3 This is a block diagram illustrating a device management apparatus 300 according to an exemplary embodiment. (Refer to...) Figure 3 The device management device 300 includes an acquisition module 301, a determination module 302, and a connection module 303.

[0180] The acquisition module 301 is configured to acquire device information corresponding to the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips.

[0181] The determining module 302 is configured to determine the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips respectively.

[0182] The connection module 303 is configured to establish a communication connection with the target device through the target chip.

[0183] In some possible implementations, the device information includes the device type of the target device, and the determining module 302 is configured to: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

[0184] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; the determining module 302 is configured to: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

[0185] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip; the determining module 302 is configured to: The main chip is identified as the target chip in response to at least one of the following conditions: The required load corresponding to the target device is less than or equal to the first load threshold; The actual load corresponding to the main chip is less than or equal to the second load threshold. The actual load corresponding to the main chip is greater than the second load threshold, and the actual load corresponding to the slave chip is greater than the second load threshold.

[0186] In some possible implementations, the device information further includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the device management device 300 is further configured to: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

[0187] In some possible implementations, the determining module 302 is configured to: Based on the Bluetooth protocol information corresponding to the target device, determine the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips; If the number of Bluetooth chips that support the Bluetooth protocol information is greater than or equal to 2 among the plurality of Bluetooth chips, the Bluetooth chip that supports the Bluetooth protocol information is determined as the candidate Bluetooth chip.

[0188] In some possible implementations, the device management device 300 is further configured to: In response to the fact that only the first Bluetooth chip among the plurality of Bluetooth chips supports the Bluetooth protocol information, the first Bluetooth chip is identified as the target chip.

[0189] In some possible implementations, the determining module 302 is configured to: In response to the historical binding status indicating that the target device and the plurality of Bluetooth chips do not have a historical binding relationship, all of the plurality of Bluetooth chips are identified as candidate Bluetooth chips; or, In response to the historical binding status indicating that the number of chips with historical binding relationships between the target device and the plurality of Bluetooth chips is greater than or equal to 2, the Bluetooth chips with historical binding relationships with the target device are determined as the candidate Bluetooth chips.

[0190] In some possible implementations, the device management device 300 is further configured to: When the historical binding status indicates that the target device has a historical binding relationship only with the second Bluetooth chip among the plurality of Bluetooth chips, the second Bluetooth chip is identified as the target chip.

[0191] In some possible implementations, the acquisition module 301 is also configured to perform any of the following: Based on the service types corresponding to the plurality of Bluetooth chips, determine the actual load corresponding to each of the plurality of Bluetooth chips; Obtain the occupied bandwidth corresponding to each of the multiple Bluetooth chips, and determine the actual load corresponding to each Bluetooth chip based on the occupied bandwidth.

[0192] In some possible implementations, the acquisition module 301 is further configured to: In response to the Bluetooth connection request from the target device, the actual load corresponding to each of the multiple Bluetooth chips is obtained.

[0193] In some possible implementations, the plurality of candidate Bluetooth chips includes a master chip and a slave chip, and the determining module 302 is further configured to: In response to establishing a communication connection between the chip and the target device, the step of determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips is periodically executed.

[0194] In some possible implementations, the device type of the target device is used to determine the demand load corresponding to the target device, wherein the larger the value of the demand load, the shorter the interval between cycles.

[0195] Regarding the device management device 300 in the above embodiments, the specific methods by which each module performs operations have been described in detail in the embodiments related to the device management method, and will not be elaborated here.

[0196] Based on the same inventive concept, this disclosure also provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the device management method provided in this disclosure.

[0197] Based on the same inventive concept, this disclosure also provides a vehicle including the electronic equipment provided in this disclosure.

[0198] Based on the same inventive concept, this disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the device management method provided in this disclosure.

[0199] Based on the same inventive concept, this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the device management method provided in this disclosure.

[0200] Reference Figure 4 , Figure 4 This is a block diagram illustrating an electronic device 400 according to an exemplary embodiment. For example, the electronic device 400 may be a mobile phone, an in-vehicle infotainment system, a computer, a messaging device, a game console, a tablet device, a fitness device, a personal digital assistant, etc.

[0201] like Figure 4 As shown, the electronic device 400 may include one or more of the following components: processing component 402, memory 404, power supply component 406, multimedia component 408, audio component 410, input / output interface 412, sensor component 414, and communication component 416.

[0202] Processing component 402 typically controls the overall operation of electronic device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 402 may include one or more processors 420 to execute instructions to complete all or part of the steps of the device management method described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.

[0203] Memory 404 is configured to store various types of data to support the operation of electronic device 400. Examples of such data include instructions for any application or method operating on electronic device 400, contact data, phonebook data, messages, pictures, videos, etc. Memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0204] Power supply component 406 provides power to various components of electronic device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 400.

[0205] Multimedia component 408 includes a screen that provides an output interface between the electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When the electronic device 400 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0206] Audio component 410 is configured to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) configured to receive external audio signals when electronic device 400 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.

[0207] Input / output interface 412 provides an interface between processing component 402 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, start buttons, and lock buttons.

[0208] Sensor assembly 414 includes one or more sensors for providing state assessments of various aspects of electronic device 400. For example, sensor assembly 414 may detect the on / off state of electronic device 400, the relative positioning of components such as the display and keypad of electronic device 400, changes in position of electronic device 400 or a component of electronic device 400, the presence or absence of user contact with electronic device 400, orientation or acceleration / deceleration of electronic device 400, and temperature changes of electronic device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0209] Communication component 416 is configured to facilitate wired or wireless communication between electronic device 400 and other devices. Electronic device 400 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0210] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the device management method described above.

[0211] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, which can be executed by a processor 420 of an electronic device 400 to perform the device management method described above. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0212] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the device management method described above when executed by the programmable device.

[0213] Reference Figure 5 , Figure 5 This is a block diagram illustrating a vehicle 500 according to an exemplary embodiment. For example, vehicle 500 can be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicle. Vehicle 500 can be an autonomous vehicle, a semi-autonomous vehicle, or a non-autonomous vehicle.

[0214] like Figure 5 As shown, vehicle 500 may include various subsystems, such as infotainment system 510, perception system 520, decision control system 530, drive system 540, and computing platform 550. Vehicle 500 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and each component of vehicle 500 can be interconnected via wired or wireless means.

[0215] In some embodiments, the infotainment system 510 may include a communication system, an entertainment system, and a navigation system, etc.

[0216] The perception system 520 may include several sensors for sensing information about the environment surrounding the vehicle 500. For example, the perception system 520 may include a global positioning system (which may be GPS, BeiDou, or other positioning systems), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0217] The decision control system 530 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system.

[0218] The drive system 540 may include components that provide powered motion to the vehicle 500. In one embodiment, the drive system 540 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0219] Some or all of the functions of vehicle 500 are controlled by computing platform 550. Computing platform 550 may include at least one processor 551 and memory 552, and processor 551 may execute instructions 553 stored in memory 552.

[0220] The processor 551 can be any conventional processor, such as a commercially available CPU. The processor may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems on chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0221] The memory 552 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0222] In addition to instruction 553, memory 552 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 552 can be used by computing platform 550.

[0223] In this embodiment of the disclosure, the processor 551 may execute instructions 553 to complete all or part of the steps of the device management method described above.

[0224] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A; X applies B; or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0225] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding this specification and the accompanying drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0226] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0227] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for managing equipment, characterized in that, include: Obtain the device information corresponding to the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips; The target chip is determined from the multiple candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the multiple candidate Bluetooth chips. A communication connection is established between the target chip and the target device.

2. The method according to claim 1, characterized in that, The device information includes at least the device type of the target device. Based on the device information of the target device and the actual load corresponding to each of the plurality of Bluetooth chips, the target chip is determined from the plurality of candidate Bluetooth chips, including: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

3. The method according to claim 2, characterized in that, The plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips includes: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

4. The method according to claim 2, characterized in that, The plurality of candidate Bluetooth chips includes a master chip and a slave chip; determining the target chip from the plurality of candidate Bluetooth chips based on the required load corresponding to the target device and the actual load corresponding to each of the plurality of candidate Bluetooth chips further includes: The main chip is identified as the target chip in response to at least one of the following conditions: The required load corresponding to the target device is less than or equal to the first load threshold; The actual load corresponding to the main chip is less than or equal to the second load threshold. The actual load corresponding to the main chip is greater than the second load threshold, and the actual load corresponding to the slave chip is greater than the second load threshold.

5. The method according to claim 1, characterized in that, The device information also includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; Before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the method further includes: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

6. The method according to claim 5, characterized in that, Based on the Bluetooth protocol information corresponding to the target device, the plurality of candidate Bluetooth chips are selected from a plurality of Bluetooth chips, including: Based on the Bluetooth protocol information corresponding to the target device, determine the number of Bluetooth chips that support the Bluetooth protocol information among multiple Bluetooth chips; If the number of Bluetooth chips that support the Bluetooth protocol information is greater than or equal to 2 among the plurality of Bluetooth chips, the Bluetooth chip that supports the Bluetooth protocol information is determined as the candidate Bluetooth chip.

7. The method according to claim 6, characterized in that, The method further includes: In response to the fact that only the first Bluetooth chip among the plurality of Bluetooth chips supports the Bluetooth protocol information, the first Bluetooth chip is identified as the target chip.

8. The method according to claim 5, characterized in that, Based on the historical pairing status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips, including: In response to the historical binding status indicating that the target device and the plurality of Bluetooth chips do not have a historical binding relationship, all of the plurality of Bluetooth chips are identified as candidate Bluetooth chips; or, In response to the historical binding status indicating that the number of chips with historical binding relationships between the target device and the plurality of Bluetooth chips is greater than or equal to 2, the Bluetooth chips with historical binding relationships with the target device are determined as the candidate Bluetooth chips.

9. The method according to claim 8, characterized in that, The method further includes: When the historical binding status indicates that the target device has a historical binding relationship only with the second Bluetooth chip among the plurality of Bluetooth chips, the second Bluetooth chip is identified as the target chip.

10. The method according to any one of claims 1-9, characterized in that, Obtain the actual load corresponding to each of the multiple Bluetooth chips, including any of the following: Based on the service types corresponding to the plurality of Bluetooth chips, determine the actual load corresponding to each of the plurality of Bluetooth chips; Obtain the occupied bandwidth corresponding to each of the multiple Bluetooth chips, and determine the actual load corresponding to each Bluetooth chip based on the occupied bandwidth.

11. The method according to any one of claims 1-9, characterized in that, Obtain the actual load corresponding to each of the multiple Bluetooth chips, including: In response to the Bluetooth connection request from the target device, the actual load corresponding to each of the multiple Bluetooth chips is obtained.

12. The method according to any one of claims 1-9, characterized in that, The plurality of candidate Bluetooth chips includes a master chip and a slave chip. The method for determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to each of the candidate Bluetooth chips further includes: In response to establishing a communication connection between the chip and the target device, the step of determining the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips is periodically executed.

13. The method according to claim 12, characterized in that, The device type of the target device is used to determine the demand load corresponding to the target device, wherein the larger the value of the demand load, the shorter the interval between cycles.

14. An equipment management device, characterized in that, include: The acquisition module is configured to acquire device information corresponding to the target device and the actual load corresponding to multiple candidate Bluetooth chips; The determination module is configured to determine the target chip from the plurality of candidate Bluetooth chips based on the device information of the target device and the actual load corresponding to the plurality of candidate Bluetooth chips respectively; The connection module is configured to establish a communication connection with the target device through the target chip.

15. The apparatus according to claim 14, characterized in that, The device information includes the device type of the target device, and the determining module is configured as follows: Based on the device type of the target device, determine the required load corresponding to the target device; The target chip is determined from the multiple candidate Bluetooth chips based on the required load of the target device and the actual load of the multiple candidate Bluetooth chips.

16. The apparatus according to claim 15, characterized in that, The plurality of candidate Bluetooth chips includes a master chip and a slave chip; the determining module is configured to: It is determined that the demand load corresponding to the target device is greater than the first load threshold; In response to the actual load corresponding to the master chip being greater than the second load threshold and the actual load corresponding to the slave chip being less than or equal to the second load threshold, the slave chip is determined as the target chip.

17. The apparatus according to claim 14, characterized in that, The device information also includes Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips; before obtaining the actual load corresponding to each of the multiple candidate Bluetooth chips, the device management device is further configured to: Based on the Bluetooth protocol information corresponding to the target device, and / or the historical binding status between the target device and multiple Bluetooth chips, the multiple candidate Bluetooth chips are selected from the multiple Bluetooth chips.

18. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the device management method according to any one of claims 1-13.

19. A vehicle, characterized in that, Includes the electronic device as described in claim 18.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the device management method according to any one of claims 1-13.

21. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the device management method according to any one of claims 1-13.

Images