Automobile fault code intelligent analysis method and system based on multi-protocol compatibility

Abstract

The invention provides an automobile fault code intelligent analysis method and system based on multi-protocol compatibility, and relates to the technical field of automobile fault code analysis, and the method comprises the steps: building a distributed state lock for each automobile fault code; when it is detected that a first protocol entry initiates a fault code status bit reading request, locking a mutual exclusion region of a status bit field, and releasing locking after status bit information is read; when it is detected that a second protocol entry initiates a fault code status bit write-in request, locking a mutual exclusion region of a status bit field and a mutual exclusion region of a status counter at the same time, and executing a status bit write-in operation and a status counter update operation during locking; when a reading request of the first protocol entry and a writing request of the second protocol entry are received concurrently, performing serialization processing on the reading request and the writing request; and outputting an analysis state of the automobile fault code by taking the state bit information after the atomic transaction and the state counter as an analysis reference. According to the method and the device, logic resolution of concurrent conflicts of the multi-protocol automobile fault code status bits can be realized.

Description

Technical Field

[0001] This application relates to the field of automotive fault code parsing technology, and more specifically, to an intelligent parsing method and system for automotive fault codes based on multi-protocol compatibility. Background Technology

[0002] With the rapid development of automotive electronics, intelligence, and connectivity, the complexity of on-board electronic control systems has increased significantly. Automotive fault code analysis technology has become a core supporting technology for ensuring safe vehicle operation and improving maintenance efficiency. This technology spans the entire vehicle lifecycle, enabling real-time analysis of fault codes transmitted by various electronic control units such as the engine, transmission, and body control. It accurately distinguishes between active, temporary, and historical fault states, providing precise data for fault location, remote diagnosis, and after-sales maintenance. This effectively shortens the fault diagnosis cycle, reduces maintenance costs, and lays the foundation for the intelligent upgrade of on-board diagnostic systems. It is of great significance for promoting the standardization and efficiency of the automotive diagnostics field.

[0003] In current automotive diagnostic scenarios, vehicles need to be compatible with multiple mainstream diagnostic protocols such as UDS, OBD-II, and SAE J1939. Different protocols are developed by different standards organizations, resulting in significant differences in the field allocation, status definition, and judgment logic of automotive fault code status bits. A unified parsing standard has not been formed. When multiple protocols report automotive fault codes concurrently, the status bit information of different protocols is prone to interactive interference, leading to contradictory fault status judgments, distorted parsing results, and even problems such as missed fault reports and false alarms. Existing technologies mostly design parsing schemes for single protocols and lack effective conflict coordination mechanisms to deal with concurrent multi-protocol scenarios. They cannot achieve compatibility and unified calibration of status bit information of different protocols, which seriously affects the reliability and accuracy of automotive diagnostic systems and restricts the large-scale application of multi-protocol automotive diagnostic scenarios. Therefore, how to achieve logical resolution of concurrent conflicts in automotive fault code status bits of multiple protocols has become a difficult problem for the industry. Summary of the Invention

[0004] This application provides a method and system for intelligent parsing of automotive fault codes based on multi-protocol compatibility, which can realize the logical resolution of concurrent conflicts of status bits of automotive fault codes from multiple protocols.

[0005] Firstly, this application provides a method for intelligent parsing of automotive fault codes based on multi-protocol compatibility, the method comprising the following steps: Establish an independent distributed state lock for each vehicle fault code; When a fault code status bit read request is detected from the first protocol entry, the mutual exclusion area of ​​the status bit field in the distributed status lock is locked, and the lock is released after the status bit information is read. When a fault code status bit write request is detected from the second protocol entry, the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter in the distributed status lock are locked at the same time. During the locking period, the status bit write operation and the status counter update operation are executed, and the write operation and update operation are encapsulated into atomic transactions. When concurrent read requests from the first protocol entry and write requests from the second protocol entry are received, the read and write requests are serialized according to the distributed state lock. Using the status bit information and status counter after the atomic transaction is completed as the parsing reference, the parsing status of the vehicle fault code is output.

[0006] In this embodiment, establishing an independent distributed state lock for each vehicle fault code specifically includes: An independent distributed state lock is created for each vehicle fault code identifier. The distributed state lock includes a mutual exclusion area for the state bit field, a mutual exclusion area for the state counter, and a priority arbiter. Bind the mutex region of the status bit field to the status bit information of the vehicle fault code, and bind the mutex region of the status counter to the status counter of the vehicle fault code. Configure a read / write priority arbitration strategy for the priority arbitrator based on the waiting time and request type of read and write requests in the waiting queue of the distributed state lock.

[0007] In this embodiment, when a fault code status bit read request is detected from the first protocol entry point, locking the mutex region of the status bit field within the distributed status lock, and releasing the lock after reading the status bit information specifically includes: When a fault code status bit read request is initiated by the first protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the read request. A non-blocking locking attempt is initiated to the mutex of the state bit field within the distributed state lock. When the locking attempt fails, the read request is added to the read wait queue of the mutex and a wait timeout timer is started. During the successful locking process, the status bit information of the vehicle fault code is read and stored in the read buffer. After the status bit information is stored in the read buffer, a release lock operation is performed on the mutex area of ​​the status bit field, and the next waiting request is woken up from the read wait queue.

[0008] In this embodiment, when a fault code status bit write request is detected from the second protocol entry point, the mutual exclusion region of the status bit field and the mutual exclusion region of the status counter within the distributed status lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed, and the write operation and update operation are encapsulated into an atomic transaction, specifically including: When a fault code status bit write request is detected from the second protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the write request. Simultaneously initiate a lock request to the mutual exclusion zone of the state bit field and the mutual exclusion zone of the state counter within the distributed state lock, and carry a transaction identifier in the lock request. When both mutual exclusion zones return a lock success flag carrying the same transaction identifier, it is confirmed that the dual-lock critical section has been entered. Within the dual-lock critical section, a state change mask is generated based on the target state bit value and the current state bit information carried by the write request. Selective bit write operation is performed based on the state change mask, and the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. The selective bit write operation and the state counter increment update operation are encapsulated into the same atomic transaction, and after the atomic transaction is committed, the mutexes of the state bit field and the mutexes of the state counter are released in the reverse order of locking.

[0009] In this embodiment, within the dual-locked critical section, a state change mask is generated based on the target state bit value carried in the write request and the current state bit information. A selective bit write operation is performed based on the state change mask. Simultaneously, the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. Specifically, this includes: Within the dual-lock critical section, a bitwise XOR operation is performed between the target state bit value carried by the write request and the current state bit information to generate a state change mask. The bit field position where the state change occurs is identified based on the state change mask. Only the bit field corresponding to the valid bit in the state change mask is written, while keeping the original state of the unchanged bit field unchanged. The number of valid bits in the state change mask is counted as the state change count, and the state counter is updated by single-cycle increment according to the state change count.

