Priority arbitration method for vehicle body domain service programs based on SOA architecture

Abstract

The present invention discloses a vehicle body domain service program priority arbitration method based on SOA architecture, which relates to the field of automotive electronic technology. The main concepts include: proposing a priority quantification method based on multi-dimensional dynamic parameters, and realizing priority adaptive optimization through dynamic adjustment of weight coefficients, which is significantly different from traditional fixed priority or single-dimensional scheduling. Furthermore, it at least supports the interruption, preservation and recovery of lower dynamic priority services by calculated higher dynamic priority services, and further reserves resources and guarantees bandwidth for security services to ensure the smooth response of security services. In addition, the weights of each dynamic feature parameter are flexibly adjusted through load perception to optimize the output dynamic priority score and achieve accurate arbitration. The present invention can dynamically adjust the initial priority according to the real-time requirements, resource occupancy and dependency of the service, and promptly respond to the current highest priority service, effectively improving resource utilization efficiency.

Description

Technical Field

[0001] The present invention relates to the field of automotive electronics technology, and in particular to a vehicle body domain service program priority arbitration method based on SOA architecture. Background Art

[0002] With the continuous development of automotive electronic systems, body-domain control systems integrate a variety of services, such as door control, lighting management, seat adjustment, and autonomous driving interaction, through a service-oriented architecture (SOA). However, under the SOA architecture, service requests are dynamic, diverse, and concurrent, and traditional fixed-priority scheduling methods present numerous challenges.

[0003] First, when multiple services request the same hardware resources (such as CAN bus, sensors) at the same time, it is easy to cause response delays or resource competition conflicts; second, fixed priority cannot adapt to changes in dynamic scenarios, such as the need to instantly seize control services such as doors and windows after a collision; third, there are complex dependencies between services and a lack of a global arbitration mechanism, resulting in high service coupling.

[0004] In the existing technology, a static scheduling solution based on time triggering has been proposed, but it fails to solve the dynamic priority problem; another method uses service queue polling, but its real-time performance is poor and cannot meet the high real-time response requirements of the vehicle system.

[0005] In general, there are at least the following deficiencies in the current field:

[0006] (1) It cannot effectively solve the resource competition and response delay problems when multiple services request the same hardware resources at the same time, which easily leads to service conflicts;

[0007] (2) The fixed priority scheduling method cannot adapt to dynamic scene changes and cannot respond to the needs of high-priority services in a timely manner;

[0008] (3) The lack of a global arbitration mechanism makes it impossible to properly handle the complex dependencies between services, resulting in high service coupling;

[0009] (4) The existing time-triggered static scheduling scheme cannot solve the dynamic priority problem and cannot meet the real-time requirements;

[0010] (5) The service queue polling method has poor real-time performance and cannot meet the high real-time response requirements of the vehicle system. Summary of the Invention

[0011] In view of the above, the present invention aims to provide a vehicle body domain service program priority arbitration method based on SOA architecture to solve the problems of inability to adjust service priority, unreasonable resource allocation and high service coupling.

[0012] The technical solution adopted in the present invention is as follows:

[0013] The present invention provides a vehicle body domain service program priority arbitration method based on SOA architecture, which includes:

[0014] Divide the vehicle body domain services into multiple types in advance and define the initial priority for each type of service;

[0015] Real-time acquisition of dynamic characteristic parameters of each running vehicle domain service and quantitative setting, the dynamic characteristic parameters include: real-time parameters, resource occupancy parameters, service dependency parameters;

[0016] Calculate the dynamic priority of each service currently running in real time based on the initial priority and the dynamic characteristic parameter;

[0017] Based on the preset preemptive arbitration strategy, resources are allocated according to the dynamic priority of each service, and then service scheduling and execution are performed. Specifically, the service with a higher dynamic priority after arbitration preempts system resources and is processed first, while the service with a lower dynamic priority after arbitration is processed in any of the following ways:

[0018] The service with a lower dynamic priority is suspended and the execution status at the time of the interruption is recorded; or, based on system resource conditions, the service with a lower dynamic priority is linked to the service with a higher dynamic priority.

[0019] In at least one possible implementation, the linkage includes: according to the current system resource usage, the service with lower dynamic priority is executed synchronously with the service with higher dynamic priority, wherein the service with lower dynamic priority is forced to be downgraded to execute in a relatively low resource occupancy manner.

