A Method and System for Concurrent Access Control of Diagnostic Resources under a Hybrid Architecture of SOVD and UDS

Abstract

This application discloses a method and system for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS, relating to the field of automotive diagnostic technology. The method includes obtaining SOVD service capability description information, where the service capability description information includes locking indication information extended for at least one diagnostic resource path; receiving a diagnostic resource access request sent by a client; determining whether the target resource requires exclusive access based on the locking indication information corresponding to the target resource path in the service capability description information; if so, querying the resource lock table; if the target resource is not locked, allocating a lock to the client and updating the resource lock table; if the target resource is locked, adding the client to a waiting queue, and allocating the lock after it is released; and releasing the lock and updating the resource lock table after the client completes access. This application can achieve explicit marking of resource locking requirements and dynamic lock management, improving the efficiency and reliability of diagnostic concurrency under a hybrid architecture.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards domain-centralized and central computing platforms, next-generation vehicle diagnostic systems face the challenge of a hybrid architecture where Service-Oriented Vehicle Diagnosis (SOVD) and traditional Unified Diagnostic Services (UDS) coexist. SOVD is based on a REST (Representational State Transfer) architecture, supporting concurrent access to vehicle diagnostic resources by multiple clients, while UDS adopts a session-oriented exclusive access mode. The two differ fundamentally in their resource access mechanisms.

[0003] In a hybrid architecture, certain UDS services require exclusive access to avoid actuator conflicts or data inconsistencies, such as the input / output control service (0x2F), routine control service (0x31), and data transfer service (0x34 / 0x35 / 0x36 / 0x37). However, the existing SOVD service capability description information does not define any attributes or fields related to resource locking requirements. This means that before initiating a diagnostic resource access request, clients cannot determine whether a target resource requires exclusive access, nor can they predict whether the resource might be subject to conflicting operations by other clients. Existing SOVD-UDS gateways only implement protocol conversion and lack the ability to detect resource locking requirements and concurrent access control mechanisms.

[0004] Due to the aforementioned defects, when multiple clients simultaneously access the same UDS resource that requires exclusive access, it can easily lead to executor conflicts, data inconsistencies, or diagnostic failures. Furthermore, due to the lack of explicit marking and lock management mechanisms for resource locking requirements, it is impossible to coordinate the access sequence of multiple clients. Summary of the Invention

[0005] The purpose of this application is to provide a diagnostic resource concurrent access control method and system under a hybrid SOVD and UDS architecture, in order to solve the problem that the existing SOVD service capability description information lacks resource locking requirement indication information, which makes it impossible for clients to determine whether the target resource needs exclusive access, thus causing multi-client access conflicts and diagnostic failures. It can realize explicit marking of resource locking requirements and dynamic lock management, thereby improving the diagnostic concurrency efficiency and reliability under the hybrid architecture.

[0006] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS, comprising the following steps: Obtain SOVD service capability description information. The service capability description information includes locking indication information for diagnostic resource paths. The locking indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access. Receive a diagnostic resource access request sent by the client, the request containing the target resource path; Based on the locking indication information corresponding to the target resource path, determine whether the target resource requires exclusive access; If exclusive access is required, then perform lock management operations: If the target resource is not locked, then a lock is allocated to the client, and the resource lock table is updated; If the target resource is locked, add the client to the waiting queue; After the client completes the access, the lock held by the client is released, and the resource lock table is updated.

[0007] Secondly, this application provides a concurrent access control system for diagnostic resources under a hybrid architecture of SOVD and UDS, including: The resource capability description module is used to obtain SOVD service capability description information. The service capability description information includes locking indication information for diagnostic resource paths. The locking indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access. The gateway module is used to receive diagnostic resource access requests sent by clients, the requests containing the target resource path; determine whether the target resource needs exclusive access based on the locking indication information corresponding to the target resource path, and call the lock management module when necessary; The lock management module is used to perform lock management operations when exclusive access is required: if the target resource is not locked, a lock is allocated to the client and the resource lock table is updated; if the target resource is locked, the client is added to the waiting queue; after the client completes access, the lock held by the client is released and the resource lock table is updated.

[0008] Thirdly, this application provides a diagnostic gateway, comprising: a memory and a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture described in any one of the above.

[0009] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture described above.

[0010] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture described above.

