Resource usage, vehicle resource usage method, device and storage medium

By creating a hardware resource agent locally, the problem of low development efficiency when connecting mobile terminals to on-board control devices is solved, and resource use is simplified and efficiency improvement is achieved.

CN113590302BActive Publication Date: 2025-04-08ALIBABA GROUP HOLDING LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202010365662.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-04-30
Publication Date
2025-04-08
Estimated Expiration
2040-04-30

AI Technical Summary

Technical Problem

In the scenario where the mobile terminal is connected to the vehicle control device, it is necessary to understand the hardware resource configuration of the mobile terminal and the vehicle control device during the software development process, resulting in low development efficiency.

Method used

By creating a local proxy for the hardware resources of the second device locally, the application of the first device can use the hardware resources of the second device by accessing the local proxy without understanding the hardware resources of the device.

Benefits of technology

It improves the efficiency of software development and simplifies the resource usage process between mobile terminals and on-board control equipment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113590302B_ABST
    Figure CN113590302B_ABST
Patent Text Reader

Abstract

The embodiments of the present application provide a resource usage, vehicle resource usage method, device and storage medium. In some embodiments of the present application, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local proxy corresponding to the hardware resources locally. The application of the first device can use the hardware resources of the second device by accessing the local local proxy; in the software development process, there is no need to understand the hardware resource status of the device, which improves development efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Vehicles, and in particular to a resource utilization, a vehicle-mounted resource utilization method, a device, and a storage medium. Background Art

[0002] The Internet of Vehicles uses the new generation of information and communication technology to achieve all-round network connections between vehicles and cloud platforms, vehicles and vehicles, vehicles and people, and vehicles. It mainly realizes the "three-network integration", that is, the integration of the in-vehicle network, the inter-vehicle network and the in-vehicle mobile Internet. The Internet of Vehicles uses sensor technology to perceive the status information of the vehicle, and uses wireless-communication networks and modern intelligent information processing technology to achieve intelligent management of traffic, intelligent decision-making of traffic information services and intelligent control of vehicles.

[0003] At present, in the scenario where a mobile terminal (such as a smart phone) is connected to an on-board control device, various vehicle connection protocols define the use of resources between the mobile terminal and the on-board control device in different ways. During the software development process, when the mobile terminal calls the hardware of the on-board control device or the on-board control device calls the hardware of the mobile terminal or calls each other's hardware, it is necessary to understand the resource configuration of the hardware resources of the mobile terminal and the on-board control device, which reduces the efficiency of software development. Summary of the invention

[0004] Multiple aspects of the present application provide a resource configuration method, device and storage medium, whereby a smart device creates a local proxy locally to proxy an application program's use of hardware resources of a second device, thereby improving development efficiency.

[0005] The embodiment of the present application provides a resource use method, wherein the method is run on a first device and includes:

[0006] Receive a resource application sent by an application, wherein the resource application carries resource demand information of the application;

[0007] According to the resource requirement information of the application, determine through negotiation with the second device that the application needs to use the hardware resources of the second device;

[0008] A local proxy for the hardware resources of the second device is created locally to proxy the application program's use of the hardware resources of the second device.

[0009] The embodiment of the present application further provides a resource use method, wherein the method is run on a second device and includes:

[0010] Obtaining resource requirement information sent by the first device;

[0011] Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources;

[0012] The information of the candidate hardware resources is provided to the first device, so that the first device determines the hardware resources that the application program of the first device needs to use according to the information of the candidate hardware resources.

[0013] The embodiment of the present application also provides a smart device, which includes: a memory, a processor and an electronic display screen;

[0014] The memory is used to store one or more computer instructions;

[0015] The processor is configured to execute the one or more computer instructions to:

[0016] Receive a resource application sent by an application, wherein the resource application carries resource demand information of the application;

[0017] According to the resource requirement information of the application, determine through negotiation with the second device that the application needs to use the hardware resources of the second device;

[0018] A local proxy for the hardware resources of the second device is created locally to proxy the application program's use of the hardware resources of the second device.

[0019] The embodiment of the present application also provides a vehicle-mounted control device, comprising: a memory, a processor and an electronic display screen;

[0020] The memory is used to store one or more computer instructions;

[0021] The processor is configured to execute the one or more computer instructions to:

[0022] Acquire resource requirement information sent by the first device;

[0023] Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources;

[0024] The information of the candidate hardware resources is provided to the first device, so that the first device determines the hardware resources that the application program of the first device needs to use according to the information of the candidate hardware resources.

[0025] In some embodiments of the present application, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local agent corresponding to the hardware resources locally. The application of the first device can use the hardware resources of the second device by accessing the local local agent. During the software development process, there is no need to understand the hardware resource status of the device, thereby improving development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0027] Figure 1a A schematic diagram of the structure of a resource negotiation system provided for an exemplary embodiment of the present application;

[0028] Figure 1b A schematic diagram of the structure of an in-vehicle resource negotiation system provided for an exemplary embodiment of the present application;

[0029] Figure 1c A schematic diagram of resource creation of an in-vehicle resource negotiation system provided by an exemplary embodiment of the present application;

[0030] Figure 2a A schematic diagram of a flow chart of a resource use method described from the perspective of a first device provided in an exemplary embodiment of the present application;

[0031] Figure 2b A schematic diagram of a flow chart of a resource use method described from the perspective of a second device provided in an exemplary embodiment of the present application;

[0032] Figure 3a A flowchart of a method for using vehicle resources described from the perspective of a smart terminal provided by an exemplary embodiment of the present application;

[0033] Figure 3b A flowchart of a method for using vehicle resources described from the perspective of a vehicle control device provided by an exemplary embodiment of the present application;

[0034] Figure 4 A flowchart of a method for using vehicle resources provided by an exemplary embodiment of the present application;

[0035] Figure 5 A schematic diagram of the structure of a smart device provided for an exemplary embodiment of the present application;

[0036] Figure 6 A schematic diagram of the structure of a smart device provided for an exemplary embodiment of the present application;

[0037] Figure 7 A schematic diagram of the structure of a smart terminal provided by an exemplary embodiment of the present application;

[0038] Figure 8 A schematic structural diagram of another vehicle-mounted control device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0040] At present, in the scenario where a mobile terminal (such as a smart phone) is connected to an on-board control device, various vehicle connection protocols define the use of resources between the mobile terminal and the on-board control device in different ways. During the software development process, when the mobile terminal calls the hardware of the on-board control device or the on-board control device calls the hardware of the mobile terminal or calls each other's hardware, it is necessary to understand the resource configuration of the hardware resources of the mobile terminal and the on-board control device, which reduces the efficiency of software development.

[0041] In response to the above-mentioned technical problems, in some embodiments of the present application, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local agent corresponding to the hardware resources locally. The application of the first device can use the hardware resources of the second device by accessing the local local agent. During the software development process, there is no need to understand the hardware resource status of the device, thereby improving development efficiency.

[0042] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0043] Figure 1a FIG. 1 is a schematic diagram of a resource negotiation system 10 provided in an exemplary embodiment of the present application. Figure 1a As shown, the resource negotiation system 10 includes a first device 10a and a second device 10b that are communicatively connected.

