Vehicle-end diagnosis middleware, vehicle-cloud collaborative diagnosis method, electronic device, and medium

Abstract

The application provides a vehicle-end diagnosis middleware, a vehicle-cloud collaborative diagnosis method, an electronic device and a medium, and belongs to the technical field of vehicle diagnosis. The vehicle-end diagnosis middleware comprises a script analysis engine, which is used for analyzing a diagnosis script in JSON format obtained from the cloud to generate diagnosis instructions suitable for a vehicle-mounted bus. The script analysis engine comprises: a pre-allocated fixed-size memory pool, which is used for storing temporary objects generated in the analysis process; a syntax tree analysis module, which is used for analyzing the diagnosis script into an abstract syntax tree and traversing and extracting diagnosis instruction fields; an instruction assembly module, which is used for assembling the diagnosis instruction fields into data frames in accordance with the vehicle-mounted bus protocol; and an incremental analysis module, which is used for detecting changes in the diagnosis script or a related configuration file and performing an analysis operation on the changed part. The application improves the analysis efficiency of the vehicle-end diagnosis script and the real-time response capability of the vehicle-cloud collaborative diagnosis.

Description

Technical Field

[0001] This invention relates to the field of vehicle diagnostic technology, specifically to a vehicle-side diagnostic middleware, a vehicle-cloud collaborative diagnostic method, electronic equipment, and media. Background Technology

[0002] Vehicle-side diagnostic middleware is a core software component deployed in the vehicle domain controller or central computing platform. It handles diagnostic tasks sent from the cloud, converts diagnostic scripts into instructions recognizable by the vehicle bus, and distributes them to each Electronic Control Unit (ECU). Simultaneously, it collects ECU response data and transmits it back to the cloud. As automotive electronic and electrical architecture evolves towards centralization, diagnostic middleware needs to be compatible with multiple bus protocols such as CAN, LIN, and DoIP, adapt to ECUs from different manufacturers and models, and meet the stringent requirements of the automotive environment regarding real-time performance, stability, and resource consumption.

[0003] In the process of developing this invention, the inventors discovered that existing vehicle-side diagnostic middleware and diagnostic script parsing solutions have at least the following drawbacks: First, traditional diagnostic script parsing engines mostly use general-purpose JSON parsing libraries or standardized OTX engines. In an in-vehicle environment, these engines face problems such as bloated code, fragmentation due to frequent dynamic memory allocation, and the need for a full scan of the script file for each parsing operation, resulting in low parsing efficiency and difficulty in achieving rapid response to diagnostic tasks under limited computing resources on the vehicle side. Second, existing middleware configuration parameters typically use a static loading method, meaning that modifications to the configuration file require a service restart to take effect. This prevents dynamic adjustment of execution conditions or timeouts during diagnostic task execution, reducing the system's adaptability to the complex in-vehicle environment. Third, the writing of local manifest files during vehicle initialization lacks atomicity guarantees. When encountering power outages, disk anomalies, or abnormal process exits, the files are easily corrupted, causing the middleware to fail to start normally or diagnostic tasks to be lost. Fourth, during vehicle-cloud interaction, existing solutions often use simple synchronous request methods in script downloading, report uploading, and status reporting, affecting the continuity of diagnostic tasks and the real-time nature of cloud monitoring.

[0004] Therefore, designing a vehicle-side diagnostic middleware with high parsing efficiency, support for hot configuration loading, protection of initialization data integrity, and robust vehicle-cloud interaction in a vehicle-based environment with limited resources is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] In view of this, it is necessary to provide a vehicle-side diagnostic middleware, a vehicle-cloud collaborative diagnostic method, electronic devices, and storage media to solve the technical problems of low efficiency in parsing vehicle-side diagnostic scripts, easy data corruption, and low configuration flexibility caused by the use of general JSON parsing libraries or standardized OTX engines in existing methods.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a vehicle-side diagnostic middleware, comprising: The script parsing engine is used to parse diagnostic scripts in JSON format obtained from the cloud and generate diagnostic instructions suitable for the vehicle bus. The script parsing engine includes: A memory pool, with a pre-allocated fixed size, is used to store temporary objects generated during the parsing process; The syntax tree parsing module is used to parse the diagnostic script into an abstract syntax tree and traverse the abstract syntax tree to extract diagnostic instruction fields; The instruction assembly module is used to assemble the diagnostic instruction field into a data frame conforming to the vehicle bus protocol, which serves as the diagnostic instruction. The incremental parsing module is used to detect changes to the diagnostic script or related configuration files and perform parsing operations on the changed parts.

[0007] In one possible implementation, the incremental parsing module includes: The change monitoring unit is used to monitor change events of the diagnostic script or related configuration files through the file system event monitoring mechanism provided by the operating system. The cache management unit is used to cache key-value pairs that have been parsed and have not been changed.

[0008] In one possible implementation, the vehicle-side diagnostic middleware includes a configuration management module; The configuration management module includes an improved INI file parser, which adopts a four-layer modular architecture, including a bottom dependency layer, a core parsing layer, a business adaptation layer, and a configuration application layer. The core parsing layer has a built-in incremental parsing module, which is used to monitor configuration file change events in real time and parse the changed paragraphs so that the service does not need to be restarted when loading parameters in real time.

[0009] In one possible implementation, the business adaptation layer includes a VIN code automatic reading module, which reads the vehicle VIN code through the vehicle information reading interface provided by the operating system and performs regular expression verification to obtain the matching result of the vehicle model parameters.

[0010] In one possible implementation, the vehicle-side diagnostic middleware includes a vehicle-cloud interaction module; The vehicle-cloud interaction module includes: The task synchronization unit is used for incremental synchronization with the cloud based on the RESTful API, and uses the MurMurHash3 hash table to store the local script version list. The script download unit is used to download diagnostic scripts in segments via multi-threading and / or to resume interrupted downloads, and to verify the integrity of the scripts using the SHA256 hash algorithm. The report upload unit is used to upload diagnostic reports in segments to the cloud and / or resume interrupted uploads. The status reporting unit is used to asynchronously report status through a portable operating system interface message queue, using protocol buffer serialization compression.