[0011] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method and system for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS. By extending the locking indication information for diagnostic resource paths in the SOVD service capability description information, the diagnostic system has an explicit marker indicating whether a diagnostic resource requires exclusive access. This solves the problems of existing service capability description information lacking resource locking requirement information and the system being unable to distinguish between ordinary resources and resources requiring exclusive access, thus providing an information foundation for subsequent lock judgment and lock management. Based on this, after receiving a diagnostic resource access request sent by the client, the system determines whether the target resource requires exclusive access based on the locking indication information corresponding to the target resource path. Since this judgment is directly based on the extended... The system uses lock indication information to automatically identify resource types and determine whether to perform locking operations, enabling accurate judgment before client access and avoiding blind access due to unpredictable conflict risks. When exclusive access is required, lock management operations are performed: if the target resource is not locked, a lock is allocated to the client, and the resource lock table is updated, thus establishing temporary exclusive rights to the target resource for the client; if the target resource is locked, the client is added to a waiting queue, thus achieving orderly queuing of competing requests; after the client completes access, the lock it holds is released, and the resource lock table is updated, thereby reclaiming the exclusive rights to the target resource and allowing the next client in the waiting queue to acquire the lock. This series of operations, through the complete chain of "lock allocation, queuing, lock release, and state update," realizes full lifecycle management of resource locks, from application, acquisition, queuing to orderly release, directly solving the technical problems of lack of lock management mechanisms and access timing coordination in multi-client concurrent scenarios. It achieves dynamic lock allocation, queuing, and orderly release for diagnostic resources, avoiding resource conflicts and diagnostic failures. Meanwhile, the efficiency of concurrent access by multiple clients is improved, the resource conflict rate is significantly reduced, and the diagnostic response time is significantly shortened, meeting the diagnostic reliability and real-time requirements of the SOVD and UDS hybrid architecture. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is an application environment diagram of a diagnostic resource concurrent access control method under a hybrid SOVD and UDS architecture in one embodiment of this application; Figure 2 A flowchart illustrating a concurrent access control method for diagnostic resources under a hybrid architecture of SOVD and UDS, provided as an embodiment of this application; Figure 3 for Figure 2 A schematic diagram of the lock state transition process for the target resource in the diagram; Figure 4 This is a schematic diagram of the structure of a diagnostic gateway provided in one embodiment of this application. Detailed Implementation

[0014] 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.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown depicts a scenario where one or more diagnostic terminals (such as diagnostic tools, tablets, laptops, or remote support systems) communicate with a diagnostic gateway (server) via a network. The diagnostic gateway can be deployed on the vehicle's domain controller, central computing platform, or a standalone diagnostic server, and connects to one or more UDS ECUs (Electronic Control Units (ECUs) supporting the UDS protocol) via the vehicle bus (such as CAN or Ethernet). A data storage system stores service capability descriptions, resource lock tables, and log data that the diagnostic gateway needs to process. This data storage system can be configured separately, integrated into the diagnostic gateway, or located in the cloud or on other servers.

[0017] The diagnostic terminal sends a diagnostic resource access request (such as a RESTful HTTP request) to the diagnostic gateway. Upon receiving the request, the diagnostic gateway determines whether the target resource requires exclusive access based on the SOVD service capability description information (which includes lock indication information) obtained locally or from the data storage system. If so, it queries the resource lock table and performs lock allocation, waiting, or release operations. Simultaneously, the diagnostic gateway converts the SOVD request into a UDS diagnostic service (e.g., 0x22 read data; specifically, for services requiring exclusive access, such as input / output control service 0x2F, routine control service 0x31, and data transmission service 0x34 / 0x35 / 0x36 / 0x37) and forwards it to the corresponding UDS ECU. The ECU's response is then converted and returned to the diagnostic terminal.

[0018] Furthermore, in some embodiments, the method can also be implemented solely by the diagnostic gateway, for example, by integrating all modules internally; or it can be implemented collaboratively by the diagnostic terminal and the diagnostic gateway, for example, by the diagnostic terminal pre-caching some service capability description information. The diagnostic terminal can include, but is not limited to, professional vehicle diagnostic tools, tablets, laptops, smartphones, smart in-vehicle devices, etc. The diagnostic gateway can be implemented using a standalone server, a vehicle domain controller, a cluster of multiple servers, or a cloud server.

[0019] In one exemplary embodiment, such as Figure 2 As shown, a method for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS is provided. This method is executed by the diagnostic gateway. In this embodiment, the method is applied to... Figure 1 Taking the diagnostic gateway in the example, the following steps are included: Obtain SOVD service capability description information. The service capability description information includes locking indication information for diagnostic resource paths. The locking indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access. Receive a diagnostic resource access request sent by the client, the request containing the target resource path; Based on the locking indication information corresponding to the target resource path, determine whether the target resource requires exclusive access; If exclusive access is required, then perform lock management operations: If the target resource is not locked, then a lock is allocated to the client, and the resource lock table is updated; If the target resource is locked, add the client to the waiting queue; After the client completes the access, the lock held by the client is released, and the resource lock table is updated.

[0020] This application implements a diagnostic resource concurrent access control method under a hybrid SOVD and UDS architecture. It extends locking indication information into the SOVD service capability description information, enabling the diagnostic system to obtain a machine-readable explicit marker indicating whether a resource requires exclusive access. This solves the problems of existing capability descriptions lacking locking requirement information and the system's inability to distinguish between ordinary resources and resources requiring exclusive access. It provides an information basis for subsequent lock judgments, making automated concurrent control possible. Receiving client requests and extracting the target resource path allows the diagnostic gateway to identify the specific target resource the client wants to access. While this is a routine input step, it provides input for subsequent judgments. Based on the locking indication information, it determines whether the target resource requires exclusive access. This allows the system to automatically identify the resource type and decide whether to enter the lock management process. This solves the problem of clients being unable to predict resource conflict risks and thus blindly accessing resources, avoiding locking all resources (reducing overhead) and avoiding not locking resources requiring exclusive access (avoiding conflicts), achieving accurate judgment of resource locking requirements. When exclusive access is required and the target resource is not locked, a lock is allocated and the resource lock table is updated, establishing a temporary exclusive right for the client to the target resource. The resource lock table records the holder, acquisition time, and timeout period. This solves the problem of inevitable conflicts caused by multiple clients simultaneously accessing the target resource without a lock mechanism in existing solutions, achieving mutual exclusion and fundamentally eliminating conflicts when concurrently accessing the same target resource. When exclusive access is required but the target resource is locked, the client is added to a waiting queue, and competing requests are queued in an orderly manner, instead of being directly rejected or requiring the client to retry continuously. This solves the inefficiency problem of clients only receiving a "resource busy" failure response without a waiting queue, requiring the application layer to retry manually. This improves the fairness and success rate of resource access and reduces unnecessary retry overhead. After the client completes access, it releases the lock and updates the resource lock table, reclaiming the exclusive right to the resource and triggering the next client in the waiting queue to acquire the lock. This solves the problem of permanent resource occupation or deadlock caused by not releasing the lock, achieving a virtuous cycle of lock resources, ensuring long-term stable operation of the system and maximizing resource utilization.

