SOA (Service Oriented Architecture)-based vehicle body domain service program priority arbitration method

Abstract

The invention discloses an SOA (service oriented architecture)-based vehicle body domain service program priority arbitration method, which relates to the technical field of automotive electronics, and mainly comprises the following steps of: proposing a priority quantification method based on multi-dimensional dynamic parameters, and realizing priority self-adaptive optimization through dynamic adjustment of weight coefficients; and the method is obviously different from the traditional fixed priority or single-dimension scheduling. Moreover, the method at least supports the interruption, storage and recovery of the calculated service with the higher dynamic priority to the service with the lower dynamic priority, further reserves resources for the security service, guarantees the bandwidth, and guarantees the smooth response of the security service. Besides, the weight of each dynamic characteristic parameter is flexibly adjusted through load sensing, so that the output dynamic priority score is optimized, and accurate arbitration is realized. According to the method, the initial priority can be dynamically adjusted according to the real-time requirement of the service, the resource occupation condition and the dependency relationship, the current service with the highest priority is responded in time, and the resource utilization efficiency is effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of automotive electronics technology, and in particular, to a method for arbitrating the priorities of body domain service programs based on the SOA architecture. Background Art

[0002] With the continuous development of automotive electronic systems, body domain control systems have integrated various services through the Service-Oriented Architecture (SOA), such as door control, lighting management, seat adjustment, and autonomous driving interaction. However, under the SOA architecture, service requests are dynamic, diverse, and concurrent, and there are many problems with traditional fixed-priority scheduling methods.

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

[0004] In the prior art, a static scheduling scheme based on time-triggering has been proposed, but it fails to solve the problem of dynamic priorities; another approach is to use service queue polling, but the real-time performance is poor and it cannot meet the high real-time response requirements of in-vehicle systems.

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

[0006] (1) It is unable to effectively solve the resource competition and response delay problems when multiple services simultaneously request the same hardware resources, and it is easy to cause service conflicts;

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

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

[0009] (4) Existing static scheduling schemes based on time-triggering cannot solve the problem of dynamic priorities and cannot meet the real-time requirements;

[0010] (5) Using the service queue polling method, the real-time performance is poor and it cannot meet the high real-time response requirements of in-vehicle systems. Summary of the Invention

[0011] In view of the above, the present invention aims to provide a method for arbitrating the priorities of body domain service programs based on the SOA architecture to solve the problems of inability to adjust service priorities, unreasonable resource allocation, and high service coupling degree.

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

[0013] The present invention provides a method for arbitrating the priorities of body domain service programs based on the SOA architecture, which includes:

[0014] Pre-divide body domain services into multiple types and define initial priorities for each type of service;

[0015] Obtain and quantify the dynamic characteristic parameters of each running body domain service in real time. The dynamic characteristic parameters include: real-time parameter, resource occupancy parameter, service dependency parameter;

[0016] According to the initial priority and the dynamic characteristic parameters, calculate the dynamic priorities of each currently running service in real time;

[0017] Based on a preset preemptive arbitration strategy, allocate resources according to the dynamic priorities of each service, and then perform service scheduling and execute the corresponding service. Specifically, it includes: enabling the service with a higher dynamic priority after arbitration to preempt system resources and be processed first, and synchronously performing any one of the following processes on the service with a lower dynamic priority after arbitration:

[0018] Suspend the service with a lower dynamic priority and record the execution state at the time of interruption; or, based on the system resource situation, enable the service with a lower dynamic priority to form a linkage with the service with a higher dynamic priority.

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

[0020] In at least one possible implementation manner, the real-time calculation of the dynamic priorities of each currently running service includes calculating 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 quantified real-time parameter, C is the quantified resource occupancy parameter, D is the quantified service dependency parameter; α, β, and γ are the initial weight coefficients preset for the corresponding dynamic characteristic parameters respectively.

