Data storage and remote monitoring system and method based on UDS

Abstract

The invention provides a UDS-based data storage and remote monitoring system and a UDS-based data storage and remote monitoring method. The method comprises the steps of collecting fault data within a period of time before and after a fault occurs when the fault occurs; preprocessing the fault data and writing the fault data into an NVM (Non-Volatile Memory) in an array form; calling a first service of the UDS to process the preprocessed fault data in the NVM according to a set format and store the processed fault data to a specified address area in the RAM; and calling a second service of the UDS to remotely access the fault data of the specified address area in the RAM to obtain the preprocessed fault data. By improving the acquisition mode, constructing a remote access mechanism and introducing a basic data analysis function, complete recording, remote diagnosis and preliminary intelligent analysis of fault data are realized, the informatization and intelligence level of the whole vehicle diagnosis system is improved, and the fault diagnosis efficiency is improved. The problems that an existing diagnosis system is insufficient in data integrity, weak in remote access capacity and limited in data analysis capacity are solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of automobile fault remote diagnosis, and in particular relates to a data storage and remote monitoring system and method based on UDS. Background Art

[0002] With the continuous development of automotive electronic systems, the UDS (Unified Diagnostic Services) protocol, as a unified diagnostic service protocol based on the ISO 14229 standard, has been widely used in vehicle ECU fault diagnosis. This protocol supports the reading and management of diagnostic trouble codes (DTCs), freeze frame data, status information, etc., and provides a standardized interface for vehicle maintenance and troubleshooting. Traditional fault diagnosis mainly relies on the OBD-II interface and localized operations are achieved through dedicated diagnostic tools. In recent years, with the development of Internet of Vehicles technology, remote communication modules such as T-Box have been introduced, allowing vehicle diagnostic information to be obtained through the CAN bus and uploaded to the cloud via the mobile network, initially realizing remote monitoring functions. The existing unified vehicle diagnostic method has many shortcomings, especially in the recording and analysis of fault data. First, the freeze frame data in the current system can only record a set of static information at the time of the fault, and lacks continuous recording of the vehicle's operating conditions before and after the fault. It is difficult to fully reflect the actual environment and conditions where the fault occurred, which limits the in-depth analysis of the cause of the fault. Secondly, the existing diagnostic process still relies on manual local operation through diagnostic instruments and lacks remote access and diagnostic mechanisms, resulting in the inability to upload and process fault data in a timely manner, affecting the efficiency of fault response. In addition, at the data analysis level, the existing system mostly stays at the storage and reading of raw data, lacks structured conversion, visual display and basic analysis functions of diagnostic data, and is difficult to provide intuitive and effective decision support for maintenance personnel or back-end platforms, which restricts the informatization and intelligence level of the vehicle diagnostic system. Summary of the Invention

[0003] In order to solve the problems raised by the background technology, the present invention proposes a data storage and remote monitoring system and method based on UDS.

[0004] A data storage and remote monitoring system based on UDS to achieve one of the purposes of the present invention includes: Data acquisition module: used to collect fault data within a period of time before and after the fault occurs; data preprocessing module: used to preprocess the fault data; and write the fault data into NVM in the form of an array; Data processing module: used to call the first service of UDS to process the pre-processed fault data in NVM according to the set format and store it in the specified address area in RAM; Remote access module: used for calling the second service of UDS to remotely access the fault data in the designated address area in the RAM to obtain the pre-processed fault data.

[0005] Furthermore, the first service is a 31 service of the UDS protocol; and the second service is a 22 service of the UDS protocol.

[0006] Furthermore, it also includes an abnormality judgment module, which is used to judge the data abnormality of the pre-processed data according to a preset threshold value and identify faulty data with data abnormality.

[0007] Furthermore, it also includes a visualization display module for displaying the pre-processed fault data and fault data with data abnormalities in a visualization form.

[0008] Furthermore, in the data processing module, the remote diagnosis platform sends a UDS 31 service request to write data into a designated address area in the RAM.