[0021] This application's diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture forms a complete closed loop of "acquiring lock indication information → judgment → allocation / waiting → release," realizing full lifecycle management of locks. Compared to existing technologies: existing technologies lack lock marking, leading to blind client access and uncontrollable resource conflicts; without a lock mechanism, multiple clients operating simultaneously require exclusive resource access; without a waiting queue, clients need to spin and retry; and without timeout management, permanent occupancy is possible. This application, through explicit marking and dynamic lock allocation, reduces the resource conflict rate from uncontrollable to quantifiable; through a resource lock table and waiting queue, it reduces the number of retries caused by resource conflicts, thereby reducing the CPU load and network I / O overhead of the diagnostic gateway and improving the overall system throughput and response speed; through proactive release and resource lock table updates, it avoids resource leaks. Simultaneously, it significantly improves the efficiency of multi-client concurrent access, significantly reduces the resource conflict rate, and significantly shortens the diagnostic response time. By employing explicit marking, dynamic resource lock tables, waiting queues, and proactive release techniques, the core issues of opaque resource locking requirements and lack of lock management mechanisms in the SOVD and UDS hybrid architecture are directly addressed. This achieves beneficial effects such as information transparency (machine-readable resource exclusive requirements), mutual exclusion access (only one client can access a resource at a time), fair queuing (orderly waiting for competing requests), resource reclamation (timely reuse after lock release), and improved system performance (concurrency efficiency, conflict rate, and response time).

[0022] Furthermore, this application is applicable to collaborative diagnostic scenarios between HPC high-performance computing units and traditional ECUs in next-generation automotive electronic and electrical architectures. It can be widely used in automated testing during vehicle R&D, off-line inspections on production lines, concurrent operation of multiple diagnostic instruments in after-sales service shops, and remote diagnostic services. Based on the standard SOVD OpenAPI extension, this application is compatible with existing diagnostic infrastructure and is easy to implement.

[0023] In a basic concurrent access control process, assume a vehicle is equipped with an HPC domain controller (acting as an SOVD server) and multiple traditional UDS ECUs. A diagnostic gateway is deployed within the domain controller, responsible for managing concurrent access to all diagnostic resources. SOVD service capability descriptions are provided using the OpenAPI specification, with custom attributes extended within it.

[0024] In the SOVD service capability description information, the following locking indication information is extended for the diagnostic resource path / actuator / throttle (throttle control): "paths": { " / actuator / throttle": { "post": { "x-sovd-lock-required": true, "lock-type": "exclusive", "lock-timeout": 10000, "summary": "Throttle control" } } } In this application, `x-sovd-lock-required` is a custom extended field that conforms to the extension mechanism of the OpenAPI Specification. Its value is a boolean (true indicates exclusive access is required, false indicates no locking is required). Similarly, `lock-type` and `lock-timeout` are also custom extended fields, used to specify the lock type (such as exclusive lock or shared lock) and the lock timeout (in milliseconds), respectively. These extended fields can appear at the path or operation level to mark the locking requirements and related attributes of diagnostic resources. Through the above extensions, the SOVD service capability description information can explicitly express resource locking requirements, providing an information foundation for subsequent dynamic lock management.

[0025] For the read-only resource path / data / engine (engine data), extend x-sovd-lock-required:false to indicate that locking is not required.

[0026] The diagnostic gateway preloads the SOVD service capability description information mentioned above and initializes the resource lock table. The resource lock table structure is as follows:

[0027] The resource lock table update cycle is set to 50ms, and read-write locks are used to ensure concurrency safety. The specific process steps are as follows: The diagnostic gateway obtains SOVD service capability description information: When the diagnostic gateway starts, it loads the above JSON description information and parses the locking indication information of each diagnostic resource path, storing it in memory.

[0028] Receive client requests: Client A (diagnostic instrument, ID="TesterA") sends an HTTP POST request to the target resource path / data / engine, requesting to read engine data.

[0029] Client B (diagnostic instrument, ID="TesterB") sends an HTTP POST request to the target resource path / actuator / throttle, requesting to perform throttle control operation.

[0030] Determine if exclusive access is required: The diagnostic gateway parses client A's request, queries the SOVD service capability description information, and finds that x-sovd-lock-required for / data / engine is false. Therefore, it determines that exclusive access is not required and forwards the request directly to the UDS ECU for processing, without involving lock operations.