[0010] In this embodiment, when a read request from the first protocol entry point and a write request from the second protocol entry point are received concurrently, the serialization of the read and write requests based on the distributed state lock specifically includes: When concurrent read requests from the first protocol entry and write requests from the second protocol entry are received, the priority arbiter of the distributed state lock is acquired. Determine the read request starvation and write request starvation in the waiting queue of the distributed state lock; The read and write service order for the current arbitration cycle is determined based on the read and write priority arbitration strategy of the priority arbitrator and the read request starvation and write request starvation in the waiting queues of the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter. If the read / write service order is read priority, then read requests will be scheduled to be executed before write requests. After the read request is completed and the mutex lock of the status bit field is released, the write request will be executed. After the write request is completed, the service delay of the read request will be used as the decay factor for updating the starvation of the write request. If the read / write service order is write-first, then write requests will be scheduled to be executed before read requests. After the write request is completed and the double lock of the mutex of the status bit field and the mutex of the status counter is released, the read request will be executed. After the read request is completed, the waiting queue dwell time of the write request will be used as the incremental factor to update the read request starvation.

[0011] In this embodiment, the status bit information and status counter after the completion of the atomic transaction are used as the parsing reference, and the parsing status of the output vehicle fault code specifically includes: After the atomic transaction is committed and all mutexes are released, the final state bit information and state counter are read from the distributed state lock of the vehicle fault code. The current status type and status confidence level of the vehicle fault code are determined based on the combined encoding of the fault request flag bit, historical fault flag bit, and unconfirmed fault flag bit in the status bit information. The frequency trend and predicted occurrence cycle of vehicle fault codes are determined based on the cumulative value of the occurrence count and the occurrence timestamp sequence of the vehicle fault codes in the status counter. The parsing status of the vehicle fault code is generated by the current status type, the status confidence level, the occurrence frequency trend, and the predicted occurrence cycle.

[0012] In this embodiment, determining the current status type and status confidence level of the vehicle fault code based on the combined encoding of the fault request flag bit, historical fault flag bit, and pending fault flag bit in the status bit information specifically includes: Extract the fault request flag, historical fault flag, and unconfirmed fault flag from the status bit information to form a three-dimensional status coding vector; When the three-dimensional state coding vector is the first preset code, the current state type of the vehicle fault code is determined to be the current fault, and the state confidence level of the vehicle fault code is set to the highest level. When the three-dimensional state coding vector is the second preset code, the current state type of the vehicle fault code is determined as a historical fault, and the number of system power-on cycles since the last occurrence of the vehicle fault code is calculated. The state confidence level is determined based on the number of system power-on cycles. When the three-dimensional state encoding vector is the third preset encoding, the current state type of the vehicle fault code is determined to be a fault to be confirmed, the state confidence level of the vehicle fault code is set to the lowest level, and the dwell timer for the fault to be confirmed is started.

[0013] In this embodiment, determining the frequency trend and predicted occurrence cycle of vehicle fault codes based on the accumulated value of the occurrence count of vehicle fault codes in the status counter and the occurrence timestamp sequence specifically includes: Extract the cumulative count of vehicle fault codes and the timestamp sequence of occurrences from the status counter; A sliding statistical window is constructed with the current time as the end point of the window and a preset window duration. The frequency of fault occurrence within the sliding statistical window is counted as the short-term occurrence frequency. The long-term occurrence frequency is calculated based on the cumulative occurrence value and the cumulative system runtime, and then the occurrence frequency trend of the vehicle fault code is determined based on the short-term occurrence frequency and the long-term occurrence frequency. The average interval between occurrences of vehicle fault codes is determined by the occurrence timestamp sequence, and the average interval is used as the predicted occurrence period of vehicle fault codes.

[0014] Secondly, this application provides a multi-protocol compatible intelligent vehicle fault code parsing system for executing a multi-protocol compatible intelligent vehicle fault code parsing method. The intelligent vehicle fault code parsing system includes: The distributed state lock building module is used to establish an independent distributed state lock for each vehicle fault code. The read status lock module is used to lock the mutual exclusion area of ​​the status bit field in the distributed status lock when a fault code status bit read request is initiated by the first protocol entry, and release the lock after reading the status bit information; The write state locking module is used to lock the mutual exclusion area of ​​the state bit field and the mutual exclusion area of ​​the state counter in the distributed state lock when a fault code state bit write request is detected from the second protocol entry. During the locking period, the state bit write operation and the state counter update operation are performed, and the write operation and update operation are encapsulated into atomic transactions. The concurrent serial processing module is used to serialize the read request and write request according to the distributed state lock when the concurrent read request of the first protocol entry and the write request of the second protocol entry are received concurrently. The vehicle fault code status bit parsing module is used to output the parsing status of the vehicle fault code by using the status bit information and status counter after the completion of the atomic transaction as the parsing reference.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: An independent distributed state lock is established for each vehicle fault code. When a fault code status bit read request is detected from the first protocol entry, the mutex region of the status bit field within the distributed state lock is locked, and the lock is released after reading the status bit information. When a fault code status bit write request is detected from the second protocol entry, the mutex regions of the status bit field and the mutex region of the status counter within the distributed state lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed, and the write operation and update operation are encapsulated into atomic transactions. When the read request from the first protocol entry and the write request from the second protocol entry are received concurrently, the read request and write request are serialized according to the distributed state lock. The status bit information and status counter after the atomic transaction are completed are used as the parsing reference to output the parsing status of the vehicle fault code.

[0016] Therefore, this application demonstrates that the status bit information and status counter after the completion of atomic transactions can be used as the parsing benchmark to output the parsing status of automotive fault codes. Firstly, by establishing an independent distributed status lock for each automotive fault code, a dedicated control area can be defined for the status bit operations of different protocols, thereby blocking the interaction interference of status bit information from multiple protocols. Secondly, when a fault code status bit read request is detected from the first protocol entry point, the lock is released after the status bit read is completed by locking the mutex region of the status bit field within the distributed status lock, which standardizes the execution order of multi-protocol read operations, prevents the status bit from being tampered with by other protocol operations during the read process, and ensures the authenticity and validity of the read status bit information. Furthermore, when a fault code status bit write request is detected from the second protocol entry point, the mutex regions of the status bit field and the status counter are locked simultaneously, and the status bit write and status counter update are synchronized. By structuring transactions as atomic transactions, intermediate state data generated by multi-protocol write operations can be eliminated, avoiding contradictions in fault status determination caused by asynchronous status bit updates, thus solving the problem of distorted parsing results. Furthermore, when concurrent read and write requests from different protocols are received, serialization is achieved through a priority arbiter of a distributed state lock, which can reasonably schedule the execution order of multi-protocol requests, preventing fault omissions and false alarms caused by read and write request resource contention, and balancing the fairness and timeliness of multi-protocol access. Finally, the status bit information and status counter value after the atomic transaction are completed are used as a unified parsing benchmark to output the vehicle fault code parsing status, which can achieve compatibility and unified calibration of status bit information from different protocols, effectively resolving concurrent conflicts caused by differences in status bit field allocation, status definition, and judgment logic among multiple protocols, significantly improving the reliability and accuracy of the on-board diagnostic system, and breaking the constraints on the large-scale application of multi-protocol on-board diagnostic scenarios.