[0011] In one possible implementation, the diagnostic execution module includes an execution condition verification unit, which is used to obtain the ECU status through a status subscription-push mechanism, compare it with preset execution conditions before the diagnostic task is executed, and report the pause status to the cloud when the conditions are not met.

[0012] On the other hand, the present invention also provides a vehicle-cloud collaborative diagnostic method, applied to vehicle-side diagnostic middleware, including: Retrieve diagnostic scripts in JSON format from the cloud; The diagnostic script is parsed using a script parsing engine; The script parsing engine's parsing process includes: Temporary objects during the parsing process are managed using a pre-allocated, fixed-size memory pool. The diagnostic script is parsed into an abstract syntax tree and the diagnostic instruction fields are extracted. Detect changes to the diagnostic script or related configuration files, and perform parsing operations on the changed parts; The diagnostic commands generated by the analysis are sent to the target ECU via the vehicle bus; Receive response data returned by the target ECU, generate a diagnostic report, and upload it to the cloud.

[0013] In one possible implementation, the vehicle-cloud collaborative diagnostic method includes: Generate the contents of a local manifest file, which includes directory structure information, file attribute information, and verification information; The contents of the manifest are written to the local manifest file using an atomic write mechanism; The atomic writing mechanism includes: The contents of the list are first written to a temporary file, and then the temporary file is forcibly written to disk. Perform format verification and hash verification on the temporary file; After verification, the temporary file is renamed to the official manifest file, overwriting the old manifest file; If the verification fails, delete the temporary file.

[0014] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the vehicle-cloud collaborative diagnostic method described in any of the above implementations.

[0015] Fourthly, the present invention also provides a computer-readable storage medium for storing a computer-readable program or instruction, which, when executed by a processor, can implement the steps of the vehicle-cloud collaborative diagnostic method described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The vehicle-cloud collaborative diagnostic method provided by this invention uses a pre-allocated fixed-size memory pool to store temporary objects generated during the parsing process, avoiding fragmentation problems caused by dynamic memory allocation and improving memory utilization efficiency and parsing stability. A syntax tree parsing module parses the JSON diagnostic script into an abstract syntax tree and extracts diagnostic instruction fields, then assembles them into data frames conforming to the vehicle bus protocol using an instruction assembly module, achieving rapid conversion from script to bus instructions. Simultaneously, an incremental parsing module is set up to perform parsing operations on changed script or configuration file portions, avoiding full-scale repetitive parsing. This improves the parsing efficiency of vehicle-side diagnostic scripts and the efficiency of system resource utilization, which is beneficial for enhancing the real-time response capability of vehicle-cloud collaborative diagnostics. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of an embodiment of the vehicle-end diagnostic intermediate provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of the incremental parsing module; Figure 3 A schematic flowchart of an embodiment of the vehicle-cloud interaction module of the vehicle-side diagnostic middleware provided by the present invention; Figure 4 This is a schematic flowchart of an embodiment of the vehicle-cloud collaborative diagnostic method provided by the present invention; Figure 5 For the present invention Figure 4 A schematic diagram of an embodiment of S402; Figure 6 This is a schematic flowchart of another embodiment of the vehicle-cloud collaborative diagnostic method provided by the present invention; Figure 7 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0019] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0020] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This invention provides a vehicle-side diagnostic middleware, a vehicle-cloud collaborative diagnostic method, an electronic device, and a storage medium. The technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] The vehicle-side diagnostic middleware and / or Docker containerized deployment provided in this embodiment are compatible with CAN bus, LIN bus, and DoIP protocols, and can seamlessly interface with TSP platforms and cloud-based diagnostic services. Regarding resource consumption, this vehicle-side diagnostic middleware strictly controls the usage of CPU, memory, and storage resources through optimized code structure, ensuring that it does not affect the normal operation of other vehicle systems. In terms of security, this vehicle-side diagnostic middleware supports certificate verification, signature verification, encrypted data storage, and access control to prevent instruction tampering and data leakage. Furthermore, this vehicle-side diagnostic middleware reserves interface expansion capabilities and / or diagnostic script format upgrades, adaptation to new ECU models, and flexible addition of new functional modules (such as security verification and log analysis).

[0024] Figure 1This is a schematic diagram of an embodiment of the vehicle-side diagnostic middleware provided by the present invention, as shown below. Figure 1 As shown, the vehicle-side diagnostic middleware includes a script parsing engine 100, which is used to parse diagnostic scripts in JSON format obtained from the cloud and generate diagnostic instructions suitable for the vehicle bus. Specifically, the script parsing engine 100 includes a memory pool 101, a syntax tree parsing module 102, an instruction assembly module 103, and an incremental parsing module 104.

[0025] Memory pool 101 has a pre-allocated fixed size for storing temporary objects generated during the parsing process.

[0026] For example, when parsing a JSON script containing multiple diagnostic instructions, the generated syntax tree nodes, intermediate variables, and other temporary data are all allocated from this memory pool 101, rather than frequently calling the system's dynamic memory allocation function. It should be noted that the size of memory pool 101 can be configured according to the actual resource situation of the in-vehicle device, for example, configured to 10KB, to achieve a balance between memory usage and parsing performance.

[0027] The syntax tree parsing module 102 is responsible for parsing the JSON-formatted diagnostic script into an abstract syntax tree and traversing the abstract syntax tree to extract diagnostic instruction fields.

[0028] An Abstract Syntax Tree (ABST) is a data structure that represents the hierarchical structure of script syntax in a tree-like format. Each node corresponds to a key-value pair or array element in the script. By traversing this tree, key fields such as the target ECU address, service identifier, and timeout can be quickly located.

[0029] The instruction assembly module 103 assembles the diagnostic instruction fields extracted by the syntax tree parsing module 102 into a data frame that conforms to the vehicle bus protocol, which is then used as the final diagnostic instruction.

[0030] Among them, the vehicle bus protocol includes, but is not limited to, CAN bus, LIN bus, or DoIP (IP-based diagnostic communication) protocol.