[0044] In this embodiment, the first device 10a negotiates with the second device 10b to determine that the application needs to use the hardware resources of the second device 10b based on the resource requirement information of the local application; the first device 10a locally creates a local agent for the hardware resources of the second device to proxy the application's use of the hardware resources of the second device.

[0045] In this embodiment, the first device 10a has a need to use the hardware resources in the second device 10b. The first device 10a can use the better hardware resources on the second device 10b, for example, a mobile phone uses the display of a smart TV; or, in a specific environment, the first device 10a uses the hardware resources of the second device 10b to bring convenience to the user, for example, a smart terminal and a vehicle-mounted control device, and the user uses the vehicle-mounted control device to make calls, videos, etc. during driving. Among them, the smart terminal can be a computer device or a handheld device, and its implementation form can be various, such as a smart phone, a personal computer, a tablet computer, and a smart speaker. For another example, the second device can be a device with a screen such as a smart TV, a smart speaker, and a smart screen, and can also be a device without a screen but capable of displaying such as a projector.

[0046] In this embodiment, the first device 10a and the second device 10b establish a communication connection. Optionally, the first device 10a can establish a communication connection with the second device 10b by using WIFI, Bluetooth, infrared or other communication methods, or the first device 10a can also establish a communication connection with the second device 10b through a mobile network. The network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 5G, etc.

[0047] In some embodiments, the application is an application running on the first device 10a, and the present application does not limit the type of the application. The application includes but is not limited to the following: instant messaging applications, audio and video applications, and telephone applications.

[0048] In some embodiments, the resource requirement information is various parameters of virtual resources that the application of the first device 10a needs to use, and the resource requirement information is adjusted accordingly according to different scenarios. The resource requirement information includes but is not limited to at least one of the following: parameters of video output devices, parameters of video input devices, parameters of audio output devices, parameters of audio input devices, parameters of user input devices, and parameters of control devices.

[0049] In this embodiment, the first device 10a sends a resource request through an application, and the resource request carries the resource demand information of the application. For example, the first device 10a is a mobile phone, and the second device 10b is a vehicle-mounted control device. The mobile phone sends a video resource request to the vehicle-mounted control device, and the video resource request carries the video resource descriptor of the application, wherein the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage authority.

[0050] In this embodiment, the first device 10a negotiates with the second device 10b to determine that the application needs to use the hardware resources of the second device 10b based on the resource requirement information of the application. An optional embodiment is that the first device 10a sends the resource requirement information of the application to the second device 10b, and after the second device 10b obtains the resource requirement information sent by the first device 10a, the second device 10b selects information of candidate hardware resources that meet the resource requirement information from its own hardware resources; sends the information of the candidate hardware resources to the first device 10a; the first device 10a receives the information of the candidate hardware resources returned by the second device 10b, and reports the information of the candidate hardware resources to the application for the application to select; the first device 10a obtains the hardware resources selected by the application as the hardware resources that the application needs to use.

[0051] For example, the first device 10a is a smart terminal, and the second device 10b is a vehicle-mounted control device. The smart terminal sends a resource request to the vehicle-mounted control device, and the resource request carries the hardware resource descriptor of the application. After the vehicle-mounted control device obtains the resource request sent by the smart terminal; the vehicle-mounted control device selects candidate hardware resource information that meets the hardware resource descriptor from its own hardware resources; the user input resources of the vehicle-mounted control device include a touchpad and a knob. If the information of the touchpad and the knob meets the hardware resource descriptor, the touchpad and the knob are used as candidate hardware resources, and the information of the touchpad and the knob is provided to the smart terminal; the smart terminal receives the information of the touchpad and the knob and reports it to the application of the smart terminal; the application selects the knob from the information of the touchpad and the knob as the hardware resource that the application needs to use.

[0052] In the above embodiment, before the first device 10a sends a resource request to the second device 10b through the application, the first device 10a includes a step of verifying the identity of the operating user. One achievable method is that the first device 10a collects the user's identity information, sends the user's identity information to the second device 10b for identity verification, and returns information of successful identity verification after the verification is passed, so that the user can use the first device 10a to send a resource request to the second device 10b. Among them, the first device 10a can also perform a user identity verification operation.

[0053] After the first device 10a negotiates with the second device to determine the hardware resources that the application needs to use, it determines whether there is a local agent corresponding to the hardware resources locally based on the identifier of the hardware resources that the application needs to use; if not, it executes the operation of creating a local agent corresponding to the hardware resources locally.

[0054] The first device 10a provides the application with an API interface (Application Programming Interface) corresponding to the local proxy, so that the application can initiate a request to use the local proxy through the API interface. In a preferred embodiment, each virtual resource of the same type as the local proxy uses the same API interface. Among them, virtual resources of the same type use the same API interface, and the data specifications and timing supported by the API interface are consistent. For different hardware implementations of virtual resources of the same type, operations can be performed through the interface of the corresponding virtual resource without having to use different interfaces for different hardware implementations. For example, the corresponding hardware of a virtual resource such as a video output device can be the screen of a vehicle-mounted system or a vehicle-mounted projector; through the write interface of the video output device, the screen and the vehicle-mounted projector can display the written video data in their own ways.

[0055] In some optional embodiments, the application of the first device 10a initiates a use request to the local proxy through the API interface. The first device 10a receives the use request of the application to the local proxy through the API interface, and establishes a resource use relationship between the application and the local proxy; the first device 10a provides the use request to the application of the second device 10b, so that the application of the second device 10b initiates a use operation of the hardware resource.

[0056] Among them, several logical channels are established between the first device 10a and the second device 10b. The logical channels can be physically wireless connections or wired connections, such as USB. If there are multiple logical channels, a header tag can be added to the data packets on each logical channel to mark the logical channel to which the data packet belongs, and then put it on the physical link for transmission to the second device 10b. The logical channel of the embodiment of the present application includes two parts: one is the channel at the control level; responsible for transmitting signaling, clocks and notifications; the other is also the channel at the data processing level; responsible for transmitting audio and video, etc.

[0057] In the above embodiment, after the first device 10a locally creates a local proxy corresponding to the hardware resource, the first device 10a may release the local proxy. The first device 10a may release the local proxy based on a request from an application program; the first device 10a may also delete all established local proxies.

[0058] The first device 10a may release the local proxy based on the request of the application. An optional embodiment is that the first device 10a receives a resource release request sent by the application; the first device 10a deletes the resource usage relationship between the application and the local proxy according to the resource release request. For example, the first device 10a receives a video resource release request sent by the application, and the first device 10a deletes the resource usage relationship between the application and the target virtual video resource.

[0059] The first device 10a deletes the locally created local proxy corresponding to the hardware resources that the application needs to use. This includes but is not limited to the following methods:

[0060] Method 1: Determine whether there are other applications using the local proxy; if not, delete the local proxy.

[0061] Method 2: Determine whether the life cycle of the local proxy has ended; if so, delete the local proxy.