[0017] In summary, the technical solution adopted in this application can realize the logical resolution of concurrent conflicts of multiple protocol vehicle fault code status bits. Attached Figure Description

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

[0019] Figure 1 This is an exemplary flowchart of an intelligent parsing method for automotive fault codes based on multi-protocol compatibility provided in this application; Figure 2 This is a schematic diagram of the structure and data binding relationship of the independent distributed state lock for vehicle fault codes provided in this application; Figure 3 This is a schematic diagram of the operation structure for writing vehicle fault code status bits according to the second protocol entry provided in this application; Figure 4 This is a module structure diagram of an intelligent automotive fault code parsing system based on multi-protocol compatibility provided in this application. Detailed Implementation

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

[0021] This application provides a method and system for intelligent parsing of automotive fault codes based on multi-protocol compatibility. The core of this method is to establish an independent distributed state lock for each automotive fault code. When a fault code status bit read request is detected from a first protocol entry point, the mutual exclusion area of ​​the status bit field within the distributed state lock is locked. After reading the status bit information, the lock is released. When a fault code status bit write request is detected from a second protocol entry point, the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter within the distributed state lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed, and the write and update operations are encapsulated as atomic transactions. When concurrent read requests from the first protocol entry point and write requests from the second protocol entry point are received, the read and write requests are serialized according to the distributed state lock. The status bit information and status counter after the atomic transactions are completed are used as the parsing benchmark to output the parsing status of the automotive fault code.

[0022] Example 1: To better understand the above technical solution, the following will provide a detailed description of the technical solution in conjunction with the accompanying drawings and specific implementation methods. (Refer to...) Figure 1 As shown in the figure, this is an exemplary flowchart of a multi-protocol compatible intelligent parsing method for automotive fault codes according to this embodiment of the present application. The intelligent parsing method for automotive fault codes includes the following steps: In step S1, an independent distributed state lock is established for each vehicle fault code.

[0023] In this embodiment, establishing an independent distributed state lock for each vehicle fault code can be achieved through the following steps: An independent distributed state lock is created for each vehicle fault code identifier. The distributed state lock includes a mutual exclusion area for the state bit field, a mutual exclusion area for the state counter, and a priority arbiter. Bind the mutex region of the status bit field to the status bit information of the vehicle fault code, and bind the mutex region of the status counter to the status counter of the vehicle fault code. Configure a read / write priority arbitration strategy for the priority arbitrator based on the waiting time and request type of read and write requests in the waiting queue of the distributed state lock.

[0024] It should be noted that, in this application, the vehicle fault code identifier refers to identification information used to uniquely distinguish different vehicle fault codes; the distributed state lock refers to a distributed lock structure used to ensure mutual exclusion and safety when multiple protocol entry points concurrently access vehicle fault code data; the mutual exclusion region of the state bit field refers to a critical region in the distributed state lock specifically used to manage the mutual exclusion of reading and writing vehicle fault code state bit information; the mutual exclusion region of the state counter refers to a critical region in the distributed state lock specifically used to manage the mutual exclusion of updating the vehicle fault code state counter; the priority arbiter refers to a scheduling unit in the distributed state lock used to adjudicate the execution order of concurrent read and write requests; the state bit information refers to multi-bit state identifier information representing the current fault state of the vehicle fault code; the state counter refers to a counter used to count the number of times the vehicle fault code state changes; and the read and write priority arbitration strategy refers to the execution rules of the priority arbiter for scheduling read and write requests based on request characteristics.

[0025] It should also be noted that the reference Figure 2As shown in the figure, this diagram illustrates the structure and data binding relationship of the independent distributed state lock for automotive fault codes provided in this application. It showcases a three-layer architecture for fault code state management in multi-protocol compatible scenarios: an automotive fault code identifier layer, a distributed state lock core layer, and a fault code associated data layer. The automotive fault code identifier layer establishes a one-to-one mapping with the distributed state lock through a unique identifier. Each fault code identifier corresponds to an independent distributed state lock, achieving fault code-level resource isolation. The distributed state lock core layer has a built-in mutual exclusion area for the state bit field, and... The mutex region of the state counter, the priority arbitrator, and the read / write request scheduling module adjudicate concurrent read / write requests from multiple protocols through read / write mutual exclusion control and read / write priority arbitration strategies, blocking cross-interference of status bit information from different protocols. The fault code associated data layer binds the mutex region of the status bit field to the vehicle fault code status bit information and the mutex region of the state counter to the vehicle fault code status counter through address binding, realizing exclusive mutual exclusion access to the core fault code data. Each distributed state lock is independent of each other and there is no data interaction, ensuring the consistency of fault code status data and the security of concurrent operations under multi-protocol compatibility.

[0026] In specific implementation, firstly, a vehicle fault code identifier is generated based on the unique encoding characteristics of the vehicle fault code. A distributed lock creation interface is used to instantiate an independent distributed state lock for each vehicle fault code identifier. The lock body structure is pre-divided into mutual exclusion areas for the state bit fields and mutual exclusion areas for the state counters, and a priority arbitrator is integrated. The instantiated distributed state lock serves as a dedicated concurrent control lock body for the vehicle fault code. Secondly, a memory address mapping binding method is used to associate and bind the mutual exclusion areas of the state bit fields in the distributed state lock with the storage address of the vehicle fault code's state bit information. Simultaneously, the mutual exclusion areas of the state counters are associated and bound with the storage address of the state counters corresponding to the vehicle fault code. The exclusion zone and its corresponding data unit serve as mutual exclusion control objects for subsequent concurrent access. Finally, an enqueue timestamp is added to each read and write request in the waiting queue of the distributed state lock. The real-time waiting time for each request is calculated by the difference between the current system time and the enqueue timestamp. At the same time, the request type is identified by parsing the type flag in the request message. The real-time waiting time of the request is then directly associated with the sorting criteria of the priority arbiter. Write requests are marked as dedicated scheduling types and read requests are marked as shared scheduling types. The waiting time sorting rules and read / write type differentiation rules are directly written into the scheduling kernel of the priority arbiter. The scheduling rules after the write is completed are used as the read / write priority arbitration strategy of the priority arbiter.