[0031] For example, if the target ECU uses CAN bus communication, the instruction assembly module 103 fills the service identifier and parameters into the data field of the CAN frame and sets the correct arbitration ID and data length.

[0032] The incremental parsing module 104 is used to detect changes in diagnostic scripts or related configuration files and perform parsing operations on the changed parts.

[0033] Specifically, when a new diagnostic script is issued from the cloud or the vehicle-side configuration file is modified, the incremental parsing module 104 only re-parses the changed paragraphs or key-value pairs, while reusing the previous parsing results for the rest. This approach avoids performing a full script scan for every diagnostic task, significantly reducing parsing time.

[0034] Furthermore, in this embodiment, the syntax tree parsing module 102 of the script parsing engine performs lexical analysis before constructing the syntax tree. This module uses C language to write basic functions such as character reading and memory allocation, eliminating unnecessary document object model operations and formatted output code found in general JSON parsing libraries.

[0035] Specifically, the module reads the JSON script content character by character, processing each character through a state machine (including an initial state, string state, numeric state, boolean state, and empty state). When a double quote is encountered, it enters the string state; when a backslash is encountered, it handles escape characters (such as newlines and double quotes). Each identified lexical unit (tag) contains type, value, line number, and column number information. Simultaneously, the module uses a regular expression state machine to synchronously check whether curly braces, square brackets, and double quotes are paired; if a mismatch is found, a format error is immediately returned.

[0036] After the syntax tree is built, the script parsing engine further performs semantic validation. The rules for semantic validation include: checking that the string length does not exceed 1024 bytes, integer values ​​are within the range of -2^31 to 2^31-1, and the nesting level of JSON objects or arrays does not exceed 16 levels. For semantics specific to diagnostic commands, the module checks whether the service identifier belongs to the standard range (0x10 to 0x3E) or the manufacturer-defined range (0x80 to 0xFF), whether the target ECU address exists in the pre-read ECU address list, and whether the current vehicle's model ID matches the model required in the script. If any validation fails, the parsing engine returns the specific error type and location.

[0037] It's worth noting that the script parsing engine also possesses dynamic parameter adaptation capabilities. The engine calls the ECU status subscription function, acquiring ECU operating status, vehicle power mode, and bus load data every 100 milliseconds. It then iterates through a preset rule table, where each rule contains a trigger condition, an execution action, and an adjustment value. When the current status matches a trigger condition (e.g., bus load exceeding 70%), the engine automatically adjusts the command timeout or transmission cycle (e.g., extending the timeout from 20 seconds to 30 seconds, or increasing the transmission interval from 10 milliseconds to 50 milliseconds) to adapt to the dynamically changing in-vehicle environment.

[0038] In addition, the script parsing engine is designed with a scalable architecture.

[0039] Specifically, the engine defines a parsing function pointer type and creates an array of parsing function pointers. When a new instruction type, a new bus protocol, or additional verification rules are needed, developers only need to register the corresponding parsing function in this array. The engine's core execution logic will automatically traverse the function pointer array and call the new function, without modifying the original core code. This extension method allows the middleware to flexibly adapt to iterative upgrades of subsequent diagnostic needs.

[0040] Through the above structure, this embodiment achieves efficient parsing and instruction generation of diagnostic scripts in a vehicle-mounted environment with limited resources. The use of a pre-allocated memory pool 101 avoids dynamic memory fragmentation, the separation of syntax tree parsing and instruction assembly clarifies the logic, and the incremental parsing module 104 reduces redundant calculations, thereby improving overall parsing efficiency and system response speed.

[0041] In some embodiments of the present invention, such as Figure 2 As shown, the incremental parsing module 104 further includes a change monitoring unit 201 and a cache management unit 202.

[0042] The change monitoring unit 201 is used to monitor change events of diagnostic scripts or related configuration files through the file system event monitoring mechanism provided by the operating system.

[0043] As a preferred approach, the file system event monitoring mechanism can be the inotify interface in Linux systems, the ReadDirectoryChangesW interface in Windows systems, or the kqueue interface in Unix-like systems. When a monitored file is modified, deleted, or added, the change monitoring unit 201 can capture the corresponding event in real time and notify the parsing engine.

[0044] The cache management unit 202 is used to cache key-value pairs that have been parsed and have not been changed.

[0045] For example, after parsing a JSON script containing multiple diagnostic commands, the cache management unit 202 stores the key name of each command and its corresponding parsing result (such as command format and parameter type) in the cache. If only one command in the script is modified subsequently, the change monitoring unit 201 detects the change, and the incremental parsing module 104 only re-parses the modified command; the parsing results of other commands are directly read from the cache management unit 202.

[0046] This embodiment achieves accurate change detection through the change monitoring unit 201, avoiding the waste of resources caused by blind polling; at the same time, the cache management unit 202 reuses the parsing results of the unchanged parts, further reducing the amount of parsing operations and disk I / O operations, which is especially suitable for scenarios where diagnostic scripts are frequently updated or configuration files are adjusted multiple times.

[0047] In some embodiments of the present invention, the vehicle-side diagnostic middleware includes a configuration management module. This configuration management module includes an improved INI file parser, which employs a four-layer modular architecture, consisting of a bottom-up dependency layer, a core parsing layer, a business adaptation layer, and a configuration application layer.

[0048] The underlying dependency layer reuses the basic file reading and character preprocessing capabilities of the open-source libini library to ensure compatibility with standard INI configuration files.

[0049] The core parsing layer has a built-in incremental parsing module 104, which is used to monitor configuration file change events in real time and perform parsing on the changed paragraphs.

[0050] The business adaptation layer is responsible for mapping the parsed configuration items to specific business scenarios, such as matching the corresponding vehicle model configuration based on the vehicle's VIN code. The configuration application layer converts the parsed results into an in-memory structure and supports callback notifications when configuration changes occur.

[0051] It should be noted that the incremental parsing module 104 in the core parsing layer is functionally similar to the incremental parsing module 104 in the script parsing engine, but they are applied to different objects. The former is for configuration files, while the latter is for diagnostic scripts. Through this improved INI file parser, when vehicle maintenance personnel modify a parameter in config.ini (such as changing the diagnostic timeout from 20 seconds to 30 seconds), the system can load the new parameter in real time without restarting the middleware service.

