Ethernet-based in-vehicle service priority arbitration system, and device and medium

Abstract

Disclosed in the present invention are an Ethernet-based in-vehicle service priority arbitration system, and a device and a medium. The system comprises: a scene orchestration module, an intelligent scene engine used as a Client, and Servers providing services. The scene orchestration module is configured to newly establish a scene, generate the ID of the scene, and set, according to requirements, the priority of the scene and a time of occupying each service. The intelligent scene engine is configured to call the services of the Servers when the scene is triggered, and add a service occupation request interface in each service needing to be arbitrated. The intelligent scene engine sends the following parameters at the service occupation request interface: the ID of the scene, the priority of the scene, the time of occupying the service, and an occupation or release request. Each Server is configured to, when receiving the service occupation request of the Client and on the basis of an arbitration method and the state of the Server, determine whether the service is allowed to be occupied, and return a service occupation request feedback at the service occupation request interface.

Description

An Ethernet-based vehicle service priority arbitration system, device and medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The embodiments of this application are based on the Chinese patent application with application number 202311674981.3 and application date December 6, 2023, and claim the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into the embodiments of this application as a reference. Technical Field

[0003] The present invention belongs to the technical field of in-vehicle Ethernet communication, and in particular relates to an Ethernet-based in-vehicle service priority arbitration system, equipment and medium. Background Art

[0004] Some vehicle functions that do not involve vehicle safety and driving, such as body and entertainment domain functions: window opening / closing control, seat front and rear adjustment, massage, music settings, etc., can be made public to users for scene settings to meet the user's personal wishes.

[0005] In automotive Ethernet communications, these services, or functions, are invoked through SOA (Service-Oriented Architecture) services. In a service-oriented (SOA) architecture, a certain degree of decoupling is required between business scenarios. However, the addition and modification of scenarios are both unpredictable and continuous, leading to increased coupling between business scenarios. This significantly increases the overlap of actuators invoked by multiple scenarios. This means that when two or more scenarios are triggered simultaneously, control requests may be made to the same actuator through SOA service calls, resulting in conflicts. Therefore, a scalable and flexible arbitration strategy must be designed to resolve conflicts arising from concurrent service invocations.

[0006] SOA is implemented using the Ethernet-based SOME / IP protocol. The SOME / IP protocol is a service-oriented communication mechanism. SOME / IP defines three types of service interfaces: Method, Event, and Field. Multiple service interfaces can be combined within a single service.

[0007] Method: There are two types of method calls: RR Method (RR stands for Request / Response, meaning both a request and a response) and FF Method (Request without a response). With the RR Method, the client transmits data to the server via the input parameter (Request) of the service interface function. After receiving the data, the server executes the function and then transmits the data back to the client via the output parameter (Response) of the service interface function. With the FF Method, the client transmits data to the server via the input parameter of the service interface function. After receiving the data, the server executes the function and does not send any feedback for the request.

[0008] Event: Event sending. After an event agreed upon by the server and the client is triggered, the server transmits it to the client through the parameters of the service interface, or without parameters, only used to notify the other party to execute a certain function.

[0009] Field: A combination of a method and an event. It performs a set of operations on the same data, such as setting and reading the air conditioner temperature and providing notification when the temperature changes. It includes three methods: Field_Getter, Field_Setter, and Field_Notifier. Read the air conditioner temperature via Field_Getter; set and write the air conditioner temperature via Field_Setter; and subscribe to the air conditioner temperature via Field_Notifier to receive notifications when it changes. Field_Getter and Field_Setter use the RR Method mechanism, while Field_Notifier uses the Event mechanism. The difference between Field_Notifier and Event is that after a client successfully subscribes to the service, the server immediately sends data, whereas Event does not.

[0010] Client: The consumer side. When calling a service through the SOA method, the party calling the service is the consumer side.

[0011] Server: When calling a service through the SOA method, the party providing the service is the server.

[0012] Summary of the Invention

[0013] The purpose of the present invention is to provide an Ethernet-based vehicle service priority arbitration system, device and medium to solve the problem of service conflict when two or more scenarios are triggered simultaneously.

[0014] The technical solutions adopted in the present invention are as follows:

[0015] An Ethernet-based vehicle service priority arbitration system, applied to vehicle electronic equipment, includes a scene arrangement module, an intelligent scene engine as a client, and a server that provides various services:

[0016] The scenario orchestration module is used to create new scenarios and generate scenario IDs, as well as set the scenario priority and the time it occupies each service according to needs;

[0017] The intelligent scene engine is used to call various server-side services after the scene is triggered. It also adds an occupation service request interface to each service that requires arbitration. The intelligent scene engine sends the following parameters to the occupation service request interface: scene ID, priority, occupation time of each service, and occupation or release request;

[0018] The server is used to determine whether to allow occupation based on the arbitration method and its own status after receiving the occupation service request from the client, and return occupation service request feedback in the occupation service request interface.

[0019] As a second aspect, the present invention also provides an electronic device, which includes: a shell, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is placed inside the space enclosed by the shell, and the processor and the memory are arranged on the circuit board; the power supply circuit is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory is used to store executable program code; the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, and is used to execute the task steps performed by the Ethernet-based vehicle service priority arbitration system described in any one of the above.

[0020] As a third aspect, the present invention also provides a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the task steps performed by the Ethernet-based vehicle service priority arbitration system described in any one of the above.

[0021] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0022] The present invention enables users to set priorities and usage times when arranging scenarios, meeting the diverse needs of users, flexibly configuring the priority of each service under multi-scenario triggering and the time it occupies, and effectively avoiding service conflicts. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a block diagram of an Ethernet-based vehicle service priority arbitration system;

[0024] Figure 2 is a schematic diagram of the process of incomplete parameters of the client and server side occupying the request and failure response;

[0025] Figure 3 is a schematic diagram of the process of client-side and server-side occupation request and positive response;

[0026] FIG4 is a schematic diagram of the response process when an occupation request is sent in a scenario with a low or equal priority;

[0027] FIG5 is a schematic diagram of the response process when an occupation request is sent by a high-priority scenario;

[0028] FIG6 is a schematic diagram of a request call for continued occupation. DETAILED DESCRIPTION

[0029] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only intended to illustrate the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0030] This invention discloses an Ethernet-based service arbitration strategy for in-vehicle Ethernet communications. By designing a scalable and flexible arbitration strategy, it avoids conflicts caused by the simultaneous invocation of the same actuator by multiple scenarios. This invention enables users to set priorities and usage times when arranging scenarios, meeting the diverse needs of individual users. It allows for flexible configuration of the priorities and usage times of various services triggered by multiple scenarios, effectively avoiding conflicts.

[0031] Figure 1 is a system block diagram of the service arbitration implementation. As shown in Figure 1, the intelligent scene engine calls the services of each server side, adopts the SOA method, and transmits data based on the SOME / IP protocol, passing through the Ethernet physical layer, data link layer, network layer, transport layer of each ECU, and then to the application layer.

[0032] In some embodiments, the application layer on the server side is composed of a service module, an arbitration module and an upper-layer application module.

[0033] Service module: Receives and processes ECU's SOME / IP messages through the service interface ServiceInterface.

[0034] Arbitration module: The arbitration module needs to implement an arbitration algorithm. After the SOME / IP message is received by the service module, the arbitration module performs algorithm calculations and outputs the final processing result.

[0035] The upper-layer application module performs algorithmic calculations based on the arbitration module, outputs the final processing results, and performs the corresponding execution operations. Specifically, if the call is successful, a success message is returned via a SOME / IP message, and the actuator is controlled. If the call fails, a failure message and the current status are returned via a SOME / IP message, and the actuator is not controlled.

[0036] For example, when the user is arranging a scene, a new scene is created and the scene ID is automatically generated. The user sets the priority of the scene and the time to occupy each service according to their own needs. As the client, the intelligent scene engine calls the services of each server after the scene is triggered, and adds a separate occupation service interface (RR Method type) to each service that needs arbitration. The client needs to send the following parameters to this interface: scene ID, priority, service occupation time, occupation / release request. After receiving the occupation request from the client, the server should determine whether it is allowed to be occupied based on the arbitration method and its own status, and return the occupation result in the occupation service request interface.