[0027] In step S2, when a fault code status bit reading request is detected from the first protocol entry, the mutual exclusion area of ​​the status bit field within the distributed status lock is locked, and the lock is released after reading the status bit information.

[0028] In this embodiment, when a fault code status bit read request is detected from the first protocol entry point, locking the mutual exclusion area of ​​the status bit field within the distributed status lock, and releasing the lock after reading the status bit information can be achieved through the following steps: When a fault code status bit read request is initiated by the first protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the read request. A non-blocking locking attempt is initiated to the mutex of the state bit field within the distributed state lock. When the locking attempt fails, the read request is added to the read wait queue of the mutex and a wait timeout timer is started. During the successful locking process, the status bit information of the vehicle fault code is read and stored in the read buffer. After the status bit information is stored in the read buffer, a release lock operation is performed on the mutex area of ​​the status bit field, and the next waiting request is woken up from the read wait queue.

[0029] It should be noted that, in this application, the first protocol entry point represents the protocol communication port that initiates the vehicle fault code status bit reading operation; the fault code status bit reading request represents the acquisition request initiated by the first protocol entry point to obtain vehicle fault code status bit information; the non-blocking lock attempt represents a mutex lock request method that does not block the current execution flow and directly returns the lock result; the read wait queue represents a queue structure in which the mutex of the status bit field is used to cache read requests that have not been successfully locked; the wait timeout timer represents a timing unit used to monitor the waiting time for read requests to lock; and the read cache area represents a cache area used to temporarily store filtered status bit information.

[0030] In specific implementation, firstly, the system listens for communication messages at the first protocol entry point via the protocol port. After identifying a fault code status bit read request message, it parses and extracts the fault code identifier carried in the message, and locates the distributed status lock of the vehicle fault code through identifier matching retrieval. Secondly, it calls the non-blocking lock request interface to initiate a lock request to the mutex of the status bit field within the distributed status lock. If the lock request returns a failure flag, the current read request is added to the read wait queue of the mutex of the status bit field for caching, and a hardware timing unit is started as a wait timeout timer for the request. Next, within the lock validity period when the lock request returns a success flag, the status bit information of the vehicle fault code is read from the bound storage address, and the obtained status bit information is stored in a dedicated read cache. Finally, after the status bit information is stored in the dedicated read cache, the lock release interface is called to perform an unlock operation on the mutex of the status bit field, and then the next pending read request is retrieved from the read wait queue and woken up.

[0031] In step S3, when a fault code status bit write request is detected from the second protocol entry, the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter in the distributed status lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed, and the write operation and update operation are encapsulated into an atomic transaction.

[0032] In this embodiment, when a fault code status bit write request is detected from the second protocol entry point, the mutual exclusion region of the status bit field and the mutual exclusion region of the status counter within the distributed status lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed. Encapsulating the write operation and the update operation into an atomic transaction can be achieved using the following steps: When a fault code status bit write request is detected from the second protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the write request. Simultaneously initiate a lock request to the mutual exclusion zone of the state bit field and the mutual exclusion zone of the state counter within the distributed state lock, and carry a transaction identifier in the lock request. When both mutual exclusion zones return a lock success flag carrying the same transaction identifier, it is confirmed that the dual-lock critical section has been entered. Within the dual-lock critical section, a state change mask is generated based on the target state bit value and the current state bit information carried by the write request. Selective bit write operation is performed based on the state change mask, and the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. The selective bit write operation and the state counter increment update operation are encapsulated into the same atomic transaction, and after the atomic transaction is committed, the mutexes of the state bit field and the mutexes of the state counter are released in the reverse order of locking.

[0033] It should be noted that, in this application, the second protocol entry point represents the protocol communication port that initiates the vehicle fault code status bit write operation; the fault code status bit write request represents an update request initiated by the second protocol entry point to modify the vehicle fault code status bit information; the transaction identifier represents identification information used to uniquely identify this double-lock and data operation process; the double-lock critical section represents a dedicated operation area simultaneously locked by the mutual exclusion section of the status bit field and the mutual exclusion section of the status counter; the status change mask represents the bit field identification information used to characterize the numerical change in the status bit information; the selective bit write operation represents a write method that only modifies the bit fields that have changed in the status bit information; and the atomic transaction represents an indivisible operation unit that ensures that the status bit write and the status counter update take effect or fail simultaneously.

[0034] It should also be noted that the reference Figure 3As shown in the figure, this diagram is a schematic diagram of the second protocol entry point vehicle fault code status bit writing operation structure provided in this application. This diagram uses a distributed state lock as the core control unit, with built-in mutual exclusion areas for status bit fields, mutual exclusion areas for status counters, and a priority arbitrator to achieve concurrent access isolation of the core fault code data. When the second protocol initiates a fault code status bit writing request, the locking request carries a transaction identifier to initiate a double mutual exclusion area locking request to the distributed state lock. After the priority arbitrator determines the double lock, if the double lock is successful, it enters the dedicated double-lock critical section. Within the critical section, the selective bit writing operation and the status counter update operation are executed synchronously. The two are encapsulated into an atomic transaction to ensure the integrity and consistency of the writing operation. After the transaction is committed, the double mutual exclusion areas are released in reverse order to complete this writing process.

[0035] In specific implementation, firstly, the communication data of the second protocol entry is monitored through the protocol port. After identifying the fault code status bit write request message, the fault code identifier carried in the message is parsed and extracted. The distributed status lock of the vehicle fault code is located by identifier matching retrieval. Secondly, a unique transaction identifier is generated for this write operation and synchronously carried in the lock request. Locking requests are simultaneously initiated to the mutual exclusion zone of the status bit field and the mutual exclusion zone of the status counter in the distributed status lock. Locking response information returned by the two mutual exclusion zones is received respectively. After verifying and confirming that both mutual exclusion zones return a lock success flag with the same transaction identifier, it is confirmed that the current entry into the double-lock critical section is confirmed. Then, within the double-lock critical section, a status change mask is generated according to the target status bit value and the current status bit information carried in the write request. Selective bit write operation is performed according to the status change mask, and the valid bits in the status change mask are used for writing. The state counter's accumulated value is updated atomically. Finally, the transaction encapsulation interface is called to associate and bind the selective bit write operation with the state counter's accumulated update operation, clarifying the execution dependency between the two operations. The bound set of operations is treated as a single atomic transaction, triggering the transaction commit verification mechanism to verify the execution integrity and data consistency of the two operations one by one. After confirming that both operations have been executed without errors and that there are no data anomalies, the atomic transaction is committed. After the transaction is successfully committed and an acknowledgment signal is returned, the unlocking operation is performed in the reverse order of the locking order (first locking the mutex of the state bit field, then locking the mutex of the state counter). First, the unlocking interface of the mutex of the state counter is called to release the mutex. After it is completely released, the unlocking interface of the mutex of the state bit field is called to release the mutex. The two mutexes after unlocking are restored to the unlocked state, serving as the initial control state for the next concurrent access.