[0009] Furthermore, the data access process of the remote access module includes: The remote diagnosis platform sends a UDS 22 service request to the ECU; The ECU locates the data address in the RAM according to the DID in the UDS 22 service request; The ECU reads the data in the data address in the RAM; The data is uploaded to the remote diagnosis platform via the CAN bus and T-Box.

[0010] Furthermore, the remote access module further includes data cleaning of the pre-processed fault data; the cleaning includes: removing the request / reply service field, the frame continuity flag, and the data byte segment contained in the second service of the UDS.

[0011] Furthermore, the remote access module further includes performing base-based conversion on the pre-processed fault data, converting the hexadecimal fault data into decimal fault data.

[0012] Furthermore, in the data preprocessing module, the preprocessing includes: processing the fault data stored in the array form according to the format of each type of fault data itself, obtaining the data size, arrangement order and fault type of each fault data in the array, and adding the data size, arrangement order and fault type as a data frame header to the header of each fault data.

[0013] Furthermore, before writing the data in the NVM in array form, the method further includes: writing the collected data into a preset buffer in the RAM; when the collection cycle reaches the set cycle, transferring the data in the preset buffer in the RAM to the NVM; retiming the collection cycle; and cyclically transferring the data in the preset buffer in the RAM after reaching the set cycle to the NVM; the storage address of the preset buffer is adjacent to the storage address of the collection module; and the collection module includes a sensor and / or an ECU control unit. After transferring the data in the preset buffer in the RAM to the NVM, the method further includes: initializing the data in the preset buffer in the RAM, such as initializing it to all Fs, i.e., all bit positions in all RAMs are 1. At the beginning of each cycle, i.e., after a new collection cycle is restarted, data is written starting from the initial address of the preset buffer in the RAM; after the collection cycle is reached, the data stored in the preset buffer in the RAM is read out according to the current write address of the preset buffer in the RAM.

[0014] A data storage and remote monitoring method based on UDS to achieve the second purpose of the present invention includes: When a fault occurs, collect fault data for a period of time before and after the fault occurs; Preprocessing the fault data; and writing the fault data into NVM in the form of an array; The first service of the UDS is called to process the pre-processed fault data in the NVM according to the set format and store it in the specified address area in the RAM; The second service of the UDS is called to remotely access the fault data in the designated address area in the RAM to obtain the pre-processed fault data.

[0015] Furthermore, it also includes: performing data anomaly judgment on the pre-processed data according to a preset threshold value, and identifying fault data with data anomaly.

[0016] A non-transitory computer-readable storage medium is provided to achieve the third objective of the present invention, on which a computer program is stored. When the computer program is executed by a processor, the steps of the UDS-based data storage and remote monitoring method are implemented.

[0017] A computer program product for achieving the fourth objective of the present invention includes a computer program / instruction, which, when executed by a processor, implements the steps of the UDS-based data storage and remote monitoring method.

[0018] The beneficial effects of the present invention include: 1) By collecting dynamic operating parameters for a period of time before and after the fault occurs, the actual operating conditions of the fault can be more comprehensively restored; 2) Utilizing UDS's 22 services in conjunction with the DID address mapping mechanism and working with remote communication modules such as the T-Box, remote access and downloading of vehicle fault data is achieved. This eliminates the limitations of traditional OBD interfaces that rely on manual operation, improves diagnostic efficiency and response speed, and is suitable for remote monitoring needs of intelligent connected vehicles. 3) Lightweight scripts are used to trim, structure, and visualize fault data returned by diagnostic services, improving data readability and usability. Furthermore, the scripts automatically identify typical fault types such as undervoltage, overcurrent, undercurrent, temperature anomalies, and torque anomalies based on preset threshold conditions, assisting maintenance personnel in quickly locating problems and improving troubleshooting efficiency. 4) Storing critical fault data in both RAM and NVM ensures data is not lost after a power outage, facilitating subsequent retrospective analysis and quality tracking, and enhancing the stability and reliability of the vehicle diagnostic system. 5) It adopts standardized UDS protocols and service interfaces with strong compatibility. It can be integrated and deployed without large-scale transformation of the existing diagnostic architecture, which helps shorten the development cycle and reduce the difficulty of system integration and subsequent maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a schematic diagram of the structure of the fault storage and remote diagnosis system based on UDS; Figure 2 It is a flow chart of the fault data collection and storage process; Figure 3 It is a communication flow diagram of the remote access and data transmission process; Figure 4 It is a functional module block diagram of data analysis and visualization processing. DETAILED DESCRIPTION