[0062] Figure 1b FIG. 2 is a schematic diagram of a vehicle resource negotiation system 20 provided in an exemplary embodiment of the present application. Figure 1b As shown, the vehicle resource negotiation system 20 includes a communication-connected intelligent terminal 20a and a vehicle control device 20b.

[0063] In this embodiment, the vehicle control device 20b maps the hardware resources required by the smart terminal 20a to the smart terminal 20a through the communication protocol, so that the smart terminal 20a can establish a local proxy locally; the application of the smart terminal 20a can improve the compatibility of the device by accessing the local proxy.

[0064] In this embodiment, the smart terminal 20a and the vehicle control device 20b establish a communication connection. Optionally, the smart terminal 20a can establish a communication connection with the vehicle control device 20b by using WIFI, Bluetooth, infrared or other communication methods, or the smart terminal 20a can also establish a communication connection with the vehicle control device 20b through a mobile network. The network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 5G, etc.

[0065] Figure 1c Schematic diagram of resource creation of the vehicle resource negotiation system 20 provided in an exemplary embodiment of the present application. Figure 1cAs shown, the vehicle resources associated with the vehicle control device 20b are mapped to the smart terminal 20a side through the ARA (Automobile Resource Abstraction) service between the smart terminal 20a and the vehicle control device 20b, and a local agent of the hardware resources of the vehicle control device 20b is created locally on the smart terminal 20a. The application of the smart terminal 20a can use the hardware resources of the vehicle control device 20b by accessing the local agent.

[0066] In this embodiment, the hardware resources include at least one of the following: video output device, video input device, audio output device, audio input device, user input device and body control device. Among them, the video output device is, for example, a screen; the video input device is, for example, a camera; the audio output device is, for example, a speaker; the audio input device is, for example, a microphone; the user input device is, for example, a touch pad, a knob; the sensor device is, for example, a vehicle speed sensor; the body control device is, for example, a window, an air conditioner.

[0067] In the above embodiment, on the side of the smart terminal 20a, the application of the smart terminal 20a interacts with the ARA server through the client; on the side of the vehicle-mounted control device 20b, the vehicle-mounted control device 20b interacts with the ARA server through the client, and uses the device resources associated with the vehicle-mounted control device. Several logical channels (solid line parts in the figure) are established between the ARA server on the side of the smart terminal 20a and the client on the side of the vehicle-mounted control device 20b, which can be implemented by the ARA protocol. The logical channel can be a wireless connection or a wired connection, such as USB. If there are multiple logical channels, a header mark can be added to the data packet on each logical channel to mark the logical channel to which the data packet belongs, and it is placed on the physical link for transmission to the vehicle-mounted control device 20b. The logical channel of the embodiment of the present application includes two major parts: one is the channel at the control level; responsible for transmitting signaling, clocks and notifications; two, it also includes the channel at the data processing level; responsible for transmitting audio and video, etc.

[0068] In the above embodiment, the ARA protocol can be integrated into the application layer, that is, implemented as an application, such as an SDK (Software Development Kit); an API interface is provided for the application, and the application accesses the status, resource specifications and resource requirements of the local agent through the API interface, and then reads and writes resources that meet the requirements through the file nodes of each resource. Alternatively, the ARA protocol can also be integrated into the operating system, and the application interacts with the operating system.

[0069] In this embodiment, the smart terminal 20a issues a resource application through an application, and the resource application carries the resource requirement information of the application. For example, the smart terminal 20a issues a video resource application to the vehicle-mounted control device 20b, and the video resource application carries the video resource descriptor of the application, wherein the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage authority.

[0070] In this embodiment, the smart terminal 20a negotiates with the vehicle control device 20b to determine the hardware resources that the application needs to use based on the resource requirement information of the application. An optional embodiment is that the smart terminal 20a sends the resource requirement information of the application to the vehicle control device 20b, and after the vehicle control device 20b obtains the resource requirement information sent by the smart terminal 20a, the vehicle control device 20b selects information about candidate hardware resources that meet the resource requirement information from its own hardware resources; sends the information about the candidate hardware resources to the smart terminal 20a; the smart terminal 20a receives the information about the candidate hardware resources returned by the vehicle control device 20b, and reports the information about the candidate hardware resources to the application for the application to select; the smart terminal 20a obtains the hardware resources selected by the application as the hardware resources that the application needs to use.

[0071] For example, the smart terminal 20a sends a user input resource application to the vehicle control device 20b, and the user input resource application carries the user input resource descriptor of the application. After the vehicle control device 20b obtains the user input resource application sent by the smart terminal 20a, the vehicle control device 20b selects candidate hardware resource information that meets the user input resource descriptor from its own user input resources. The user input resources of the vehicle control device 20b include a touchpad and a knob. If the information of the touchpad and the knob meets the user input resource descriptor, the touchpad and the knob are used as candidate hardware resources, and the information of the touchpad and the knob is provided to the smart terminal 20a. The smart terminal 20a receives the information of the touchpad and the knob and reports it to the application of the smart terminal 20a. The application selects the knob from the information of the touchpad and the knob as the hardware resource that the application needs to use.

[0072] In the above embodiment, before the smart terminal 20a sends a resource request to the vehicle control device 20b through the application, the smart terminal 20a includes a step of verifying the identity of the operating user. One achievable method is that the smart terminal 20a collects the user's identity information, sends the user's identity information to the vehicle control device 20b for identity verification, and returns information of successful identity verification after the verification is passed, so that the user can use the smart terminal 20a to send a resource request to the vehicle control device 20b. Among them, the smart terminal 20a can also perform a user identity verification operation.

[0073] After the smart terminal 20a negotiates with the second device to determine the hardware resources that the application needs to use, it determines whether there is a local agent corresponding to the hardware resources locally based on the identifier of the hardware resources that the application needs to use; if not, it executes the operation of creating a local agent corresponding to the hardware resources locally.

[0074] The intelligent terminal 20a provides the application with an API interface (Application Programming Interface) corresponding to the local proxy, so that the application can initiate a request to use the local proxy through the API interface. In a preferred embodiment, each virtual resource of the same type as the local proxy uses the same API interface. Among them, virtual resources of the same type use the same API interface, and the data specifications and timing supported by the API interface are consistent. For different hardware implementations of virtual resources of the same type, operations can be performed through the interface of the corresponding virtual resource without having to use different interfaces for different hardware implementations. For example, the corresponding hardware of a virtual resource such as a video output device can be the screen of a vehicle-mounted system or a vehicle-mounted projector; through the write interface of the video output device, the screen and the vehicle-mounted projector can display the written video data in their own ways.

[0075] In some optional embodiments, the application of the smart terminal 20a initiates a use request to the local proxy through the API interface. The smart terminal 20a receives the use request of the application to the local proxy through the API interface, and establishes a resource use relationship between the application and the local proxy; the channel provides the use request to the application of the vehicle control device 20b, and after receiving the use request, the application of the vehicle control device 20b initiates a use operation of the hardware resources.

[0076] In the above embodiment, after the smart terminal 20a creates a local proxy corresponding to the hardware resource locally, the smart terminal 20a can release the local proxy. The smart terminal 20a can release the local proxy based on the request of the application program; the first device 10a can also delete all the established local proxies.

