SOA service arbitration method and device, vehicle terminal, electronic equipment and storage medium

Abstract

The invention discloses an SOA service arbitration method and device, a vehicle terminal, electronic equipment and a storage medium, and solves the problems of low SOA service arbitration response efficiency and low resource utilization rate in the prior art. The SOA service arbitration method comprises the steps that a plurality of service requests are received, each service request is marked with a timestamp and a priority label, the priority label comprises a first priority or a second priority, and the plurality of service requests comprise a first service request marked with the first priority and a second service request marked with the second priority; generating a retention time window for the first service request; under the condition that the arbitration triggering condition is met, whether the retention time window is overtime or not is checked; and if the overtime retention time window is detected, triggering a degradation strategy to skip an execution process of the overtime first service request.

Description

Technical Field

[0001] This application relates to the field of in-vehicle service technology, specifically to a service-oriented architecture (Service- Oriented Architecture (SOA) services include arbitration methods and devices, vehicle terminals, electronic devices, and storage media. Background Technology

[0002] As vehicles become increasingly intelligent and connected, Service-Oriented Architecture (SOA) has become the core of the next generation of automotive electronic and electrical architectures. By decoupling vehicle functions into reusable, loosely coupled services, SOA significantly improves the flexibility and scalability of software development. In SOA systems, when multiple client applications concurrently request the same service resource—for example, multiple Advanced Driver Assistance Systems (ADAS) simultaneously requesting camera data—a service arbitration mechanism must be used to determine the processing order of the requests to avoid resource conflicts and ensure critical functionality.

[0003] Currently, mainstream service arbitration strategies still fall short in terms of overall efficiency and reliability in dynamic and complex in-vehicle operating environments, often leading to problems such as system response delays and low resource utilization efficiency, making it difficult to meet the stringent requirements of real-time performance and determinism in scenarios such as advanced autonomous driving. Summary of the Invention

[0004] In view of this, embodiments of this application provide an SOA service arbitration method and apparatus, a vehicle terminal, an electronic device, and a storage medium, which solve the problems of low response efficiency and low resource utilization in SOA service arbitration in the prior art.

[0005] The first aspect of this application provides an SOA service arbitration method, comprising: receiving multiple service requests, each service request being marked with a timestamp and a priority label, the priority label including a first priority or a second priority, the multiple service requests including a first service request marked with a first priority and a second service request marked with a second priority; generating a retention time window for the first service request; checking whether the retention time window has timed out if the arbitration triggering condition is met; if a timed-out retention time window is detected, triggering a degradation strategy to skip the execution process of the timed-out first service request.

[0006] In conjunction with the first aspect, in some possible implementations, if a timeout retention window is detected, triggering a degradation strategy includes: if a timeout retention window is detected, selecting and executing the second service request with the earliest timestamp; or, maintaining an idle state; or, executing the default service.

[0007] In conjunction with the first aspect, in some possible implementations, if a timeout retention window is detected, the SOA service arbitration method also includes: adding a timeout label to the first service request that has timed out, with the timeout label having the same priority level as the second priority.

[0008] In conjunction with the first aspect, among some possible implementations, the SOA service arbitration method also includes: if no timeout retention window is found, iterate through multiple service requests and check if there is a first service request that has not timed out; if it exists, execute the first service request with the earliest timestamp; if it does not exist, execute the service request with the earliest timestamp.

[0009] In conjunction with the first aspect, in some possible implementations, checking whether the retention time window has timed out when the arbitration triggering condition is met includes: checking whether the retention time window has timed out in the order of timestamps when the arbitration triggering condition is met.

[0010] In conjunction with the first aspect, some possible implementations include, before generating a retention time window for the first service request, storing multiple service requests in the order of their timestamps.

[0011] In conjunction with the first aspect, in some possible implementations, checking whether the retention window has timed out when the arbitration triggering conditions are met includes: checking whether the retention window has timed out when a new service request is received and no service request is in the execution state; or, checking whether the retention window has timed out when the current service request has been completed.

[0012] A second aspect of this application provides an SOA service arbitration apparatus, comprising: a collection module configured to receive multiple service requests, each service request being marked with a timestamp and a priority label, the priority label including a first priority or a second priority, the multiple service requests including a first service request marked with a first priority and a second service request marked with a second priority; a buffer configured to store the multiple service requests and generate a retention time window for the first service request; and an arbitrator configured to, when the arbitration triggering condition is met, check whether the retention time window has timed out, and if a timed-out retention time window is detected, trigger a degradation strategy to skip the execution process of the timed-out first service request.

[0013] In conjunction with the second aspect, in some possible implementations, the SOA service arbitration device also includes an execution module; if a timeout retention window is detected, triggering a degradation strategy includes: if the arbitrator detects a timeout retention window, selecting the second service request with the earliest timestamp; the execution module executes the second service request with the earliest timestamp; or, the execution module remains idle; or, the execution module executes the default service.

[0014] A third aspect of this application provides a vehicle terminal, including an SOA service arbitration device provided in any embodiment of this application, or an SOA service arbitration method provided in any embodiment of this application.

[0015] A fourth aspect of this application provides an electronic device, including: a processor; and a memory storing a computer program, which is executed by the processor to implement the SOA service arbitration method provided in any embodiment of this application.

[0016] The fifth aspect of this application provides a computer-readable storage medium storing a computer program, which is executed by a processor to implement the SOA service arbitration method provided in any embodiment of this application.

[0017] According to the SOA service arbitration method and apparatus, vehicle terminal, electronic device and storage medium provided in the embodiments of this application, on the one hand, service arbitration is performed by combining timestamps and priorities, which solves the problem of execution order disorder caused by Ethernet latency; on the other hand, by setting a configurable retention time window for high-priority service requests, low-priority service requests are forcibly blocked within the retention time window, ensuring that critical services, i.e., high-priority service requests, preempt resources; on the third hand, in the case of retention time window timeout, a degradation strategy is configured to skip timeout high-priority requests, avoid blocking subsequent service requests, and improve the robustness of the system. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of SOA in the AUTOSAR AP platform.

[0019] Figure 2 This is a flowchart illustrating the SOA service arbitration method provided in the first embodiment of this application.

[0020] Figure 3 This is a schematic diagram illustrating the execution process of an SOA service arbitration method provided in an embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating the SOA service arbitration method provided in the second embodiment of this application.

[0022] Figure 5This demonstrates a typical application scenario of the SOA service arbitration method in the automotive environment.

[0023] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application.

[0024] Figure 7 This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application.

[0025] Figure 8 This is a structural block diagram of an SOA service arbitration device provided in an embodiment of this application. Detailed Implementation

[0026] In traditional Automotive Open System Architecture Adaptive Platform (AUTOSAR AP) platforms, Service-Oriented Architecture (SOA) arbitration relies on static priorities or message arrival order, failing to consider priority inversion issues caused by Ethernet transmission latency. For example, if a high-priority message arrives later due to network congestion, a low-priority message may be processed first.

[0027] While traditional arbitration strategies such as fixed priority are theoretically simple and effective, the inventors, through in-depth analysis and testing, discovered a fundamental contradiction in the dynamic Service-Oriented Architecture (SOA) environment of vehicles: the conflict between the "static priority" of high-priority requests and their "dynamic timeliness." Specifically, a service request marked as high-priority (such as an emergency avoidance request based on sensor data at a certain moment) has a time-limited urgency. If it waits too long in the queue due to blocking by preceding long tasks or resource lock contention, it may fail. If it is still prioritized for execution due to its static high-priority label, two serious problems arise: first, the execution result may be erroneous or dangerous (e.g., making control decisions based on outdated data); second, this "outdated" request will continuously block the queue, depriving other valid requests (including other real-time high-priority requests and all low-priority requests) of the execution opportunity, leading to a decrease in overall system throughput and an increase in response latency—the so-called "priority inversion" or "starvation" phenomenon. The lack of a mechanism to detect and handle this "request failure" state in existing solutions is a key reason for the low efficiency of system service arbitration response and low resource utilization.

[0028] In view of this, this application proposes a dynamic service arbitration method with timeliness awareness, which resolves the above contradictions by imposing a "reservation time window" on high-priority requests and introducing a timeout degradation mechanism.

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] In the accompanying drawings, the dimensions of layers and regions may be exaggerated for clarity. It is understood that when a structure is referred to as being "on" or "below" another structure, the structure may be directly on or below the other structure, or there may be intermediate structures. The same reference numerals always indicate the same structure. Structures referred to herein include any of the following: membrane, element, device, component, assembly.