[0020] The following specific embodiments are provided to explain the technical solutions of the present invention so that those skilled in the art can understand the present invention. The scope of protection of the present invention is not limited to the specific implementation structures described below. Any implementation schemes created by those skilled in the art that include the technical solutions of the present invention but differ from the following specific implementation schemes are also within the scope of protection of the present invention.

[0021] A data storage and remote monitoring method based on UDS (1) Fault triggering and data collection When a fault occurs, the system first collects key operating parameters over a period of time through sensors and the ECU control unit, including but not limited to vehicle speed, motor speed, voltage, current, temperature, and torque. Some of the data that is helpful for fault analysis (such as voltage, current, temperature, and torque) is then latched in the form of an array after the fault occurs. The array contains fault data for 200 cycles before the fault and 100 cycles after the fault, and is written to a preset buffer in RAM. The capacity of this preset buffer is 300 groups × the number of sensor parameter bytes. It is only used to quickly cache the raw cycle data collected when the fault occurs. Once written, it immediately triggers the "RAM→NVM" persistence process. This buffer belongs to the ECU real-time data cache area, is close to the sensor / ECU acquisition module, and has a pre-fixed address. It is a temporary cache area that is only responsible for temporarily and quickly storing the 300 groups of raw fault data when the fault occurs. Figure 2 The complete process from when a fault occurs to when data is written to RAM is shown, including the following steps: Fault event triggering; The key operating parameters of 300 cycles before and after the fault are collected through the array; Write some data that is helpful for fault analysis into NVM for persistent storage; Call the RID trigger routine to select 300 cycles of data of different faults in NVM and write them to the specified address in RAM.

[0022] The technical benefits of this step include: ensuring that all important data from the period before and after the failure is accurately captured, enabling real-time monitoring and rapid response to the failure; and providing a complete failure context environment, which facilitates in-depth analysis of the root cause of the problem.

[0023] The method for collecting key operating parameters involves using a screening algorithm based on a fault tree model. This algorithm first constructs a fault tree based on common fault types, mapping the underlying leaf nodes to specific sensor data. During the data collection phase, each sensor data point is assigned a weight based on the logical relationships within the fault tree. When a potential fault signal is detected, a specific number (e.g., the first 50) of sensor data points with strong correlation to the fault are selected for collection, sorted by weight from highest to lowest.

[0024] The technical effects of using an array to store fault data include: 1. The core feature of an array is that it continuously stores data of the same type in chronological order. The ordered index of the array subscript can directly correspond to the time series before and after the fault. This continuous recording method can completely restore the context of the fault, provide dynamic data support for analyzing the cause of the fault, and solve the problem of insufficient integrity of traditional static data. 2. The array supports batch reading, writing, conversion, and transmission, and is adapted to the technical process of batch storage and calling in the UDS protocol and remote monitoring. The 300 groups of data in the array can be written as a whole to the RAM buffer or NVM, and the UDS 31 service (RID) can trigger a routine to quickly call the entire group of data in the array without having to process individual records one by one; 3. The processing power of hardware such as vehicle ECUs and T-Boxes is limited. The simple data structure of the array can reduce the computing load of embedded scripts, ensuring efficient data cropping, conversion, and visualization under the limited computing power of the vehicle.

[0025] (2) Writing key data to NVM for persistent storage To prevent data loss due to power outages and ensure persistent storage of fault data, the system further writes the fault data, stored in array form, to NVM (Non-Volatile Memory). This ensures that historical fault information is retained even in power outages, facilitating subsequent tracing and analysis. This step ensures that historical fault information is preserved even when the vehicle's power is turned off, enhancing data security and reliability and facilitating subsequent maintenance.

