CN118540376A - SOA-based vehicle-end service call processing method, system, storage medium and vehicle - Google Patents

Abstract

The invention discloses a vehicle-end service call processing method based on an SOA architecture, which comprises the following steps: receiving a service call request for the method class service from a service requester, and obtaining request parameters in the service call request; obtain the action serial number corresponding to the request parameter) and the priority information corresponding to the action serial number, and store at least part of the request parameter, the action serial number and the priority information into the current call queue corresponding to the requested call service; carrying out arbitration processing on the service call request according to priority information corresponding to the action sequence number, and calling and executing the method service after the arbitration is passed; and deleting the information corresponding to the current action sequence number in the call queue after the execution is completed. The invention also discloses a corresponding system, a storage medium and a vehicle. By implementing the method and the device, the efficiency and the safety of remote procedure call can be improved, and the development and maintenance cost is reduced.

Description

A vehicle-side service call processing method, system, storage medium and vehicle based on SOA architecture

Technical Field

The present invention relates to the technical field of automobile service-oriented architecture (SOA), and in particular to a vehicle-side service call processing method, system, storage medium and vehicle based on SOA architecture.

Background Art

In smart cars, software is becoming more and more important. In recent years, service-oriented architecture (SOA) has been slowly introduced into the automotive field, and SOME/IP (Scalable service-oriented Middleware over IP) protocol has been increasingly used in vehicle Ethernet communications.

Among them, the automotive SOA architecture abstracts and decouples the functions and capabilities of the current traditional automotive electronic control system to form an independent logical unit - Service, and provides other modules with the service interface for calling. The service interface is defined in a neutral way, which is independent of the hardware platform, operating system and programming language that implements the service. This allows services built in various systems to interact in a unified and universal way.

SOME/IP is a service-oriented scalable protocol. As a user-controlled message automotive middleware, it realizes resource (information, function, etc.) sharing across platforms or operating systems through mechanisms such as serialization, remote procedure call (RPC), service discovery, publishing and subscription. Remote procedure call (RPC) is a communication protocol that allows a program running on one terminal to call a subroutine on another terminal without the need for programmers to program this interaction. As shown in Figure 1, a flow chart of using the remote procedure call (RPC) mechanism to perform service calls in an existing SOME/IP protocol is shown. During transmission, data must be transmitted in the form of a binary byte stream according to certain rules (serialization operation); as the data receiver, the binary data stream must also be parsed according to the agreed rules to obtain a data structure consistent with the sender, such as a structure, array, etc. This is a deserialization operation. In the service call request using SOME/IP, it is necessary to carry request parameter information such as service number (ServiceID), method number (MethodID), requester number (ClientID), session number (SessionID) and load (Payload).

However, there are some shortcomings in remote procedure calls in the automotive SOA architecture. Specifically, the method service provider cannot identify the service requester at the application layer, and the corresponding controlled load cannot distinguish the control source, so it is impossible to implement operations such as intra-group arbitration and control authority management.

In the current SOA distributed service architecture, when the client (service requester) remotely calls the specified service of the server (service provider) through protocols such as SOME/IP, some functions may be abnormal due to failure to identify the specific caller. The following example is used to illustrate, for example, in a typical functional scenario, it is assumed that the speaker (service provider) has two method classes (Method) services, StartHorn and StopHorn, and callers A and B are service requesters in the same group.

Among them, caller A calls StartHorn due to a warning reminder to turn on the horn, with an expected working cycle of 30s;

Caller B calls StartHorn due to a fault reminder to turn on the horn with an expected working cycle of 10s;

Caller B completes the expected function and calls StopHorn to turn off the horn.

Because callers A and B are call sources with the same priority, caller B turns off the horn that caller A has turned on at the same time when turning off the horn, causing the horn work sequence number of caller A to terminate abnormally. The action sequence diagram of this RPC application scenario is shown in Figure 2 below. In Figure 2, ON only represents the working state, not specifically the continuous horn state. The working state can also be the intermittent horn state according to the work template. The corresponding workflow of each participant is shown in Figure 3. Obviously, there are disputes that need to be arbitrated in this workflow.

To resolve the dispute, the following solutions are generally adopted:

First, in some examples, other modules or caller A monitors the operating status of the horn all the time, and when it detects that the horn is turned off, it calls StartHorn again to turn on the horn due to its own needs; or

Second, caller B determines whether the speaker can be turned off before calling StopHorn.

However, both existing solutions impose additional functional logic requirements on the caller, which is inconsistent with the loose coupling, flexibility and reusability of the SOA service architecture. At the same time, the uncertainty and anonymity of the caller result in extremely low development efficiency, great development difficulty and high maintenance cost.

Summary of the invention

The technical problem to be solved by the present invention is to provide a vehicle-side service call processing method, system, storage medium and vehicle based on SOA architecture, which can arbitrate when making remote procedure calls to avoid affecting the functions of other callers. It can effectively reduce the monitoring behavior and repeated calling behavior of the application layer, reduce the amount of code and communication data, and thus improve the efficiency and security of remote procedure calls.

In order to solve the above technical problems, as one aspect of the present invention, a vehicle-side service call processing method based on SOA architecture is provided, which is applied to the service provider and at least includes the following steps:

Receive a service call request for a method class (Method) service from a service requester, and obtain request parameters in the service call request;

Obtaining an action number (ActionID) corresponding to the request parameter and priority information corresponding to the action number, and storing at least part of the request parameter, the action number and the priority information in a current call queue corresponding to the requested service;

Arbitrate the service call request according to the priority information corresponding to the action sequence number, and after the arbitration is passed, call the method class service and execute it;

After the execution is completed, the service requester related information corresponding to the current action sequence number in the call queue is deleted.

The step of obtaining the action number (Action ID) corresponding to the request parameter and the priority information corresponding to the action number, and storing at least part of the request parameter, the action number and the priority information in the current call queue corresponding to the requested service further includes:

According to the request parameters, a pre-stored call source tracing list is searched to determine whether the requested method service needs to be included in the call source management, wherein the request parameters at least include: service ID, method ID, requester ID (ClientID), session ID (SessionID) and payload (Payload);

Generate or query the call source traceability list according to the request parameter mapping to obtain the action number corresponding to the current service call request and the priority information corresponding to the action number;

At least part of the request parameters, action sequence number and priority information are stored in the current call queue corresponding to the requested service through the adding interface.

The step of arbitrating the service call request according to the priority information corresponding to the action sequence number includes:

According to the action sequence number, it is checked whether there are other action sequences with the same name in the current call queue;

If it does not exist, the arbitration will be directly determined to be successful;

If so, the priority information of the current action number is compared with the priority information of other action numbers with the same name. When the priority of the current action number is the highest priority, it is determined that the arbitration is passed.

The step of arbitrating the service call request according to the priority information corresponding to the action sequence number further includes:

Determine whether there is a preceding action sequence of the current action number in the current call queue. If so, compare the priority information of the current action number with the priority information of the preceding action number in the current call queue. When the priority of the current action number is the highest priority, determine that the arbitration is passed.

Among them, the step of deleting the service requester related information corresponding to the current action sequence number in the call queue after the execution is completed specifically includes:

After the current method service is executed, the information corresponding to the current action number is deleted from the call queue, including: service number, method number, requester number, session number, current action number and priority information.

Wherein, after the execution is completed, the step of deleting the service requester related information corresponding to the current action sequence number in the call queue further includes:

After the current method service is executed, the information corresponding to the preceding action number of the current action number is deleted from the call queue, including: service number, method number, requester number, session number, preceding action number and priority information.

Among them, further include:

Preset the leading action sequence number for the action sequence numbers in the function items that appear in pairs;

When the vehicle is initialized, it queries and obtains the latest call source traceability list from the cloud and stores it. The call source traceability list contains multiple records, each of which contains a service number, method number, action number and priority information. The priority information includes priority and sub-priority values.

Accordingly, another aspect of the present invention provides a vehicle-side service call processing system based on SOA architecture, which at least includes:

A service call acquisition unit, used to receive a service call request for a method class (Method) service from a service requester, and obtain request parameters in the service call request;

A call queue establishment unit, used to obtain an action number (ActionID) corresponding to the request parameter and priority information corresponding to the action number, and store at least part of the request parameter, the action number and the priority information into a current call queue corresponding to the service requested to be called;