[0036] In this embodiment, within the dual-locked critical section, a state change mask is generated based on the target state bit value carried by the write request and the current state bit information. A selective bit write operation is then performed based on the state change mask. Simultaneously, the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. This can be achieved through the following steps: Within the dual-lock critical section, a bitwise XOR operation is performed between the target state bit value carried by the write request and the current state bit information to generate a state change mask. The bit field position where the state change occurs is identified based on the state change mask. Only the bit field corresponding to the valid bit in the state change mask is written, while keeping the original state of the unchanged bit field unchanged. The number of valid bits in the state change mask is counted as the state change count, and the state counter is updated by single-cycle increment according to the state change count.

[0037] It should be noted that the bitwise XOR operation described in this application represents a logical operation used to compare the target state bit value with the current state bit information and mark the difference bits between the two. The operation rule is that if the corresponding bit values ​​are the same, the output is 0, and if the values ​​are different, the output is 1. The valid bit represents the bit in the state change mask that is output as 1, indicating that the corresponding bit field has undergone a state change. The state change count represents the value obtained after counting the number of valid bits in the state change mask. The single-cycle incremental update represents an atomic update method that completes the update of the state counter accumulation value within one system clock cycle without being interrupted by other operations.

[0038] In specific implementation, firstly, within the dual-lock critical zone, the existing status bit information of the vehicle fault code is read, and the target status bit value carried in the write request is extracted. These two sets of status bit data are synchronously input into the hardware logic operation unit, which performs a bitwise XOR operation, comparing the numerical differences of each bit in the two sets of data. The difference marker result is used as a status change mask. Secondly, the generated status change mask is traversed bit by bit, identifying each valid bit with a value of 1, determining the status bit field position corresponding to each valid bit, and performing the write operation only on these identified bit field positions to transfer the target status bit value. The values ​​of the corresponding bits in the status bit value are overwritten to the bit field. The unchanged bit fields in the mask with values ​​of 0 are not modified in any way, and their original states remain unchanged, thus completing the selective bit writing operation. Finally, the status change mask is counted bit by bit through a dedicated counter register, and the total number of valid bits is recorded. The total number obtained is used as the status change count. The hardware atomic accumulation instruction is called to increment and update the original accumulated value of the status counter according to the status change count within one system clock cycle, ensuring that the update process is not interrupted by other concurrent operations. The updated count value is used as the new accumulated value of the status counter.

[0039] In step S4, when a read request from the first protocol entry and a write request from the second protocol entry are received concurrently, the read request and the write request are serialized according to the distributed state lock.

[0040] In this embodiment, when a read request from the first protocol entry point and a write request from the second protocol entry point are received concurrently, the serialization of the read and write requests based on the distributed state lock can be achieved through the following steps: When concurrent read requests from the first protocol entry and write requests from the second protocol entry are received, the priority arbiter of the distributed state lock is acquired. Determine the read request starvation and write request starvation in the waiting queue of the distributed state lock; The read and write service order for the current arbitration cycle is determined based on the read and write priority arbitration strategy of the priority arbitrator and the read and write request starvation of the waiting queue in the distributed state lock. If the read / write service order is read priority, then read requests will be scheduled to be executed before write requests. After the read request is completed and the mutex lock of the status bit field is released, the write request will be executed. After the write request is completed, the service delay of the read request will be used as the decay factor for updating the starvation of the write request. If the read / write service order is write-first, then write requests will be scheduled to be executed before read requests. After the write request is completed and the double lock of the mutex of the status bit field and the mutex of the status counter is released, the read request will be executed. After the read request is completed, the waiting queue dwell time of the write request will be used as the incremental factor to update the read request starvation.

[0041] It should be noted that, in this application, concurrent reception refers to the state in which read requests from the first protocol entry point and write requests from the second protocol entry point are captured by the system within the same time window; read request starvation refers to the degree of starvation of read requests waiting in the waiting queue; write request starvation refers to the degree of starvation of write requests waiting in the waiting queue; arbitration cycle refers to the time unit in which the priority arbitrator makes a ruling and schedule for concurrent requests; read / write service order refers to the execution order of read requests and write requests; service latency refers to the total time spent from initiation to completion of a read request; decay factor refers to the parameter used to reduce write request starvation; dwell time refers to the total waiting time of a write request from enqueuing to starting execution in the waiting queue; and increment factor refers to the parameter used to increase read request starvation.

[0042] In specific implementation, firstly, when a read request from the first protocol entry and a write request from the second protocol entry arrive simultaneously, a priority arbiter is obtained from the distributed state lock of the vehicle fault code. Secondly, the enqueue timestamps of all read and write requests in the waiting queues of the mutex area of ​​the state bit field and the mutex area of ​​the state counter are read respectively. The cumulative waiting time of each request is calculated by the difference between the current system time and the enqueue timestamp. The cumulative waiting time of read requests is accumulated, and the total accumulated time is used as the read request hunger of the waiting queue. The cumulative waiting time of write requests is also accumulated, and the total accumulated time is used as the write request hunger of the waiting queue. Next, the read and write priority arbitration strategy of the priority arbiter is loaded. The read request hunger and write request hunger of the waiting queue, as well as the corresponding decay factor and increment factor, are synchronously passed to the priority arbiter. The priority arbiter uses write requests as the default basic priority type, deducts the write request hunger and decay factor to reduce the hunger weight of write requests, and adds the read request hunger and increment factor to increase the hunger weight of read requests. The two adjusted hunger values ​​are directly compared. If the adjusted read request hunger is higher, read priority is determined; otherwise, write priority is determined. This comparison result is used as the read / write service order for the current arbitration cycle. Furthermore, if the priority arbitrator determines the read / write service order to be read priority, read requests are scheduled before write requests, triggering the read request execution process. After the read request completes all operations and releases the mutex lock in the status bit field, the write request execution process is started. After the write request is completed, the execution time of the read request from initiation to completion is calculated. The total time taken is used as the service latency for this operation, and this service latency is used as the decay factor for the starvation of update write requests. Finally, if the priority arbiter determines that the read and write service order is write priority, the write request will be arranged before the read request, triggering the write request execution process. After the write request completes all operations and releases the double lock of the mutex of the status bit field and the mutex of the status counter, the read request execution process will be started. After the read request is completed, the dwell time of the write request in the waiting queue is calculated, and this dwell time is used as the incremental factor for updating the starvation of read requests.

[0043] In step S5, the status bit information and status counter after the atomic transaction are used as the parsing reference to output the parsing status of the vehicle fault code.