[0031] The diagnostic gateway parses client B's request, queries the SOVD service capability description information, and finds that x-sovd-lock-required in / actuator / throttle is true, indicating that exclusive access is required.

[0032] Query the resource lock table and allocate locks: In response to client B's request, the diagnostic gateway queries the resource lock table for the record with the target resource ID / actuator / throttle, and the current lock status of the target resource is unlocked.

[0033] The diagnostic gateway assigns a lock to the client, updates the lock status to locked, sets the holder ID to "TesterB", sets the acquisition time to the current time, and sets the timeout to the current time + 10000ms.

[0034] The diagnostic gateway returned a 200 OK response, allowing client B to perform diagnostic operations.

[0035] Pending processing of subsequent requests: While client B holds the lock, client C (Diagnostic, ID="TesterC") also requests access to the same target resource / actuator / throttle.

[0036] The diagnostic gateway queries the resource lock table and finds that the lock status is locked. Then, it adds client C to the waiting queue of the target resource and returns a 202 Accepted or 423 Locked status code (configurable) to prompt the client to wait.

[0037] Lock release: After client B completes the throttle control operation, it sends a DELETE request or a specific lock release request (such as POST / lock / release).

[0038] After receiving the release request, the diagnostic gateway restores the lock status of / actuator / throttle in the resource lock table to unlocked, and clears the holder ID, acquisition time, and timeout.

[0039] If a client (such as client C) exists in the waiting queue, the next client is retrieved in first-in-first-out order, a lock is assigned to it, and the resource lock table is updated.

[0040] like Figure 3 As shown, when the target resource is unlocked, the lock state transitions to locked after the client successfully acquires the lock. When the target resource is locked, subsequent requesting clients cannot immediately acquire the lock and enter a waiting queue. At this time, the lock state can be considered waiting (or remaining locked, but the waiting queue is not empty). When the lock holder releases the lock, if the waiting queue is not empty, the next client is removed from the queue, and its lock state transitions from waiting (or in the queue) to locked; if the queue is empty, the lock state reverts to unlocked. Therefore, Figure 3 It clearly demonstrates the basic loop of unlocked→locked→unlocked, as well as the process of adding to and waking up the waiting queue in the locked state.

[0041] This embodiment extends the lock indication information, enabling the diagnostic system to explicitly mark resource lock requirements. Clients can determine whether a target resource requires exclusive access before access, thus avoiding blind access. Simultaneously, through dynamic maintenance of the resource lock table and the lock application, allocation, waiting, and release processes, complete lock lifecycle management is achieved. The resource lock table is updated every 50ms to ensure real-time lock status, laying the foundation for more advanced concurrency control. This addresses the technical problems of existing SOVD service capability descriptions lacking resource lock requirement information, clients being unable to determine whether a target resource requires exclusive access, and the lack of basic lock lifecycle management.

[0042] Based on the basic concurrent access control process described above, this embodiment further introduces a lock renewal and priority arbitration mechanism to solve the problems of lock timeout failure and blocked urgent requests.

[0043] A vehicle has broken down. The on-site technician (client A, priority P=5) is performing a routine check using a diagnostic tool. A remote expert (client B, priority P=9) needs to intervene urgently to perform a critical system diagnostic. Additionally, a regular diagnostic tool (client C, priority P=3) is also waiting for the same resource.

[0044] Based on the lock allocation described above, a lock renewal function is added. Assume client A acquires a lock on a target resource with a lock timeout of 5000ms (initial value). Client A's operation requires a relatively long time (e.g., routine control service 0x31 might take 8 seconds). Before the lock timeout (e.g., at 4000ms), client A sends a lock renewal request (POST / lock / renew, carrying the diagnostic resource path and client ID) to the diagnostic gateway. Upon receiving the request, the diagnostic gateway extends the lock timeout by 50% of the initial value, i.e., by 2500ms. The new timeout is the current time + 2500ms. In this embodiment, the duration of a single renewal is limited to 50% of the initial lock-timeout, and the maximum number of renewals is 3. If client A completes its operation before the lock timeout, the lock is released normally; if the operation is not completed before the maximum number of renewals, the lock is forcibly reclaimed, and client A receives a 408 error code.

[0045] When multiple clients are waiting for the same target resource lock at the same time, the diagnostic gateway no longer adopts the simple FCFS (First Come, First Served) strategy, but instead calculates the arbitration score based on the priority weight formula and selects the client with the highest arbitration score to acquire the lock.

[0046] The priority weight formula is: in, For arbitration scores, This is the priority weighting coefficient (dimensionless, default 0.7). Client priority (dimensionless, value range 1 to 10, the larger the value, the higher the priority). This is the waiting time weighting coefficient (dimensionless, default 0.3). The waiting time is in milliseconds (ms). It is the unit time constant (with a value of 1ms, used for dimension normalization).

[0047] In this embodiment, the time cost of the arbitration decision process is less than or equal to 10ms, ensuring the real-time nature of lock allocation.