[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 adaptive adjustment model are adjusted.

[0023] In at least one possible implementation, the quantization settings include:

[0024] According to the real-time requirements of the body domain service, the real-time parameter values of the service are configured within a predetermined numerical range;

[0025] According to the proportion of system resources occupied by the body domain service, the resource occupancy parameter values of the service are configured within a predetermined numerical range, where the resource occupancy at least includes: CPU occupancy, memory occupancy, and network bandwidth occupancy;

[0026] Based on the dependency relationship between different body domain services, the dependency parameter values of the pre-service in the dependency relationship are increased within a predetermined numerical range.

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

[0028] The services are pre-divided into safety services, comfort services, and infotainment services, and high, medium, and low priorities are configured for safety services, comfort services, and infotainment services in sequence;

[0029] According to the established service importance and real-time requirements, different initial priority values are set for each type of service.

[0030] In at least one possible implementation, the preemptive arbitration strategy further includes: reserving a predetermined proportion of system resources for safety 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, an arbitration sequence is generated by at least combining the service running timestamp and / or the service type dimension.

[0032] In at least one possible implementation, the arbitration method further includes: if an exception occurs or the execution fails during the service execution, the service rollback is triggered and an associated notification is output.

[0033] Compared with the prior art, the present invention can at least demonstrate the following advantages for the requirements and problems in a specific SOA architecture scenario:

[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 can effectively solve the problem that the fixed priority in the existing technology cannot adapt to dynamic scene changes, and ensure 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 rate of the on-board electronic control unit ECU in real time, so as to adaptively adjust the weight coefficient in the dynamic priority model, 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 executes abnormally, a rollback strategy is triggered and 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 schematic flow chart of a method for arbitrating body domain service program priorities based on a SOA architecture provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] Embodiments of the present invention are described in detail below, and 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 only used to explain the present invention, and cannot be interpreted 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 the vehicle body domain 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, body domain services are divided into three categories: safety, comfort, and infotainment. Among them, safety services may include: collision warning, braking control, airbag, etc., and the highest initial priority P_base = 100 is set for such services; comfort services may include: window control, seat adjustment, air conditioning management, etc., and the medium initial priority P_base = 60 is set for such services; infotainment services may include navigation, audio playback, vehicle communication, etc., and the lowest initial priority P_base = 30 is set for such services.

[0043] Step S2: Obtain and quantify the dynamic characteristic parameters of each body domain service during operation (during operation means being in the execution process, currently triggered, etc.). The dynamic characteristic parameters include: real-time parameter, resource occupancy rate parameter, service dependency parameter.

[0044] This step can be understood as identifying the service type in real time and outputting the initial priority value and the characteristic parameter values of each current service. Expanding, obtain the initial priority of a certain service that is currently running or triggered, as well as the dynamic characteristic parameters: real-time requirement R, resource occupancy rate C, and service dependency relationship D. Among them, the value range of the real-time requirement R can be preset as 0 - 10. For example, for an emergency service (such as collision warning), the real-time parameter score R = 10 can be set for this service; the resource occupancy rate C is the percentage of the service occupying CPU, memory, and network bandwidth resources, and the value range can be preset as 0 - 100%; the value range of the service dependency relationship D can be preset as 0 - 10. Dependency relationship description: If a certain service A is a precondition for a certain service B, then increase the D value of service A, such as D = 5.

[0045] Step S3: Calculate the dynamic priority of each service currently running in real time according to the initial priority and the dynamic characteristic parameters.

[0046] This step can be understood as calculating the dynamic priority based on the real-time requirement, resource occupancy rate, and service dependency relationship on the basis of the initial priority. The dynamic priority calculation model can refer to the following formula: P_dynamic = P_base + α·R + β·(1 / C) + γ·D, where: P_dynamic is the dynamic priority, P_base is the basic priority, R is the real-time requirement value, C is the resource occupancy rate value, D is the service dependency relationship value, and α, β, and γ are initial weight coefficients set in advance by combining tests, calibration, and expert experience; for example, P_dynamic = P_base + 0.4R + 0.3(1 / C) + 0.3D. Among them, the initial weight coefficients are α = 0.4, β = 0.3, and γ = 0.3.

[0047] Step S4: Based on the preset preemptive arbitration strategy, allocate resources (allocate system resources such as CPU, memory, and network bandwidth) according to the dynamic priorities of each service, and then perform service scheduling and execute the corresponding service. Specifically, it includes: enabling the service with a higher dynamic priority after arbitration to preempt system resources and be processed preferentially, and synchronously performing any one of the following processes on the service with a lower dynamic priority after arbitration:

[0048] Suspend the service with a lower dynamic priority and record the execution state at the time of interruption; or, based on the system resource situation, enable the service with a lower dynamic priority to form a linkage with the service with a higher dynamic priority.

[0049] Regarding the arbitration strategy involving resource preemption, it can be further expanded. In some other preferred embodiments of the present invention, in order to ensure vehicle driving safety, a resource reservation mechanism is also designed, mainly reserving a certain proportion of CPU, memory resources, and network bandwidth for the aforementioned safety services to avoid "starvation" of the service due to insufficient preemption and inability to run in a timely manner;

[0050] In addition, the initial weight coefficients are mentioned above, and a load balancing module can be designed accordingly to monitor the system resource utilization rate 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 system load (CPU, memory, bus utilization rate). For example, in some preferred embodiments of the present invention:

[0051] When it is monitored that the system is under high load, the real-time weight (α↑) can be increased and the resource occupancy weight (β↓) can be decreased; when it is monitored that the system is under low load, the resource utilization rate and service quality can be balanced (β↑, γ↑). For example, when the CPU utilization rate exceeds 80%, the memory utilization rate exceeds 90%, or the network bandwidth utilization rate exceeds 70%, it indicates that the ECU is in a high load state. Then, before calculating the dynamic priority, the values of the weight coefficients α, β, and γ can be dynamically adjusted to avoid the long-term starvation of services with lower dynamic priorities.

[0052] Based on the above concept of resource reservation and load balancing, another technical route of the present invention is that, on the premise of sufficient system resources, even if all major resources are used for the operation of higher-priority services after arbitration, the services arbitrated as having lower dynamic priorities can still be in a state linked to the higher-priority services. That is, in terms of background system resource scheduling and processing, higher-priority services still have an advantage, but at the actual execution and operation level, the lower-priority services at this time can be downgraded and synchronously executed in a relatively low-resource-occupation manner until the higher-priority services are executed. This will be illustrated by examples later. In other words, in this technical route, the high or low priority arbitrated mainly reflects in resource scheduling and allocation (mainly to ensure the smooth operation of high-priority services with all system resources), rather than the order of service execution (under the premise of ensuring the resource configuration of high-priority services, services with different priorities can be in a synchronous parallel state).

[0053] In addition to the scenarios involved in the above embodiments, the present invention also takes into account small-probability events in actual operations: First, it cannot be completely excluded that there are cases where the dynamic priority values are the same after arbitration. Based on this, in some preferred embodiments of the present invention, a conflict resolution mechanism is introduced. Specifically, at least the service running timestamp and / or the service type dimension are combined to generate an arbitration sequence to solve the arbitration special case of the same priority. For example, the priorities of service A and service B are the same, but A is triggered earlier than B, then the sorting in the generated sequence can be A, B; another example is that the priorities of service A and service B are the same, but A is the audio playback in entertainment information and B is vehicle-mounted communication, then the sorting in the generated sequence can be B, A. The above is a schematic introduction rather than a limitation, and the order factors can be set in advance for different types of services or different subclasses in the same type of service based on the actual situation. Second, if an exception / failure occurs during the service execution, in some other preferred embodiments of the present invention, a fault tolerance mechanism is introduced to trigger the service rollback mechanism (such as resource release, status recovery) and output an associated notification to reduce the coupling between services.

[0054] Combining the above embodiments, taking the scenario of "automatically closing the window during emergency braking" as an example, the specific processing process is described as follows:

[0055] Currently, the window lifting and lowering service (a comfort service with an initial priority value P_base = 60) is being executed. The dynamic characteristic parameters of the service are obtained in real time and quantified for setting: for example, R = 2, C = 10%, D = 0; through the above model calculation, the dynamic priority of the window lifting and lowering service at this time is: P_dynamic = 60 + 0.42 + 0.3(1 / 0.1) + 0.30 = 68;

[0056] At this time, the collision warning service (a safety service with an initial priority value of P_base = 100) is triggered, and the dynamic characteristic parameters of the service are obtained in real time and quantified as follows: the real-time requirement value R = 10 (highest), the resource occupancy rate value C = 5%, it depends on the window control service, and the dependency value D = 5; the dynamic priority of the collision warning service is obtained through the above model: P_dynamic = 100 + 0.4×10 + 0.3×(1 / 0.05) + 0.3×5 = 120.

[0057] The arbitration engine compares the current window lifting service with the priority of the collision warning service. Since the dynamic priority of the collision warning service, 120, is higher than that of the window lifting service, which is 68, on the one hand, the arbitration engine immediately pauses the window service and records the interruption scene (saved to the cache), and on the other hand, preempts and allocates resources to the collision warning service, enabling the later-triggered service to perform collision warning operations (such as emergency braking). After the emergency braking is completed, the low-priority service is resumed according to the cache status to continue its execution, that is, the uncompleted operations of the original window lifting service can be resumed after the preemption is completed. In addition, as mentioned above, if the system resources are sufficient at this time, while giving priority to the collision warning service, the window lifting service can still operate in a degraded and linked manner. For example, while performing emergency braking, the window speed is reduced and lifted.

[0058] Finally, it should also be pointed out that based on the software method embodiment of the above dynamic priority arbitration, the hardware alternative only needs to implement the same functional logic (such as service classification, priority calculation, resource arbitration, etc.), which all conform to the technical concept provided by the present invention; in addition, through modular design, the concept of the present invention can also be made compatible with the Autosar architecture and can be integrated into the existing in-vehicle ECU software platform, demonstrating good portability and compatibility. The hardware design scheme mentioned above is only an exemplary embodiment, and the specific component models are not limited in actual operation, that is, the core technical route of the present invention is decoupled from the hardware and can be implemented through various different hardware carriers such as circuits.

[0059] In summary, the main design concept of the present invention includes: proposing a priority quantization method based on multi-dimensional dynamic parameters, achieving adaptive optimization of priorities through dynamic adjustment of weight coefficients, which is significantly different from traditional fixed priorities or single-dimensional scheduling. Moreover, it at least supports the interruption, saving, and restoration of higher dynamic priority services to lower dynamic priority services after calculation. Further, resources are reserved for security services and bandwidth (such as computing resources, bus bandwidth) is guaranteed to ensure the smooth response of security services. In addition, the weights of various dynamic characteristic parameters are flexibly adjusted through load perception to optimize the output dynamic priority scores and achieve precise arbitration. The present invention can dynamically adjust the initial priority according to the real-time requirements, resource occupancy, and dependency relationships of services, timely respond to the service with the highest current priority, and effectively improve the resource utilization efficiency.

[0060] In the embodiments of the present invention, if there are any expressions of orientation, they are relative concepts based on the embodiments. In addition, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that there can be three relationships. For example, A and / or B can represent the situation where A exists alone, A and B exist simultaneously, or B exists alone. Here, A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one of the following" and its similar expressions refer to any combination of these items, including any combination of single items 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 and b and c, where a, b, and c can be single or multiple.

[0061] The structure, features, and effects of the present invention have been described in detail based on the embodiments shown in the drawings above. However, the above are only the preferred embodiments of the present invention. It should be noted that for the technical features involved in the above embodiments and their preferred modes, those skilled in the art can reasonably combine and match them into various equivalent solutions without departing from or changing the design concept and technical effects of the present invention. Therefore, the scope of implementation of the present invention is not limited by the drawings. Any changes made in accordance with the concept of the present invention or modified into equivalent embodiments with equivalent changes still fall within the spirit covered by the description and the drawings, and shall be within the protection scope of the present invention.

Claims

1. A method for arbitrating the priority of a vehicle body domain service program based on a 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; Calculate the dynamic priority of each service currently running in real time according to the initial priority and the dynamic characteristic parameter; Based on the preset preemptive arbitration strategy, resources are allocated according to the dynamic priority of each service, and then service scheduling is performed and the corresponding service is executed, specifically including: enabling the service with a higher dynamic priority after arbitration to preempt system resources and give priority to processing, and simultaneously performing any of the following processing on the service with a lower dynamic priority after arbitration: The service with a lower dynamic priority is suspended and the execution status at the time of the interruption is recorded; or, based on the system resource situation, the service with a lower dynamic priority is linked with the service with a higher dynamic priority.

2. The method for arbitrating the priority of vehicle body domain service programs 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 method for arbitrating the priority of vehicle body domain service programs based on SOA architecture according to claim 1 is characterized in that: The real-time calculation of the dynamic priority of each service currently running includes calculation 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 quantified real-time parameter, C is the quantified resource occupancy parameter, and D is the quantified service dependency parameter; α, β, and γ are the pre-set initial weight coefficients corresponding to each dynamic feature parameter.

4. The method for arbitrating the priority of a vehicle body domain service program based on SOA architecture according to claim 3 is characterized in that: 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.

5. The method for arbitrating the priority of vehicle body domain service programs 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 specified value range; According to the proportion of system resources occupied by the vehicle body domain service, configure the resource occupancy rate parameter value of the service within a predetermined value range, 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.

6. The method for arbitrating the priority of vehicle body domain service programs based on SOA architecture according to claim 1 is characterized in that: Defining the initial priority for each type of service includes: Divide services into safety, comfort and infotainment categories in advance, and assign high, medium and low priorities to safety services, comfort services and infotainment services in turn; Different initial priority values ​​are set for each type of service based on the established service importance and real-time requirements.

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

8. The method for arbitrating the priority of a vehicle body domain service program based on a SOA architecture according to any one of claims 1 to 7, 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.

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

Images