[0031] When a structure is referred to as being “connected” to another structure, it can be directly connected to the other structure or indirectly connected to the other structure by means of one or more intermediate structures placed between them.

[0032] Figure 1 This is a schematic diagram of the Service-Oriented Architecture (SOA) within the Automotive Open System Architecture Adaptive Platform (AUTOSAR AP). Figure 1As shown, the SOA architecture macroscopically includes a vehicle terminal 10 and a cloud 20. The vehicle terminal 10 and the cloud 20 communicate through a telematics unit (such as a T-Box) and a mobile network (4G / 5G) to achieve functions such as over-the-air (OTA) software upgrades, data backhaul, and cloud monitoring. In this embodiment, the vehicle terminal 10 is the core platform of the technical solution of this application. Its specific form can be an in-vehicle infotainment (IVI), an autonomous driving domain controller (ADDC), a body domain controller (BDC), or a zone controller, etc. It integrates an SOA service arbitration device 100, or runs software of the service arbitration method provided in this application embodiment on its main processor to ensure efficient and secure resolution of resource competition among services within the vehicle.

[0033] The service arbitration device 100 serves to ensure efficient, secure, and deterministic resolution of competition for shared computing resources, communication bandwidth, or physical devices (such as sensors and execution modules) among services within the vehicle terminal 10. In other words, although the vehicle terminal 10 as a whole exists within a larger SOA architecture that may include the cloud, the service arbitration device 100 and its arbitration process are purely local behaviors of the vehicle terminal 10. Their decisions do not depend on or involve real-time information interaction with the cloud 20. The cloud 20 may periodically obtain arbitration-related logs for analysis but will not participate in the real-time arbitration decision-making cycle.

[0034] Figure 2 This is a flowchart illustrating the SOA service arbitration method provided in the first embodiment of this application. Figure 3 This is a schematic diagram illustrating the execution process of an SOA service arbitration method provided in an embodiment of this application. (In conjunction with...) Figure 2 and Figure 3 As shown, the SOA arbitration methodology introduces dynamic timeliness management. The SOA arbitration methodology includes: Step S110: Receive multiple service requests. This process can be executed by the acquisition module 11.

[0035] Service requests are marked with timestamps and priority tags. Priority tags include first priority P_H or second priority P_L. Multiple service requests include a first service request marked with first priority and a second service request marked with second priority.

[0036] Service requests are initiated by service consumers (such as autonomous driving modules and in-vehicle entertainment systems) to access service providers (such as camera data services and motor control services). Each service request carries a timestamp and a priority tag. For example, service requests may also carry a service identifier, which serves as a unique identifier for the service. Priority tags include at least a first priority and a second priority. For example, an emergency braking request is tagged as a first priority, and a song switching request as a second priority. Multiple service requests may include both a first service request tagged as a first priority and a second service request tagged as a second priority.