[0052] For example, if a diagnostic task is in progress and it is necessary to temporarily adjust the response wait time of an ECU, the new settings will take effect immediately after modifying the configuration file, without interrupting the current task.

[0053] This embodiment achieves hot loading of configuration parameters through a four-layer modular architecture, which improves the flexibility and maintainability of the middleware in complex in-vehicle environments and avoids interruption of diagnostic tasks due to service restarts.

[0054] In some embodiments of the present invention, the service adaptation layer includes a VIN code automatic reading module, which is used to read the vehicle VIN code through the vehicle information reading interface provided by the operating system and perform regular expression verification to obtain the matching result of the vehicle model parameters.

[0055] Specifically, the vehicle information reading interface provided by the operating system has different implementations on different platforms.

[0056] For example, in Linux systems, the VIN code can be obtained by reading the virtual file / sys / class / vin / vin_code; in other embedded operating systems, it may be obtained through the standard OBD-II diagnostic interface or automotive Ethernet service.

[0057] After the VIN code automatic reading module calls these interfaces, it obtains a 17-digit VIN string and then uses regular expressions to verify whether its format conforms to international standards (e.g., non-letters I, O, Q, and the ninth digit is a check digit). If the verification is successful, the VIN code is matched with the locally stored vehicle configuration table, and the corresponding bus parameters, ECU address mappings, and other configuration items are automatically loaded.

[0058] For example, if the first three digits of a vehicle's VIN code are "LFV", representing FAW-Volkswagen, the system will automatically switch to the corresponding CAN bus baud rate and diagnostic session mode.

[0059] This embodiment enables manual configuration of vehicle parameters, reduces manual intervention during deployment, avoids diagnostic failures due to configuration errors, and improves the adaptation efficiency of middleware across different vehicle models.

[0060] In some embodiments of the present invention, such as Figure 3 As shown, the vehicle-side diagnostic middleware includes a vehicle-cloud interaction module 300. The vehicle-cloud interaction module 300 is the hub for communication between the middleware and the cloud-based diagnostic service, and it internally includes a task synchronization unit 301, a script download unit 302, a report upload unit 303, and a status reporting unit 304.

[0061] Task synchronization unit 301 is used for incremental synchronization with the cloud based on RESTful API, and uses MurMurHash3 hash table to store the local script version list.

[0062] RESTful API is an interface design specification based on the HTTP protocol, representing a state transition style. Task synchronization unit 301 periodically sends synchronization requests to the cloud, carrying the hash value of the local script list, which the cloud uses to determine which scripts need to be updated.

[0063] MurMurHash3 is a non-cryptographic hash function that features fast computation speed and low collision rate, making it suitable for use in environments with limited vehicle resources.

[0064] Specifically, the synchronization requests initiated by task synchronization unit 301 are transmitted using HTTPS protocol with TLS 1.3 and a certificate verification mechanism to prevent man-in-the-middle attacks. Request parameters are organized in JSON format and include a list of current script versions on the vehicle side, middleware identifiers, and other information. After the task data returned from the cloud enters the vehicle side, the task synchronization unit verifies each field using a field validator. This field validator has built-in custom regular expressions and length validation rules; for example, the task ID field must be a 32-bit hexadecimal string, and the execution time field must be a timestamp conforming to ISO 8701 format. Any fields that do not meet the specifications are filtered and discarded to prevent illegal data injection into the middleware.

[0065] The script download unit 302 is used to download diagnostic scripts in segments through multi-threading and / or to resume interrupted downloads, and to verify the integrity of the scripts through SHA256 hash algorithm.

[0066] Specifically, when a large diagnostic script needs to be downloaded, the script download unit 302 starts multiple concurrent threads to request different byte ranges (Range) of the script from the cloud CDN nodes. If the network is interrupted during the download, only the incomplete segments are requested when the download resumes. After the download is complete, the SHA256 value of the entire script is calculated and compared with the standard value sent from the cloud. Only if they match is the script saved.

[0067] Furthermore, the script download unit 302 implements multi-threaded download functionality based on the libcurl library. Before downloading, the unit initiates an HTTP Range request to the cloud CDN node, dividing the diagnostic script into multiple segments, the size of which can be dynamically adjusted according to network conditions. During the download process, the offsets of successfully received segments are recorded in a local temporary file. If the network is interrupted, the unit reads this record file during the next download and only requests the incomplete segments. After all segments are downloaded, the unit calculates the SHA256 hash value of the entire script file and compares it byte-by-byte with the standard hash value issued by the cloud. After successful verification, the temporary file is atomically moved to the official script directory via the rename system call. When updating the local script version list, the unit adopts a read-write lock mechanism (pthread_rwlock_t), allowing multiple read threads to access the list simultaneously, but exclusive locks are used for write operations (such as adding a new script) to prevent data inconsistency caused by concurrent modifications.

[0068] The report upload unit 303 is used to upload diagnostic reports in segments to the cloud, and also supports resuming interrupted uploads. Diagnostic reports may contain fault codes from multiple ECUs and a large number of data stream records; segmented uploading avoids the need for re-uploading the entire report due to a single upload timeout or failure. After each segment is successfully uploaded, the cloud returns an ETag identifier, which the vehicle uses to record that the segment has been uploaded.

[0069] Furthermore, the report upload unit 303 divides the diagnostic report into 1MB segments. The segmentation operation is completed via the `split` system call, and the segment files are named in the format "report_xxx_part_serial number". Simultaneously, the unit generates a segment list file, which records the total number of segments, the serial number of each segment, the SHA256 hash value of each segment, and the segment size. During upload, the unit sends each segment using an HTTP PUT request, and the cloud returns the verification identifier of that segment via the ETag field. If the network is interrupted during the upload process, after reconnection, the unit first requests a list of successfully uploaded segments from the cloud, uploading only the missing segments. After all segments are uploaded, the cloud merges them and returns the final verification result. Upon receiving a successful response, the vehicle updates its local report status via a callback function and calls the `unlink` function to clean up temporary segment files.