[0044] In this embodiment, the status bit information and status counter after the completion of the atomic transaction are used as the parsing reference. The parsing status of the vehicle fault code can be output by the following steps: After the atomic transaction is committed and all mutexes are released, the final state bit information and state counter are read from the distributed state lock of the vehicle fault code. The current status type and status confidence level of the vehicle fault code are determined based on the combined encoding of the fault request flag bit, historical fault flag bit, and unconfirmed fault flag bit in the status bit information. The frequency trend and predicted occurrence cycle of vehicle fault codes are determined based on the cumulative value of the occurrence count and the occurrence timestamp sequence of the vehicle fault codes in the status counter. The parsing status of the vehicle fault code is generated by the current status type, the status confidence level, the occurrence frequency trend, and the predicted occurrence cycle.

[0045] It should be noted that the current state type mentioned in this application is used to characterize the fault classification state of the vehicle fault code; the state confidence level is used to characterize the credibility of the current state type; the occurrence frequency trend is used to characterize the changing trend of the frequency of occurrence of the vehicle fault code; the prediction occurrence period is used to characterize the estimated recurrence time interval of the vehicle fault code; and the parsed state is a complete judgment result of the comprehensive state and change pattern of the vehicle fault code.

[0046] In specific implementation, firstly, after the atomic transaction is successfully committed and the mutexes of the status bit field and the status counter are released, the latest status bit information and status counter are retrieved from the distributed status lock of the vehicle fault code. Secondly, the current status type and status confidence level of the vehicle fault code are determined based on the combined encoding of the fault request flag, historical fault flag, and pending fault flag in the status bit information. Next, the occurrence frequency trend and predicted occurrence cycle of the vehicle fault code are determined based on the cumulative value of the occurrence count of the vehicle fault code and the occurrence timestamp sequence in the status counter. Finally, the information of the four dimensions of current status type, status confidence level, occurrence frequency trend, and predicted occurrence cycle are structured and encapsulated to form a unified fault code parsing status data structure. This data structure includes a fault code identifier, status type enumeration value, confidence level value, trend direction indicator, and prediction cycle duration. The parsed status is returned to the upper-layer diagnostic service or diagnostic instrument terminal through a preset status output interface, completing the entire output process of the vehicle fault code parsing status.

[0047] In this embodiment, determining the current status type and status confidence level of the vehicle fault code based on the combined encoding of the fault request flag bit, historical fault flag bit, and unconfirmed fault flag bit in the status bit information can be achieved through the following steps: Extract the fault request flag, historical fault flag, and unconfirmed fault flag from the status bit information to form a three-dimensional status coding vector; When the three-dimensional state coding vector is the first preset code, the current state type of the vehicle fault code is determined to be the current fault, and the state confidence level of the vehicle fault code is set to the highest level. When the three-dimensional state coding vector is the second preset code, the current state type of the vehicle fault code is determined as a historical fault, and the number of system power-on cycles since the last occurrence of the vehicle fault code is calculated. The state confidence level is determined based on the number of system power-on cycles. When the three-dimensional state encoding vector is the third preset encoding, the current state type of the vehicle fault code is determined to be a fault to be confirmed, the state confidence level of the vehicle fault code is set to the lowest level, and the dwell timer for the fault to be confirmed is started.

[0048] It should be noted that the three-dimensional status coding vector described in this application is formed by combining the fault request flag bit, the historical fault flag bit, and the pending fault flag bit in a fixed position order; the first preset code, the second preset code, and the third preset code are predefined vehicle fault status differentiation coding rules; the number of system power-on cycles is the number of power-on operation cycles accumulated by the vehicle system since the last trigger of the fault code. Its value directly reflects the timeliness of historical faults. The fewer the number of cycles, the closer the fault is to the present and the higher the status credibility. The more the number of cycles, the weaker the fault timeliness and the lower the status credibility.

[0049] In specific implementation, firstly, a bit-field extraction operation is performed on the final status bit information after the atomic transaction is committed. The level values ​​of the fault request flag, historical fault flag, and pending fault flag are extracted using a bit-field recognition algorithm and combined in a fixed order to form a three-bit status code vector. Secondly, the generated three-bit status code vector is compared bit-by-bit with a first preset code. If they match completely, the current status type of the vehicle fault code is immediately determined to be the current fault. Since the current fault is the most recently triggered fault after the atomic transaction, its status authenticity is the highest, and the status confidence level of the vehicle fault code is directly configured to the highest level. Next, if the three-bit status code vector matches a second preset code, the current status type of the vehicle fault code is determined to be a historical fault. At this point, the vehicle system power-on log is retrieved, and the last fault code in the vehicle system power-on log is counted. The system power-on cycles since the fault occurred are used to determine the status confidence level. If the number of system power-on cycles is ≤3, it indicates that the fault occurred recently and is highly timely, so the status confidence level of the vehicle fault code is determined to be medium-high. If the number of system power-on cycles is ≤10, the fault timeliness is moderate, so the status confidence level of the vehicle fault code is determined to be medium. If the number of system power-on cycles is >10, the fault timeliness is weak, so the status confidence level of the vehicle fault code is determined to be medium-low. Finally, if the three-dimensional status code vector matches the third preset code, the current status type of the vehicle fault code is determined to be a fault awaiting confirmation. Since this type of fault has not been finally confirmed, the status authenticity is the lowest, so the status confidence level of the vehicle fault code is set to the lowest level. At the same time, the dedicated timing module for the fault awaiting confirmation is triggered, and the dwell timer starts to record the dwell time of the fault awaiting confirmation in real time.

[0050] In this embodiment, determining the frequency trend and predicting the occurrence cycle of vehicle fault codes based on the accumulated number of occurrences and the occurrence timestamp sequence of the status counter can be achieved using the following steps: Extract the cumulative count of vehicle fault codes and the timestamp sequence of occurrences from the status counter; A sliding statistical window is constructed with the current time as the end point of the window and a preset window duration. The frequency of fault occurrence within the sliding statistical window is counted as the short-term occurrence frequency. The long-term occurrence frequency is calculated based on the cumulative occurrence value and the cumulative system runtime, and then the occurrence frequency trend of the vehicle fault code is determined based on the short-term occurrence frequency and the long-term occurrence frequency. The average interval between occurrences of vehicle fault codes is determined by the occurrence timestamp sequence, and the average interval is used as the predicted occurrence period of vehicle fault codes.

[0051] It should be noted that the cumulative number of occurrences mentioned in this application is the total number of times the vehicle fault code has occurred; the occurrence timestamp sequence is the real-time time record of the system when each vehicle fault is triggered.