[0037] In one embodiment, the timestamp is marked with TSN / QoS to adapt to industrial-grade real-time networks and improve timestamp reliability. Specifically, this application deeply integrates Time-Sensitive Networking (TSN) and Ethernet Quality of Service (QoS) mechanisms to ensure timestamp integrity and transmission reliability. When generating a service request, the service consumer not only embeds the timestamp as an application-layer data field but also associates its key time information with the network layer. One implementation method is to use IEEE 802.1AS-Rev (Generalized Precise Time Protocol gPTP) in the TSN standard to establish a sub-microsecond precision global clock synchronization within the vehicle. Before calling the service interface, the service consumer's application first queries the local gPTP synchronization clock to generate a 64-bit "logical transmission timestamp." Subsequently, when encapsulating the request into an Ethernet frame, the system network stack driver layer or dedicated hardware (such as a TSN-enabled Ethernet controller) actively intervenes. The hash value of the timestamp or a simplified sequence number can be filled into a specific field in the Ethernet frame header, for example, as supplementary information to the Priority Code Point (PCP) in the VLAN tag (IEEE 802.1Q), or using metadata from the IEEE 802.1Qci flow filtering protocol. More importantly, the data stream corresponding to this request can be configured on the TSN switch with deterministic scheduling gating and reserved bandwidth, which itself provides hardware-level protection for the time sensitivity of high-priority requests in the form of network configuration. When the network port where the acquisition module 11 is located receives the Ethernet frame, its TSN-aware network interface controller (NIC) can parse the time-related marker and cross-check it with the application layer timestamp within the frame. If a difference exceeding the tolerance is found between the network layer timestamp and the application layer timestamp (which may indicate unacceptable out-of-order or delay during transmission), the acquisition module 11 can immediately mark the frame as "suspicious" or discard it directly, and send an error response to the service consumer requesting retransmission. This dual time guarantee mechanism of "application layer-network layer" greatly improves the reliability and anti-interference capability of timestamps as arbitration basis in complex vehicle network environments.

[0038] In one embodiment, the timestamp is provided by a local PTP clock synchronization module and uses a microsecond-level timestamp to ensure a logical timing error of <10μs and an arbitration accuracy of ≥99.9%. To achieve sub-millisecond or even microsecond-level arbitration accuracy, this application imposes stringent requirements on the generation and management of timestamps. Inside the vehicle terminal 10, a global time domain is established, driven by a Precision Time Protocol (PTP) master clock. This master clock is typically provided by the vehicle's central gateway or a domain controller with a highly stable crystal oscillator. The processor (or dedicated time synchronization coprocessor) housing the service arbitration device 100 maintains strict synchronization with the master clock via the PTP slave clock protocol. The local PTP clock synchronization module typically includes a high-precision digital phase-locked loop (DPLL) and a dedicated hardware timestamp unit (TSU). When a service consumer's software call needs to send a request, it doesn't simply call the operating system's `gettimeofday()` function (which typically has significant jitter and uncertainty). Instead, it uses a dedicated, lightweight library or Direct Memory Access (DMA) driver that bypasses the OS kernel to initiate a request to the local TSU to "get the current PTP time". Within the same clock cycle of receiving the instruction, the TSU hardware directly reads the current time value from a counter register phase-locked with the PTP clock source. This value is typically a nanosecond or microsecond integer counting from a certain epoch. The generation point of this timestamp is strictly controlled to be at the "last moment" before the service request message body is serialized and about to be sent to the network stack or inter-process communication (IPC) queue, minimizing additional latency introduced by software processing. Subsequently, this timestamp is tightly bound to the request payload as part of the request metadata. At the arbitration end, the acquisition module 11, upon receiving the request, also uses its local PTP clock, synchronized with the sender, to record an "arrival timestamp". By comparing the sending and arriving timestamps, the dwell time of the request on the communication path can be accurately calculated. This is of significant reference value for subsequently evaluating the "freshness" of the request and dynamically adjusting its retention time window. This hardware-assisted, end-to-end PTP synchronization scheme ensures that the timestamps of requests from different service consumers are comparable and consistent under the same high-precision, low-jitter global time reference. Real-world testing data shows that, in a typical hybrid architecture of in-vehicle controller area network (IVN) and Ethernet, after adopting the above scheme, the logical timing error of cross-ECU service requests (i.e., whether the timestamp value of a request that should have been sent earlier is indeed less than that of a later request) can be stably controlled within 10 microseconds. This makes the timestamp-based sorting highly reliable; the probability of the arbitrator making an incorrect sort due to timestamp errors is less than 0.1%, thus supporting the high reliability target of arbitration accuracy ≥99.9%.

[0039] Step S120: Generate a retention time window for the first service request. This execution process can be performed by buffer 12.

[0040] The retention window can be represented as: ReservationWindow = CurrentTime + T_High, where CurrentTime represents the time at which the retention window is generated, and T_High is the configured retention duration. The length of T_High can be configured based on the service type, vehicle status, or system policy. For example, for a vehicle stability control request, the retention window might be set to 10ms; for a navigation route update request, it might be set to 500ms. In one embodiment, the same T_High can be configured for all first service requests, for example, T_High can be set to 50ms.