[0077] The smart terminal 20a may release the local proxy based on the request of the application. An optional embodiment is that the smart terminal 20a receives a resource release request sent by the application; the smart terminal 20a deletes the resource usage relationship between the application and the local proxy according to the resource release request. For example, the smart terminal 20a receives a video resource release request sent by the application, and the smart terminal 20a deletes the resource usage relationship between the application and the target virtual video resource.

[0078] The intelligent terminal 20a deletes the local proxy corresponding to the hardware resource created locally. This includes but is not limited to the following methods:

[0079] Method 1: Determine whether there are other applications using the local proxy; if not, delete the local proxy.

[0080] Method 2: Determine whether the life cycle of the local proxy has ended; if so, delete the local proxy.

[0081] The vehicle-mounted control device 20b can release local resources. One achievable way is to receive a resource release request sent by a local application program and delete the hardware resources being used according to the resource release request.

[0082] In the above-mentioned system embodiment of the present application, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local agent corresponding to the hardware resources locally. The application of the first device can use the hardware resources of the second device by accessing the local local agent. During the software development process, there is no need to understand the hardware resource status of the device, thereby improving development efficiency.

[0083] Figure 2a The following is a flow chart of a resource usage method described from the perspective of a first device provided by an exemplary embodiment of the present application. Figure 2a As shown, the method includes:

[0084] S211: receiving a resource application sent by an application, where the resource application carries resource demand information of the application;

[0085] S212: Negotiate with the second device to determine, based on the resource requirement information of the application, that the application needs to use hardware resources of the second device;

[0086] S213: Create a local proxy for the hardware resources of the second device locally, and use the hardware resources of the second device by the proxy application.

[0087] Figure 2b The following is a flow chart of a resource usage method described from the perspective of a second device provided by an exemplary embodiment of the present application. Figure 2b As shown, the method includes:

[0088] S221: Acquire resource requirement information sent by the first device;

[0089] S222: Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources;

[0090] S223: Provide the information of the candidate hardware resources to the first device, so that the first device can determine the hardware resources that the application program of the first device needs to use according to the information of the candidate hardware resources.

[0091] In this embodiment, the second device maps the hardware resources required by the first device to the first device through a communication protocol, so that the first device can establish a local proxy locally; the application of the first device can improve the compatibility of the device by accessing the local proxy.

[0092] In this embodiment, the first device has a need to use the hardware resources in the second device. The first device can use the better hardware resources on the second device, for example, a mobile phone uses the display of a smart TV; or, in a specific environment, the first device uses the hardware resources of the second device to bring convenience to the user, for example, a smart terminal and a vehicle-mounted control device, and the user uses the vehicle-mounted control device to make calls, videos, etc. during driving. Among them, the smart terminal can be a computer device or a handheld device, and its implementation form can be various, such as a smart phone, a personal computer, a tablet computer, and a smart speaker. For another example, the second device can be a device with a screen such as a smart TV, a smart speaker, and a smart screen, and can also be a device without a screen but capable of displaying such as a projector.

[0093] In this embodiment, the first device and the second device establish a communication connection. Optionally, the first device can establish a communication connection with the second device using a communication method such as WIFI, Bluetooth, infrared, etc., or the first device can also establish a communication connection with the second device through a mobile network. The network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 5G, etc.

[0094] In some embodiments, the application is an application running on the first device, and the application does not limit the type of the application. The application includes but is not limited to the following: instant messaging applications, audio and video applications, and telephone applications.

[0095] In some embodiments, the resource requirement information is various parameters of virtual resources that the application of the first device needs to use, and the resource requirement information is adjusted accordingly according to different scenarios. The resource requirement information includes but is not limited to at least one of the following: parameters of video output devices, parameters of video input devices, parameters of audio output devices, parameters of audio input devices, parameters of user input devices, and parameters of control devices.

[0096] In this embodiment, the first device sends a resource request through an application, and the resource request carries the resource requirement information of the application. For example, the first device is a mobile phone, and the second device is a vehicle-mounted control device. The mobile phone sends a video resource request to the vehicle-mounted control device, and the video resource request carries the video resource descriptor of the application, wherein the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage authority.

[0097] In this embodiment, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application. An optional embodiment is that the first device sends the resource requirement information of the application to the second device, and after the second device obtains the resource requirement information sent by the first device, the second device selects information about candidate hardware resources that meet the resource requirement information from its own hardware resources; sends the information about the candidate hardware resources to the first device; the first device receives the information about the candidate hardware resources returned by the second device, and reports the information about the candidate hardware resources to the application for selection by the application; the first device obtains the hardware resources selected by the application as the hardware resources that the application needs to use.

[0098] For example, the first device is a smart terminal, and the second device is an on-board control device. The smart terminal sends a user input resource request to the on-board control device, and the user input resource request carries the user input resource descriptor of the application. After the on-board control device obtains the user input resource request sent by the smart terminal; the on-board control device selects candidate hardware resource information that meets the user input resource descriptor from its own user input resources; the user input resources of the on-board control device include a touchpad and a knob. If the information of the touchpad and the knob meets the user input resource descriptor, the touchpad and the knob are used as candidate hardware resources, and the information of the touchpad and the knob is provided to the smart terminal; the smart terminal receives the information of the touchpad and the knob and reports it to the application of the smart terminal; the application selects the knob from the information of the touchpad and the knob as the hardware resource that the application needs to use.

[0099] In the above embodiment, before the first device sends a resource request to the second device through an application, the first device includes a step of verifying the identity of the operating user. One achievable method is that the first device collects the user's identity information, sends the user's identity information to the second device for identity verification, and returns information indicating successful identity verification after the verification is successful, so that the user can use the first device to send a resource request to the second device. The first device can also perform a user identity verification operation.

[0100] After the first device negotiates with the second device to determine the hardware resources that the application needs to use, it determines whether there is a local agent corresponding to the hardware resources locally based on the identifier of the hardware resources that the application needs to use; if not, it executes the operation of creating a local agent corresponding to the hardware resources locally.

[0101] The first device provides the application with an API interface (Application Programming Interface) corresponding to the local proxy, so that the application can initiate a request to use the local proxy through the API interface. In a preferred embodiment, each virtual resource of the same type as the local proxy uses the same API interface. Among them, virtual resources of the same type use the same API interface, and the data specifications and timing supported by the API interface are consistent. For different hardware implementations of virtual resources of the same type, operations can be performed through the interface of the corresponding virtual resource without having to use different interfaces for different hardware implementations. For example, the corresponding hardware of a virtual resource such as a video output device can be the screen of a vehicle-mounted system or a vehicle-mounted projector; through the write interface of the video output device, the screen and the vehicle-mounted projector can display the written video data in their own ways.

[0102] In some optional embodiments, the application of the first device initiates a use request to the local proxy through the API interface. The first device receives the use request of the application to the local proxy through the API interface, and the first device establishes a resource use relationship between the application and the local proxy according to the use request; the first device provides the use request to the application of the second device, so that the application of the second device initiates a use operation of the hardware resource.