[0052] In specific implementation, firstly, the numerical field recording the cumulative number of fault triggers is read from the status counter to obtain the cumulative number of occurrences of the vehicle fault codes since the system's first power-on. Simultaneously, the timestamp data stored sequentially in the status counter according to the fault trigger order is read line by line. After removing invalid null values ​​and abnormal time data, a complete sequence of occurrence timestamps of the vehicle fault codes arranged chronologically is obtained. Secondly, using the current system time as the endpoint of the sliding statistical window, and considering the actual needs of vehicle fault management, the duration of the sliding statistical window is set (set to 1 hour in this application, but can be dynamically adjusted according to the actual scenario without limitation). All fault timestamps falling within this sliding statistical window are filtered out, and the number of fault occurrences within the window is counted, which is taken as the short-term occurrence frequency. Then, the... The system startup log is retrieved, and the cumulative runtime from system startup to the present is calculated. The cumulative number of fault occurrences is divided by the cumulative system runtime, and the result is taken as the long-term fault occurrence frequency. The short-term occurrence frequency is then dynamically compared with the long-term occurrence frequency. If the short-term occurrence frequency is higher than the long-term occurrence frequency, it indicates that the fault occurrence frequency is increasing. If the short-term occurrence frequency is lower than the long-term occurrence frequency, it indicates that the fault occurrence frequency is decreasing. If the two are basically equal, it indicates that the fault occurrence frequency is stable. This clarifies the frequency trend of vehicle fault codes. Finally, the time interval between each fault occurrence in the timestamp sequence is calculated, and the difference between two adjacent fault trigger times is calculated. The average value of all differences is used as the predicted occurrence cycle of vehicle fault codes.

[0053] Therefore, this application demonstrates that the status bit information and status counter after the completion of atomic transactions can be used as the parsing benchmark to output the parsing status of automotive fault codes. Firstly, by establishing an independent distributed status lock for each automotive fault code, a dedicated control area can be defined for the status bit operations of different protocols, thereby blocking the interaction interference of status bit information from multiple protocols. Secondly, when a fault code status bit read request is detected from the first protocol entry point, the lock is released after the status bit read is completed by locking the mutex region of the status bit field within the distributed status lock, which standardizes the execution order of multi-protocol read operations, prevents the status bit from being tampered with by other protocol operations during the read process, and ensures the authenticity and validity of the read status bit information. Furthermore, when a fault code status bit write request is detected from the second protocol entry point, the mutex regions of the status bit field and the status counter are locked simultaneously, and the status bit write and status counter update are synchronized. By structuring transactions as atomic transactions, intermediate state data generated by multi-protocol write operations can be eliminated, avoiding contradictions in fault status determination caused by asynchronous status bit updates, thus solving the problem of distorted parsing results. Furthermore, when concurrent read and write requests from different protocols are received, serialization is achieved through a priority arbiter of a distributed state lock, which can reasonably schedule the execution order of multi-protocol requests, preventing fault omissions and false alarms caused by read and write request resource contention, and balancing the fairness and timeliness of multi-protocol access. Finally, the status bit information and status counter value after the atomic transaction are completed are used as a unified parsing benchmark to output the vehicle fault code parsing status, which can achieve compatibility and unified calibration of status bit information from different protocols, effectively resolving concurrent conflicts caused by differences in status bit field allocation, status definition, and judgment logic among multiple protocols, significantly improving the reliability and accuracy of the on-board diagnostic system, and breaking the constraints on the large-scale application of multi-protocol on-board diagnostic scenarios.

[0054] In summary, the technical solution adopted in this application can realize the logical resolution of concurrent conflicts of multiple protocol vehicle fault code status bits.

[0055] Example 2: This application provides an intelligent vehicle fault code parsing system based on multi-protocol compatibility, referencing... Figure 4 As shown in the figure, this is a module structure diagram of a multi-protocol compatible intelligent vehicle fault code parsing system according to this embodiment of the present application. The intelligent vehicle fault code parsing system includes: Distributed state lock building module 100 is used to establish an independent distributed state lock for each vehicle fault code; The read status lock module 200 is used to lock the mutual exclusion area of ​​the status bit field in the distributed status lock when a fault code status bit read request is initiated by the first protocol entry, and release the lock after reading the status bit information. The write state locking module 300 is used to lock the mutual exclusion area of ​​the state bit field and the mutual exclusion area of ​​the state counter in the distributed state lock when a fault code state bit write request is detected from the second protocol entry. During the locking period, the state bit write operation and the state counter update operation are performed, and the write operation and update operation are encapsulated into atomic transactions. The concurrent serial processing module 400 is used to serialize the read request and write request according to the distributed state lock when the concurrent read request of the first protocol entry and the write request of the second protocol entry are received concurrently. The vehicle fault code status bit parsing module 500 is used to output the parsing status of the vehicle fault code by using the status bit information and status counter after the completion of the atomic transaction as the parsing reference.

[0056] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0057] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compactdisc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0058] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

Claims

1. A method for intelligent parsing of automotive fault codes based on multi-protocol compatibility, characterized in that, The intelligent vehicle fault code parsing method includes the following steps: Establish an independent distributed state lock for each vehicle fault code; When a fault code status bit read request is detected from the first protocol entry, the mutual exclusion area of ​​the status bit field in the distributed status lock is locked, and the lock is released after the status bit information is read. When a fault code status bit write request is detected from the second protocol entry, the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter in the distributed status lock are locked at the same time. During the locking period, the status bit write operation and the status counter update operation are executed, and the write operation and update operation are encapsulated into atomic transactions. When concurrent read requests from the first protocol entry and write requests from the second protocol entry are received, the read and write requests are serialized according to the distributed state lock. Using the status bit information and status counter after the atomic transaction is completed as the parsing reference, the parsing status of the vehicle fault code is output.

2. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 1, characterized in that, Establishing an independent distributed state lock for each vehicle fault code specifically includes: An independent distributed state lock is created for each vehicle fault code identifier. The distributed state lock includes a mutual exclusion area for the state bit field, a mutual exclusion area for the state counter, and a priority arbiter. Bind the mutex region of the status bit field to the status bit information of the vehicle fault code, and bind the mutex region of the status counter to the status counter of the vehicle fault code. Configure a read / write priority arbitration strategy for the priority arbitrator based on the waiting time and request type of read and write requests in the waiting queue of the distributed state lock.

3. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 1, characterized in that, When a fault code status bit read request is detected from the first protocol entry point, the mutual exclusion area of ​​the status bit field within the distributed status lock is locked, and the lock is released after reading the status bit information. Specifically, this includes: When a fault code status bit read request is initiated by the first protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the read request. A non-blocking locking attempt is initiated to the mutex of the state bit field within the distributed state lock. When the locking attempt fails, the read request is added to the read wait queue of the mutex and a wait timeout timer is started. During the successful locking process, the status bit information of the vehicle fault code is read and stored in the read buffer. After the status bit information is stored in the read buffer, a release lock operation is performed on the mutex area of ​​the status bit field, and the next waiting request is woken up from the read wait queue.

4. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 1, characterized in that, When a fault code status bit write request is detected from the second protocol entry point, the mutual exclusion area of ​​the status bit field and the mutual exclusion area of ​​the status counter within the distributed status lock are locked simultaneously. During the locking period, the status bit write operation and the status counter update operation are performed, and the write operation and update operation are encapsulated into an atomic transaction, specifically including: When a fault code status bit write request is detected from the second protocol entry, the distributed status lock of the vehicle fault code is located according to the fault code identifier carried in the write request. Simultaneously initiate a lock request to the mutual exclusion zone of the state bit field and the mutual exclusion zone of the state counter within the distributed state lock, and carry a transaction identifier in the lock request. When both mutual exclusion zones return a lock success flag carrying the same transaction identifier, it is confirmed that the dual-lock critical section has been entered. Within the dual-lock critical section, a state change mask is generated based on the target state bit value and the current state bit information carried by the write request. Selective bit write operation is performed based on the state change mask, and the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. The selective bit write operation and the state counter increment update operation are encapsulated into the same atomic transaction, and after the atomic transaction is committed, the mutexes of the state bit field and the mutexes of the state counter are released in the reverse order of locking.

5. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 4, characterized in that, Within the dual-locked critical section, a state change mask is generated based on the target state bit value carried in the write request and the current state bit information. A selective bit write operation is performed based on the state change mask. Simultaneously, the accumulated value of the state counter is atomically updated based on the number of valid bits in the state change mask. Specifically, this includes: Within the dual-lock critical section, a bitwise XOR operation is performed between the target state bit value carried by the write request and the current state bit information to generate a state change mask. The bit field position where the state change occurs is identified based on the state change mask. Only the bit field corresponding to the valid bit in the state change mask is written, while keeping the original state of the unchanged bit field unchanged. The number of valid bits in the state change mask is counted as the state change count, and the state counter is updated by single-cycle increment according to the state change count.

6. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 1, characterized in that, When concurrent read requests from the first protocol entry point and write requests from the second protocol entry point are received, the serialization of the read and write requests based on the distributed state lock specifically includes: When concurrent read requests from the first protocol entry and write requests from the second protocol entry are received, the priority arbiter of the distributed state lock is acquired. Determine the read request starvation and write request starvation in the waiting queue of the distributed state lock; The read and write service order for the current arbitration cycle is determined based on the read and write priority arbitration strategy of the priority arbitrator and the read and write request starvation of the waiting queue in the distributed state lock. If the read / write service order is read priority, then read requests will be scheduled to be executed before write requests. After the read request is completed and the mutex lock of the status bit field is released, the write request will be executed. After the write request is completed, the service delay of the read request will be used as the decay factor for updating the starvation of the write request. If the read / write service order is write-first, then write requests will be scheduled to be executed before read requests. After the write request is completed and the double lock of the mutex of the status bit field and the mutex of the status counter is released, the read request will be executed. After the read request is completed, the waiting queue dwell time of the write request will be used as the incremental factor to update the read request starvation.

7. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 1, characterized in that, Using the status bit information and status counter after the atomic transaction is completed as the parsing basis, the parsing status of the output vehicle fault code specifically includes: After the atomic transaction is committed and all mutexes are released, the final state bit information and state counter are read from the distributed state lock of the vehicle fault code. The current status type and status confidence level of the vehicle fault code are determined based on the combined encoding of the fault request flag bit, historical fault flag bit, and unconfirmed fault flag bit in the status bit information. The frequency trend and predicted occurrence cycle of vehicle fault codes are determined based on the cumulative value of the occurrence count and the occurrence timestamp sequence of the vehicle fault codes in the status counter. The parsing status of the vehicle fault code is generated by the current status type, the status confidence level, the occurrence frequency trend, and the predicted occurrence cycle.

8. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 7, characterized in that, The current status type and status confidence level of the vehicle fault code are determined based on the combined encoding of the fault request flag, historical fault flag, and pending fault flag in the status bit information. Specifically, this includes: Extract the fault request flag, historical fault flag, and unconfirmed fault flag from the status bit information to form a three-dimensional status coding vector; When the three-dimensional state coding vector is the first preset code, the current state type of the vehicle fault code is determined to be the current fault, and the state confidence level of the vehicle fault code is set to the highest level. When the three-dimensional state coding vector is the second preset code, the current state type of the vehicle fault code is determined as a historical fault, and the number of system power-on cycles since the last occurrence of the vehicle fault code is calculated. The state confidence level is determined based on the number of system power-on cycles. When the three-dimensional state encoding vector is the third preset encoding, the current state type of the vehicle fault code is determined to be a fault to be confirmed, the state confidence level of the vehicle fault code is set to the lowest level, and the dwell timer for the fault to be confirmed is started.

9. The intelligent parsing method for automotive fault codes based on multi-protocol compatibility as described in claim 7, characterized in that, Determining the frequency trend and predicted occurrence cycle of vehicle fault codes based on the accumulated occurrence count and timestamp sequence of the fault codes in the status counter specifically includes: Extract the cumulative count of vehicle fault codes and the timestamp sequence of occurrences from the status counter; A sliding statistical window is constructed with the current time as the end point of the window and a preset window duration. The frequency of fault occurrence within the sliding statistical window is counted as the short-term occurrence frequency. The long-term occurrence frequency is calculated based on the cumulative occurrence value and the cumulative system runtime, and then the occurrence frequency trend of the vehicle fault code is determined based on the short-term occurrence frequency and the long-term occurrence frequency. The average interval between occurrences of vehicle fault codes is determined by the occurrence timestamp sequence, and the average interval is used as the predicted occurrence period of vehicle fault codes.

10. A multi-protocol compatible intelligent vehicle fault code parsing system, used to execute the multi-protocol compatible intelligent vehicle fault code parsing method as described in any one of claims 1 to 9, characterized in that, The intelligent vehicle fault code parsing system includes: The distributed state lock building module is used to establish an independent distributed state lock for each vehicle fault code. The read status lock module is used to lock the mutual exclusion area of ​​the status bit field in the distributed status lock when a fault code status bit read request is initiated by the first protocol entry, and release the lock after reading the status bit information; The write state locking module is used to lock the mutual exclusion area of ​​the state bit field and the mutual exclusion area of ​​the state counter in the distributed state lock when a fault code state bit write request is detected from the second protocol entry. During the locking period, the state bit write operation and the state counter update operation are performed, and the write operation and update operation are encapsulated into atomic transactions. The concurrent serial processing module is used to serialize the read request and write request according to the distributed state lock when the concurrent read request of the first protocol entry and the write request of the second protocol entry are received concurrently. The vehicle fault code status bit parsing module is used to output the parsing status of the vehicle fault code by using the status bit information and status counter after the completion of the atomic transaction as the parsing reference.

Images