[0070] The status reporting unit 304 is used to asynchronously report status through the Portable Operating System Interface (POSIX) message queue and uses Protocol Buffer (Protobuf) serialization compression.

[0071] The status reporting unit 304 places information such as the middleware's running status and task execution progress into a message queue, which is then sent by a separate background thread to avoid blocking the main diagnostic process. Protobuf is a high-efficiency binary serialization format that can compress structured data to less than 50% of its original size, saving network bandwidth.

[0072] Preferably, the POSIX message queue used by the status reporting unit 304 has a capacity of 100 messages, with each message having a maximum size of 4KB, ensuring no data loss during a large number of status changes in a short period. The reporting strategy is incremental: reporting is triggered only when the status value changes, such as when a task status changes from pending to executing, rather than periodically reporting the same status repeatedly. Protobuf serialization compression can compress the volume of structured data to less than 50% of its original size. The status reporting period can be set via parameters in the configuration file, with a default value of 10 seconds, meaning a heartbeat and cumulative status overview are reported every 10 seconds, ensuring that the cloud can monitor the operation of the vehicle-side middleware in real time.

[0073] This embodiment enhances the robustness and transmission efficiency of vehicle-to-cloud interaction through mechanisms such as incremental synchronization, multi-threaded breakpoint resume, fragmented uploading, and asynchronous compressed reporting. In particular, it can ensure the continuous execution of diagnostic tasks and reliable data transmission even in weak network environments.

[0074] In some embodiments of the present invention, the vehicle-side diagnostic middleware includes a diagnostic execution module, which is used to obtain the ECU status through a status subscription-push mechanism, compare the preset execution conditions before the diagnostic task is executed, and report the pause status to the cloud when the conditions are not met.

[0075] Specifically, the diagnostic execution module first subscribes to the status signals of key ECUs from the bus system, such as vehicle power mode, car mode, and engine speed. The subscription period is configurable, with a typical value of 1 second. When the ECU status changes, the bus system actively pushes the new status to the diagnostic execution module.

[0076] Upon receiving a diagnostic task from the cloud, the diagnostic execution module checks the task's preset execution conditions (such as "PowerMode must be ON"). If the current ECU status meets the conditions, the diagnostic task is allowed to continue; otherwise, a pause status is reported to the cloud, along with the current ECU status value.

[0077] For example, a diagnostic task may require the vehicle to be idling in order to read certain data. If the vehicle is currently in motion, the diagnostic execution module will prevent the issuance of diagnostic commands and simultaneously notify the cloud that "the vehicle status is inconsistent, and the task is suspended." Afterward, the diagnostic execution module will continue to poll the ECU status, and once the conditions are met, diagnostic execution will resume immediately.

[0078] Preferably, the diagnostic execution module further includes an instruction issuing unit and a data receiving unit. The instruction issuing unit implements communication between the CAN bus and the LIN bus based on the SocketCAN interface. Specifically, this unit adopts a multi-threaded scheduling mechanism: the main thread is responsible for issuing diagnostic instructions, and the sub-threads are dedicated to receiving the response data returned by the target ECU, with the sub-threads having the highest priority to ensure no data loss. The instruction issuing unit sets up a 1024-byte circular buffer for temporarily storing the received bus data and listens for bus data arrival events through the select system call. The timeout period can be dynamically adjusted through a configuration file, with a default value of 20 seconds and a minimum of 5 seconds to adapt to the response characteristics of different ECUs.

[0079] After receiving the ECU response, the data receiving unit uses a lookup table-based signal parsing algorithm to parse the raw bus data frame. This algorithm pre-defines signal parsing rules for different CAN identifiers, including data start bit, length, precision, and offset. It can convert raw data bytes (such as CAN ID, data length, and data field) into plaintext format within 10 milliseconds, for example, converting a sensor's hexadecimal value into an actual physical quantity (such as coolant temperature: 95℃). The parsed data is written to a local execution detail file in real time for easy traceability and fault analysis.

[0080] Specifically, when acquiring ECU status through the status subscription-push mechanism, the target statuses to be subscribed to include PowerMode and CarMode, with a fixed subscription period of 1 second. After an ECU status change, the bus system actively pushes the new status to the middleware's status buffer. When a cloud-based diagnostic task is issued, the unit invokes a status matching algorithm to accurately compare the task's preset execution conditions with the current ECU status.

[0081] For example, a diagnostic task requires "PowerMode = ON". If the current PowerMode is ACC (accessory power-on mode), the condition is not met. In this case, the unit initiates a status polling mechanism, re-querying the ECU status every second and simultaneously reporting the pause status to the cloud. The reported pause message carries the specific status value of the current ECU (e.g., "PowerMode = ACC"). Once the polling detects that PowerMode has become ON, the unit immediately triggers the diagnostic execution module to continue executing the task.

[0082] This embodiment combines status subscription-push with condition comparison to avoid performing diagnostic tasks under inapplicable vehicle conditions, improving the accuracy of diagnostic results while reducing interference from invalid commands to the ECU and the waste of network resources. Reporting the pause status to the cloud also allows the cloud to monitor task progress in real time, which is beneficial for remote scheduling and management.

[0083] In some embodiments of the present invention, the vehicle-side diagnostic middleware further includes a deployment initialization module. This deployment initialization module is used to automatically complete the installation, configuration, and local storage environment construction of the middleware after the vehicle is powered on, providing reliable basic support for subsequent diagnostic execution.

[0084] Specifically, the deployment initialization module first packages the middleware core program, dependent libraries, and configuration templates into a .tar.gz installation package and uploads it to the / opt / directory of the vehicle container. By executing the install.sh script, the underlying systemd application programming interface is called to configure the service unit. The Restart=always parameter is set to automatically restart the process in case of abnormality, and After=network.target is configured to ensure that the middleware service is started only after the network is ready. Simultaneously, the deployment initialization module integrates a process daemon script that checks the running status of the middleware process every 5 seconds. If an abnormal process exit is detected, it is immediately restarted to ensure the continuity of diagnostic tasks.