An arbitration processing unit, used for arbitrating the service call request according to the priority information corresponding to the action sequence number;

A service calling processing unit, used to call and execute the method service after the arbitration result of the arbitration processing unit is that the arbitration is passed;

The calling queue information deleting unit deletes the service requester related information corresponding to the current action sequence number in the calling queue after execution is completed.

Wherein, the calling queue establishing unit further comprises:

A call source determination unit, used to query a pre-stored call source tracing list according to the request parameters to determine whether the requested method service needs to be included in the call source management, wherein the request parameters at least include: service number (ServiceID), method number (MethodID), requester number (ClientID), session number (SessionID) and load (Payload);

An action sequence number information acquisition unit, used to obtain the action sequence number corresponding to the current service call request and the priority information corresponding to the action sequence number by generating or querying the call source tracing list according to the request parameter mapping;

The storage unit is used to store at least part of the request parameters, action sequence number and priority information into the current call queue corresponding to the requested service through the adding interface.

Wherein, the arbitration processing unit further includes:

A query unit, used for querying whether there are other action numbers with the same name in the current call queue according to the action number;

The current action sequence number arbitration processing unit is used to directly determine that the arbitration is passed if the query unit finds that the action sequence number does not exist; and if the query unit finds that the action sequence number exists, compare the priority information of the current action sequence number with the priority information of other action sequence numbers with the same name, and determine that the arbitration is passed when the priority of the current action sequence number is the highest priority;

The predecessor action sequence number arbitration processing unit is used to determine whether there is a predecessor action sequence of the current action sequence number in the current calling queue. If so, the priority information of the current action sequence number is compared with the priority information of the predecessor action sequence number in the current calling queue. When the priority of the current action sequence number is the highest priority, it is determined that the arbitration is passed.

The calling queue information deleting unit specifically includes:

The current action sequence number information deletion unit is used to delete the information corresponding to the current action sequence number in the call queue after the current method service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, current action sequence number and priority information;

The predecessor action sequence number information deletion unit is used to delete the information corresponding to the predecessor action sequence number of the current action sequence number in the call queue after the current method type service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, predecessor action sequence number and priority information.

Among them, further include:

An action number association setting unit, used to pre-set a leading action number for the action numbers in the function items that appear in pairs;

The call source traceability list update unit is used to query and obtain the latest call source traceability list from the cloud and store it when the vehicle is initialized. The call source traceability list contains multiple records, each record contains a service number, a method number, an action number and priority information, and the priority information includes priority and sub-priority values.

Correspondingly, another aspect of the present invention further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the aforementioned method when executed by a processor.

Correspondingly, another aspect of the present invention further provides a vehicle, which is provided with a service provider and a service requester of a vehicle-side service, and the service provider and the service requester implement remote procedure calls through the SOME/IP protocol, and the aforementioned vehicle-side service call processing system based on the SOA architecture is integrated in the SOME/IP middleware.

The implementation of the embodiments of the present invention has the following beneficial effects:

The embodiment of the present invention provides a vehicle-side service call processing method, system, storage medium and vehicle based on SOA architecture. By adding a call source management function to the RPC call process in the current SOME/IP protocol, a queue management mechanism is established, and the history of method service calls can be traced by using the current call queue; and an action sequence number is generated according to specific call parameters, and arbitration is performed for the current remote procedure call according to the priority information corresponding to the action sequence number.

By implementing the present invention, by establishing a queue management mechanism within the service and a dynamic ID (action sequence number) between service callers and providers, on the one hand, all valid callers of the current function can be dynamically monitored, and on the other hand, function arbitration can be implemented for specific callers to avoid affecting the functions of other callers. It can effectively reduce the monitoring behavior and repeated calling behavior at the application layer, reduce the amount of code and communication data, and improve the bad experience caused by function switching, thereby improving the efficiency and security of remote procedure calls; at the same time, it can reduce the cost of developing and maintaining the automotive SOA service architecture.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, without paying creative labor, other drawings obtained based on these drawings still belong to the scope of the present invention.

FIG1 is a schematic diagram of an overall application environment for using the RPC mechanism to perform service calls in an existing SOME/IP protocol;

FIG2 is an action sequence diagram of an existing RPC application scenario;