[0037] In other embodiments, a separate occupancy service notification interface (Event type) is added to each service that requires arbitration. The event triggering condition is that when the client triggers an occupancy service request and the server replies that occupancy is not allowed, the server calls the occupancy service notification interface to notify the client of the following parameters: the occupancy status of the current service, the ID of the occupied scene, the occupancy time, and other information.

[0038] In this embodiment, the arbitration algorithm is as follows:

[0039] (1) After a scenario is triggered, when the client needs to occupy a service, it needs to declare the scenario ID, priority, time to occupy the service, and occupation or release request in the service interface when calling the service interface; the first one to be released can then initiate another occupation request;

[0040] (2) If the same service is called concurrently in scenarios with the same priority, a first-come, first-served policy is adopted;

[0041] (3) If different priority scenarios call the same service in parallel, the higher priority scenario interrupts the lower priority scenario, but the lower priority scenario cannot interrupt the higher priority scenario.

[0042] (4) If a scene is occupying a service and wants to continue to occupy the service, the heartbeat mechanism is used: within the specific occupation time, the second occupation request is sent, and so on, to achieve continuous occupation; during the occupation process, if other scenes send occupation requests, the strategies of (2) and (3) are followed;

[0043] (5) When the server receives a release request from the client before the service time expires or after the service time expires, it releases the resources for other clients to call.

[0044] The arbitration module implements all of the aforementioned service arbitration algorithms, resource occupation requests and releases, and heartbeat mechanisms. Keyword conventions are used (for example, the occupation service interface ID is fixed at 0xA0A0). When a service interface ID contains a keyword, the arbitration module automatically recognizes it and initiates the arbitration algorithm. A service can be composed of multiple service interfaces. Service interfaces can be composed of methods (RR method / FF method), events, and fields (Field_Getter, Field_Setter, Field_Notifier). Each service has a unique service ID, which includes multiple vehicle-specific service interface IDs.

[0045] For example, the window service has a service ID of 0x0101, which includes four window-specific service interfaces 0x0001 to 0x0004, one occupied service request interface 0xA0A0, and one occupied service notification interface 0xB0B0, as shown in Table 1.

[0046] Table 1 Window service list

[0047] Specifically, the algorithm and execution results are as follows:

[0048] Add an independent occupancy service request interface to each service that needs arbitration (as shown in Table 1, OccupySrvRR, service interface ID is: 0xA0A0):

[0049] The expression is:

[0050] Occupancy service request interface name (occupancy service request parameters, occupancy service request feedback parameters)

[0051] That is OccupySrvRR(OccupySrvRR_Req, OccupySrvRR_Resp)

[0052] The occupancy service request parameter OccupySrvRR_Req specifically includes the following four parameters, and the parameter definitions are shown in Table 2.

[0053] Table 2 Definition of Occupy Service Request Parameters OccupySrvRR_Req

[0054] In this embodiment, the priority of the scene is 0 to 7, 7 is the highest priority, and 0 is the lowest priority. If the user does not set this option, the default is 0. If the user defaults to 0 when creating a new scene, the last-in-first-out triggering is used.

[0055] In some embodiments, the occupancy service request feedback parameter OccupySrvRR_Resp specifically includes the following parameter OccupyResp, and the parameter definition is shown in Table 3.

[0056] Table 3 Definition of occupancy service request feedback parameter OccupySrvRR_Resp

[0057] In some embodiments, an independent occupancy service notification interface is added to each service that requires arbitration (as shown in Table 1, OccupySrvEvent, service interface ID: 0xB0B0):

[0058] The expression is: Occupancy service notification interface name (notification parameter)

[0059] That is OccupySrvEvent(OccupySrvSts)

[0060] As shown in Table 4, the occupied service notification parameter OccupySrvSts specifically includes the following four parameters.

[0061] Table 4 Definition of Occupancy Service Notification Parameter OccupySts

[0062] Example 1

[0063] As shown in Figure 2, when the client in scenario 1 makes a service request, it should first send an occupancy service request through the occupancy service request interface OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp). The arbitration module automatically identifies and activates the arbitration method based on the keyword (the agreed keyword is the interface ID: 0xA0A0, 0xB0B0).

[0064] Example 2

[0065] When the client scene 1 makes a service request, it calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp), and assigns the input parameter OccupySrvRR_Req, which includes the following parameters: the ID of scene 1 (SceneID), priority (ScenePriorityID), the time to occupy the service (OccupyTime), and the occupation / release request (OccupyReq).