[0085] The deployment initialization module also performs local file system initialization via the `init.sh` script. This script recursively creates four hierarchical directories using the `mkdir -p` command: `script` (script storage directory), `task` (diagnostic task storage directory), `report` (diagnostic report storage directory), and `tmp` (temporary file transfer directory). After directory creation, it configures exclusive permissions for each directory using the `chmod 700` command, allowing only the file owner to read, write, and execute, and prohibiting access by unauthorized processes. Then, the script calls a C-language-based cJSON parsing library interface to generate a local manifest file. The manifest includes the manifest version number, generation timestamp, vehicle VIN code, middleware version number, absolute paths, purpose descriptions, and permission configuration information for the four directories, as well as the filename, size, SHA256 hash value, and generation time of each file in the `script` and `task` directories.

[0086] It should be noted that the generation of the local manifest file employs an atomic write mechanism. The specific process is as follows: First, the manifest content built using cJSON is written to a temporary file in the tmp temporary directory (named manifest_${timestamp}.tmp). After writing, the fsync command is called to force the data in memory to be flushed to disk. Then, the cJSON_Parse interface is used to verify the validity of the JSON format of the temporary file, and the SHA256 hash value of the file content is compared with the calculated value during generation. After successful double verification, the rename system call is called to perform an atomic renaming operation, officially renaming the temporary file to manifest.json and overwriting the old manifest file. If any step of writing, verification, or renaming fails, a rollback operation is immediately performed, deleting the invalid temporary file, retaining the previous valid manifest, outputting an error log to the system log partition, and terminating the initialization process.

[0087] Through the above deployment initialization module, this embodiment realizes the automated installation of middleware, process protection, and reliable initialization of the file system in the vehicle environment. The atomic write mechanism effectively prevents file corruption caused by power failure or abnormal exit, and improves the robustness of the system.

[0088] In some embodiments of the present invention, the vehicle-side diagnostic middleware further includes a report generation module. This report generation module employs template technology, pre-setting a JSON-formatted report template. The template defines a basic information module (such as diagnostic time, vehicle VIN code, and middleware version), an execution details module (sending time, response time, and execution result for each instruction), a diagnostic result module (fault code list, pass / fail status), and a log path module.

[0089] During the diagnostic task execution, the report generation module dynamically fills the corresponding positions in the template with real-time collected data through a data filling mechanism. For example, when an ECU returns fault code P0300 (multi-cylinder misfire), the module writes the fault code, its description, and the time of occurrence into the diagnostic results module. After the report is generated, the module calls the SHA256 algorithm to calculate the hash value of the entire report file. This hash value is uploaded to the cloud along with the report for the cloud to verify whether the report has been tampered with during transmission. In addition, when writing the report file, the module applies a file lock using the `flock` function to ensure that other processes cannot modify or delete the file during the writing process. Finally, the generated report file is stored in the report directory ` / mnt / diag / report / `, and the local report list is updated synchronously.

[0090] This embodiment ensures the uniformity of the output format by generating templated reports, while the SHA256 hash checksum and file locking mechanism enhance the security and integrity of the reports, which is beneficial for subsequent data analysis and cloud storage.

[0091] Figure 4 This is a schematic flowchart of an embodiment of the vehicle-cloud collaborative diagnostic method provided by the present invention, as shown below. Figure 4 As shown, the vehicle-cloud collaborative diagnostic method includes: Figure 4 This is a schematic flowchart of an embodiment of the vehicle-cloud collaborative diagnostic method provided by the present invention, as shown below. Figure 4 As shown, this vehicle-cloud collaborative diagnostic method is applied to vehicle-side diagnostic middleware, including: Retrieve diagnostic scripts in JSON format from the cloud; S402. Utilize a script parsing engine to parse the diagnostic script; the script parsing engine parsing process includes: S501: Uses a pre-allocated fixed-size memory pool to manage temporary objects during the parsing process; S502. Parse the diagnostic script into an abstract syntax tree and extract the diagnostic instruction fields; S503, if there are changes to the detection and diagnostic scripts or related configuration files, perform a parsing operation on the changed parts; S504. The diagnostic commands generated by the analysis are sent to the target ECU via the vehicle bus; S505 receives the response data returned by the target ECU, generates a diagnostic report, and uploads it to the cloud.

[0092] Specifically, in step S401, the vehicle-side diagnostic middleware initiates a synchronization request to the cloud-based diagnostic service through the vehicle-cloud interaction module. The cloud returns the diagnostic scripts that need to be added or updated based on the current script version list on the vehicle side. The diagnostic scripts are organized in JSON format for easy parsing and cross-platform transmission.

[0093] For example, a script is sent from the cloud to read engine control unit fault codes, which includes fields such as the target ECU address, service identifier 0x19, and the type of fault code to be read.

[0094] In step S402, the script parsing engine is the core execution unit of this embodiment, and its internal parsing process is further refined into steps S501 to S505.

[0095] In step S501, the memory pool requests a contiguous block of memory from the system, such as 10KB, during the initialization of the parsing engine. Temporary objects such as abstract syntax tree nodes and intermediate variables generated during subsequent parsing are allocated from this memory pool, avoiding frequent calls to the system's dynamic memory allocation function, thereby reducing memory fragmentation and improving allocation efficiency.

[0096] In step S502, the diagnostic script is parsed into an abstract syntax tree (AST) and diagnostic instruction fields are extracted. The parsing engine reads the JSON script character by character, constructing the AST through lexical and syntactic analysis. Each node in the tree corresponds to a key-value pair or array element in the script. Subsequently, the tree is traversed to extract the core fields required for the diagnostic instructions, including but not limited to the identifier of the target ECU, the diagnostic service identifier, the timeout parameter, and the execution order. For example, the script may extract the ECU address 0x7E0, the service identifier 0x22 (read data), and the data identifier 0x1101 to be read.

[0097] In step S503, changes to the diagnostic script or related configuration files are detected, and parsing operations are performed on the changed parts. The parsing engine monitors change events of script files and configuration files through the file system event listening mechanism provided by the operating system (such as inotify in Linux). When a change is detected in a certain paragraph, only that paragraph is re-parsed, while the rest reuses the previous parsing results. For example, if only the timeout in the script is changed from 20 seconds to 30 seconds, the parsing engine only updates the parsing result corresponding to the timeout, while other fields remain unchanged.