[0041] In one embodiment, step S120 specifically involves generating a retention time window for the first service request when storing it. For example, after step S110, according to step S120, multiple service requests are stored in timestamp order, and a retention time window is generated for the first service request when storing it. Storing requests in timestamp order facilitates the order check in step S130, simplifying the logical complexity of "finding the earliest service request" and "order check timeout," reducing the algorithm's time overhead (e.g., eliminating the need for sorting each time), and more importantly, ensuring the predictability and fairness of the arbitration process in the time dimension. This is crucial for in-vehicle real-time systems that need to meet time-series constraints. Ordered storage brings fundamental simplification to the algorithm. Since the queue is always stored in timestamp order, the "service request with the earliest timestamp" is the head node of the queue. For "order check timeout," the timeout detector 133 can simply traverse sequentially from the head of the queue. Since timestamps are monotonically increasing, theoretically, if a P_H request at the top of the queue doesn't time out, then service requests that are later in the queue (at the back of the queue) are less likely to time out (assuming their T_High configurations are similar). This provides a potential short-circuit optimization opportunity for the checking process: once the first non-timeout P_H request is encountered, timeout checks on subsequent P_H requests can be stopped, as they are guaranteed not to have timed out either. This significantly reduces the computational overhead in the worst-case scenario.

[0042] Step S120 forms the data structure foundation for the correct operation of the SOA arbitration method. Buffer 12 internally implements a high-efficiency data structure based on multiple indices for managing service requests. It is not merely a simple first-in-first-out queue, but a sorted container with timestamps as the primary key, implemented using, for example, a red-black tree or skip list, to ensure that the time complexity of insertion, deletion, and sequential traversal operations is logarithmic. This is crucial for in-vehicle scenarios that may have dozens of concurrent requests.

[0043] If we compare service arbitration to a "station entry" scenario, the reservation time window can be seen as a "VIP ticket," granting priority passage through the gate. Similarly, the first service request with a reservation time window has priority for execution. This means setting a configurable reservation time window for high-priority requests (i.e., the first service request), forcibly blocking low-priority requests within the reservation time window to ensure high-priority requests preempt resources. This analogy vividly illustrates the "privileged" nature of the reservation time window. In the arbitrator's logic, there exists a global "high-priority service valid" flag. This flag is set when any P_H request that hasn't timed out exists in buffer 12. The priority reservation unit 132 (or the arbitrator's core logic) checks this flag first when making a decision. If the flag is true, any P_L request will not be included in the candidate range for this arbitration, i.e., it will be "forcibly blocked." This blocking is logical; the request remains in the queue, but its status is marked as "suspended due to high-priority request waiting." This flag is only cleared after all P_H requests have been processed (executed or timed out and degraded), giving P_L requests a chance to be scheduled. This ensures that high-priority requests have absolute preemption of resources during the "fresh" period.

[0044] However, in this embodiment, even if the first service request has priority, it may not necessarily be executed first. This is because, considering Ethernet congestion, the retention window for the first service request may time out. In this case, under the traditional fixed priority strategy, the timed-out first service request will continue to block all subsequent service requests. This application further provides a degradation strategy to trigger when the retention window for the first service request times out, to skip the execution process of the timed-out first service request, i.e., steps S130 and S140, thereby avoiding blocking subsequent service requests and causing problems such as system errors and disordered execution order. In other words, the first service request in this application is a "time-limited privilege," and the privilege will expire. The root causes of retention window timeout can be varied: in addition to delays caused by network congestion, it may also be that the service provider is busy for a long time, is preempted by other higher-priority system tasks (such as interrupts), or the request itself needs to wait for an external event (such as sensor data ready) and cannot be completed for a long time. Regardless of the reason, retention window timeout, as an objective and measurable indicator, signifies that the "golden processing time" of the service request has passed. At this point, continuing to insist on its priority is detrimental to the system. The innovation of this application lies in proactively identifying and handling this "privilege expired" state, rather than allowing it to cause blockages as in traditional systems.

[0045] Step S130: If the arbitration triggering conditions are met, check whether the retention time window has timed out. This execution process can be performed by the timeout detector 133.

[0046] The execution of this inspection step is triggered by certain conditions. For example, arbitration trigger conditions include: receiving a new service request and no service request is currently in execution (i.e., the execution module is idle), or the currently executing service request has been completed (i.e., feedback information indicating the completion of the current service request has been received). The design of the arbitration trigger conditions determines the arbitrator's response mode and real-time performance. This embodiment supports a hybrid trigger mode to balance response speed and efficiency.

[0047] Specifically, the buffer already stores multiple service requests, including the first service request and the second service request.

[0048] In one embodiment, when a new service request is received and the execution module is idle, a timeout check is performed. For example, after the acquisition module 11 receives a new service request and stores it in buffer 12, it sends a hardware interrupt or software signal to the arbitrator 13. The interrupt service routine or signal handling function of the arbitrator 13 first checks the status register of the execution module 14. If the status register shows "idle," a timeout check is immediately initiated. This mode has extremely low latency and is suitable for scenarios with strict requirements on the response time of individual service requests. To prevent interrupt storms under extremely high request rates, a minimum arbitration interval, such as 1 μs, can be set, within which subsequent interrupts arriving will be merged. In another embodiment, the check is performed when feedback information indicating that the current service request has been completed is received.

[0049] In another embodiment, a timeout check is performed when a service request being executed has completed. This is a more common and robust pattern. After completing a service request call, execution module 14 sends a "task completed" message (possibly via a message queue, mailbox, or shared memory flag) to arbitrator 13. Arbitrator 13's main loop or a dedicated low-priority background task polls or blocks waiting for this message. Once received, a timeout check is triggered. This pattern forms a stable "execution-arbitration-execution" pipeline, ensuring that CPU resources are continuously used for request processing and avoiding context switching overhead caused by frequent interruptions.

[0050] In another embodiment, a periodic check for timeouts is performed. In this case, the arbitrator 13 can be configured with a high-precision timer (such as an OS Tick or hardware Timer) to trigger the arbitration check at a fixed period (e.g., T_Cycle = 1ms). This approach provides deterministic, periodic scheduling opportunities, consistent with the periodic task model commonly found in automotive control systems. Even without new requests arriving or task completion events, the timer ensures that the system periodically checks the queue status, processes potentially timed-out requests, and prevents "starvation."

[0051] In one embodiment, if the arbitration trigger condition is met, the buffer is traversed to check if the retention time window has timed out. In this case, the first service request corresponding to the timed-out retention time window should be the first service request with the earliest timestamp. Once a timed-out retention time window is detected, step S140 is executed immediately.

[0052] The implementation of the "traversal check" requires careful design to balance accuracy and performance. The timeout detector 133 maintains a cursor pointing to the current check position. Each time arbitration is triggered, it sequentially traverses the sorted container of buffer 12, starting from the cursor position (usually the head of the queue). For each node, the following operations are performed: 1) Determine if it is a P_H request; 2) If so, read its stored expiry time ExpiryTime; 3) Obtain the current system time T_Current; 4) Compare if (T_Current>= ExpiryTime). The key here is obtaining "T_Current". To ensure the accuracy of the judgment, T_Current must come from the same monotonically increasing clock source (i.e., the PTP clock) as the CurrentTime used to generate ExpiryTime. The comparison operation itself should use atomic read operations to avoid clock jumps at the moment of comparison. "Immediately execute step S140" means adopting a "first-hit" strategy. Once a timed-out P_H request is found, the traversal stops immediately, and the arbitration logic jumps to the degradation processing flow. This is because, from a system perspective, the mere existence of one timed-out high-priority service request is sufficient proof that the current scheduling state is abnormal (the high-priority request was not processed in a timely manner), requiring immediate corrective action (i.e., a degradation strategy). Further inspection of subsequent requests may uncover more timed-out requests, but the corrective action only needs to be performed once, and processing the earliest timed-out service request is usually the most reasonable approach. The cursor is reset to the head of the queue after each successful arbitration (whether the request was executed or the timeout was resolved) to ensure fairness.

