Service arbitration method and system under vehicle-mounted central computing architecture and electronic equipment

Abstract

The invention discloses a service arbitration method and system under a vehicle-mounted central computing architecture and electronic equipment. The method comprises the following steps: acquiring a service request sent by a service requester; obtaining a service request execution state; according to the service request execution state and the sending sequence of the service requests, determining the service request which is successfully arbitrated at present, and only one service request which is successfully arbitrated at present; and obtaining the service request which is successfully arbitrated at present as a to-be-executed service request and executing the service request. The service request can be rapidly arbitrated, the successfully arbitrated service request is determined and executed, and only one service request is ensured to be executed within the same time, so that the problems of service conflict and resource competition are effectively avoided, the response time of service calling is greatly shortened, and the overall efficiency of the system is improved; through a strict arbitration mechanism, it is ensured that only the service requests meeting the conditions are executed, and therefore system errors and faults caused by the fact that the service requests are executed mistakenly are reduced.

Description

Technical Field

[0001] The present application belongs to the technical field of vehicle-mounted electronic systems, and specifically relates to a service arbitration method, system and electronic equipment under a vehicle-mounted central computing architecture. Background Art

[0002] With the continuous enrichment of automobile functions and the improvement of intelligence, vehicle systems have become extremely complex. Numerous decentralized electronic control units (ECUs) and complex communication networks have made system maintenance and upgrades difficult. Based on various practical factors, the traditional distributed architecture has gradually evolved into a central computing architecture. The central computing architecture provides more efficient data processing and communication capabilities by centralizing computing resources. However, under the central computing architecture, resource contention and conflict issues of different functional services have become increasingly prominent, and an effective service arbitration mechanism is needed to ensure the stability and reliability of the system. Summary of the invention

[0003] The technical purpose of this application is to solve the technical problem that resource competition and conflict between different functional services lead to system performance degradation under the current vehicle-mounted central computing architecture, and to provide a service arbitration method, system and electronic device under the vehicle-mounted central computing architecture.

[0004] In order to achieve the above technical objectives, this application adopts the following technical solutions.

[0005] In a first aspect, an embodiment of the present application provides a service arbitration method under a vehicle-mounted central computing architecture, comprising: Obtain the service request sent by the service requester; Get the service request execution status; Determine the currently successfully arbitrated service request according to the execution status of the service request and the order in which the service requests are sent, where there is only one currently successfully arbitrated service request; The currently successfully arbitrated service request is obtained as a to-be-executed service request and executed.

[0006] In some implementations, the service request execution state includes a first state and a second state, wherein the first state indicates that the service request is not being executed, and the second state indicates that the service request is being executed; Determining the service request that has been successfully arbitrated according to the execution status of the service request and the order in which the service requests are sent, including: In the first state, determining the service request sent first as the current successfully arbitrated service request; In the second state, the most recently sent service request is determined as the currently successfully arbitrated service request.

[0007] In some implementations, the service request includes a priority indicator; The service arbitration method further includes: If the priority of the newly sent service request is less than or equal to the priority of the currently successfully arbitrated service request, the currently successfully arbitrated service request remains unchanged; If the priority of the newly sent service request is greater than the priority of the currently successfully arbitrated service request, the service request with the highest priority is taken as the latest currently successfully arbitrated service request.

[0008] In some implementations, a first container is provided, wherein the first container is used to store the currently successfully arbitrated service request; A second container is set, where the second container is used to store the to-be-executed service request.

[0009] In some implementations, both the first container and the second container use a queue data structure.

[0010] In some implementations, the service arbitration method further includes: For other service requests that have not been successfully arbitrated, an arbitration response is sent to the corresponding service requester to inform that an existing service request is being executed.

[0011] In a second aspect, an embodiment of the present application provides a service arbitration system under a vehicle-mounted central computing architecture, including at least one service management module, each of the service management modules including a service arbitration unit and a service execution unit; The service arbitration unit is configured to obtain a service request sent by a service requester, obtain a service request execution status of the service execution unit, and determine a currently successfully arbitrated service request according to the service request execution status and the order in which the service requests are sent, wherein there is only one currently successfully arbitrated service request; The service execution unit is configured to obtain the currently successfully arbitrated service request as a to-be-executed service request and execute it.

[0012] In some implementations, the service request execution state includes a first state and a second state, wherein the first state indicates that the service request is not being executed, and the second state indicates that the service request is being executed; The service arbitration unit is further configured to, in the first state, determine the first sent service request as the currently successfully arbitrated service request; and in the second state, determine the latest sent service request as the currently successfully arbitrated service request.