FIG3 is a schematic diagram of the workflow of each participant in FIG2 ;

FIG4 is a schematic diagram of the main process of an embodiment of a vehicle-side service call processing method based on SOA architecture provided by the present invention;

5 is a schematic diagram of the overall application environment of the present invention using the RPC mechanism for service invocation;

FIG6 is a functional schematic diagram of a call source management module involved in the present invention;

FIG7 is an action sequence diagram of an RPC application scenario according to the present invention;

FIG8 is a schematic diagram of the workflow of each participant in FIG7;

FIG9 is a schematic structural diagram of an embodiment of a vehicle-side service call processing system based on SOA architecture provided by the present invention;

FIG10 is a schematic diagram of the structure of the call queue establishment unit in FIG9;

FIG11 is a schematic diagram of the structure of the arbitration processing unit in FIG9;

FIG. 12 is a schematic diagram of the structure of the call queue information deletion unit in FIG. 9 .

DETAILED DESCRIPTION

In order to make the objectives, technical solutions and advantages of the present invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings.

As shown in FIG4, a schematic diagram of the main process of an embodiment of a vehicle-side service call processing method based on SOA architecture provided by the present invention is shown; in combination with FIG5 to FIG6, in this embodiment, the method is applied to the service provider side, specifically, it can be implemented by using a call source management module (SourcingManager) deployed as shown in FIG5. As can be seen from FIG6, the call source management module can implement functions such as listening (Listen), filtering (Filter), adding (Add), querying (Query), deleting (Delete) and data management (DataMgr). More specifically, the method provided by the present invention includes at least the following steps:

Step S10, receiving a service call request for a method class (Method) service from a service requester, and obtaining request parameters in the service call request; the request parameters at least include: a service serial number (ServiceID), a method serial number (MethodID), a requester serial number (ClientID), a session serial number (SessionID) and a payload (Payload), wherein the payload includes specific call input parameters of the method class request;

The service call request may be, for example, a start request (StartRequest) or a stop request (StopRequest).

Step S11, obtaining the action number (ActionID) corresponding to the request parameter and the priority information corresponding to the action number, and storing at least part of the request parameter, the action number and the priority information into the current call queue corresponding to the requested service;

More specifically, the step S11 further includes:

Step S110, querying a pre-stored call source tracing list according to the request parameters to determine whether the requested method service needs to be included in the call source management; for example, in some embodiments, it can be marked in the call source tracing list;

It is understandable that a call source tracing list needs to be pre-stored on the vehicle side. The call source tracing list includes multiple records, each of which contains a service number, a method number, an action number, and priority information (priority and sub-priority). The priority information includes priority and sub-priority values. As shown in Table 1 below, it is an example table of a call source tracing list;

Table 1. Example table of call source traceability list

In actual examples, an initial call source traceability list is provided when the vehicle leaves the factory; during the vehicle's life cycle, if the call source traceability list needs to be updated due to new services or scenarios, the list will be updated to the cloud. The main information contained in the list is the same as the example information in the above table; therefore, when the vehicle is initialized (when the vehicle is powered on), it is necessary to query the cloud to see if there is an update to the list, and then download the latest call source traceability list from the cloud and store it.

In the actual example, after monitoring the relevant call information parameters, the call source management module queries the call source traceability list through the command SourcingManager.Filter(ServiceID,MethodID) to determine whether the method class service of the request needs to be included in the call source management;

At the same time, it is necessary to set the pre-action sequence number for the action sequence number in the function items that appear in pairs in advance. For the function items that appear in pairs (such as Start/Stop, TurnOn/TurnOff, etc.), if you need to limit the specific call source when executing Stop, TurnOff, etc. (for example, the caller can only close the components that he opened), you need to specify its pre-action sequence number (pre-ActionID) in advance. The following Table 2 shows the corresponding relationship table between each action sequence number and its pre-action sequence number.

Table 2 Correspondence between action numbers and their preceding action numbers

Prepend ActionID ActionID ACT_HORN_START ACT_HORN_Stop ACT_FLFLASHER_START ACT_FLFLASHER_Stop

Step S111, generating or querying the call source tracing list according to the request parameter mapping to obtain the action number corresponding to the current service call request and the priority information corresponding to the action number;