[0020] In at least one possible implementation, the real-time calculation of the dynamic priority of each currently running service includes calculation according to the following model:

[0021] P_dynamic=P_base+α·R+β·(1 / C)+γ·D, where P_dynamic is the dynamic priority, P_base is the initial priority, R is the quantized real-time parameter, C is the quantized resource occupancy parameter, and D is the quantized service dependency parameter. α, β, and γ are the pre-set initial weight coefficients corresponding to each dynamic feature parameter.

[0022] In at least one possible implementation, before calculating the dynamic priority, the usage of system resources is monitored in real time, and the initial weight coefficients in the model are adaptively adjusted.

[0023] In at least one possible implementation, the quantization setting includes:

[0024] According to the real-time requirements of the vehicle body domain service, configure the real-time parameter values ​​of the service within the established value range;

[0025] According to the proportion of system resources occupied by the vehicle body domain service, configure the resource occupancy parameter value of the service within a predetermined range of values, wherein the resource occupancy rate includes at least: CPU occupancy rate, memory occupancy rate, and network bandwidth occupancy rate;

[0026] Based on the dependency relationships between different vehicle body domain services, the dependency parameter values ​​belonging to the front-end services in the dependency relationships are increased within a given numerical range.

[0027] In at least one possible implementation, defining an initial priority for each type of service includes:

[0028] Services are pre-classified into safety, comfort, and infotainment, with high, medium, and low priorities assigned to safety, comfort, and infotainment services, respectively.

[0029] Different initial priority values ​​are set for each type of service based on the established service importance and real-time requirements.

[0030] In at least one possible implementation, the preemptive arbitration strategy further includes: reserving a predetermined proportion of system resources for security services in advance.

[0031] In at least one possible implementation, the arbitration method further includes: if the dynamic priorities of different services are the same after arbitration, generating an arbitration sequence by combining at least a service running timestamp and / or a service type dimension.

[0032] In at least one possible implementation, the arbitration method further includes: if an exception occurs or execution fails during service execution, triggering a service rollback and outputting a related notification.

[0033] Compared with the existing technology, the present invention addresses the needs and problems in specific SOA architecture scenarios and can at least demonstrate the following advantages:

[0034] (1) By dividing the vehicle body services into safety, comfort, and infotainment categories, and defining the initial priority for each service category, and combining the dynamic characteristic parameters of the services (real-time requirements, resource occupancy, and service dependencies), a dynamic priority model is adopted. This effectively solves the problem that the fixed priority in existing technologies cannot adapt to dynamic scene changes, ensuring that high-real-time services can respond in a timely manner.

[0035] (2) A preemptive arbitration strategy is introduced, whereby high-priority services can interrupt low-priority services and preempt resources. At the same time, a resource reservation mechanism is used to reserve minimum bandwidth and computing resources for security services, thereby solving the resource competition and response delay problems when multiple services request the same hardware resources at the same time, and effectively eliminating service conflicts. In addition, a load balancing module is set up to monitor the resource usage of the vehicle electronic control unit (ECU) in real time, thereby adaptively adjusting the weight coefficient in the dynamic priority model to avoid long-term starvation of low-priority services and improve resource utilization.

[0036] (3) Furthermore, a conflict resolution and fault tolerance mechanism is introduced, and a unique arbitration sequence is generated using timestamps and service types, which solves the arbitration problem when services have the same priority. When a service is executed abnormally, a rollback strategy is triggered and the associated services are notified, which reduces the coupling between services and achieves efficient resource allocation and service conflict resolution. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be further described below with reference to the accompanying drawings, in which:

[0038] Figure 1 A flow chart of a method for arbitrating vehicle body domain service program priorities based on SOA architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The following describes embodiments of the present invention in detail. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended only to explain the present invention and are not to be construed as limiting the present invention.

[0040] The present invention proposes an embodiment of a vehicle body domain service program priority arbitration method based on SOA architecture. Specifically, Figure 1 shown, including:

[0041] Step S1: pre-classify vehicle body services into safety, comfort, and infotainment categories, and define an initial priority for each category of services;

[0042] Specifically, in some embodiments of the present invention, vehicle body services are divided into three categories: safety, comfort, and infotainment. Safety services may include collision warning, brake control, and airbags, with a highest initial priority of P_base = 100. Comfort services may include window control, seat adjustment, and air conditioning management, with a medium initial priority of P_base = 60. Infotainment services may include navigation, audio playback, and in-vehicle communications, with a lowest initial priority of P_base = 30.