[0013] In some implementations, the service arbitration unit includes a first container, the first container is used to store the currently successfully arbitrated service request; the service execution unit includes a second container, the second container is used to store the to-be-executed service request.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the service arbitration method under the vehicle-mounted central computing architecture described in the first aspect.

[0015] The embodiments of the present application provide a service arbitration method and system under a vehicle-mounted central computing architecture, which can obtain the service request sent by the service requester and the execution status of the service request in real time, and can quickly arbitrate the service request, determine and execute the service request that has been successfully arbitrated, and ensure that only one service request is executed at the same time, thereby effectively avoiding service conflicts and resource competition problems, greatly shortening the response time of service calls, and improving the overall efficiency of the system; through a strict arbitration mechanism, it is ensured that only qualified service requests are executed, thereby reducing system errors and failures caused by incorrect execution of service requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are for explanation purposes only and are not intended to limit the scope of the present application in any way. In addition, the shapes and proportional dimensions of the components in the drawings are only for illustration purposes and are used to help understand the present application. They do not specifically limit the shapes and proportional dimensions of the components of the present application. Under the guidance of the present application, those skilled in the art can select various possible shapes and proportional dimensions to implement the present application according to specific circumstances. In the drawings: Figure 1 is a structural diagram of a service arbitration system under a vehicle-mounted central computing architecture according to an exemplary embodiment; Figure 2 is a flow chart of another service arbitration method under a vehicle-mounted central computing architecture according to an exemplary embodiment; Figure 3 is a flow chart of a service arbitration method under a vehicle-mounted central computing architecture according to an exemplary embodiment; Figure 4 It is a flowchart of another service arbitration method under a vehicle-mounted central computing architecture according to an exemplary embodiment. DETAILED DESCRIPTION

[0017] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. 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 creative work should fall within the scope of protection of this application.

[0018] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more features.

[0019] The present application provides a service arbitration method under a vehicle-mounted central computing architecture. The method is directed to a service arbitration system under a vehicle-mounted central computing architecture including a service requester and a service provider. Figure 1 The following is a brief description of the service arbitration system under the vehicle-mounted central computing architecture. Figure 1 As shown, the service arbitration system under the vehicle central computing architecture (hereinafter referred to as the service arbitration system) acts as a service hub, receiving service requests from one or more service requesters, and the service requester can initiate a service request to call the service through the service-oriented architecture (SOA) interface (API) or the software defined vehicle (SDV) interface (API). The main function of the service arbitration system under the vehicle central computing architecture is to provide services to each service requester through the SOA or SDV API.

[0020] Under the vehicle-mounted central computing architecture, the service arbitration system (which can be regarded as the service center) under the vehicle-mounted central computing architecture acts as a data communication hub, exchanges data between different vehicle-mounted systems and devices, provides conversion and adaptation of different protocols, and provides conversion of signals and services to interact with the central computing unit. In specific implementation, the system includes setting up a corresponding service management module for a certain service, such as Figure 1 As shown, the service management module includes a service arbitration unit and a service execution unit.

[0021] SOA (Service-Oriented Architecture) combines different functional units (services) of an application through well-defined interfaces and protocols. The service arbitration system under the vehicle central computing architecture can provide multiple different services, each of which represents an independent business capability or a group of related functions and is accessed through standardized interfaces and protocols. Figure 2 As shown, in some embodiments, the service arbitration system under the vehicle-mounted central computing architecture sets a service management module for each service, and each service management module includes a respective service arbitration unit and a service execution unit.

[0022] The service arbitration method under the vehicle-mounted central computing architecture provided in the embodiment of the present application can be used for the service arbitration system under the above vehicle-mounted service central computing architecture, running on the service hub end, specifically, as Figure 3 ,The service arbitration method under the vehicle central computing architecture includes: Step S101: Obtain a service request sent by a service requester.

[0023] For example, combining Figure 1 The service arbitration system uses the SOA interface or the SDV interface to obtain the service request sent by the service requester. There can be concurrent call requests for the same service. In a specific implementation, the service request may include the service requester flag and the requested service flag. The service management module in the service arbitration system can clearly identify which service requester sent the service request and whether the service to be called is the service corresponding to the service management module.

[0024] Step S102: Obtain the service request execution status.

[0025] Step S103: Determine the currently successfully arbitrated service request according to the service request execution status and the order in which the service requests are sent. There is only one currently successfully arbitrated service request.

[0026] Step S104: obtaining the currently successfully arbitrated service request as a to-be-executed service request and executing it.

[0027] In some embodiments, in combination Figure 1 and Figure 2 The service arbitration method provided in the embodiment also includes: setting a first container, the first container is used to store the service requests that are currently successfully arbitrated; setting a second container, the second container is used to store the service requests to be executed.