[0103] Among them, several logical channels are established between the first device and the second device. The logical channels can be physically wireless connections or wired connections, such as USB. If there are multiple logical channels, a header tag can be added to the data packets on each logical channel to mark the logical channel to which the data packet belongs, and then put it on the physical link for transmission to the second device. The logical channel of the embodiment of the present application includes two parts: one is the channel at the control level; responsible for transmitting signaling, clocks and notifications; the other is also the channel at the data processing level; responsible for transmitting audio and video, etc.

[0104] In the above embodiment, after the first device locally creates a local proxy corresponding to the hardware resource, the first device may release the local proxy. The first device may release the local proxy based on a request from an application program; the first device may also delete all established local proxies.

[0105] The first device may release the local proxy based on a request from an application. An optional embodiment is that the first device receives a resource release request sent by an application; the first device deletes the resource usage relationship between the application and the local proxy according to the resource release request. For example, the first device receives a video resource release request sent by an application, and the first device deletes the resource usage relationship between the application and the target virtual video resource.

[0106] The first device deletes the locally created local proxy corresponding to the hardware resource, including but not limited to the following methods:

[0107] Method 1: Determine whether there are other applications using the local proxy; if not, delete the local proxy.

[0108] Method 2: Determine whether the life cycle of the local proxy has ended; if so, delete the local proxy.

[0109] In this embodiment, the second device may release the local resources. One achievable manner is to receive a resource release request sent by a local application program and delete the hardware resources being used according to the resource release request.

[0110] Figure 3a The following is a flow chart of a method for using vehicle resources from the perspective of a smart terminal, provided as an exemplary embodiment of the present application. Figure 3a As shown, the method includes:

[0111] S311: receiving a resource application sent by an application, where the resource application carries resource demand information of the application;

[0112] S312: Negotiate with the vehicle control device to determine, based on the resource requirement information of the application, that the application needs to use hardware resources of the vehicle control device;

[0113] S313: locally create a local proxy corresponding to the hardware resources that the application needs to use, so that the application can use the local proxy.

[0114] Figure 3b The following is a flow chart of a method for using vehicle resources from the perspective of a vehicle control device provided by an exemplary embodiment of the present application. Figure 3b As shown, the method includes:

[0115] S321: Obtain resource demand information sent by the smart terminal;

[0116] S322: Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources;

[0117] S323: providing the information of the candidate hardware resources to the smart terminal, so that the smart terminal can determine the hardware resources that the application program of the smart terminal needs to use according to the information of the candidate hardware resources.

[0118] In this embodiment, the vehicle control device maps the hardware resources that the smart terminal needs to use to the smart terminal through a communication protocol, so that the smart terminal can establish a local proxy for the hardware resources of the vehicle control device locally; and the proxy application uses the hardware resources of the vehicle control device.

[0119] In this embodiment, the intelligent terminal and the vehicle-mounted control device establish a communication connection. Optionally, the intelligent terminal can establish a communication connection with the vehicle-mounted control device using WIFI, Bluetooth, infrared, or other communication methods, or the intelligent terminal can also establish a communication connection with the vehicle-mounted control device through a mobile network. The network standard of the mobile network can be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 5G, etc.

[0120] Figure 1c Schematic diagram of resource creation of the vehicle resource negotiation system 20 provided in an exemplary embodiment of the present application. Figure 1c As shown, the vehicle resources associated with the vehicle control device are mapped to the smart terminal side through the ARA (Automotive Resource Abstraction) service between the smart terminal and the vehicle control device, and a local proxy is created locally in the smart terminal. The application of the smart terminal can access the local proxy.

[0121] In this embodiment, the hardware resources include at least one of the following: video output device, video input device, audio output device, audio input device, user input device and body control device. Among them, the video output device is, for example, a screen; the video input device is, for example, a camera; the audio output device is, for example, a speaker; the audio input device is, for example, a microphone; the user input device is, for example, a touch pad, a knob; the sensor device is, for example, a vehicle speed sensor; the body control device is, for example, a window, an air conditioner.

[0122] In the above embodiment, on the side of the smart terminal, the application of the smart terminal interacts with the ARA server through the client; on the side of the vehicle-mounted control device, the vehicle-mounted control device interacts with the ARA server through the client, and uses the device resources associated with the vehicle-mounted control device. Several logical channels (solid line parts in the figure) are established between the ARA server on the smart terminal side and the client on the side of the vehicle-mounted control device, which can be implemented by the ARA protocol. The logical channel can be a wireless connection or a wired connection, such as USB. If there are multiple logical channels, a packet header mark can be added to the data packet on each logical channel to mark the logical channel to which the data packet belongs, and it is placed on the physical link for transmission to the vehicle-mounted control device. The logical channel of the embodiment of the present application includes two major parts: one is the channel at the control level; responsible for transmitting signaling, clocks and notifications; two, it also includes the channel at the data processing level; responsible for transmitting audio and video, etc.

[0123] In the above embodiment, the ARA protocol can be integrated into the application layer, that is, implemented as an application, such as an SDK (Software Development Kit); an API interface is provided for the application, and the application accesses the status, resource specifications and resource requirements of the local agent through the API interface, and then reads and writes resources that meet the requirements through the file nodes of each resource. Alternatively, the ARA protocol can also be integrated into the operating system, and the application interacts with the operating system.

[0124] In this embodiment, the intelligent terminal issues a resource request through an application, and the resource request carries the resource requirement information of the application. For example, the intelligent terminal issues a video resource request to the vehicle control device, and the video resource request carries the video resource descriptor of the application, wherein the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage authority.

[0125] In this embodiment, the intelligent terminal negotiates with the vehicle control device to determine the hardware resources that the application needs to use based on the resource requirement information of the application. An optional embodiment is that the intelligent terminal sends the resource requirement information of the application to the vehicle control device, and after the vehicle control device obtains the resource requirement information sent by the intelligent terminal, the vehicle control device selects information about candidate hardware resources that meet the resource requirement information from its own hardware resources; sends the information about the candidate hardware resources to the intelligent terminal; the intelligent terminal receives the information about the candidate hardware resources returned by the vehicle control device, and reports the information about the candidate hardware resources to the application for the application to select; the intelligent terminal obtains the hardware resources selected by the application as the hardware resources that the application needs to use.

[0126] For example, the smart terminal sends a user input resource request to the vehicle control device, and the user input resource request carries the user input resource descriptor of the application. After the vehicle control device obtains the user input resource request sent by the smart terminal, the vehicle control device selects candidate hardware resource information that meets the user input resource descriptor from its own user input resources. The user input resources of the vehicle control device include a touchpad and a knob. If the information of the touchpad and the knob meets the user input resource descriptor, the touchpad and the knob are used as candidate hardware resources, and the information of the touchpad and the knob is provided to the smart terminal. The smart terminal receives the information of the touchpad and the knob and reports it to the application of the smart terminal. The application selects the knob from the information of the touchpad and the knob as the hardware resource that the application needs to use.

[0127] In the above embodiment, before the smart terminal sends a resource request to the vehicle control device through the application, the smart terminal includes a step of verifying the identity of the operating user. One achievable method is that the smart terminal collects the user's identity information, sends the user's identity information to the vehicle control device for identity verification, and returns information of successful identity verification after the verification is passed, so that the user can use the smart terminal to send a resource request to the vehicle control device. Among them, the smart terminal can also perform a user identity verification operation.