[0066] As shown in Figure 2, if the parameter is wrong (OccupyTime = 0), it means that the arbitration strategy is incomplete when the client requests. The server calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) and assigns the parameter "Occupy Service Request Feedback (OccupyResp)" in the parameter OccupySrvRR_Resp to: "0x1: Call failed, occupation service RR interface parameters are incomplete", and a text pop-up reminder or voice playback is performed on the HMI.

[0067] If the parameters are complete, the server should judge based on its own status and reply whether it is allowed to be occupied.

[0068] As shown in Figure 3, when only scenario 1 currently makes an occupation service request to the server, the server determines that it can be occupied based on the arbitration mechanism and its own status. It then calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to provide feedback on the occupation service request. The parameter "Occupy Service Request Feedback (OccupyResp)" in the parameter OccupySrvRR_Resp is assigned the value "0x2: Positive reply, allowing occupation". The timer Timer is started based on the parameter "Occupy Time (OccupyTime)" in the parameter OccupySrvRR_Req. Occupy , Timer Occupy =OccupyTime. Occupy Before the timeout, the client can call the occupancy service request interface OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send a release request, and assign the parameter "Occupy / Release Request (OccupyReq)" in the OccupySrvRR_Req to "0x1: Release Request". The server will respond after receiving the "0x1: Release Request" or Timer from the client. OccupyWhen the timeout expires, the resources are automatically released to allow other clients to continue calling.

[0069] As shown in Figure 4, when the client side scenario 1 makes an occupation service request to the server, the server side determines that it can be occupied based on the arbitration mechanism and its own status, and calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to respond to the occupation service request, assigning the parameter "Occupy Service Request Feedback (OccupyResp)" in OccupySrvRR_Resp to "0x2: Positive reply, allowing occupation". The timer Timer is started based on the parameter "Occupy Time of the service (OccupyTime)" in OccupySrvRR_Req. Occupy , Timer Occupy = OccupyTime. When Scenario 1 is triggered by Scenario 2 of a lower or equal priority within the requested "OccupyTime" period, the client sends an occupancy request for Scenario 2. The server continues to execute the client's service request and sends feedback to the client of Scenario 2 via the occupancy service request interface OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp). The parameter "OccupyResp" in the parameter OccupySrvRR_Resp is assigned the value "0x3: Negative reply, occupation not allowed." The client of Scenario 2 is notified via the occupancy service notification interface OccupySrvEvent (OccupySts). The parameters in the parameter OccupySts are assigned: the ID of Scenario 1 currently occupying the service, the requested occupancy time (OccupyTime), and the remaining occupancy time (OccupyRemainTime). A text pop-up window or voice message will be played on the HMI: "There are currently multiple scene requests. The service request for scene 2 cannot be executed according to the arbitration mechanism." Occupy Before the timeout, the client can call the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send a release request, and assign the parameter "Occupy / Release Request (OccupyReq)" in the OccupySrvRR_Req to be "0x1: Release Request". The server will send a release request after receiving the "0x1: Release Request" from the client or the Timer. Occupy When the timeout expires, the resources are automatically released to allow other clients to continue calling.

[0070] As shown in Figure 5, when the client side scenario 1 makes an occupation service request to the server, the server side calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send the occupation service request feedback, and assigns the parameter OccupyResp of the parameter OccupySrvRR_Resp to: 0x2: positive reply: allowed to be occupied. And according to the parameter "Occupy time (OccupyTime)" in the input parameter OccupySrvRR_Req, the timer Timer is started. Occupy , Timer Occupy = OccupyTime. When scene 1 has a higher priority than scene 1 and sends an occupancy request within the "occupancy time (OccupyTime)" requested by scene 1, the server stops executing the service request of scene 1. Then the server calls the occupancy service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send the occupancy service request feedback to the client of scene 2, and assigns the parameter in OccupySrvRR_Resp: "0x2: positive reply, allowed to be occupied". A text pop-up window or voice playback will be displayed on the HMI: "There are currently multiple scene requests. According to the arbitration mechanism, it is necessary to stop executing the service request of scene 1." In the Timer Occupy Before the timeout, the client of scenario 2 can call the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send a release request, and assign the parameter "Occupy / Release Request (OccupyReq)" in OccupySrvRR_Req to "0x1: Release Request". The server will send a release request after receiving the "0x1: Release Request" or Timer from the client of scenario 2. Occupy When the timeout expires, the resources are automatically released to allow other clients to continue calling.