[0043] Step S2: acquiring dynamic characteristic parameters of each vehicle body domain service in operation (operation means being in the process of execution, currently triggered, etc.) in real time and quantifying and setting them. The dynamic characteristic parameters include: real-time parameters, resource occupancy parameters, and service dependency parameters;

[0044] This step can be understood as real-time identification of service types and output of initial priority values ​​and characteristic parameter values ​​of each service. To elaborate, obtain the initial priority of a currently running or triggered service, as well as dynamic characteristic parameters: real-time demand R, resource occupancy rate C and service dependency D. Among them, the value range of real-time demand R can be preset to 0-10. For example, for emergency services (such as collision warning), the real-time parameter score R=10 of the service can be set; resource occupancy rate C is the percentage of CPU, memory and network bandwidth resources occupied by the service, and the value range can be preset to 0-100%; the value range of service dependency D can be preset to 0-10. Dependency description: If a service A is a prerequisite for a service B, then increase the D value of service A, such as D=5.

[0045] Step S3: Calculate the dynamic priority of each currently running service in real time based on the initial priority and the dynamic characteristic parameter;

[0046] This step can be understood as calculating the dynamic priority based on the initial priority, taking into account real-time requirements, resource utilization, and service dependencies. The dynamic priority calculation model can be referred to as: P_dynamic = P_base + α·R + β·(1 / C) + γ·D, where P_dynamic is the dynamic priority, P_base is the base priority, R is the real-time requirement value, C is the resource utilization value, D is the service dependency value, and α, β, and γ are initial weight coefficients pre-set based on testing, calibration, and expert experience. For example, P_dynamic = P_base + 0.4R + 0.3(1 / C) + 0.3D. The initial weight coefficients are α = 0.4, β = 0.3, and γ = 0.3.

[0047] Step S4: Based on the preset preemptive arbitration strategy, resources (such as CPU, memory, and network bandwidth) are allocated according to the dynamic priority of each service, and then service scheduling is performed and the corresponding service is executed. Specifically, the service with a higher dynamic priority after arbitration is preempted and processed first, and the service with a lower dynamic priority after arbitration is simultaneously processed in any of the following ways:

[0048] The service with a lower dynamic priority is suspended and the execution status at the time of the interruption is recorded; or, based on system resource conditions, the service with a lower dynamic priority is linked to the service with a higher dynamic priority.

[0049] Regarding the arbitration strategy involving resource preemption, it is possible to further expand upon it. In some other preferred embodiments of the present invention, a resource reservation mechanism is designed to ensure vehicle driving safety. This mechanism primarily reserves a certain percentage of CPU, memory resources, and network bandwidth for the aforementioned security services, thereby preventing insufficient preemption from causing "starvation" of the service and preventing it from running in a timely manner.

[0050] Furthermore, the initial weight coefficients mentioned above can be used to design a load balancing module based on them to monitor the utilization of system resources in real time, mainly the processor of the electronic control unit, etc., and dynamically adjust the initial weight coefficients (α, β, γ) in the model based on the real-time load of the system (CPU, memory, bus utilization). For example, in some preferred embodiments of the present invention:

[0051] When monitoring a system under high load, the real-time weight can be increased (α↑) and the resource usage weight can be reduced (β↓). When monitoring a system under low load, resource utilization and service quality can be balanced (β↑, γ↑). For example, when CPU utilization exceeds 80%, memory utilization exceeds 90%, or network bandwidth utilization exceeds 70%, indicating that the ECU is under high load, the weight coefficients α, β, and γ can be dynamically adjusted before calculating the dynamic priority to prevent low-priority services from being starved for a long time.

[0052] Based on the above-mentioned concept of resource reservation and load balancing, another technical route of the present invention is that, under the premise of sufficient system resources, even if the main resources are used for the operation of higher-priority services after arbitration, the services arbitrated as lower dynamic priorities can also be in a state of linkage with higher-priority services, that is, in terms of background system resource scheduling and processing, higher-priority services are still in an advantageous position, but in terms of actual execution and operation, the lower-priority services can be downgraded and executed synchronously with relatively low resource occupancy until the execution of the higher-priority services is completed, which will be explained with examples later. In other words, in this technical route, the priority level arbitrated is mainly reflected in resource scheduling and allocation (mainly based on the full use of system resources to ensure the smooth operation of high-priority services), rather than the order of service execution (under the premise of ensuring the allocation of high-priority service resources, services of different priorities can be in a synchronous and parallel state).