It can be understood that, in some examples, the call source management module can obtain relevant method class service request parameters according to the requested method serial number (MethodID) and the corresponding load (Payload), and generate the action serial number (ActionID) and the corresponding priority information (PriorityLevel, SubPriorityLevel) according to pre-defined rules;

In another example, the action number corresponding to the current service call request and the priority information corresponding to the action number may also be obtained by querying the call source tracing list according to the request parameter mapping.

The corresponding relationship between the request parameters and the action sequence numbers may be shown in the following table 3:

Table 3. Correspondence between request parameters and action numbers

ServiceID MethodID Parameter 1 Parameter 2 Parameter n… AcitonID 0x0001 0x0123 xxx xxx xxx ACT_HORN_START 0x0002 0x0123 xxx xxx xxx ACT_FLFLASHER_START 0x0001 0x0155 xxx xxx xxx ACT_003 0x0002 0x0155 xxx xxx xxx ACT_004 … … … … … …

Step S112: Store at least part of the request parameters, action sequence number and priority information into the current call queue corresponding to the requested service through the adding interface.

The service provider calls the source management module to call SourcingManager.Add to add the caller related information in the interface. Specifically, at least part of the request parameters, action sequence number and priority information are stored in the current call queue corresponding to the requested service through the add interface. Table 4 below is a call queue diagram:

Table 4. Current call queue diagram

Step S12, arbitrating the service call request according to the priority information corresponding to the action sequence number, and after the arbitration is passed, calling the method service and executing it;

In a specific example, only the actions performed may be arbitrated, including:

Use SourcingManager.Query(ActionID) to query whether there are other action numbers with the same name in the current call queue according to the action number;

If it does not exist, the arbitration will be directly determined to be successful;

If it exists, the priority information of the current action number is compared with the priority information of other action numbers with the same name. When the priority of the current action number is the highest priority, it is determined that the arbitration is passed, the arbitration right is obtained, and the method class service is allowed to be called and executed. Otherwise, an indication of call failure is returned, where the failure reason is arbitration failure.

In another specific example, arbitration may be performed on the sequence number of the preceding action of the currently executed action.

For example, if ACT_HORN_STOP is executed this time, arbitration is more concerned with whether the preceding action ACT_HORN_START is for which the caller has arbitration rights. Specifically:

Use SourcingManager.Query(prefixActionID) to check whether the prefixAcitonID exists in the current call queue;

If it does not exist, the arbitration will be directly determined to be successful;

If it exists, the priority information of the current action number is compared with the priority information of the previous action number in the current call queue. When the priority of the current action number is the highest priority, the arbitration is determined to be passed; otherwise, the call fails and the reason for the failure is arbitration failure.

Step S13, after the execution is completed, delete the service requester related information corresponding to the current action sequence number in the call queue.

In a specific example, the executed ActionID information needs to be deleted. The step S13 further includes:

After the execution of the current method class service is completed, the service provider deletes the caller-related information in the interface of the calling source management module (SourcingManager); specifically, the information corresponding to the current action sequence number is deleted, that is, the information related to the action sequence number executed by the requester sequence number and the session sequence number is deleted, including: service sequence number (ServiceID), method sequence number (MethodID), requester sequence number (ClientID), session sequence number (SessionID), current action sequence number (ActionID) and priority information (PriorityLevel, SubPriorityLevel).

In another specific example, it is necessary to delete the preceding ActionID information of the executed actions individually or collectively, and the step S13 further includes:

Call SourcingManager.Delete to delete the information related to the sequence of preceding actions executed by the requester number (ClientID) and session number (SessionID), including: service number (ServiceID), method number (MethodID), requester number (ClientID), session number (SessionID), preceding action number (preceding ActionID) and priority information (PriorityLevel, SubPriorityLevel).

5 and 6 , the method provided by the present invention mainly applies the call source management link shown in FIG. 5 , and at the same time utilizes the relevant interface provided by the call source management module (SourcingManager) to perform query and other application tasks on demand in the implementation link.

It can be understood that the system of the present invention forms a call source tracing list dynamically by adding a call source management module in the middleware service proxy related components, marking the ServiceID, MethodID, ClientID, SessionID, ActionID, and priority related information of the service call when the service is called. When the related service is called later, the call source of the currently executed action can be identified by querying the list, and call arbitration based on SessionID, ClientID or ActionID can be realized by comparing the ActionID priority in the list;