[0071] As shown in Figure 6, when the client side scenario 1 makes an occupation service request to the server, the server side calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send the occupation service request feedback, and assigns the parameter OccupyResp of the parameter OccupySrvRR_Resp to: 0x2: positive reply: allowed to be occupied. And according to the parameter "Occupy time (OccupyTime)" in the parameter OccupySrvRR_Req, the timer Timer is started. Occupy1 , Timer Occupy1 = OccupyTime. Scenario 1: After the occupation request, if you want to continue to occupy the space, then 1 / 2 of the Timer Occupy1 Then the server calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send the occupation service request feedback to the client, and assigns the parameter OccupyResp of OccupySrvRR_Resp to be: 0x2: positive reply: allowed to be occupied. Scenario 1: If the subsequent occupation request is still required, the same procedure is repeated in the 1 / 2 timer. Occupyn Continue to send occupation requests before the Timer Occupyn Before the timeout, the client can call the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) to send a release request, and assign the parameter "Occupy / Release Request (OccupyReq)" in the OccupySrvRR_Req to be "0x1: Release Request". The server will send a release request after receiving the "0x1: Release Request" from the client or the Timer. Occupy When the timeout expires, the resources are automatically released to allow other clients to continue calling.

[0072] When scenario 1 calls a service and other scenarios call the service in parallel, the process is executed according to Figures 4 and 5 based on the priority of the scenarios.

[0073] Actual Case

[0074] When in the "Caring for the Baby" mode, the user does not want to be interrupted by other scenes, such as the "Movie Watching" mode. Then you can set the "Caring for the Baby" mode to have a higher priority than other scenes. When the "Movie Watching" mode is activated on the passenger side, the "Caring for the Baby" mode has a high priority, and the "Movie Watching" mode has a low priority. When the user activates the "Caring for the Baby" mode, 7 service interfaces will be activated, so these 7 service interfaces will be occupied by the "Caring for the Baby". When other scenes are triggered and these 7 service interfaces need to be called, they need to wait for the "Caring for the Baby" mode to release resources before they can be occupied, but this does not affect the calling of other service interfaces in the scene.

[0075] When the "Baby Care" and "Movie Viewing" scenarios are invoked simultaneously, the same service interfaces (items 3, 5, 6, and 7) are executed. The service interfaces (items 3, 5, 6, and 7) invoked in "Baby Care" mode cannot be invoked in "Movie Viewing" mode, and a text and voice reminder is displayed on the HMI: "Currently, multiple scenarios are being requested. Due to the arbitration mechanism, some service requests in Movie Viewing mode cannot be executed." Service interfaces not invoked in "Baby Care" mode (such as items 8, 9, and 10) can be invoked in "Movie Viewing" mode, provided no other higher-priority scenarios are invoked.

[0076] Table 5. Services executed in two scenarios

[0077] A separate service occupancy request interface 0xA0A0 ​​and a separate occupancy service notification interface 0xB0B0 are added to each service. Taking the central control screen service as an example, its service list design is shown in Table 6:

[0078] Table 6 Service list design example (central control screen service)

[0079] Specific implementation method

[0080] 1. Occupancy service request

[0081] When a user creates a "Baby Care" scenario, the system automatically generates an ID ranging from 0x01 to 0xFF. The user sets a priority of 7 and a timer of 30 minutes. This scenario can be triggered using various methods, including: 1. Voice activation; 2. Soft switch triggering; 3. The passenger-side central control screen. Once triggered, the scenario engine Cient calls the occupancy service request interface functions for each of the seven services, OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp), assigning the values ​​to the input parameter OccupySrvRR_Req as shown in Table 7.

[0082] Table 7 OccupySrvRR_Req parameter values ​​in the service interface OccupySrvRR

[0083] 2. Positive reply / negative reply + status