[0048] Suppose that at a certain moment, the lock on the target resource is held by client D. There are three clients in the waiting queue: Client X: Priority P=9, has been waiting for 100ms; Client Y: Priority P=5, has been waiting for 200ms; Client Z: Priority P=3, has been waiting for 50ms; Calculate the PriorityScore for each client: Client X: Client Y: Client Z: The diagnostic gateway selects client Y, which has the highest score, to acquire the lock. Although client X has a higher priority, its waiting time is shorter, while client Y's waiting time is longer. The weighting formula balances priority and fairness.

[0049] For emergency scenarios, this embodiment supports high-priority clients preempting locks on target resources held by low-priority clients. The specific rule is as follows: when the priority of the client requesting the lock is greater than or equal to a first threshold (e.g., 8), and the priority of the current lock holder is less than or equal to a second threshold (e.g., 3), the diagnostic gateway forcibly releases the current lock and immediately transfers it to the client requesting the lock. The preempted client receives an HTTP 423 error code, indicating "The diagnostic session was interrupted by a high-priority task." It should be noted that the first and second thresholds can be fixed values ​​preset by the system, or they can be dynamically adjusted by maintenance personnel through a configuration interface according to the actual application scenario. For example, in a scenario involving remote expert intervention, the first threshold can be lowered to 6, or in a scenario with high security requirements, the second threshold can be raised to 5. This application does not specifically limit this.

[0050] In this scenario, on-site technician client A holds the lock with a priority of P=5, which does not meet the condition of being less than or equal to 3. Therefore, remote expert client B (P=9) cannot directly preempt the lock. The system administrator can configure more flexible preemption rules, such as triggering preemption when the requester's priority is more than 4 levels higher than the holder's. To demonstrate preemption, consider another scenario: the current lock holder is client C (priority P=2), and remote expert client B (P=9) requests the same lock. Since the requester's priority 9 is greater than 8 and the holder's priority 2 is less than 3, the diagnostic gateway immediately forcibly releases client C's lock, assigns the lock to client B, and returns a 423 error code to client C. Client B then acquires the lock and begins emergency diagnostics.

[0051] This embodiment further addresses the following technical issues: lock timeout failure leading to long-running task interruptions; the use of the FCFS strategy during multi-client contention, ignoring priority differences, potentially causing urgent diagnostic requests to be blocked for extended periods; and the lack of a preemption mechanism preventing high-priority tasks from acquiring resources promptly. To address these issues, this embodiment employs a lock renewal mechanism, priority weight arbitration, and preemptive locking. The lock renewal mechanism prevents long-running diagnostic tasks from being forced to terminate due to lock timeout, improving the diagnostic success rate. Priority weight arbitration balances priority and waiting fairness; tests show that the average response time for urgent diagnostic requests is reduced by 30%. Preemptive locking ensures that high-priority tasks can quickly acquire resources, meeting real-time requirements such as remote expert intervention, while simultaneously improving overall efficiency for multi-client concurrent access by over 40%.

[0052] Building upon this, this embodiment further introduces security degradation and deadlock handling mechanisms to address potential deadlocks and lock timeout failures in multi-client concurrent scenarios. Consider the following circular wait scenario: Client M (priority P=4) holds a lock on resource A and requests a lock on resource B.

[0053] Client N (priority P=6) holds a lock on resource B and requests a lock on resource A.

[0054] At this point, M is waiting for N to release B, and N is waiting for M to release A, resulting in a deadlock.

[0055] In this embodiment, the diagnostic gateway has a built-in periodic task that constructs a resource wait-for graph every 100ms. The resource wait-for graph is a directed graph where nodes are client IDs and edges represent clients waiting for a lock held by another client. The specific construction method is as follows: traverse the resource lock table; for each client in a waiting state, find the current lock holder corresponding to the target resource it is waiting for, and add a directed edge from the waiting client to the lock holder.

[0056] In the above scenario, the diagnostic gateway detects that the edge M→N (M waits for N to release B) and the edge N→M (N waits for M to release A) form a loop, and determines that a deadlock has occurred.

[0057] Deadlock recovery strategy: Select the client with the lowest priority in the loop and forcibly release all locks held by it. In this embodiment, client M has a priority of 4, which is lower than client N's priority of 6, so client M is selected. The diagnostic gateway forcibly releases the lock on resource A held by client M, updates the lock status to unlocked, removes client M from the waiting queue, and returns a 423 error code to it. Client N then acquires the lock on resource A, completes the operation, and the deadlock is resolved.

[0058] In addition, each lock has a timeout period (expire_time) set during allocation, and this embodiment further provides a lock timeout handling mechanism. Another periodic task of the diagnostic gateway (period ≤ 50ms) checks the expire_time of all locks. If the current time exceeds expire_time and the lock has not been released, the lock is forcibly reclaimed, its state is restored to unlocked, and a 408 error code is returned to the original holder. Simultaneously, if there are clients in the waiting queue, locks are allocated according to arbitration scores.

[0059] For example, after client A acquires a lock, it fails to release the lock due to network failure or program crash, and the lock timeout is set to 5000ms. After 5000ms, the diagnostic gateway detects the timeout, forcibly reclaims the lock, and returns a 408 Request Timeout (HTTP status code 408) to client A (if a connection is still possible). Client B in the waiting queue then acquires the lock, and the system returns to normal.