[0028] As an example, the first container and the second container may adopt a queue data structure. A queue is a first-in-first-out (FIFO) data structure. In C language, a queue can be implemented by an array and a pointer (or a structure), or by a linked list. In the embodiment, the queue lengths used by the first container and the second container in the embodiment of the present application are both 1 to ensure limited resource occupation of the system.

[0029] In other embodiments, the first container and the second container are not limited to the queue data format, and may also be stored in variables, stacks, etc., without limitation.

[0030] As an example, the service request execution status of the embodiment of the present application includes a first state and a second state, wherein the first state indicates that the service request is not executed (i.e., the service execution unit of the service management module is in a waiting state), and the second state indicates that the service request is being executed (i.e., the service execution unit of the service management module is in an active state); according to the service request execution status and the order in which the service requests are sent, the service request that is currently successfully arbitrated is determined, including: in the first state, the service request that is sent first is determined as the service request that is successfully arbitrated; in the second state, the service request that is most recently sent is determined as the service request that is successfully arbitrated.

[0031] In the present application, "first" refers to the front position in the time sequence, that is, the earliest occurrence in time, and "latest" refers to the back position in the time sequence, that is, the latest occurrence in time.

[0032] As an example, when a service request is not in the execution state, the service request that first arrives at the service arbitration unit enters the first container (such as the arbitration queue), that is, the service request that first arrives enters the arbitration queue as a service request that successfully arbitrates, which helps to ensure timely response of the service and continuity of processing.

[0033] In the example, when the service request is in the execution state, at this time, there are several service requests sent from different service requesters that enter the arbitration queue in order of arrival. Only the latest service request that enters the arbitration queue is saved in the arbitration queue as a service request that has been arbitrated successfully. The service arbitration unit can send an arbitration response to the corresponding service requester of other service requests that have not been successfully arbitrated (other service requests that are not successfully arbitrated) to inform that the existing service request is being executed. If a newer service request currently arrives at the service arbitration unit, the previously arbitrated service request that is at the end of the service arbitration queue is removed from the arbitration queue. The service arbitration unit informs the corresponding service requester through a response that the latest service request becomes the last arbitration-completed service request that enters the arbitration queue and will be executed as a pending service request. The tail value acquisition strategy adopted in this application means that only the latest service request will be retained, which helps to avoid wasting resources on outdated or no longer needed service requests, and can always keep attention and response to the latest service requests. This helps to reduce waiting time and improve overall processing efficiency.

[0034] Combination Figure 1 and Figure 4 For example, when the service is not in the execution state, i.e., the first state, the service request a1 sent by the service request method A1 arrives first, then the service request a1 is determined as the current successfully arbitrated service request and can be stored in the first container. The service request a1 is then moved out of the first container and can be directly sent to the second container to be executed by the service execution unit.

[0035] Then, when service request a1 is executed, i.e., in the second state, service request a2 sent by service requester A2 arrives, and service request a2 is taken as the service request currently arbitrated and moved into the first container, waiting for service request a1 in the service execution unit to be executed or a new service request to arrive; at this time, service request an sent by service requester An arrives, and service request a1 is not yet executed, so the newly arrived service request an is taken as the service request currently arbitrated and moved into the first container, and service request a2 is not successfully arbitrated, which means that service request a2 has not seized resources, so it is moved out of the first container. Service request an waits in the first container for service request a1 to be executed or a new service request to arrive.

[0036] In the embodiment, when the service execution unit executes the service request, it waits in a blocking manner until the service request is completed and returns the execution result to the service requester.

[0037] In a specific embodiment, the service arbitration unit can directly interact with the service execution unit in context. For example, the service arbitration unit accesses the size of the second container in the service execution unit to see if it is zero. If it is zero, it means that the service request has been executed; if it is not zero, it means that there are still service requests being executed. In some embodiments, after executing the service request, the service execution unit can also send status information to the service arbitration unit to feedback the current status of the service execution unit.

[0038] In some embodiments, the service request includes a priority identifier; the service arbitration method under the vehicle-mounted central computing architecture also includes: if the priority of the newly sent service request is less than or equal to the priority of the currently successfully arbitrated service request, the currently successfully arbitrated service request remains unchanged; if the priority of the newly sent service request is greater than the priority of the currently successfully arbitrated service request, the service request with the highest priority is used as the latest currently successfully arbitrated service request.