[0053] Step S140: If a timeout retention window is detected, a degradation strategy is triggered. This process can be executed by execution module 14.

[0054] The core purpose of the degradation strategy is to skip the execution process of the first service request that has timed out. The system will no longer attempt to execute this "outdated" high-priority request, allowing the arbitrator to continue processing subsequent valid service requests. This significantly improves the system's response efficiency and resource utilization, and avoids the risk of executing expired instructions.

[0055] According to the SOA service arbitration method provided in this embodiment, the closed-loop management of "generating a retention time window - checking for timeout - triggering a degradation strategy" fundamentally solves the problems of outdated high-priority requests (i.e., the first service request) invalidally occupying arbitration resources, or the system not knowing which service request to execute, resulting in system errors, or service request packet loss, thereby improving the robustness and reliability of SOA service arbitration.

[0056] In one embodiment, the degradation strategy in step S140 includes multiple strategies, and any one of the multiple strategies can be executed if a timeout retention window is detected.

[0057] For example, the degradation strategy includes a first strategy, which selects and executes the second service request with the earliest timestamp. That is, the timed-out first service request is skipped, and the second service request that has been waiting the longest in the buffer queue is executed instead. This reflects the fairness idea of ​​"punishing" the failed first service request while "compensating" the second service request, and can effectively alleviate the "starvation" problem of low-priority requests.

[0058] The detailed process of the first strategy is as follows: When arbitrator 13 decides to adopt this strategy, it first needs to locate the target in the queue. Since the queue is sorted by timestamp, finding the "earliest P_L request" is efficient; it only needs to traverse from the head and find the first request with the priority label P_L and the status "waiting". Then, the arbitrator instructs execution module 14 to execute the earliest P_L request that was just found. Before calling the P_L service, execution module 14 may optionally attach a flag to its call context to inform the service provider that "this call occurred after a high-priority request timed out and was downgraded". Some service providers may adjust their internal behavior based on this information (e.g., using slightly older but available cached data instead of triggering a completely new, time-consuming data collection).

[0059] For example, a degradation strategy includes a second strategy: maintaining an idle state. That is, the arbitrator does not execute any service requests, and may enter a low-power state or perform background maintenance tasks until the next new service request arrives. This is suitable for scenarios with energy-sensitive or extremely conservative security requirements, ensuring that no risk is introduced by scheduling a potentially problematic service request.

[0060] Strategy Two (Safe Suspension) is implemented more cautiously. When this strategy is triggered, Arbitrator 13 will issue an event to the system stating that "arbitration has entered a safe hold state." Upon receiving the instruction, Execution Module 14 will not initiate any new service calls. Simultaneously, Arbitrator 13 itself can initiate a "watchdog process." The core of this strategy is "restraining action by remaining still," proactively suspending new operations that might introduce further uncertainty when the system state becomes uncertain (e.g., high-priority service request timeout), preventing a chain reaction of failures.

[0061] For example, a degradation strategy includes a third strategy, which executes a pre-defined default service. This default service is typically a safe, low-resource-consumption "no-operation" or "heartbeat-keeping" service. This maintains the service provider's liveness while avoiding unpredictable states caused by arbitrator idleness.