[0026] (3) Call UDS 31 service to package the freeze frame The system then calls the UDS 31 service (Routine ID, RID), triggering a specific routine that pre-processes the fault data in the NVM according to a set format and temporarily stores it in a designated address area in RAM for subsequent access. This designated address area, with a capacity adapted to the UDS service data packet size, is used to temporarily store data read from the NVM and processed according to the UDS 31 service format for remote access by the UDS 22 service. It is automatically cleared after data transfer is complete. This area is a dedicated cache for the UDS diagnostic service, located near the diagnostic protocol processing module, such as the UDS service layer and the DID mapping table in memory. It stores standardized diagnostic data that has been cropped and formatted, specifically for remote reading by the UDS 22 service or invocation by local diagnostic tools. It is read by the UDS service and may be cleared after the transfer is complete. The technical effects of this step include: Fault data can be transferred from the NVM to the RAM. Since the NVM can store faults caused by different faults, multiple sets of data can be stored in the same RAM through different routine instructions, enabling conversion between fault data for different faults and facilitating subsequent reading and transmission. Its features include the standardized UDS protocol to ensure compatibility and support for flexible data encapsulation formats. Its advantages include simplifying the interaction process between different systems and improving data exchange efficiency.

[0027] The method for processing according to the set format includes: processing the fault data stored in the array form according to the format of each type of fault data itself, obtaining the data size, arrangement order and fault type of each fault data in the array, and adding it as a data frame header to the header of each fault data.

[0028] (4) Remote access through UDS 22 service To meet remote diagnostic requirements, the system uses UDS's 22 (Read Data By Identifier) ​​service in conjunction with the DID (Data Identifier) ​​to access data in the designated address area in RAM. An external host computer or cloud platform can initiate diagnostic requests via the vehicle network through a remote communication module such as the T-Box to obtain a complete fault data set, enabling remote monitoring of the vehicle's status and fault diagnosis. This step allows maintenance personnel to complete preliminary remote diagnostics without direct contact with the vehicle, improving diagnostic flexibility and efficiency while reducing maintenance costs.

[0029] Figure 3 The data access process for remote diagnosis is demonstrated, including: The remote diagnosis platform sends a 31 service request to write data to the specified address in RAM; The remote diagnosis platform sends 22 a service request; ECU locates the data address in RAM according to DID; Returns the specified diagnostic data; Data is uploaded to the remote platform via the CAN bus and T-Box, enabling remote diagnosis and data download.

[0030] (5) Fault data analysis and structured conversion After receiving raw fault data from an external host computer or cloud platform, it undergoes further processing. This includes removing redundant information, extracting useful fields, and converting it into an easily understandable structured format (such as JSON or CSV). Additionally, metadata tags can be added as needed to facilitate better organization and retrieval of the information. This step improves data processing speed and accuracy and facilitates cross-platform sharing.

[0031] In terms of data post-processing, embodiments of the present invention also provide a lightweight intelligent analysis solution: This solution uses scripts to crop and structure the raw data downloaded from the 22 service, extract valid fields, and visualize them in charts. Furthermore, the scripts incorporate judgment logic that automatically identifies undervoltage, overcurrent, undercurrent, abnormal temperature, or abnormal torque based on preset threshold conditions (such as voltage below a lower limit, current out of range, temperature anomalies, and excessive torque fluctuations). This helps maintenance personnel quickly locate the root cause of the problem and improves troubleshooting efficiency.

[0032] (6) Visual display and abnormal judgment By visualizing the converted data and applying the logic rules in the embedded script based on the fault trigger logic, potential problems (such as undervoltage and overcurrent) can be identified. This not only allows intuitive visualization of the changing trends of various indicators, but also enables quick location of anomalies. The user-friendly graphical interface is easy to understand and communicate, accelerating the troubleshooting process and improving overall work efficiency.