[0128] After the smart terminal negotiates with the second device to determine the hardware resources that the application needs to use, it determines whether there is a local agent corresponding to the hardware resources locally based on the identifier of the hardware resources that the application needs to use; if not, it executes the operation of creating a local agent corresponding to the hardware resources locally.

[0129] The intelligent terminal provides the application with an API interface (Application Programming Interface) corresponding to the local proxy, so that the application can initiate a request to use the local proxy through the API interface. In a preferred embodiment, each virtual resource of the same type as the local proxy uses the same API interface. Among them, virtual resources of the same type use the same API interface, and the data specifications and timing supported by the API interface are consistent. For different hardware implementations of virtual resources of the same type, operations can be performed through the interface of the corresponding virtual resource without having to use different interfaces for different hardware implementations. For example, the corresponding hardware of a virtual resource such as a video output device can be the screen of a vehicle-mounted system or a vehicle-mounted projector; through the write interface of the video output device, the screen and the vehicle-mounted projector can display the written video data in their own way.

[0130] In some optional embodiments, the application of the smart terminal initiates a use request to the local proxy through the API interface. The smart terminal receives the use request of the application to the local proxy through the API interface, and the smart terminal establishes a resource use relationship between the application and the local proxy according to the use request; the smart terminal provides the use request to the application of the vehicle control device, so that the application of the vehicle control device initiates the use operation of the hardware resources.

[0131] In the above embodiment, after the smart terminal locally creates a local proxy corresponding to the hardware resource, the smart terminal can release the local proxy. The smart terminal can release the local proxy based on the request of the application program; the first device 10a can also delete all the established local proxies.

[0132] The smart terminal can release the local proxy based on the request of the application. An optional embodiment is that the smart terminal receives a resource release request sent by the application; the smart terminal deletes the resource usage relationship between the application and the local proxy according to the resource release request. For example, the smart terminal receives a video resource release request sent by the application, and the smart terminal deletes the resource usage relationship between the application and the target virtual video resource.

[0133] The smart terminal deletes the local proxy corresponding to the hardware resource created locally, including but not limited to the following methods:

[0134] Method 1: Determine whether there are other applications using the local proxy; if not, delete the local proxy.

[0135] Method 2: Determine whether the life cycle of the local proxy has ended; if so, delete the local proxy.

[0136] The vehicle-mounted control device can release local resources. One possible implementation method is to receive a resource release request sent by a local application program and delete the hardware resources being used according to the resource release request.

[0137] Combined with the description of the above embodiments, Figure 4 A flowchart of a method for using vehicle resources provided by an exemplary embodiment of the present application is shown below. Figure 4 As shown, the method includes:

[0138] S401: The intelligent terminal obtains the user's identity information;

[0139] S402: Sending the user's identity information to the vehicle-mounted control device so that the vehicle-mounted control device performs identity authentication and returns the authentication result;

[0140] S403: If the vehicle control device returns a result of authentication passing, the smart terminal sends a resource request through the application program;

[0141] S404: The intelligent terminal negotiates with the vehicle-mounted control device to determine the hardware resources required by the application program according to the resource requirement information of the application program;

[0142] S405: The vehicle-mounted control device obtains resource demand information sent by the intelligent terminal;

[0143] S406: The vehicle-mounted control device selects information of candidate hardware resources that meet the resource requirement information from the hardware resources;

[0144] S407: The vehicle control device provides the information of the candidate hardware resources to the intelligent terminal;

[0145] S408: The intelligent terminal locally creates a local proxy for the hardware resources of the vehicle-mounted control device, and the proxy application uses the hardware resources of the second device.

[0146] It should be noted that the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 401 to 408 can be device A; for another example, the execution subject of steps 401 and 402 can be device A, and the execution subject of steps 403 to 408 can be device B; and so on.

[0147] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or executed in parallel, and the sequence numbers of the operations, such as 401, 402, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., do not represent the order of precedence, and do not limit the "first" and "second" to be different types.

[0148] In the above-mentioned method embodiment of the present application, the first device negotiates with the second device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local agent corresponding to the hardware resources locally. The application of the first device can use the hardware resources of the second device by accessing the local local agent. During the software development process, there is no need to understand the hardware resource status of the device, thereby improving development efficiency.

[0149] Figure 5The following is a schematic diagram of a smart device provided by an exemplary embodiment of the present application. Figure 5 As shown, the smart device includes: a memory 501 and a processor 502. In addition, the smart device also includes necessary components such as a power supply component 503, a communication component 504, and an electronic display screen 505.

[0150] The memory 501 is used to store computer programs and can be configured to store various other data to support operations on the smart device. Examples of such data include instructions for any application or method used to operate on the smart device.

[0151] Memory 501 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 memory, flash memory, magnetic disk or optical disk.

[0152] The communication component 504 is used for data transmission with other devices.

[0153] Processor 502 can execute computer instructions stored in memory 501 to: receive a resource request sent by an application, the resource request carrying resource requirement information of the application; negotiate with the second device to determine, based on the resource requirement information of the application, that the application needs to use the hardware resources of the second device; and locally create a local proxy for the hardware resources of the second device to proxy the application's use of the hardware resources of the second device.

[0154] Optionally, when the processor 502 negotiates with the second device to determine that the application needs to use the hardware resources of the second device based on the resource requirement information of the application, the processor 502 is specifically used to: send the resource requirement information of the application to the second device, so that the second device returns information about candidate hardware resources that meet the resource requirement information; receive the information about the candidate hardware resources returned by the second device, and report the information about the candidate hardware resources to the application for the application to select; and obtain the hardware resources selected by the application as the hardware resources that the application needs to use.

[0155] Optionally, the processor 502 locally creates a local proxy for the hardware resources of the second device. Before the proxy application uses the hardware resources of the second device, it can also be used to: determine whether there is a local proxy corresponding to the hardware resources in the local proxy based on the identifier of the hardware resources that the application needs to use; if not, execute the operation of locally creating a local proxy for the hardware resources.

[0156] Optionally, the processor 502 locally creates a local proxy for the hardware resources of the second device. After the proxy application uses the hardware resources of the second device, it can also be used to: provide an API interface of the local proxy to the application so that the application can initiate a request to use the local proxy through the API interface.

[0157] Optionally, the processor 502 can also be used to: receive a usage request initiated by an application to the local agent through an API interface; establish a resource usage relationship between the application and the local agent; and provide the usage request to the application of the second device so that the application of the second device can initiate an operation to use the hardware resources of the second device.

[0158] Optionally, the processor 502 may be further configured to: receive a resource release request sent by the application; and delete the resource usage relationship between the application and the local proxy according to the resource release request.

[0159] Optionally, the processor 502 may be further configured to: delete a locally created local proxy corresponding to the hardware resources of the second device that the application needs to use.