[0060] The diagnostic gateway logs all deadlock and timeout events, creating an anomaly log. This log includes: event type (deadlock / timeout), involved resource ID, client ID, timestamp, and lock holding information. These logs can be used for after-sales analysis or system optimization.

[0061] This embodiment primarily addresses deadlock and lock timeout failure issues that may occur in multi-client concurrent scenarios. Existing solutions lack effective deadlock detection and recovery mechanisms, easily leading to system freezes; there is also no automatic lock reclamation mechanism after lock timeout, resulting in permanent resource occupation. To address these issues, this embodiment achieves security degradation through deadlock detection using a resource wait graph, forced release of the lowest priority client lock, and forced lock reclamation after timeout. By periodically constructing a resource wait graph (100ms period), deadlocks can be quickly detected; by forcibly releasing the lowest priority client lock, deadlock recovery is completed within 50ms, preventing system freezes; the lock timeout forced reclamation mechanism prevents permanent resource occupation. Testing shows that after applying this embodiment, the resource conflict rate in the hybrid architecture is reduced to below 1%, and system stability is significantly enhanced.

[0062] Furthermore, this application can be further extended in the following aspects to enhance the system's flexibility, real-time performance, and robustness. For example, adaptive lock timeout adjustment: Based on the execution time statistics of historical diagnostic operations, the lock timeout is dynamically adjusted. For the same diagnostic resource path, the diagnostic gateway records the average and variance of each lock holding time, automatically setting the lock timeout to the average plus twice the standard deviation, avoiding fixed timeouts that cause long tasks to frequently renew or short tasks to wait too long. Differentiated lock strategies based on resource type: Different lock strategies are adopted for different UDS service types. For read-only services (such as 0x22 reading data), shared locks are supported, allowing multiple clients to read simultaneously; for write services (such as 0x2E writing data), exclusive locks are used to avoid write-write conflicts; for routine control (0x31), the lock type is dynamically selected based on the routine's side effects. Distributed lock management (cross-diagnostic gateway scenarios): In more complex vehicle architectures (such as multiple domain controllers each having their own diagnostic gateway), it is extended to a distributed lock manager. A global resource lock table is maintained through a consistency protocol (such as Raft), achieving resource locking coordination across diagnostic gateways and preventing different domain controllers from accessing the same physical actuator simultaneously. Locking strategy linked to vehicle status: Access vehicle status information (such as vehicle speed, ignition status, and driving mode). When the vehicle is in motion, certain high-risk exclusive diagnostic operations (such as throttle control operations) are prohibited, even if the client acquires the lock, and a safety restriction error code is returned. When the vehicle is stationary, these operations are allowed, further enhancing vehicle security. Graphical lock monitoring and diagnostic interface: A management interface (such as a web dashboard) is provided, displaying real-time information such as the lock status of all resources, waiting queues, client priorities, and lock holding time, facilitating monitoring and manual intervention by maintenance personnel (such as forcibly releasing deadlocked resources). Collaboration with the vehicle cloud platform: Resource lock status is reported to the cloud-based vehicle management platform, enabling intelligent scheduling of remote diagnostic tasks. The cloud dynamically adjusts the diagnostic resource lock allocation strategy for each vehicle based on the global diagnostic task queue, preventing multiple remote diagnostic tasks from simultaneously locking the same resource of the same vehicle model. All of the above extensions are derived from the core inventive concept of resource lock indication information plus dynamic lock management, further enhancing the practical value and scope of protection of this application.

[0063] This application also provides an application scenario in which the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture described above is applied. Specifically, the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture provided in this embodiment can be applied to the remote diagnosis and maintenance of ride-hailing fleets. The following example, using the remote diagnosis and maintenance scenario of a ride-hailing operating company's fleet, illustrates the comprehensive effect of the above-mentioned extended technology in practical applications. This company manages hundreds of new energy vehicles, each equipped with the diagnostic gateway of this application. One day, the operating platform received remote alarms from multiple vehicles of the same model, indicating abnormal motor controller temperatures. The platform dispatch center needs to perform remote diagnosis on multiple vehicles simultaneously, but must avoid vehicle status conflicts or data inconsistencies due to concurrent operations.

[0064] Regarding adaptive lock timeout adjustment, the diagnostic gateway, based on historical data, discovered that the average time for reading the motor controller temperature for this vehicle model was 200ms, with a standard deviation of 50ms. Therefore, it automatically set the lock timeout to 200ms plus twice the standard deviation, i.e., 300ms, instead of a fixed 5000ms. When a remote diagnostic task is executed, if a vehicle's read time exceeds 300ms due to network latency, the gateway quickly reclaims the lock and returns a 408 error. The platform then retryes, preventing other urgent tasks from being blocked due to an excessively long fixed timeout.

[0065] Regarding the differentiated locking strategy based on resource type, the temperature reading service (UDS 0x22) is marked as read-only, and the gateway uses a shared lock, allowing the platform to read data from multiple vehicles simultaneously without mutual exclusion. Meanwhile, another remote task needs to perform a software write to the motor controller of a vehicle (UDS 0x34 / 0x36). This resource is marked as an exclusive lock, and the gateway ensures that only this write task locks the controller at any given time, while other reading tasks wait or are degraded to cached data.