[0062] The third strategy aims to maintain the basic liveness and determinism of the system. The system needs to predefine one or more "default services." These services undergo rigorous testing and possess the following characteristics: extremely short and deterministic execution time (e.g., <10μs), no side effects, and minimal resource consumption (no dynamic memory allocation, no use of shared peripherals). A typical example is sending a heartbeat message to a local loopback service interface, whose implementation simply updates a local counter and returns success. Alternatively, a "no-operation proxy" can be invoked, which does not actually call any backend service but follows the complete service call protocol and returns a pre-defined security response (e.g., "Status: Received"). When this strategy is adopted, execution module 14 invokes this pre-defined default service. The beauty of this strategy is that it maintains the "heartbeat" of the service framework (such as the AUTOSAR RPC mechanism). Some service providers or underlying communication middleware may have timeout mechanisms; if no requests are received for an extended period, it may be mistakenly judged as a communication failure and enter an error state. Periodically executing the default service can prevent this. At the same time, it also provides the arbitrator with a "harmless" output, allowing the entire arbitration state machine to continue moving forward instead of stagnating at the degrade decision point.

[0063] The SOA service arbitration method provided in this embodiment offers a variety of configurable degradation strategies, enabling system designers to make fine-tuning adjustments based on functional safety levels and application scenarios. For example, for a service arbitrator related to brake control, a second strategy may be adopted to ensure absolute safety; for a service arbitrator of an infotainment system, a first strategy may be adopted to optimize the user experience.

[0064] Figure 4 This is a flowchart illustrating the SOA service arbitration method provided in the second embodiment of this application. Figure 4 The SOA service arbitration method shown is in Figure 2 Based on the SOA service arbitration method shown, combined with Figure 4 and Figure 3 As shown, according to step S140, if a timeout retention window is detected, the method further includes: adding a timeout label TIMEOUT to the timed-out first service request, where the timeout label TIMEOUT has the same priority level as the second priority. This is equivalent to downgrading the timed-out first service request, reducing its priority from the first priority to the second priority. Adding a "TIMEOUT" tag is a crucial state management enhancement. It's not just a simple boolean flag, but metadata with rich semantics. Adding TIMEOUT is an atomic operation and triggers a series of related operations: 1) Immediately update the "Valid Priority" attribute of the service request in the buffer sorting container. From then on, this request is treated as a P_L request in all sorting and filtering logic. 2) Optionally, reposition the service request in the sorting container. Although its timestamp remains unchanged, its physical location may not need to be changed because it now belongs to the P_L category, and the queue as a whole is globally sorted by timestamp (regardless of priority). However, to optimize the efficiency of subsequent searches for the "earliest P_L request," it can be linked to a separate "P_L request list." 3) Trigger a "Priority Degradation" event. This event can be captured by the System Health Monitoring (SHM) module for logging, updating counters, or even as input to trigger higher-level fault response mechanisms such as feature degradation.

[0065] In this case, in one embodiment, the SOA service arbitration method further includes: Step S410: If no timeout retention window is found, iterate through multiple service requests and check if there is a first service request that has not timed out. This execution process can be performed by the timeout detector 133.

[0066] Specifically, if the process of traversing the buffer fails to find a timeout retention window, the system retraces the multiple service requests in the buffer in timestamp order to check if there is a first service request that has not timed out. This is the key branch point of the arbitration logic. When the initial traversal (timeout check) does not "hit" any timeout window, the system enters a "steady-state" decision process. Step S410, "checking if there is a first service request that has not timed out," can be efficiently completed by querying the global "high-priority service valid" flag without retracing. If the flag is true, the system proceeds directly to step S420; if it is false, it means that either there are no P_H requests in the queue, or all P_H requests have been marked TIMEOUT (i.e., downgraded), and the system proceeds to step S430.

[0067] Step S420: If a high-priority request exists, execute the first service request with the earliest timestamp. This execution process can be performed by execution module 14. This is the purest embodiment of the high-priority principle. Since a high-priority request that has not timed out has been confirmed, arbitrator 13 does not need to consider any P_L requests. It only needs to start from the head of the queue and find the first P_H request with a "waiting" status and no TIMEOUT tag. Since the queue is sorted by timestamp, this request is naturally also the "earliest" P_H request that has not timed out. Execution module 14 is instructed to call the service corresponding to this request.

[0068] In step S430, if no such request exists, the service request with the earliest timestamp is executed. This execution process can be performed by execution module 14. At this time, the buffer includes the second service request, and may also include the first service request that has been degraded after timeout. The service request with the earliest timestamp among them is selected for execution. At this time, the queue enters the "unprivileged request" state. The arbitrator needs to make a selection from all the remaining requests in the "waiting" state. The decision rule for step S430 is "earliest global logical timestamp priority". In implementation, since the queue itself is globally sorted by timestamp, the head node of the queue is the service request with the earliest timestamp, regardless of its original priority, whether it is P_H (already labeled TIMEOUT) or P_L. Arbitrator 13 only needs to retrieve the head node and hand it over to execution module 14. This is actually a degenerate but absolutely fair scheduling strategy, ensuring that as long as the queue is not empty, at least one request will be processed, and the system will not deadlock.

[0069] The SOA service arbitration method provided in this embodiment further optimizes the completeness and fairness of the arbitration logic. In this embodiment, the average waiting time for high-priority service requests within the retention time window is <5ms, meeting ASIL-D level real-time requirements. Under simulated network congestion scenarios (latency >100ms), the system can still correctly execute arbitration without priority inversion. Low-priority service requests are executed in timestamp order when there is no contention from high-priority service requests, avoiding resource waste.