[0160] Optionally, when deleting the locally created local proxy corresponding to the hardware resources of the second device that the application needs to use, the processor 502 is specifically used to: determine whether there are other applications using the local proxy; if not, delete the local proxy; or determine whether the life cycle of the local proxy has ended; if so, delete the local proxy.

[0161] Optionally, each local agent of the same type as the local agent uses the same API interface.

[0162] Optionally, the first device is a smart terminal, and the second device is a vehicle-mounted control device; or, the first device is a vehicle-mounted control device, and the second device is a smart terminal.

[0163] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores the computer program and the computer program is executed by one or more processors, the one or more processors execute Figure 2a Each step in the method embodiment.

[0164] Figure 6 The following is a schematic diagram of a smart device provided by an exemplary embodiment of the present application. Figure 6 As shown, the smart device includes: a memory 601 and a processor 602. In addition, the smart device also includes necessary components such as a power supply component 603 and a communication component 604.

[0165] The memory 601 is used to store computer programs and can be configured to store various other data to support operations on the smart device. Examples of such data include instructions for any application or method used to operate on the smart device.

[0166] Memory 601 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 memory, flash memory, magnetic disk or optical disk.

[0167] The communication component 604 is used for data transmission with other devices.

[0168] Processor 602 can execute computer instructions stored in memory 601 to: obtain resource requirement information sent by the first device; select information of candidate hardware resources that meet the resource requirement information from the hardware resources; provide the information of the candidate hardware resources to the first device, so that the first device can determine the hardware resources that the application of the first device needs to use based on the information of the candidate hardware resources.

[0169] Optionally, when determining information of candidate hardware resources that meet resource requirement information from hardware resources, processor 602 is specifically used to: select at least one type of hardware resources associated with the resource requirement information from the hardware resources; and select information of candidate hardware resources that serve the resource requirement information from at least one type of hardware resources.

[0170] Optionally, the resource requirement information is a video resource descriptor; when the processor 602 selects information of candidate hardware resources that meet the resource requirement information from the hardware resources, it is specifically used to: select information of candidate hardware resources that meet the video resource descriptor from the hardware resources.

[0171] Optionally, the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage rights.

[0172] Optionally, the second device is a vehicle-mounted control device whose hardware resources include at least one of the following: a video output device, a video input device, an audio output device, an audio input device, a user input device and a body control device.

[0173] Optionally, after providing the information of the candidate hardware resource to the first device, the processor 602 may also be configured to: receive a resource release request sent by a local application; and delete the hardware resource in use according to the resource release request.

[0174] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores the computer program and the computer program is executed by one or more processors, the one or more processors execute Figure 2a Each step in the method embodiment.

[0175] Figure 7 The following is a schematic diagram of a smart terminal structure provided by an exemplary embodiment of the present application. Figure 7 As shown, the smart terminal includes: a memory 701 and a processor 702. In addition, the smart terminal also includes necessary components such as a power supply component 703, a communication component 704, and an electronic display screen 705.

[0176] The memory 701 is used to store computer programs and can be configured to store various other data to support operations on the smart terminal. Examples of such data include instructions for any application program or method operating on the smart terminal.

[0177] Memory 701 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 memory, flash memory, magnetic disk or optical disk.

[0178] The communication component 704 is used for data transmission with other devices.

[0179] Processor 702 can execute computer instructions stored in memory 701 to: receive a resource request sent by an application, the resource request carrying resource requirement information of the application; negotiate with the vehicle-mounted control device to determine, based on the resource requirement information of the application, that the application needs to use the hardware resources of the vehicle-mounted control device; and locally create a local proxy for the hardware resources of the vehicle-mounted control device to proxy the application's use of the hardware resources of the vehicle-mounted control device.

[0180] Optionally, when the processor 702 negotiates with the vehicle-mounted control device to determine that the application needs to use the hardware resources of the vehicle-mounted control device based on the resource requirement information of the application, it is specifically used to: send the resource requirement information of the application to the vehicle-mounted control device, so that the vehicle-mounted control device returns information about candidate hardware resources that meet the resource requirement information; receive the information about the candidate hardware resources returned by the vehicle-mounted control device, and report the information about the candidate hardware resources to the application for the application to select; obtain the hardware resources selected by the application as the hardware resources that the application needs to use.

[0181] Optionally, the processor 702 locally creates a local proxy for the hardware resources of the vehicle-mounted control device. Before the proxy application uses the hardware resources of the vehicle-mounted control device, it can also be used to: determine whether there is a local proxy corresponding to the hardware resources in the local proxy based on the identifier of the hardware resources that the application needs to use; if not, execute the operation of locally creating a local proxy for the hardware resources.

[0182] Optionally, the processor 702 locally creates a local proxy for the hardware resources of the vehicle-mounted control device. After the proxy application uses the hardware resources of the vehicle-mounted control device, it can also be used to: provide the application with an API interface of the local proxy so that the application can initiate a request to use the local proxy through the API interface.

[0183] Optionally, processor 702 can also be used to: receive a usage request initiated by an application to a local agent through an API interface; establish a resource usage relationship between the application and the local agent; and provide the usage request to an application of the vehicle-mounted control device so that the application of the vehicle-mounted control device can initiate an operation to use hardware resources.

[0184] Optionally, the processor 702 may be further configured to: receive a resource release request sent by an application; and delete the resource usage relationship between the application and the local proxy according to the resource release request.

[0185] Optionally, the processor 702 may be further configured to: delete a locally created local proxy corresponding to a hardware resource of the vehicle-mounted control device that the application needs to use.

[0186] Optionally, when deleting the locally created local agent corresponding to the hardware resources, the processor 702 is specifically used to: determine whether there are other applications using the local agent; if not, delete the local agent; or determine whether the life cycle of the local agent has ended; if so, delete the local agent.

[0187] Optionally, each local agent of the same type as the local agent uses the same API interface.

[0188] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores the computer program and the computer program is executed by one or more processors, the one or more processors execute Figure 3a Each step in the method embodiment.

[0189] Figure 8 The following is a schematic diagram of a vehicle control device provided by an exemplary embodiment of the present application. Figure 8As shown, the vehicle-mounted control device includes: a memory 801 and a processor 802. In addition, the vehicle-mounted control device also includes necessary components such as a power supply component 803 and a communication component 804.

[0190] The memory 801 is used to store computer programs and can be configured to store various other data to support operations on the vehicle-mounted control device. Examples of such data include instructions for any application program or method used to operate on the vehicle-mounted control device.

[0191] Memory 801 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 memory, flash memory, magnetic disk or optical disk.

[0192] The communication component 804 is used for data transmission with other devices.

[0193] Processor 802 can execute computer instructions stored in memory 801 to: obtain resource requirement information sent by the smart terminal; select information of candidate hardware resources that meet the resource requirement information from the hardware resources; provide the information of the candidate hardware resources to the smart terminal, so that the smart terminal can determine the hardware resources that the application of the smart terminal needs to use based on the information of the candidate hardware resources.

[0194] Optionally, when determining information of candidate hardware resources that meet resource requirement information from hardware resources, processor 802 is specifically used to: select at least one type of hardware resources associated with the resource requirement information from the hardware resources; and select information of candidate hardware resources that serve the resource requirement information from at least one type of hardware resources.