[0098] In step S504, the parsed diagnostic commands are sent to the target ECU via the vehicle bus. The command assembly module assembles the extracted diagnostic command fields into data frames according to the bus protocol (CAN, LIN, or DoIP) supported by the target ECU, and then sends them down through the corresponding bus interface.

[0099] For example, for a CAN bus, assemble a data frame containing an arbitration ID of 0x7E0 and a data length of 8 bytes, where the first byte of the data field is the service identifier 0x22, and the subsequent bytes are the data identifiers 0x11 and 0x01.

[0100] In step S505, the response data returned by the target ECU is received, a diagnostic report is generated, and uploaded to the cloud. The vehicle-side middleware receives the response frame from the target ECU via the bus, parses out the actual data (such as fault code values ​​or sensor readings), then fills in the data according to the preset report template to generate a JSON format diagnostic report, and finally uploads the report in segments to the cloud through the vehicle-cloud interaction module.

[0101] It should be noted that the abstract syntax tree in this embodiment is a data structure that represents the script syntax hierarchy in a tree-like structure. Each node contains a key name, value type, value data, and pointers to child and sibling nodes. This structure allows for efficient field lookup and traversal operations. Memory pooling technology refers to pre-allocating a fixed-size memory region at program startup. Subsequent object allocations are performed within this region, and during deallocation, only the pointer is moved without actually returning the memory to the operating system, thus avoiding heap memory fragmentation.

[0102] This embodiment significantly improves parsing efficiency and memory usage efficiency through steps such as pre-allocating a memory pool, parsing an abstract syntax tree, and incremental parsing. At the same time, it quickly sends diagnostic commands to the ECU and returns the results, realizing a closed-loop process for vehicle-cloud collaborative diagnosis.

[0103] In some embodiments of the present invention, such as Figure 6 As shown, the vehicle-cloud collaborative diagnostic method also includes: S601. Generate the contents of the local manifest file to obtain the manifest contents, which include directory structure information, file attribute information and verification information. S602. Use an atomic write mechanism to write the manifest content to the local manifest file; Furthermore, the atomic writing mechanism includes: Write the list contents to a temporary file first, and then force write the temporary file to disk; Perform format and hash checks on temporary files; After verification, the temporary file will be renamed to the official manifest file, overwriting the old manifest file. If the verification fails, delete the temporary file.

[0104] In this embodiment, the vehicle-cloud collaborative diagnostic method also includes an atomic writing process for the local manifest file. This process is typically executed when the middleware initializes or updates the local manifest file to ensure the integrity and reliability of the manifest file.

[0105] In step S601, the manifest content includes directory structure information, file attribute information, and verification information. Specifically, the vehicle-side middleware first creates four hierarchical directories: a script storage directory, a diagnostic task storage directory, a diagnostic report storage directory, and a temporary file transfer directory. These directories are then traversed, collecting the absolute path and permission settings of each subdirectory, as well as the filename, file size, and generation timestamp of each file. Simultaneously, a SHA256 hash value is calculated for each file as the basis for integrity verification. The metadata of the manifest content also includes the manifest version number, generation time, and vehicle VIN code.

[0106] In step S602, an atomic write mechanism is used to write the manifest content to the local manifest file. This mechanism ensures the atomicity of the file write through a series of operations, preventing file corruption due to power outages or process abnormalities.

[0107] The middleware first creates a temporary file in the temporary directory. The filename usually includes a timestamp or a random number to ensure uniqueness, such as "manifest_20260415120000.tmp". After writing the manifest content generated in step S601 to this temporary file, the fsync system call is invoked to force the data to be flushed from the page cache to the disk storage medium, ensuring that the data is actually written to disk and does not remain in the cache.

[0108] When performing format and hash verification on a temporary file, the middleware reads the file content, uses the cJSON parsing library to verify whether it conforms to the JSON format specification, and recalculates the SHA256 hash value of the file, comparing it with the hash value generated in step S601. The temporary file is considered valid only if both match.

[0109] After successful verification, the temporary file is atomically renamed to the official manifest file, overwriting the old manifest file. The middleware calls the `rename` system call to change the pathname of the temporary file to the pathname of the official manifest file (e.g., "manifest.json"). This operation is atomic on POSIX-compliant systems, meaning it either succeeds in renaming or remains unchanged, without any intermediate states.

[0110] If validation fails, delete the temporary file. If format validation or hash validation fails, the middleware immediately calls the unlink function to delete the temporary file and logs the error, while retaining the previous version's official manifest file unchanged, and the initialization process terminates.

[0111] As a preferred method, besides fsync, fdatasync can also be used for forced disk write operations. The latter only refreshes the file data without refreshing the metadata, offering slightly better performance but with slightly different applicable scenarios. This embodiment uses fsync to ensure that both data and metadata are completely written to disk.

[0112] This embodiment uses an atomic write mechanism to ensure that even if a power outage, disk error, or abnormal process exit occurs during the write process, a partially written corrupted manifest file will not be generated. The system will either obtain a complete new version of the manifest or retain the old version of the manifest, thereby ensuring the reliability of middleware initialization and subsequent operation and avoiding problems such as diagnostic tasks failing to execute or file corruption caused by manifest file corruption.

[0113] like Figure 7 As shown, the present invention also provides an electronic device 700. The electronic device 700 includes a processor 701, a memory 702, and a display 703. Figure 7 Only some components of the electronic device 700 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0114] In some embodiments, processor 701 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 702 or process data, such as the vehicle-cloud collaborative diagnostic method of the present invention.

[0115] In some embodiments, processor 701 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 701 may be local or remote. In some embodiments, processor 701 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, intranet, multi-cloud, etc., or any combination thereof.

[0116] In some embodiments, memory 702 may be an internal storage unit of electronic device 700, such as a hard disk or memory of electronic device 700. In other embodiments, memory 702 may also be an external storage device of electronic device 700, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 700.