[0066] In terms of distributed lock management, a vehicle is equipped with two domain controllers (power domain and body domain), each with its own diagnostic gateway. When the platform needs to adjust the parameters of the motor controller and the window status simultaneously, the distributed lock manager maintains a global lock table through the Raft protocol to prevent the two gateways from locking the same physical actuator (such as the motor controller) at the same time, thus preventing conflicts.

[0067] Regarding the locking strategy linked to vehicle status, while the vehicle is in motion (speed greater than zero), the platform attempts to remotely perform motor controller calibration (a high-risk operation). The gateway detects that the vehicle is in motion and refuses to execute the calibration, even if the client has acquired the lock, returning an error code: "Vehicle in motion, operation prohibited." The calibration task is only allowed to execute after the vehicle comes to a complete stop, ensuring driving safety.

[0068] Regarding the graphical lock monitoring and diagnostic interface, operations and maintenance personnel can view the lock status, waiting queue, client priority, and lock holding time of all vehicles in real time through a web dashboard. If the motor controller lock of a certain vehicle is occupied for an extended period by an abnormal task, the operations and maintenance personnel can manually force the lock to be released, thus resuming subsequent diagnostics.

[0069] Regarding collaboration with the vehicle cloud platform, the cloud-based dispatch center dynamically adjusts the lock allocation strategy for each vehicle based on the global diagnostic task queue. When multiple vehicles of the same model need to have their software flashed simultaneously, the cloud allocates time windows in a staggered manner to avoid gateway overload caused by a large number of concurrent lock requests, while ensuring that each vehicle has exclusive access to resources during the flashing process.

[0070] This application scenario integrates basic lock management, priority arbitration (remote expert tasks have higher priority than regular inspections), and deadlock detection (avoiding multi-task loop waiting), and combined with the aforementioned extended technologies, fully demonstrating the flexibility, real-time performance, and robustness of this application in complex fleet remote diagnostic environments.

[0071] Based on the same inventive concept, this application also provides a concurrent access control system for diagnostic resources under a hybrid architecture of SOVD and UDS for implementing the above-described method. The solution provided by this system is similar to the implementation described in the above-described method; therefore, the specific limitations in one or more system embodiments provided below can be found in the limitations of the method described above, and will not be repeated here.

[0072] In one exemplary embodiment, a concurrent access control system for diagnostic resources under a hybrid architecture of SOVD and UDS is provided, comprising: The resource capability description module is used to store SOVD service capability description information. The description information includes lock indication information (such as x-sovd-lock-required, lock-type, lock-timeout, etc.) for at least one diagnostic resource path. The lock indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access.

[0073] The gateway module is used to receive diagnostic resource access requests sent by clients, the requests containing the target resource path; based on the locking indication information corresponding to the target resource path, it determines whether the target resource needs exclusive access, and calls the lock management module when necessary.

[0074] The lock management module queries the resource lock table when exclusive access is required. If the target resource is not locked, a lock is allocated to the client, and the resource lock table is updated. If the target resource is locked, the client is added to a waiting queue, and allocation is performed after the lock is released. After the client completes access, the lock held by the client is released, and the resource lock table is updated. This module also provides interfaces for lock renewal and waiting queue management, and can be extended to support calls from external modules (such as arbitration modules and security degradation modules) to enhance the system's concurrency control capabilities.

[0075] As an optional implementation, the SOVD service capability description information stored in the resource capability description module is stored in the OpenAPI specification format and a query interface is provided so that other modules can obtain locking indication information based on the diagnostic resource path.

[0076] As an optional implementation, the gateway module, acting as the system's entry point, receives HTTP / RESTful diagnostic resource access requests from clients, parses the target resource path in the request, calls the resource capability description module to obtain locking indication information, and determines whether exclusive access to the target resource is required. If exclusive access is required, the lock management module is invoked to perform a lock operation; otherwise, SOVD-UDS protocol conversion is directly performed and the request is forwarded to the UDS ECU. The gateway module is also responsible for returning a response to the client.

[0077] As an optional implementation, the lock management module maintains a resource lock table to implement lock application, acquisition, release, renewal, and waiting queue management. Specific functions include: querying the resource lock table to determine the current status of the target resource (unlocked / locked / waiting); allocating locks to clients and updating the resource lock table (recording the holder ID, acquisition time, and timeout); adding clients that fail to acquire the lock to the waiting queue; receiving lock release requests, releasing the lock and updating the resource lock table, and retrieving the next client from the waiting queue to be allocated a lock; and receiving lock renewal requests and extending the lock's timeout.

[0078] In a preferred embodiment, the system further includes the following enhancement modules: The arbitration module is used to calculate an arbitration score and select the acquirer when multiple clients are waiting for the same resource lock, based on a priority weighting formula. The lock management module calls the decision result of the arbitration module through a reserved interface, thereby replacing the default FIFO (First In, First Out) waiting queue order.

[0079] The security degradation module is used to periodically build resource wait graphs to detect deadlocks and forcibly release locks, as well as handle lock timeouts. The lock management module executes the corresponding lock reclamation operation when it detects a lock timeout or receives a forced release command from the security degradation module.