[0195] Optionally, the resource requirement information is a video resource descriptor; when the processor 802 selects information of candidate hardware resources that meet the resource requirement information from the hardware resources, it is specifically used to: select information of candidate hardware resources that meet the video resource descriptor from the hardware resources.

[0196] Optionally, the video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay, and usage rights.

[0197] Optionally, the vehicle-mounted control device is a vehicle-mounted control device whose hardware resources include at least one of the following: a video output device, a video input device, an audio output device, an audio input device, a user input device and a body control device.

[0198] Optionally, after providing the information of the candidate hardware resources to the intelligent terminal, the processor 802 may also be configured to: receive a resource release request sent by a local application; and delete the hardware resources in use according to the resource release request.

[0199] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores the computer program and the computer program is executed by one or more processors, the one or more processors execute Figure 3b Each step in the method embodiment.

[0200] In the above-mentioned device embodiment of the present application, the smart terminal negotiates with the vehicle-mounted control device to determine the hardware resources that the application needs to use based on the resource requirement information of the application, and creates a local agent corresponding to the hardware resources locally, so that the application of the smart terminal can use the corresponding vehicle-mounted resources of the vehicle-mounted control device by accessing the local local agent.

[0201] Above Figures 5 to 8 The communication component in is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0202] Above Figure 5-Figure 8 The power supply component in the device provides power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power supply component is located.

[0203] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0204] The present invention is described with reference to the flowchart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the process and / or box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0205] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0206] These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0207] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0208] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0209] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0210] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0211] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A resource use method, wherein: The method is run on a first device and includes: Receive a resource application sent by an application, wherein the resource application carries resource demand information of the application; According to the resource requirement information of the application, determine through negotiation with the second device that the application needs to use the hardware resources of the second device; Creating a local proxy for the hardware resources of the second device locally, and proxying the application program to use the hardware resources of the second device; An API interface of the local agent is provided to the application so that the application can initiate a request to use the local agent through the API interface, and the request is provided to the application of the second device so that the application of the second device can initiate an operation to use the hardware resources of the second device.

2. The method according to claim 1, characterized in that According to the resource requirement information of the application, negotiating with the second device to determine that the application needs to use the hardware resources of the second device includes: Sending the resource requirement information of the application to the second device, so that the second device returns information about candidate hardware resources that meet the resource requirement information; receiving information about candidate hardware resources returned by the second device, and reporting the information about the candidate hardware resources to the application for selection by the application; The hardware resource selected by the application is obtained as the hardware resource of the second device that the application needs to use.

3. The method according to claim 1, characterized in that Before locally creating a local proxy for the hardware resources of the second device and proxying the use of the hardware resources of the second device by the application program, the method further includes: According to the identifier of the hardware resource required to be used by the application program, determining whether there is a local agent corresponding to the hardware resource in the local agent; If it does not exist, an operation of locally creating a local proxy for the hardware resource is performed.

4. The method according to claim 1, characterized in that: Also includes: Receiving a usage request initiated by the application to the local proxy through the API interface; Establishing a resource usage relationship between the application and the local agent; The usage request is provided to an application of the second device.

5. The method according to claim 4, characterized in that Also includes: receiving a resource release request sent by the application; The resource usage relationship between the application and the local agent is deleted according to the resource release request.

6. The method according to claim 5, characterized in that Also includes: The locally created local proxy corresponding to the hardware resource of the second device that the application needs to use is deleted.

7. The method according to claim 6, characterized in that Deleting the locally created local proxy corresponding to the hardware resource of the second device that the application needs to use includes: Determine whether there are other applications using the local proxy; if not, delete the local proxy; or, Determine whether the life cycle of the local agent has ended; if so, delete the local agent.

8. The method according to claim 1, characterized in that Each local agent of the same type as the local agent uses the same API interface.

9. The method according to claim 1, characterized in that: The first device is a smart terminal, and the second device is a vehicle-mounted control device; or, The first device is a vehicle-mounted control device, and the second device is a smart terminal.

10. A resource use method, wherein: The method is run on a second device and includes: Obtaining resource requirement information sent by the first device; Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources; Providing the information of the candidate hardware resources to the first device, so that the first device determines the hardware resources that the application of the first device needs to use according to the information of the candidate hardware resources; Receive a usage request sent by an application of a first device through a local agent, and provide the usage request to an application of a second device so that the application of the second device can initiate an operation of using the hardware resources of the second device, wherein the local agent uses the hardware resources of the second device on behalf of the application of the first device.

11. The method according to claim 10, characterized in that The information of candidate hardware resources that meet the resource requirement information is determined from the hardware resources, including: Selecting at least one type of hardware resource associated with the resource requirement information from the hardware resources; Information of candidate hardware resources serving the resource requirement information is selected from the at least one type of hardware resources.

12. The method according to claim 10, characterized in that The resource requirement information is a video resource descriptor; The information of selecting candidate hardware resources that meet the resource requirement information from the hardware resources includes: Information of candidate hardware resources that conform to the video resource descriptor is selected from the hardware resources.

13. The method according to claim 12, characterized in that The video resource descriptor includes at least one of the following: video format, resolution, scanning accuracy, delay and usage rights.

14. The method according to any one of claims 10 to 13, characterized in that: The second device is a vehicle-mounted control device, and the hardware resources include at least one of the following: a video output device, a video input device, an audio output device, an audio input device, a user input device, and a vehicle body control device.

15. The method according to claim 10, characterized in that After providing the information of the candidate hardware resource to the first device, the method further includes: Receive resource release requests sent by local applications; The hardware resources being used are deleted according to the resource release request.

16. A smart device, wherein: include: Memory, processors and electronic displays; The memory is used to store one or more computer instructions; The processor is configured to execute the one or more computer instructions to: Receive a resource application sent by an application, wherein the resource application carries resource demand information of the application; According to the resource requirement information of the application, determine through negotiation with the second device that the application needs to use the hardware resources of the second device; Creating a local proxy for the hardware resources of the second device locally, and proxying the application program to use the hardware resources of the second device; An API interface of the local agent is provided to the application so that the application can initiate a request to use the local agent through the API interface, and the request is provided to the application of the second device so that the application of the second device can initiate an operation to use the hardware resources of the second device.

17. A vehicle-mounted control device, wherein: include: Memory, processors and electronic displays; The memory is used to store one or more computer instructions; The processor is configured to execute the one or more computer instructions to: Obtaining resource requirement information sent by the first device; Selecting information of candidate hardware resources that meet the resource requirement information from the hardware resources; Providing the information of the candidate hardware resources to the first device, so that the first device determines the hardware resources that the application of the first device needs to use according to the information of the candidate hardware resources; Receive a usage request sent by an application of a first device through a local agent, and provide the usage request to an application of a second device so that the application of the second device can initiate an operation of using the hardware resources of the second device, wherein the local agent uses the hardware resources of the second device on behalf of the application of the first device.

Citation Information

Patent Citations

  • Routing proxy for resource requests and resources

    CN102833148A

  • Method for obtaining hardware resources and electronic equipment

    CN110147282A