[0070] Figure 5 This demonstrates a typical application scenario of the SOA service arbitration method in an automotive environment. (See also...) Figure 5 The hybrid arbitration execution process, based on timestamps and priorities, is fundamentally divided into four stages: initialization, request submission, hybrid arbitration, and low-priority execution + recovery. It involves the coordinated operation of the service requester, request acquisition unit, PTP clock synchronization unit, arbitration buffer unit, hybrid arbitration unit, and service execution unit. Key parameters are the high-priority retention window T_{high} = 30ms and the arbitration period T_{Cycle} = 1ms. The specific execution process is as follows: Phase 1: Initialization (T=0ms).

[0071] The PTP clock synchronization unit provides a microsecond-level synchronization clock, serving as the time base for the entire process. Arbitrator 13 loads arbitration parameters and initiates 1ms-period arbitration. Buffer 12 is initialized, enabling the arbitration method.

[0072] Phase 2: Request submission (T=0~20ms).

[0073] At T=0ms, the service consumer sends low-priority service request L3, high-priority service request L0, and high-priority service request L0_002. Low-priority service request L3 and high-priority service request L0 are transmitted with a 20ms Ethernet delay, verified by the acquisition module 11, and stored in the arbitration buffer 12 according to their timestamps. Due to network congestion, high-priority service request L0_002 is not delivered.

[0074] When T=20ms, the request acquisition module 11 receives the low-priority service request L3 and the high-priority service request L0, and verifies the service requests. The arbitration buffer 12 rearranges the requests according to the timestamp (e.g., L0-L3), and at the same time generates a retention time window (20+30=50ms) for the high-priority service request L0.

[0075] Phase 3: Hybrid arbitration (T=20~50ms).

[0076] Arbitration is triggered at T=20ms. If the high-priority service request L0 is detected to have not timed out, the low-priority service request L3 is blocked. Arbitrator 13 issues an instruction to execute high-priority service request L0 to execution module 14. After execution module 14 reports that high-priority service request L0 has been successfully executed, buffer 12 removes high-priority service request L0.

[0077] When the timeout of the high-priority service request L0_002 was detected at T=50ms, the arbitrator 13 triggered a degradation strategy, such as executing a safe rollback logic, and the execution module 14 reported that the degradation was successfully executed.

[0078] Phase 4: Low-priority execution + recovery (T=51~65ms).

[0079] Arbitration is triggered at T=51ms. Since there is no valid high-priority service request L0, low-priority service request L3 is executed. After the execution module 14 reports that low-priority service request L3 was successfully executed, the arbitration buffer 12 removes low-priority service request L3.

[0080] At T=65ms, the service consumer resends a new high-priority service request L0, and arbitrator 13 terminates the downgrade strategy, completing the entire arbitration process.

[0081] This application also provides an SOA service arbitration device. Figure 6 This is a structural block diagram of an SOA service arbitration device provided in one embodiment of this application. Specifically, as... Figure 6As shown, the SOA service arbitration device 100 includes: a data acquisition module 11, a buffer 12, an arbitrator 13, and an execution module 14.

[0082] The acquisition module 11 is configured to receive multiple service requests. Specifically, the acquisition module 11 receives service requests sent by various service consumers. Each service request carries a service identifier, a timestamp, and a priority tag when sent by the consumer. The priority tag includes either a first priority or a second priority. Multiple service requests include a first service request marked with a first priority and a second service request marked with a second priority. That is, the first service request can be considered a high-priority service request, and the second service request can be considered a low-priority service request.

[0083] Buffer 12 is configured to store multiple service requests and generate a reservation window for the first service request. Specifically, buffer 12 stores service requests to be processed, which are arranged in ascending order of timestamps within the buffer. At the same time, buffer 12 is also used to maintain reservation windows for high-priority requests, such as generating reservation windows for high-priority requests.

[0084] Arbitrator 13 is the core module for service arbitration processing, comprising a timestamp sorter 131, a priority retainer 132, and a timeout detector 133. The timestamp sorter 131 is configured to sort service requests in the buffer by their sending timestamps. The priority retainer 132 is configured to reserve execution eligibility for high-priority requests and block low-priority requests within the retention time window. The timeout detector 133 is configured to mark high-priority service requests that time out within the retention time window as timeouts and trigger a degradation strategy.

[0085] The execution module 14 is configured to execute the service request based on the result of the arbitrator 13 and return the execution completion status to the arbitrator 13.

[0086] In one embodiment, the acquisition module 11 is configured to receive multiple service requests, each service request being marked with a timestamp and a priority label. The priority label includes either a first priority or a second priority. The multiple service requests include a first service request marked with the first priority and a second service request marked with the second priority. The buffer 12 is configured to generate a retention time window for the first service request. The arbitrator 13 is configured to check whether the retention time window has timed out if the arbitration triggering condition is met; if a timed-out time window is detected, a degradation strategy is triggered to skip the execution process of the timed-out first service request. The execution module 14 is configured to execute the degradation strategy.

[0087] In one embodiment, the degradation strategy includes: selecting and executing the second service request with the earliest timestamp; or maintaining an idle state; or executing the default service.

[0088] In one embodiment, the arbitrator 13 is further configured to add a timeout tag to the first service request that has timed out if a timeout retention window is detected, with the timeout tag having the same priority as the second priority.

[0089] In one embodiment, the arbitrator 13 is further configured to, if no timeout retention window is found, traverse multiple service requests and check if there is a first service request that has not timed out. The execution module 14 is further configured to, if it exists, execute the first service request with the earliest timestamp; otherwise, execute the service request with the earliest timestamp.

[0090] In one embodiment, the step of arbitrator 13 checking whether the retention time window has timed out when the arbitration triggering condition is met is specifically executed as follows: when the arbitration triggering condition is met, arbitrator 13 checks whether the retention time window has timed out in the order of timestamps.