More specifically, by storing and managing the caller information (ClientID) of the service when the service user calls the service, the call queue information of the service is provided, so that the execution module can query all existing callers of the service when needed, and at the same time provide a queue member deletion function so that the execution module can release the caller information after completing the required function.

After completing the current caller's work instruction, the implementation execution module implements the interrupt recovery operation and more detailed permission management for specific callers according to the queue information provided by the call source management module. As shown in Figures 7 and 8, Figure 7 is an action timing diagram of an RPC application scenario (speaker control) of the present invention, and Figure 8 is a schematic diagram of the workflow of each participant in Figure 7; By performing queue query and priority comparison measures, disputes and conflicts in Figure 3 can be avoided.

As shown in FIG9 , a schematic diagram of the structure of an embodiment of a vehicle-side service call processing system based on SOA architecture provided by the present invention is shown. Combined with FIGS. 10 to 12 , in this embodiment, the system 1 is integrated into the SOME/IP middleware between the service provider and the service requester, which at least includes:

The service call acquisition unit 10 is used to receive a service call request for a method class (Method) service from a service requester, and obtain request parameters in the service call request; the request parameters at least include: a service serial number (ServiceID), a method serial number (MethodID), a requester serial number (ClientID), a session serial number (SessionID) and a load (Payload);

A call queue establishment unit 11 is used to obtain an action number (ActionID) corresponding to the request parameter and priority information corresponding to the action number, and store at least part of the request parameter, the action number and the priority information into a current call queue corresponding to the requested service;

The arbitration processing unit 12 is used to perform arbitration processing on the service call request according to the priority information corresponding to the action sequence number;

A service calling processing unit 13, configured to call and execute the method service after the arbitration result of the arbitration processing unit is that the arbitration is passed;

A call queue information deleting unit 14, after execution is completed, deletes the service requester related information corresponding to the current action sequence number in the call queue;

An action number association setting unit 16, used to pre-set a leading action number for the action numbers in the function items that appear in pairs;

The call source traceability list update unit 15 is used to query and obtain the latest call source traceability list from the cloud and store it when the vehicle is initialized. The call source traceability list contains multiple records, each record contains a service number, a method number, an action number and priority information, and the priority information includes priority and sub-priority values.

As shown in FIG10 , the calling queue establishing unit 11 further includes:

The call source determination unit 110 is used to query the pre-stored call source tracing list according to the request parameters to determine whether the requested method service needs to be included in the call source management;

The action sequence number information acquisition unit 111 is used to obtain the action sequence number corresponding to the current service call request and the priority information corresponding to the action sequence number by generating or querying the call source traceability list according to the request parameter mapping;

The storage unit 112 is used to store at least part of the request parameters, action sequence number and priority information into the current call queue corresponding to the requested service through the adding interface.

As shown in FIG11 , the arbitration processing unit 12 further includes:

A query unit 120, configured to query whether there are other action numbers with the same name in the current call queue according to the action number;

The current action sequence number arbitration processing unit 121 is used to directly determine that the arbitration is passed if the query unit finds that the action sequence number does not exist; and if the query unit finds that the action sequence number exists, compare the priority information of the current action sequence number with the priority information of other action sequence numbers with the same name, and determine that the arbitration is passed when the priority of the current action sequence number is the highest priority;

The predecessor action sequence number arbitration processing unit 122 is used to determine whether there is a predecessor action sequence of the current action sequence number in the current calling queue. If so, the priority information of the current action sequence number is compared with the priority information of the predecessor action sequence number in the current calling queue. When the priority of the current action sequence number is the highest priority, it is determined that the arbitration is passed.

As shown in FIG. 12 , the calling queue information deleting unit 13 specifically includes:

The current action sequence number information deleting unit 130 is used to delete the information corresponding to the current action sequence number in the call queue after the current method service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, current action sequence number and priority information;

The predecessor action sequence number information deletion unit 131 is used to delete the information corresponding to the predecessor action sequence number of the current action sequence number in the call queue after the current method type service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, predecessor action sequence number and priority information.