[0117] Furthermore, the memory 702 may include both internal storage units of the electronic device 700 and external storage devices. The memory 702 is used to store application software and various types of data installed on the electronic device 700.

[0118] In some embodiments, display 703 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 703 is used to display information from electronic device 700 and to display a visual user interface. Components 701-703 of electronic device 700 communicate with each other via a system bus.

[0119] In one embodiment, when the processor 701 executes the vehicle-cloud collaborative diagnostic program in the memory 702, the following steps can be implemented: Retrieve diagnostic scripts in JSON format from the cloud; The diagnostic script is parsed using a script parsing engine; The script parsing engine's parsing process includes: Temporary objects during the parsing process are managed using a pre-allocated, fixed-size memory pool. The diagnostic script is parsed into an abstract syntax tree and the diagnostic instruction fields are extracted. Detect changes to the diagnostic script or related configuration files, and perform parsing operations on the changed parts; The diagnostic commands generated by the analysis are sent to the target ECU via the vehicle bus; Receive response data returned by the target ECU, generate a diagnostic report, and upload it to the cloud.

[0120] It should be understood that when the processor 701 executes the mangrove ecological degradation assessment program in the memory 702, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0121] Furthermore, the embodiments of the present invention do not specifically limit the type of electronic device 700 mentioned. Electronic device 700 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, electronic device 700 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0122] Accordingly, this application also provides a computer-readable storage medium for storing a computer-readable program or instruction. When the program or instruction is executed by a processor, it can implement the steps or functions of the vehicle-cloud collaborative diagnostic method provided in the above-described method embodiments.

[0123] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0124] The vehicle-side diagnostic middleware, diagnostic method, electronic device, and storage medium provided by this invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A vehicle-side diagnostic middleware, characterized in that, include: The script parsing engine is used to parse diagnostic scripts in JSON format obtained from the cloud and generate diagnostic instructions suitable for the vehicle bus. The script parsing engine includes: A memory pool, with a pre-allocated fixed size, is used to store temporary objects generated during the parsing process; The syntax tree parsing module is used to parse the diagnostic script into an abstract syntax tree and traverse the abstract syntax tree to extract diagnostic instruction fields; The instruction assembly module is used to assemble the diagnostic instruction field into a data frame conforming to the vehicle bus protocol, which serves as the diagnostic instruction. The incremental parsing module is used to detect changes to the diagnostic script or related configuration files and perform parsing operations on the changed parts.

2. The vehicle-side diagnostic middleware according to claim 1, characterized in that, The incremental parsing module includes: The change monitoring unit is used to monitor change events of the diagnostic script or related configuration files through the file system event monitoring mechanism provided by the operating system. The cache management unit is used to cache key-value pairs that have been parsed and have not been changed.

3. The vehicle-side diagnostic middleware according to claim 1, characterized in that, Includes a configuration management module; The configuration management module includes an improved INI file parser, which adopts a four-layer modular architecture, including a bottom dependency layer, a core parsing layer, a business adaptation layer, and a configuration application layer. The core parsing layer has a built-in incremental parsing module, which is used to monitor configuration file change events in real time and parse the changed paragraphs so that the service does not need to be restarted when loading parameters in real time.

4. The vehicle-side diagnostic middleware according to claim 3, characterized in that, The business adaptation layer includes a VIN code automatic reading module, which is used to read the vehicle VIN code through the vehicle information reading interface provided by the operating system and perform regular expression verification to obtain the matching result of the vehicle model parameters.

5. The vehicle-side diagnostic middleware according to any one of claims 1 to 4, characterized in that, The vehicle-side diagnostic middleware includes a vehicle-cloud interaction module; The vehicle-cloud interaction module includes: The task synchronization unit is used for incremental synchronization with the cloud based on the RESTful API, and uses the MurMurHash3 hash table to store the local script version list. The script download unit is used to download diagnostic scripts in segments via multi-threading and / or to resume interrupted downloads, and to verify the integrity of the scripts using the SHA256 hash algorithm. The report upload unit is used to upload diagnostic reports in segments to the cloud and / or resume interrupted uploads. The status reporting unit is used to asynchronously report status through a portable operating system interface message queue, using protocol buffer serialization compression.

6. The vehicle-side diagnostic middleware according to any one of claims 1 to 4, characterized in that, The diagnostic execution module includes an execution condition verification unit, which is used to obtain the ECU status through a status subscription-push mechanism, compare the preset execution conditions before the diagnostic task is executed, and report the pause status to the cloud when the conditions are not met.

7. A vehicle-cloud collaborative diagnostic method, applied to vehicle-side diagnostic middleware, characterized in that, include: Retrieve diagnostic scripts in JSON format from the cloud; The diagnostic script is parsed using a script parsing engine; The script parsing engine's parsing process includes: Temporary objects during the parsing process are managed using a pre-allocated, fixed-size memory pool. The diagnostic script is parsed into an abstract syntax tree and the diagnostic instruction fields are extracted. Detect changes to the diagnostic script or related configuration files, and perform parsing operations on the changed parts; The diagnostic commands generated by the analysis are sent to the target ECU via the vehicle bus; Receive response data returned by the target ECU, generate a diagnostic report, and upload it to the cloud.

8. The vehicle-cloud collaborative diagnostic method according to claim 7, characterized in that, include: Generate the contents of a local manifest file to obtain the manifest content, which includes directory structure information, file attribute information, and verification information; The contents of the manifest are written to the local manifest file using an atomic write mechanism; The atomic writing mechanism includes: The contents of the list are first written to a temporary file, and then the temporary file is forcibly written to disk. Perform format verification and hash verification on the temporary file; After verification, the temporary file is renamed to the official manifest file, overwriting the old manifest file; If the verification fails, delete the temporary file.

9. An electronic device, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the vehicle-cloud collaborative diagnostic method of claim 7 or 8.

10. A computer-readable storage medium, characterized in that, Used to store computer-readable programs or instructions, which, when executed by a processor, can implement the steps in the vehicle-cloud collaborative diagnostic method described in claim 7 or 8.

Images