[0091] In one embodiment, buffer 12 is further configured to store multiple service requests in the order of their timestamps.

[0092] In one embodiment, the step of arbitrator 13 checking whether the retention time window has expired when the arbitration triggering condition is met is specifically executed as follows: when arbitrator 13 receives a new service request and no service request is in the execution state, it checks whether the retention time window has expired; or, when the current service request has been completed, it checks whether the retention time window has expired.

[0093] According to the SOA service arbitration device 100 provided in this embodiment, on the one hand, service arbitration is performed by combining timestamps and priorities, which solves the problem of execution order disorder caused by Ethernet latency; on the other hand, by setting a configurable retention time window for high-priority service requests, low-priority service requests are forcibly blocked within the retention time window, ensuring that critical services, i.e., high-priority service requests, preempt resources; and on the other hand, in the case of retention time window timeout, a degradation strategy is configured to skip timeout high-priority requests, avoid blocking subsequent service requests, and improve the robustness of the system.

[0094] It should be noted that the SOA service arbitration device and the SOA service arbitration method provided in this application belong to the same inventive concept. Technical details not described in the SOA service arbitration device embodiment can be found in the SOA service arbitration method embodiment, and will not be repeated here.

[0095] This application also provides an electronic device. Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 700 includes a processor 710 and a memory 720. The memory 720 stores a computer program that, when executed by the processor 710, implements the Service-Oriented Architecture (SOA) service arbitration method provided in any embodiment of this application. The electronic device can be a test device, a simulation platform, or any embedded device requiring service arbitration functionality.

[0096] The processor 710 may include one or more cores for processing data. The processor 710 connects to various parts of the vehicle terminal 10 via various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 720, and by calling data stored in the memory 720. Optionally, the processor 710 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 710 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 710 and may be implemented separately using a communication chip.

[0097] The memory 720 may include random access memory (RAM) or read-only memory (ROM). The memory 720 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 720 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below.

[0098] This application also provides a computer-readable storage medium. Figure 8This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. For example... Figure 8 As shown, a computer program 810 is stored on a computer-readable storage medium 800. When executed by a processor, the computer program 810 is used to implement the service-oriented architecture (SOA) service arbitration method provided in any embodiment of the application.

[0099] The computer-readable storage medium 800 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 800 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 800 has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code may, for example, be compressed in a suitable form.

[0100] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0101] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for arbitrating SOA services, characterized in that, include: Receive multiple service requests, each service request being marked with a timestamp and a priority tag, the priority tag including a first priority or a second priority, the multiple service requests including a first service request marked with the first priority and a second service request marked with the second priority; Generate a retention time window for the first service request; If the arbitration triggering conditions are met, check whether the retention time window has timed out; If the retention window times out, a degradation strategy is triggered to skip the execution of the timed-out first service request.

2. The SOA service arbitration method of claim 1, wherein, If the retention time window is found to have expired, the degradation strategy is triggered as follows: If the reserved time window times out, select and execute the second service request with the earliest timestamp; or, maintain the idle state; or, execute the default service.

3. The SOA service arbitration method according to claim 1, characterized in that, If the retention time window is found to have expired, the SOA service arbitration method further includes: A timeout tag is added to the first service request that times out, and the timeout tag has the same priority level as the second priority.

4. The SOA service arbitration method of claim 3, wherein, Also includes: If no timeout retention window is found, iterate through the multiple service requests and check if there is a first service request that has not timed out. If it exists, execute the first service request with the earliest timestamp; If it does not exist, execute the service request with the earliest timestamp.

5. The SOA service arbitration method of claim 1, wherein, The step of checking whether the retention time window has timed out when the arbitration triggering conditions are met includes: If the arbitration triggering conditions are met, check whether the retention time window has timed out in the order of the timestamps.

6. The SOA service arbitration method of claim 5, wherein, Before generating the retention time window for the first service request, the method further includes: The multiple service requests are stored in the order of the timestamps.

7. The SOA service arbitration method according to claim 1, characterized in that, The step of checking whether the retention time window has timed out when the arbitration triggering conditions are met includes: Upon receiving a new service request, and if no service request is currently in execution, check if the retention window has timed out; or If the current service request has been completed, check if the retention time window has timed out; or Periodically check whether the retention time window has timed out.

8. An SOA service arbitration apparatus, characterized by, include: The acquisition module is configured to receive multiple service requests, each service request being marked with a timestamp and a priority tag. The priority tag includes a first priority or a second priority. The multiple service requests include a first service request marked with the first priority and a second service request marked with the second priority. A buffer is configured to store the plurality of service requests and generate a retention time window for the first service request; The arbitrator is configured to check whether the retention time window has expired when the arbitration triggering conditions are met. If the retention time window has expired, a degradation strategy is triggered to skip the execution process of the timed-out first service request.

9. The SOA service arbitration device according to claim 8, characterized in that, It also includes an execution module; the step of triggering a degradation strategy if the retention window times out includes: If the arbitrator detects that the retention window has expired, it selects the second service request with the earliest timestamp; the execution module executes the second service request with the earliest timestamp; or... The execution module remains idle; or... The execution module performs the default service.

10. A vehicle terminal, characterized by Includes the SOA service arbitration apparatus as described in claim 8 or 9, or performs the SOA service arbitration method as described in any one of claims 1-7.

11. An electronic device, comprising: include: processor; and A memory storing a computer program, which is executed by the processor to implement the SOA service arbitration method according to any one of claims 1-7.

12. A computer-readable storage medium, characterized in that, The system contains a computer program that is executed by a processor to implement the SOA service arbitration method according to any one of claims 1-7.

Images