For more details, please refer to and combine the methods described in Figures 4 to 8 above, which will not be described in detail here.

Accordingly, another aspect of the present invention further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the method described in the aforementioned Figures 4 to 8 are implemented. For more details, reference can be made to and in combination with the aforementioned method described in Figures 4 to 8, which will not be described in detail here.

Correspondingly, another aspect of the present invention further provides a vehicle, which is provided with a service provider and a service requester of a vehicle-side service, wherein the service provider and the service requester implement remote procedure calls through the SOME/IP protocol, and the vehicle-side service call processing system based on the SOA architecture described in the above-mentioned Figures 9 to 12 is integrated in the SOME/IP middleware. For more details, please refer to and combine the above-mentioned contents described in Figures 9 to 12, which will not be repeated here.

The implementation of the embodiments of the present invention has the following beneficial effects:

The embodiment of the present invention provides a vehicle-side service call processing method, system, storage medium and vehicle based on SOA architecture. By adding a call source management function to the RPC call process in the current SOME/IP protocol, a queue management mechanism is established, and the history of method service calls can be traced by using the current call queue; and an action sequence number is generated according to specific call parameters, and arbitration is performed for the current remote procedure call according to the priority information corresponding to the action sequence number.

By implementing the present invention, by establishing a queue management mechanism within the service and a dynamic ID (action sequence number) between service callers and providers, on the one hand, all valid callers of the current function can be dynamically monitored, and on the other hand, function arbitration can be implemented for specific callers to avoid affecting the functions of other callers. It can effectively reduce the monitoring behavior and repeated calling behavior at the application layer, reduce the amount of code and communication data, and improve the bad experience caused by function switching, thereby improving the efficiency and security of remote procedure calls; at the same time, it can reduce the cost of developing and maintaining the automotive SOA service architecture.

It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, devices, 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.

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.

The above disclosure is only a preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the claims of the present invention are still within the scope of the present invention.

Claims (15)