[0033] Figure 4 The composition of the data analysis module and visualization module is shown, including: Raw data input module: used to receive fault data obtained by UDS 22 service; Data trimming and cleaning module: used to remove redundant fields. Because diagnostic services contain a large number of request / reply service fields, frame continuity flags, and data byte segments, these data are irrelevant to fault diagnosis and need to be removed to save storage space and improve data read and write efficiency. Data conversion module: This module is used to convert data bases. Because each set of fault data contains 300 data points in hexadecimal floating-point format, the hexadecimal data must be converted to decimal data, each containing 300 data points, based on the data type. Its technical benefits include: The raw hexadecimal floating-point data output by vehicle sensors is not intuitive and cannot be directly correlated with vehicle operating conditions (for example, it is impossible to determine the actual vehicle speed). After conversion to decimal, it can be directly mapped to vehicle operating parameters, allowing engineers to quickly understand the data through visualization platforms or diagnostic tools, lowering the technical threshold for fault analysis. Automatic vehicle fault diagnosis relies on decimal thresholds for physical quantities. Hexadecimal data must first be converted to decimal before comparison with preset thresholds is required to identify fault types such as undervoltage, overcurrent, and temperature anomalies. Decimal data can be directly used to draw trend curves for visualization and analysis of parameter evolution prior to a fault. However, hexadecimal data cannot directly participate in such mathematical operations and visualization analysis. This module bridges the application barriers between raw collected data and fault diagnosis and remote analysis, serving as a necessary step in transitioning fault data storage and practical application.

[0034] Visual display module: used to display the changing trends of voltage, current, temperature and torque in fault data in the form of charts; Abnormal judgment module: used to automatically identify undervoltage, overcurrent, undercurrent, temperature abnormality, torque abnormality according to the threshold set by the fault trigger logic, and output the diagnosis results.

[0035] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0036] The software and hardware system used to implement the above-mentioned UDS-based data storage and remote monitoring method is as follows: Figure 1 Shown, including: ECU (Electronic Control Unit): Vehicle control unit, used for fault detection and data collection; RAM storage area: used to temporarily store operating parameters for a period of time before and after a fault occurs; NVM storage area: non-volatile memory, used to persist critical fault data; Routine Handler: This handles the triggering and execution of specific routines, such as writing fault data to a specific RAM address. DID Handler: Used to process the 22 Read Data By Identifier request in the UDS protocol, find the corresponding data according to the DID and read the information in RAM / NVM; DCM (Diagnostic Communication Manager): Diagnostic Communication Manager, used to receive and parse UDS requests (such as 22 and 31), and distribute requests to corresponding processing modules (such as DID Handler or RoutineHandler); T-Box (Telematics Box): Vehicle-mounted communication terminal, used to establish remote connection and upload diagnostic data; Remote Diagnostics Platform / Host Computer: Background system or diagnostic device, used to receive and analyze diagnostic data; CAN bus: used for internal communication between ECU and T-Box; Remote Diagnostics Platform: background diagnostic server or cloud system, used to initiate diagnostic requests, receive diagnostic responses, analyze fault data, and support remote monitoring and OTA upgrade; Mobile network (such as 4G / 5G): used for remote communication between T-Box and cloud platform.

[0037] The embodiment of the application also provides a UDS-based data storage and remote monitoring system, comprising: Data acquisition module: used to acquire fault data within a period of time before and after the occurrence of a fault when the fault occurs; Data preprocessing module: used to preprocess fault data; and write the fault data in an array form into NVM; Data processing module: used to call the first service of UDS to process and store the preprocessed fault data in NVM into a specified address area in RAM according to a set format; Remote access module: used to call the second service of UDS to remotely access the fault data in the specified address area in RAM to obtain the preprocessed fault data.

[0038] In some embodiments, an anomaly judgment module is further included, which is used to perform data anomaly judgment on the preprocessed data according to a preset threshold, and identify fault data with data anomaly.

[0039] In some embodiments, a visual display module is further included, which is used to display the preprocessed fault data and fault data with data anomaly in a visual form.

[0040] The embodiment of the application also provides a non-transitory computer readable storage medium, which stores a computer program, the computer program comprising program instructions, the program instructions being executed by a processor to implement various steps of the method of the application, which will not be described here.