[0084] When the service is allowed to be occupied, the server side gives a positive reply, calls the occupation service request interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) of the seven services, and assigns the parameter OccupySrvRR_Resp as shown in Table 8.

[0085] Table 8 Parameter assignment of OccupySrvResp in the service interface OccupySrvRR

[0086] If the server does not allow the service to be occupied, it will give a negative response:

[0087] (1) It is detected that the parameters of OccupySrvRR_Req of the service interface OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) are incomplete, and the service interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) is called, and the parameter "OccupyResp" in the parameter OccupySrvRR_Resp is assigned to "0x1: call failed, the occupied service RR interface parameters are incomplete", as shown in Table 9.

[0088] Table 9: Parameter assignment of OccupySrvResp in the service interface OccupySrvRR

[0089] (2) If the four parameters of the OccupySrvRR_Req parameter of the service interface OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) are complete, but the service on the server side is being occupied by other high-priority scenarios, the service interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) is called, and the parameter "OccupyResp" in the OccupySrvRR_Resp is assigned to "0x3: Negative reply: occupation is not allowed", as shown in Table 10.

[0090] In addition, the Server calls the service interface OccupySrvEvent (OccupySrvSts) to notify the Client of relevant information, and assigns the parameter "OccupySts" in the OccupySrvSts parameter to "0x1: occupied"; the parameter "OccupySceneID" is "the ID of the currently occupied service Scene is 0x01", the parameter "OccupySceneime" is "the occupation time requested by the currently occupied service Scene is 30 minutes"; the parameter "OccupyRemainTime" is "the remaining occupation time is 15 minutes", as shown in Table 11.

[0091] Table 10 Parameter assignment of OccupySrvResp in the service interface OccupySrvRR

[0092] Table 11 Parameter assignment of OccupySrvSts in the service interface OccupySrvEvent

[0093] 3. Release Request

[0094] Before the occupation time expires, if the user actively exits by clicking the "Exit" button, the Client calls the service interface function OccupySrvRR (OccupySrvRR_Req, OccupySrvRR_Resp) of the seven services, and the parameters assigned to the input parameter OccupySrvRR_Req are shown in Table 12.

[0095] When the occupied time times out, the server automatically releases the resources for other clients to call.

[0096] Table 12 OccupySrvRR_Req parameter values ​​in the service interface OccupySrvRR

[0097] 4. Repeated occupation

[0098] At half of the timed time, that is, 15 minutes, the system will prompt whether to repeat the scene after the timed time ends. If so, the occupation request will continue.

[0099] Repeat steps 1, 2, and 3 above.

[0100] The present invention also provides an electronic device, which includes: a shell, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is placed inside the space enclosed by the shell, and the processor and the memory are arranged on the circuit board; the power supply circuit is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory is used to store executable program code; the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, and is used to execute the task steps performed by the Ethernet-based vehicle service priority arbitration system described in any one of the above.

[0101] The present invention also provides a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the task steps performed by the Ethernet-based vehicle service priority arbitration system described in any one of the above.

[0102] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0103] It should be noted that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0104] It should be pointed out that, according to the needs of implementation, the various steps / components described in this application can be split into more steps / components, or two or more steps / components or partial operations of steps / components can be combined into new steps / components to achieve the purpose of the present invention.

[0105] It will be easily understood by those skilled in the art that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. An Ethernet-based vehicle service priority arbitration system, applied to electronic equipment in a vehicle, characterized in that: It includes the scene arrangement module, the intelligent scene engine as the client, and the server that provides various services: The scenario arrangement module is used to create a new scenario and generate the scenario ID, as well as set the scenario priority and the time occupied by each service according to the needs; Intelligent scene engine, used to call services on each server after the scene is triggered; And add an occupation service request interface to each service that needs arbitration, and the intelligent scene engine sends the following parameters to the occupation service request interface: scene ID, priority, occupation time of each service, and occupation or release request; The server is used to determine whether to allow occupation according to the arbitration method and its own status after receiving the occupation service request from the client, and return the occupation service request feedback in the occupation service request interface.

2. The Ethernet-based vehicle service priority arbitration system according to claim 1, characterized in that: The intelligent scene engine uses the SOA method to call the services of each server and transmits data based on the SOME / IP protocol, passing through the Ethernet physical layer, data link layer, network layer and transport layer of each server-side ECU, and then to the application layer.