[0053] In addition to the scenarios described in the above embodiments, the present invention also accounts for the rare occurrences of actual operations. First, the possibility of identical dynamic priority values ​​after arbitration cannot be completely ruled out. Based on this, some preferred embodiments of the present invention incorporate a conflict resolution mechanism. Specifically, this mechanism utilizes at least the service execution timestamp and / or service type to generate an arbitration sequence to address the special case of identical priority arbitration. For example, if services A and B have the same priority, but A triggers before B, the generated sequence may be ranked A, then B. Alternatively, if services A and B have the same priority, but A is for audio playback in the entertainment and information category, and B is for in-vehicle communication, the generated sequence may be ranked B, then A. The above description is illustrative and not restrictive; order factors can be pre-set for different types of services or different subcategories within the same service category based on actual circumstances. Second, if an exception or failure occurs during service execution, other preferred embodiments of the present invention incorporate a fault-tolerance mechanism that triggers a service rollback mechanism (such as resource release or state recovery) and outputs associated notifications to reduce inter-service coupling.

[0054] In combination with the above embodiments, the specific processing process is described here by taking the scenario of "automatically closing the car windows during emergency braking" as an example:

[0055] The window lift service (a comfort service with an initial priority of P_base = 60) is currently being executed. The dynamic characteristic parameters of this service are obtained in real time and quantitatively set: for example, R = 2, C = 10%, and D = 0. The dynamic priority of the window lift service at this time is calculated using the above model: P_dynamic = 60 + 0.42 + 0.3(1 / 0.1) + 0.30 = 68.

[0056] At this time, the collision warning service (safety service, initial priority value P_base = 100) is triggered, and the dynamic characteristic parameters of the service are obtained in real time and quantified: real-time requirement value R = 10 (highest), resource utilization value C = 5%, dependency on the window control service, dependency value D = 5. The dynamic priority of the collision warning service is obtained through the above model: P_dynamic = 100 + 0.410 + 0.3(1 / 0.05) + 0.35 = 120.

[0057] The arbitration engine compares the priorities of the current window lift service and the collision warning service. Since the collision warning service's dynamic priority of 120 is higher than the window lift service's 68, the arbitration engine immediately suspends the window lift service and records the interruption (saving it to the cache). It then preempts and allocates resources to the collision warning service, allowing the later-triggered service to perform collision warning operations (such as emergency braking). After the emergency braking operation is completed, the lower-priority service is restored based on the cached state, allowing it to continue. This means that the unfinished operation of the original window lift service can be resumed after the preemption is complete. Furthermore, as mentioned above, if sufficient system resources are available, the window lift service can be downgraded while the collision warning service is prioritized, allowing for example, simultaneous window lowering and lowering during emergency braking.

[0058] Finally, it should be noted that based on the software implementation of the dynamic priority arbitration method described above, hardware alternatives only need to implement the same functional logic (such as service classification, priority calculation, resource arbitration, etc.) and are consistent with the technical concepts provided by this invention. Furthermore, through modular design, the present invention is compatible with the Autosar architecture and can be integrated into existing in-vehicle ECU software platforms, demonstrating excellent portability and compatibility. The hardware design discussed above is merely an exemplary embodiment; in actual operation, specific component models are not required. This means that the core technical approach of this invention is decoupled from the hardware and can be implemented using a variety of different hardware carriers, such as circuits.

[0059] In summary, the main design concepts of the present invention include: proposing a priority quantization method based on multi-dimensional dynamic parameters, realizing priority adaptive optimization through dynamic adjustment of weight coefficients, which is significantly different from traditional fixed priority or single-dimensional scheduling. Furthermore, it at least supports the interruption, preservation and recovery of lower dynamic priority services by calculated higher dynamic priority services, and further reserves resources for security services and guarantees bandwidth (such as computing resources, bus bandwidth) to ensure the smooth response of security services. In addition, the weights of each dynamic characteristic parameter are flexibly adjusted through load perception to optimize the output dynamic priority score and achieve precise arbitration. The present invention can dynamically adjust the initial priority according to the real-time requirements, resource occupancy and dependency of the service, and promptly respond to the current highest priority service, effectively improving resource utilization efficiency.