[0080] The caching module is used to cache diagnostic data for read-only resources. The cache validity period is a preset duration (e.g., 5 seconds) after the lock is released. For read-only diagnostic resources (such as the read data identifier 0x22 service), when other clients request the same read-only resource within the preset duration, the gateway module directly returns the data from the cache without having to send another request to the UDS ECU, thereby reducing duplicate UDS communication and lowering response latency. If the data changes during the caching period (triggered by a write operation), the cache automatically expires.

[0081] As a preferred implementation, the gateway module also integrates SOVD-UDS session synchronization functionality. In the hybrid architecture, when the UDS requests access to certain services (such as 0x2F input / output control and 0x31 routine control), the ECU must be in extended diagnostic session mode. Therefore, when a client successfully acquires a resource lock requiring exclusive access, the gateway module automatically sends a 0x10 03 (enter extended diagnostic session) request to the corresponding UDS ECU; when the lock is released, the gateway module sends a 0x10 01 (return to default session) request. This ensures the consistency between the UDS session state and the lock state, avoiding diagnostic service rejection due to incorrect session mode.

[0082] Specifically, the mapping between the SOVD RESTful API and the UDS service includes, but is not limited to: GET / {entity} / data / {data-id} is mapped to UDS 0x22 Read Data Service; POST / {entity} / actuator / {actuator-id} is mapped to 0x2F Input / Output Control; POST / {entity} / routine / {routine-id} is mapped to 0x31 Routine Control; DELETE / {entity} / faults is mapped to 0x14 Clear Fault Codes; and the mappings for 0x34 / 0x35 / 0x36 / 0x37 Data Transfer Service are included.

[0083] In one exemplary embodiment, a diagnostic gateway is provided. This diagnostic gateway can be a standalone server, a vehicle domain controller, or a module integrated into a central computing platform. Its internal structure diagram can be as follows: Figure 4As shown, the diagnostic gateway includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media. The database stores SOVD service capability description information, resource lock tables, and exception log data. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with one or more diagnostic terminals (such as diagnostic instruments, tablets, and laptops) via a network connection. When the computer program is executed by the processor, it implements a concurrent access control method for diagnostic resources under a hybrid SOVD and UDS architecture.

[0084] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. A specific diagnostic gateway may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0085] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0086] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0087] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0088] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0089] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0090] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0091] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0092] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are merely for the purpose of helping to understand the method and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for concurrent access control of diagnostic resources under a hybrid architecture of SOVD and UDS, characterized in that, Includes the following steps: Obtain SOVD service capability description information. The service capability description information includes locking indication information for diagnostic resource paths. The locking indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access. Receive a diagnostic resource access request sent by the client, the request containing the target resource path; Based on the locking indication information corresponding to the target resource path, determine whether the target resource requires exclusive access; If exclusive access is required, then perform lock management operations: If the target resource is not locked, then a lock is allocated to the client, and the resource lock table is updated; If the target resource is locked, add the client to the waiting queue; After the client completes the access, the lock held by the client is released, and the resource lock table is updated.

2. The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture according to claim 1, characterized in that, The locking indication information also includes at least one of lock type and lock timeout time; the lock type includes exclusive lock or shared lock.

3. The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture according to claim 1, characterized in that, The resource lock table records the resource ID, lock status, holder ID, acquisition time, and timeout. The method further includes: Receive the lock renewal request sent by the client and extend the lock's timeout period by a preset duration.

4. The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture according to claim 1, characterized in that, When multiple clients are waiting for the same resource lock, the arbitration score of each client is calculated according to the priority weight formula, and the client with the highest arbitration score is selected to acquire the lock. The priority weight formula is as follows: in, For arbitration scores, For client priority, The waiting time is in milliseconds (ms). It is a unit time constant. This is the priority weight coefficient. This is the waiting time weighting coefficient.

5. The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture according to claim 4, characterized in that, When the priority of the client requesting the lock is higher than the first threshold and the priority of the current lock holder is lower than the second threshold, the current lock is forcibly released and transferred to the client requesting the lock.

6. The diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture according to claim 1, characterized in that, Also includes: A resource wait graph is periodically constructed. If a loop is detected, a deadlock is identified, and all locks held by the client with the lowest priority are forcibly released. If the lock is held for longer than the timeout period, the lock will be forcibly reclaimed and a timeout error code will be returned to the holder.

7. A concurrent access control system for diagnostic resources under a hybrid architecture of SOVD and UDS, characterized in that, include: The resource capability description module is used to obtain SOVD service capability description information. The service capability description information includes locking indication information for diagnostic resource paths. The locking indication information is used to mark whether the diagnostic resource corresponding to the diagnostic resource path needs exclusive access. The gateway module is used to receive diagnostic resource access requests sent by clients, the requests containing the target resource path; determine whether the target resource needs exclusive access based on the locking indication information corresponding to the target resource path, and call the lock management module when necessary; The lock management module is used to perform lock management operations when exclusive access is required: if the target resource is not locked, a lock is allocated to the client and the resource lock table is updated; If the target resource is locked, add the client to the waiting queue; After the client completes the access, the lock held by the client is released, and the resource lock table is updated.

8. A diagnostic gateway, comprising: A memory and a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the diagnostic resource concurrent access control method under the SOVD and UDS hybrid architecture as described in any one of claims 1-6.

Images