3. The Ethernet-based vehicle service priority arbitration system according to claim 2, characterized in that: The application layer on the server side includes service module, arbitration module and upper application module; The service module is used to receive and process the SOME / IP message of the ECU through the service interface ServiceInterface; The arbitration module is used to implement the arbitration method; after the SOME / IP message is received by the service module, it is calculated by the arbitration module and then the final processing result is output; The upper-layer application module is used to perform corresponding execution operations according to the final processing results output by the arbitration module after calculation. The specific operations are: if the call is successful, the call success information is returned through the SOME / IP message, and the actuator is controlled; if the call fails, the call failure information and the current status are returned through the SOME / IP message, and the actuator is not controlled.

4. The Ethernet-based vehicle service priority arbitration system according to claim 3, characterized in that: Arbitration methods include: (1) After a scene is triggered, when the client needs to occupy a service, it needs to declare the scene ID, priority, time to occupy the service, and occupation or release request in the service interface when calling the service interface; the later one can initiate an occupation request again only after the first one releases the service; (2) If the same service is called concurrently in scenarios with the same priority level, a first-come, first-served policy is adopted; (3) If different priority scenarios call the same service in parallel, the high priority interrupts the low priority, but the low priority cannot interrupt the high priority; (4) If a scene is occupying a service and wants to continue to occupy the service, the heartbeat mechanism is used: continue to send a second occupation request within a specific occupation time, and so on, to achieve continuous occupation; during the occupation process, if other scenes send occupation requests, follow the strategies of (2) and (3); (5) The server receives a release request from the client before the service time expires or releases the resource after the service time expires, so that other clients can call it.

5. The Ethernet-based vehicle service priority arbitration system according to claim 4, characterized in that: The arbitration module implements the arbitration method, resource occupation request and release request, and heartbeat mechanism; Keywords are agreed upon for each service. When the service signal contains specific keywords, the arbitration module automatically recognizes and enables the arbitration method. Each service has a unique service ID. Each service includes: multiple vehicle-specific service interface IDs, and separately adds 1 occupied service request interface ID and 1 occupied service notification interface ID.

6. The Ethernet-based vehicle service priority arbitration system according to claim 5, characterized in that: An occupation service request interface ID is added separately to each service that needs arbitration. The client sends the following parameters to the server through the occupation service request interface: scene ID, scene priority, time occupied for the service, and occupation or release request; the server replies to the client with the following parameters through the occupation service request interface: occupation service request feedback. An occupied service notification interface ID is added separately to each service that needs arbitration. The server actively notifies the client of the following parameters through the occupied service notification interface: the current occupied service status, the ID of the current occupied service scenario, the occupied time applied for by the current occupied service scenario, and the remaining occupied time.

7. The Ethernet-based vehicle service priority arbitration system according to claim 6, characterized in that: The occupancy service request interface is of RR Method type, and the occupancy service notification interface is of Event type.

8. The Ethernet-based vehicle service priority arbitration system according to claim 6, characterized in that: The occupation service request interface function is: The function name is Occupancy Service Request Interface, the input parameter is Occupancy Service Request, and the output parameter is Occupancy Service Request Feedback; The occupation service request includes four parameters: the scene ID, the scene priority, the time to occupy the service, and the occupation or release request; The occupation service request feedback includes a parameter: occupation service request feedback. The parameter occupation service request feedback includes the following definitions: call failure, occupation service request interface parameters are incomplete; positive reply, allow occupation; negative reply, do not allow occupation; The occupied service notification interface function is: The function name is Occupancy Service Notification Interface, and the output parameter is the occupancy notification status; The occupancy notification status includes four parameters: current occupancy service status, current occupancy service scene ID, current occupancy service The occupied time and remaining occupied time of the service scenario application.

9. An electronic device, characterized in that: The electronic device includes: a shell, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is placed inside the space enclosed by the shell, and the processor and the memory are arranged on the circuit board; the power supply circuit is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory is used to store executable program code; the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, and is used to execute the task steps performed by the Ethernet-based vehicle service priority arbitration system as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the task steps performed by the Ethernet-based in-vehicle service priority arbitration system as described in any one of claims 1 to 8.

Images