[0060] If the expressions expressing directions are mentioned in the embodiments of the present invention, they are relative concepts based on the embodiments. In addition, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c or a, b and c, where a, b, c can be single or multiple.

[0061] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings, but the above is only a preferred embodiment of the present invention. It should be noted that the technical features involved in the above embodiments and their preferred modes can be reasonably combined and matched into a variety of equivalent schemes by those skilled in the art without departing from or changing the design ideas and technical effects of the present invention; therefore, the scope of implementation of the present invention is not limited to what is shown in the drawings. Any changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which still do not exceed the spirit covered by the description and drawings, should be within the scope of protection of the present invention.

Claims

1. A vehicle body domain service program priority arbitration method based on SOA architecture, characterized in that: include: Divide the vehicle body domain services into multiple types in advance and define the initial priority for each type of service; Real-time acquisition of dynamic characteristic parameters of each running vehicle domain service and quantitative setting, the dynamic characteristic parameters include: real-time parameters, resource occupancy parameters, service dependency parameters; Based on the initial priority and the dynamic characteristic parameters, the dynamic priority of each service currently running is calculated in real time, and the calculation is performed according to the following model: P_dynamic = P_base + α·R + β·(1 / C) + γ·D, where P_dynamic is the dynamic priority, P_base is the initial priority, R is the quantized real-time parameter, C is the quantized resource usage parameter, and D is the quantized service dependency parameter. α, β, and γ are the pre-set initial weight coefficients corresponding to the dynamic characteristic parameters. Furthermore, before calculating the dynamic priority, the system resource usage is monitored in real time and the initial weight coefficients in the model are adaptively adjusted. Based on the preset preemptive arbitration strategy, resources are allocated according to the dynamic priority of each service, and then service scheduling and execution are performed. Specifically, the service with a higher dynamic priority after arbitration preempts system resources and is processed first, while the service with a lower dynamic priority after arbitration is processed in any of the following ways: The service with a lower dynamic priority is suspended and the execution status at the time of the interruption is recorded; or, based on system resource conditions, the service with a lower dynamic priority is linked to the service with a higher dynamic priority.

2. The vehicle body domain service program priority arbitration method based on SOA architecture according to claim 1 is characterized in that: The linkage includes: according to the current system resource usage, making the service with lower dynamic priority and the service with higher dynamic priority execute synchronously, wherein the service with lower dynamic priority is forced to be downgraded and executed in a relatively lower resource occupation manner.

3. The vehicle body domain service program priority arbitration method based on SOA architecture according to claim 1 is characterized in that: The quantization settings include: According to the real-time requirements of the vehicle body domain service, configure the real-time parameter values ​​of the service within the established value range; According to the proportion of system resources occupied by the vehicle body domain service, configure the resource occupancy parameter value of the service within a predetermined range of values, wherein the resource occupancy rate includes at least: CPU occupancy rate, memory occupancy rate, and network bandwidth occupancy rate; Based on the dependency relationships between different body domain services, the dependency parameter values ​​belonging to the front-end services in the dependency relationships are increased within a given numerical range.

4. The vehicle body domain service program priority arbitration method based on SOA architecture according to claim 1 is characterized in that: Defining the initial priority for each type of service includes: Services are pre-classified into safety, comfort, and infotainment, with high, medium, and low priorities assigned to safety, comfort, and infotainment services, respectively. Different initial priority values ​​are set for each type of service based on the established service importance and real-time requirements.

5. The vehicle body domain service program priority arbitration method based on SOA architecture according to claim 4 is characterized in that: The preemptive arbitration strategy also includes: reserving a predetermined proportion of system resources for security services in advance.

6. The vehicle body domain service program priority arbitration method based on SOA architecture according to any one of claims 1 to 5, characterized in that: The arbitration method further includes: if the dynamic priorities of different services are the same after arbitration, generating an arbitration sequence by combining at least a service running timestamp and / or a service type dimension.

7. The vehicle body domain service program priority arbitration method based on SOA architecture according to any one of claims 1 to 5, characterized in that: The arbitration method further includes: if an exception occurs or execution fails during the service execution, triggering a service rollback and outputting a related notification.

Images