[0039] In some embodiments, a service request first determines its own priority when it is issued, and 0 can be used as the maximum value of the priority value. When a new service request arrives at the service gateway, the priority of the currently successfully arbitrated service request stored in the first container is compared with the new service request, and the service request with a higher priority will be retained in the first container and wait for the pending service request in the second container to be executed before being moved into the second container. For service requests with a lower priority, the corresponding service requester can be informed through a response that the service is being executed. The introduction of a priority identifier in the embodiment enables the system to process service requests with different importance. When the priority of the newly sent service request is higher, the system can dynamically adjust and give priority to these high-priority requests, thereby improving the response speed and flexibility of the system.

[0040] Corresponding to the above embodiments, the present application provides a service arbitration system under a vehicle-mounted central computing architecture, including at least one service management module, the service management module including a service arbitration unit and a service execution unit. The service arbitration unit is configured to obtain a service request sent by a service requester, obtain the service request execution status of a service execution unit, and determine the current successfully arbitrated service request according to the service request execution status and the order in which the service requests are sent. There is only one service request that has been successfully arbitrated. The service execution unit is configured to obtain the current successfully arbitrated service request as a pending service request and execute it.

[0041] As an example, the service request execution status includes a first state and a second state, wherein the first state indicates that the service request is not executed, and the second state indicates that the service request is being executed; the service arbitration unit is also configured to, in the first state, determine the first sent service request as the currently successfully arbitrated service request; and in the second state, determine the most recently sent service request as the currently successfully arbitrated service request.

[0042] An embodiment of the present application also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned service arbitration method under the vehicle-mounted central computing architecture.

[0043] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A service arbitration method under a vehicle-mounted central computing architecture, characterized in that: include: Obtain the service request sent by the service requester; Get the service request execution status; Determine the currently successfully arbitrated service request according to the execution status of the service request and the order in which the service requests are sent, where there is only one currently successfully arbitrated service request; The currently successfully arbitrated service request is obtained as a to-be-executed service request and executed.

2. The service arbitration method under the vehicle-mounted central computing architecture according to claim 1, characterized in that: The service request execution state includes a first state and a second state, wherein the first state indicates that the service request is not executed, and the second state indicates that the service request is being executed; Determining the service request that has been successfully arbitrated according to the execution status of the service request and the order in which the service requests are sent, including: In the first state, determining the service request sent first as the current successfully arbitrated service request; In the second state, the most recently sent service request is determined as the currently successfully arbitrated service request.

3. The service arbitration method under the vehicle-mounted central computing architecture according to claim 2, characterized in that: The service request includes a priority identifier; The service arbitration method further includes: If the priority of the newly sent service request is less than or equal to the priority of the currently successfully arbitrated service request, the currently successfully arbitrated service request remains unchanged; If the priority of the newly sent service request is greater than the priority of the currently successfully arbitrated service request, the service request with the highest priority is taken as the latest currently successfully arbitrated service request.

4. The service arbitration method under the vehicle-mounted central computing architecture according to claim 1, characterized in that: Setting a first container, where the first container is used to store the currently successfully arbitrated service request; A second container is set, where the second container is used to store the to-be-executed service request.

5. The service arbitration method under the vehicle-mounted central computing architecture according to claim 4, characterized in that: The first container and the second container both adopt a queue data structure.

6. The service arbitration method under the vehicle-mounted central computing architecture according to claim 1, characterized in that: The service arbitration method further includes: For other service requests that have not been successfully arbitrated, an arbitration response is sent to the corresponding service requester to inform that an existing service request is being executed.

7. A service arbitration system under a vehicle-mounted central computing architecture, characterized in that: It includes at least one service management module, each of which includes a service arbitration unit and a service execution unit; The service arbitration unit is configured to obtain a service request sent by a service requester, obtain a service request execution status of the service execution unit, and determine a currently successfully arbitrated service request according to the service request execution status and the order in which the service requests are sent, wherein there is only one currently successfully arbitrated service request; The service execution unit is configured to obtain the currently successfully arbitrated service request as a to-be-executed service request and execute it.

8. The service arbitration system under the vehicle-mounted central computing architecture according to claim 7, characterized in that: The service request execution state includes a first state and a second state, wherein the first state indicates that the service request is not executed, and the second state indicates that the service request is being executed; The service arbitration unit is further configured to, in the first state, determine the service request sent first as the current service request that has successfully been arbitrated; In the second state, the most recently sent service request is determined as the currently successfully arbitrated service request.

9. The service arbitration system under the vehicle-mounted central computing architecture according to claim 7, characterized in that: The service arbitration unit comprises a first container, wherein the first container is used to store the currently successfully arbitrated service request; The service execution unit includes a second container, and the second container is used to store the to-be-executed service request.

10. An electronic device, characterized in that: include: at least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the service arbitration method under the vehicle central computing architecture described in any one of claims 1 to 6.

Images