[0041] The computer-readable storage medium may be the data transmission device provided in any of the aforementioned embodiments or an internal storage unit of a computer device, such as a hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc., provided on the computer device.

[0042] Furthermore, the computer-readable storage medium may include both an internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data to be output or that has been output.

[0043] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0044] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0045] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0046] These computer program instructions can also be loaded into a computer or other programmable data processing devices, so that a series of operational steps are generated to realize the computer-implemented processes, and the instructions executed on the computer or other programmable devices provide a process for implementing the functions specified in the flowchart Figure 1 one flow or multiple flows and / or the functions specified in the block Figure 1 one flow or multiple flows and / or the functions specified in the block

[0047] The embodiments of the present application also provide a computer program product, comprising computer programs / instructions, which, when executed by a processor, realize the steps of the method for storing and remotely monitoring data based on UDS.

[0048] The contents not described in detail in the specification belong to the prior art known to those skilled in the art.

Claims

1. A data storage and remote monitoring system based on UDS, characterized in that: include: Data acquisition module: used to collect fault data within a period of time before and after the fault occurs; Data preprocessing module: used to preprocess fault data; and writing the fault data into NVM in the form of an array; Data processing module: used to call the first service of UDS to process the pre-processed fault data in NVM according to the set format and store it in the specified address area in RAM; Remote access module: used for calling the second service of UDS to remotely access the fault data in the designated address area in the RAM to obtain the pre-processed fault data.

2. The data storage and remote monitoring system based on UDS according to claim 1, characterized in that: It also includes an abnormality judgment module for performing data abnormality judgment on the pre-processed data based on a preset threshold value and identifying abnormal fault data.

3. The data storage and remote monitoring system based on UDS according to claim 1, characterized in that: The data access process of the remote access module includes: The remote diagnosis platform sends a UDS 22 service request to the ECU; The ECU locates the data address in the RAM according to the DID in the UDS 22 service request; The ECU reads the data in the data address in the RAM; The data is uploaded to the remote diagnosis platform via the CAN bus and T-Box.

4. The UDS-based data storage and remote monitoring system according to claim 1, characterized in that: The remote access module also includes data cleaning for the pre-processed fault data; the cleaning includes: removing the request / reply service field, the frame continuity flag, and the data byte segment contained in the second service of the UDS.

5. The UDS-based data storage and remote monitoring system according to claim 1, characterized in that: The remote access module also includes performing base conversion on the pre-processed fault data, converting the hexadecimal fault data into decimal fault data.

6. The UDS-based data storage and remote monitoring system according to claim 1, characterized in that: In the data preprocessing module, the preprocessing includes: processing the fault data stored in the array form according to the format of each type of fault data itself, obtaining the data size, arrangement order and fault type of each fault data in the array, and adding the data size, arrangement order and fault type as a data frame header to the header of each fault data.

7. The UDS-based data storage and remote monitoring system according to claim 1, characterized in that: Before writing the data in the NVM in array form, the method further includes: writing the collected data into a preset buffer in the RAM; when the collection period reaches a set period, transferring the data in the preset buffer in the RAM to the NVM; retiming the collection period; and cyclically transferring the data in the preset buffer in the RAM after reaching the set period to the NVM; the storage address of the preset buffer is adjacent to the storage address of the collection module; and the collection module includes a sensor and / or an ECU control unit.

8. A data storage and remote monitoring method based on UDS of the system according to claim 1, characterized in that: include: When a fault occurs, collect fault data for a period of time before and after the fault occurs; and preprocessing the fault data; and writing the fault data into NVM in the form of an array; The first service of the UDS is called to process the pre-processed fault data in the NVM according to the set format and store it in the specified address area in the RAM; The second service of the UDS is called to remotely access the fault data in the designated address area in the RAM to obtain the pre-processed fault data.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the UDS-based data storage and remote monitoring method according to claim 8 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the UDS-based data storage and remote monitoring method according to claim 8 are implemented.

Images