1. A vehicle-side service call processing method based on SOA architecture, characterized in that it comprises at least the following steps: Receive a service call request for a method class (Method) service from a service requester, and obtain request parameters in the service call request; Obtaining an action number (ActionID) corresponding to the request parameter and priority information corresponding to the action number, and storing at least part of the request parameter, the action number and the priority information in a current call queue corresponding to the requested service; Arbitrate the service call request according to the priority information corresponding to the action sequence number, and after the arbitration is passed, call the method class service and execute it; After the execution is completed, the service requester related information corresponding to the current action sequence number in the call queue is deleted. 2. The method according to claim 1, wherein the step of obtaining an action number (Action ID) corresponding to the request parameter and priority information corresponding to the action number, and storing at least part of the request parameter, the action number and the priority information in a current call queue corresponding to the requested service further comprises: According to the request parameters, a pre-stored call source tracing list is searched to determine whether the requested method service needs to be included in the call source management, wherein the request parameters at least include: service ID, method ID, requester ID (ClientID), session ID (SessionID) and payload (Payload); Generate or query the call source traceability list according to the request parameter mapping to obtain the action number corresponding to the current service call request and the priority information corresponding to the action number; At least part of the request parameters, action sequence number and priority information are stored in the current call queue corresponding to the requested service through the adding interface. 3. The method according to claim 2, wherein the step of arbitrating the service call request according to the priority information corresponding to the action sequence number comprises: According to the action sequence number, it is checked whether there are other action sequences with the same name in the current call queue; If it does not exist, the arbitration will be directly determined to be successful; If so, the priority information of the current action number is compared with the priority information of other action numbers with the same name. When the priority of the current action number is the highest priority, it is determined that the arbitration is passed. 4. The method according to claim 3, wherein the step of arbitrating the service call request according to the priority information corresponding to the action sequence number further comprises: Determine whether there is a preceding action sequence of the current action number in the current call queue. If so, compare the priority information of the current action number with the priority information of the preceding action number in the current call queue. When the priority of the current action number is the highest priority, determine that the arbitration is passed. 5. The method according to claim 4, wherein after the execution is completed, the step of deleting the service requester related information corresponding to the current action sequence number in the call queue specifically comprises: After the current method service is executed, the information corresponding to the current action number is deleted from the call queue, including: service number, method number, requester number, session number, current action number and priority information. 6. The method according to claim 4, wherein after the execution is completed, the step of deleting the service requester related information corresponding to the current action sequence number in the call queue further comprises: After the current method service is executed, the information corresponding to the preceding action number of the current action number is deleted from the call queue, including: service number, method number, requester number, session number, preceding action number and priority information. 7. The method according to any one of claims 1 to 6, further comprising: Preset the leading action number for the action numbers in the function items that appear in pairs. 8. The method according to any one of claims 1 to 6, further comprising: When the vehicle is initialized, it queries and obtains the latest call source traceability list from the cloud and stores it. The call source traceability list contains multiple records, each of which contains a service number, method number, action number and priority information. The priority information includes priority and sub-priority values. 9. A vehicle-side service call processing system based on SOA architecture, characterized by at least comprising: A service call acquisition unit, used to receive a service call request for a method class (Method) service from a service requester, and obtain request parameters in the service call request; A call queue establishment unit, used to obtain an action number (ActionID) corresponding to the request parameter and priority information corresponding to the action number, and store at least part of the request parameter, the action number and the priority information into a current call queue corresponding to the service requested to be called; An arbitration processing unit, used for arbitrating the service call request according to the priority information corresponding to the action sequence number; A service calling processing unit, used to call and execute the method service after the arbitration result of the arbitration processing unit is that the arbitration is passed; The calling queue information deleting unit deletes the service requester related information corresponding to the current action sequence number in the calling queue after execution is completed. 10. The system according to claim 9, wherein the call queue establishment unit further comprises: A call source determination unit, used to query a pre-stored call source tracing list according to the request parameters to determine whether the requested method service needs to be included in the call source management, wherein the request parameters at least include: service number (ServiceID), method number (MethodID), requester number (ClientID), session number (SessionID) and load (Payload); An action sequence number information acquisition unit, used to obtain the action sequence number corresponding to the current service call request and the priority information corresponding to the action sequence number by generating or querying the call source tracing list according to the request parameter mapping; The storage unit is used to store at least part of the request parameters, action sequence number and priority information into the current call queue corresponding to the requested service through the adding interface. 11. The system according to claim 10, wherein the arbitration processing unit further comprises: A query unit, used for querying whether there are other action numbers with the same name in the current call queue according to the action number; The current action sequence number arbitration processing unit is used to directly determine that the arbitration is passed if the query unit finds that the action sequence number does not exist; and if the query unit finds that the action sequence number exists, compare the priority information of the current action sequence number with the priority information of other action sequence numbers with the same name, and determine that the arbitration is passed when the priority of the current action sequence number is the highest priority; The predecessor action sequence number arbitration processing unit is used to determine whether there is a predecessor action sequence of the current action sequence number in the current calling queue. If so, the priority information of the current action sequence number is compared with the priority information of the predecessor action sequence number in the current calling queue. When the priority of the current action sequence number is the highest priority, it is determined that the arbitration is passed. 12. The system according to claim 11, wherein the call queue information deletion unit specifically comprises: The current action sequence number information deletion unit is used to delete the information corresponding to the current action sequence number in the call queue after the current method service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, current action sequence number and priority information; The predecessor action sequence number information deletion unit is used to delete the information corresponding to the predecessor action sequence number of the current action sequence number in the call queue after the current method type service is executed, including: service sequence number, method sequence number, requester sequence number, session sequence number, predecessor action sequence number and priority information. 13. The system according to any one of claims 9 to 12, further comprising: An action number association setting unit, used to pre-set a leading action number for the action numbers in the function items that appear in pairs; The call source traceability list update unit is used to query and obtain the latest call source traceability list from the cloud and store it when the vehicle is initialized. The call source traceability list contains multiple records, each record contains a service number, a method number, an action number and priority information, and the priority information includes priority and sub-priority values. 14. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented. 15. A vehicle, characterized in that it is provided with a service provider and a service requester of a vehicle-side service, and remote procedure calls are implemented between the service provider and the service requester via the SOME/IP protocol, wherein at one place, a vehicle-side service call processing system based on the SOA architecture as described in any one of claims 9 to 13 is integrated in the SOME/IP middleware.