Data processing method, data writing method and device, diagnostic equipment and medium
By expanding the data sources and storage methods in the power chassis domain control system, and using diagnostic questionnaires and serial peripheral interfaces to write operating data into flash memory, the problem of inaccurate fault location caused by insufficient microcontroller storage is solved, and efficient and accurate fault diagnosis is achieved.
Patent Information
- Application Number
- CN202511753082.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-26
- Publication Date
- 2026-03-03
AI Technical Summary
In the power chassis domain control system, the existing technology relies on the limited non-volatile memory of the microcontroller, which leads to insufficient accuracy in fault location and makes it difficult to accurately locate the cause of the fault in a complex software environment.
By acquiring the operating data of the power chassis domain control system from the microcontroller and flash memory, matching data identifiers and routine identifiers using a diagnostic questionnaire, and writing the data into the flash memory using a serial peripheral interface, a dynamic rolling and fault event-triggered storage method is achieved to ensure the integrity and reliability of critical data.
It improves the accuracy and efficiency of fault location, reduces misdiagnosis, lowers maintenance costs, and provides a rich data foundation to support accurate diagnosis.
Smart Images

Figure CN121597465A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle technology, specifically to data processing methods, data writing methods and devices, diagnostic equipment, and media. Background Technology
[0002] As automotive electronic architecture evolves towards domain centralization, the increasing complexity and integration of each domain's functions make troubleshooting software-related issues a critical challenge.
[0003] Currently, power chassis domain control is mainly based on microcontroller units (MCUs). However, the storage space of the non-volatile memory built into the MCU is relatively limited. The troubleshooting method is still mainly based on the diagnostic fault code freeze frame data preset by Unified Diagnostic Services (UDS) to achieve basic diagnosis and problem troubleshooting.
[0004] However, given the exponential increase in the complexity of current functional software, it is no longer sufficient to accurately pinpoint the cause of a fault by relying solely on the limited data stored in the diagnostic fault code freeze frame.
[0005] Therefore, improving the accuracy of fault location in the power chassis domain control system has become a technical problem that needs to be solved. Summary of the Invention
[0006] In view of this, embodiments of this application provide a data processing method, a data writing method and apparatus, a diagnostic device, and a medium.
[0007] In a first aspect, embodiments of this application provide a data processing method applied to a diagnostic device in a vehicle, the diagnostic device being connected to the vehicle's on-board system, the method comprising: When a fault event occurs in the power chassis domain control system of the vehicle, the current operating data of the power chassis domain control system is obtained from the microcontroller of the vehicle system, and / or relevant operating data is obtained from the flash memory of the vehicle system; wherein, the relevant operating data includes operating data within a preset time period before and after the fault event occurs; the microcontroller is used to collect the operating data of the power chassis domain control system and store the operating data in the flash memory; The fault diagnosis result is determined based on the current operating data and / or the relevant operating data.
[0008] The method provided in this application is applied to a diagnostic device connected to the vehicle's onboard system, which includes a microcontroller and a flash memory. When a fault event occurs in the vehicle's powertrain chassis domain control system, the current operating data of the powertrain chassis domain control system collected by the microcontroller can be obtained from the onboard system's microcontroller, and the operating data stored in the flash memory within a preset time period before and after the fault event can be obtained from the flash memory. This expands the data source and scope. Because the microcontroller is responsible for continuously collecting operating data and storing it in the flash memory, the flash memory can store a larger amount of continuous operating data, compensating for the storage limitations of the microcontroller and providing complete operating data for the moment of the fault or the trend of the process. Based on this, the diagnosis no longer relies solely on matching a single fault code, but rather on a comprehensive judgment based on the current operating data or the operating data within a preset time period before and after the fault event to determine the fault diagnosis result, accurately locating the fault location. At the same time, because the data is more comprehensive, it can also reduce misjudgments, enabling rapid subsequent fault diagnosis and reducing maintenance costs.
[0009] In conjunction with the first aspect, in one possible implementation, obtaining current operating data from the microcontroller of the vehicle system and / or obtaining relevant operating data from the flash memory of the vehicle system includes: Obtain the data identifier associated with the fault event; The current operating data is obtained from the microcontroller based on the data identifier; Obtain the storage address corresponding to the routine identifier associated with the fault event; Relevant operational data is obtained from the flash memory based on the storage address.
[0010] The method provided in this application can obtain data identifiers related to fault events, and then retrieve current operating data from the microcontroller based on these data identifiers. It can also obtain routine identifiers related to fault events and their corresponding storage addresses, and then retrieve relevant operating data from the flash memory based on the storage addresses corresponding to the routine identifiers. The data identifiers can be used to lock the current operating data related to the fault event in the microcontroller, avoiding interference from irrelevant data. The storage addresses of relevant operating data in the flash memory can be located based on the routine identifiers, enabling targeted retrieval. This precise identifier-based acquisition mechanism reduces data transmission volume and filtering costs, improving data acquisition efficiency and ensuring the specificity of diagnostic criteria, further enhancing the accuracy and timeliness of fault location.
[0011] In conjunction with the first aspect or its corresponding implementation, in one possible implementation, before acquiring current operating data from the microcontroller of the vehicle system and / or acquiring relevant operating data from the flash memory of the vehicle system, the method further includes: The diagnostic questionnaire determines the storage addresses corresponding to the data identifiers and / or routine identifiers related to the fault events; the diagnostic questionnaire includes data identifiers, routine identifiers, and storage addresses corresponding to the routine identifiers for different fault events.
[0012] The method provided in this application solves the problem of time-consuming data identifier and address matching when a fault occurs by pre-constructing a diagnostic survey form and establishing a correspondence between fault events and data identifiers, routine identifiers, and the corresponding storage addresses of the routine identifiers. After a fault occurs, there is no need for temporary retrieval; the required data identifier and storage address can be quickly determined directly through the diagnostic survey form, significantly shortening the lead time for data acquisition. At the same time, the standardized correspondence avoids errors from manual matching, ensuring the accuracy of data retrieval. Pre-constructing the diagnostic survey form makes the data acquisition process more efficient and reliable, providing a guarantee for subsequent rapid fault diagnosis and improved location accuracy, and is particularly suitable for rapid response scenarios with multiple fault types in complex domain control systems.
[0013] Secondly, embodiments of this application provide a data writing method, the method being applied to a vehicle's in-vehicle system, the in-vehicle system being connected to a diagnostic device as described in the first aspect or any corresponding embodiment, the method comprising: The microcontroller of the vehicle system collects the operating data of the vehicle's power chassis domain control system and writes the operating data to the flash memory of the vehicle system through a serial peripheral interface; the flash memory is used to store the operating data of the power chassis domain control system.
[0014] The method provided in this application acquires operational data through a microcontroller and writes it to a flash memory via a serial peripheral interface. This overcomes the storage limitations of the microcontroller itself and utilizes the larger capacity of the flash memory to achieve continuous storage of operational data, providing a richer data foundation for diagnostic equipment. The high-speed characteristics of the serial peripheral interface ensure efficient and reliable data transmission, avoiding data loss or delay. This solves the data gap problem caused by insufficient storage in traditional microcontrollers, allowing complete data before and after a fault to be preserved, providing a data reserve guarantee for accurate diagnosis.
[0015] In conjunction with the second aspect, in one possible implementation, when the microcontroller includes an application module, an intermediate module, and a drive module, the step of collecting the operating data of the vehicle's powertrain chassis domain control system through the microcontroller of the in-vehicle system and writing the operating data to the flash memory of the in-vehicle system via a serial peripheral interface includes: The application module collects the operating data of the vehicle's power chassis domain control system and transmits the operating data to the intermediate module through the runtime environment interface. The intermediate module determines the storage method corresponding to the operating data; the storage method is determined based on whether a fault event has occurred in the power chassis domain control system, and when a fault event occurs, the time elapsed between the current moment and the occurrence of the fault event. The driver module determines the storage address corresponding to the running data, and writes the running data to the corresponding storage address through the serial peripheral interface based on the storage method.
[0016] The method provided in this application embodiment achieves intelligent data storage management through layered collaboration of the application module, intermediate module, and driver module within a microcontroller. The application module is responsible for data acquisition, the intermediate module dynamically determines the storage method based on the fault state and time difference, and the driver module accurately locates the storage address and completes the writing, forming a closed-loop control from acquisition to storage. This layered architecture ensures both the professionalism of data acquisition and the preservation of critical data (such as data before and after a fault) through dynamic storage strategies, improving the targeting and effectiveness of data storage and laying the foundation for subsequent efficient diagnosis.
[0017] In conjunction with the second aspect or its corresponding implementation, in one possible implementation, when the storage method includes a dynamic rolling storage method and a fault event triggered storage method, and the corresponding flash memory includes a first storage area corresponding to the dynamic rolling storage method and a second storage area corresponding to the fault event triggered storage method, determining the storage address corresponding to the running data through the driver module includes: Based on the storage method, the target storage area for the running data is determined by the driver module; the target storage area is either the first storage area or the second storage area. Obtain the basic storage information of each storage block in the target storage area, and determine the target storage block based on the basic storage information of each storage block; Obtain the basic storage information of each storage page in the target storage block, and determine the target storage page based on the basic storage information of each storage page; wherein, the basic storage information includes the number of times running data is written, the total storage capacity, and the current remaining storage space; The storage address corresponding to the running data is determined based on the target storage area, the target storage block, and the target storage page.
[0018] The method provided in this application divides the flash memory space into a first storage area for dynamic rolling storage and a second storage area for fault-triggered storage. It determines the storage address by combining basic information such as the write count and capacity of storage blocks and pages, thus achieving fine-grained management of flash memory space. Dynamic rolling storage avoids invalid occupancy, fault-triggered storage ensures the retention of critical data, and address selection based on storage block / page status optimizes space utilization efficiency, reduces storage fragmentation, ensures efficient and orderly data writing, and provides a structured foundation for subsequent rapid data retrieval.
[0019] In conjunction with the second aspect or its corresponding implementation, in one possible implementation, after writing the runtime data to the corresponding storage address via the serial peripheral interface based on the storage method, the method further includes: Based on the importance level of the operational data and the basic storage information of the target storage block, the erase priority of the target storage block in the dynamic priority queue is adjusted; wherein, the dynamic priority queue includes all storage blocks sorted by erase priority from high to low and the erase priority corresponding to each storage block; the importance level is determined based on the degree of correlation between the operational data and the safe operation of the vehicle, and the importance level and the degree of correlation are positively correlated; the erase priority is negatively correlated with the importance level, the total storage capacity and the current remaining storable space, and positively correlated with the number of writes to the target storage block; When the total remaining available storage space of the flash memory is less than the global threshold, an erase operation is performed according to the adjusted dynamic priority queue until the total remaining available storage space of the flash memory is greater than or equal to the global threshold. Before erasing any storage block, if there is running data in the storage block with an importance level higher than a preset threshold, the running data with an importance level higher than the preset threshold is backed up.
[0020] The method provided in this application manages storage block erasure through a dynamic priority queue. It adjusts the erasure priority based on data importance level and storage block status, erasing data according to priority when flash memory space is insufficient, and backing up high-importance operational data. This ensures that flash memory always has sufficient space to store new data, while also ensuring that critical operational data is not accidentally deleted through logic linking importance levels to vehicle safety. It balances storage efficiency and data security, resolving the contradiction between data retention and updates under limited flash memory space.
[0021] Thirdly, embodiments of this application provide a diagnostic device connected to a vehicle's onboard system, the diagnostic device comprising: The data acquisition module is used to acquire the current operating data of the power chassis domain control system from the microcontroller of the vehicle system and / or acquire relevant operating data from the flash memory of the vehicle system when a fault event occurs in the power chassis domain control system of the vehicle; wherein, the relevant operating data includes operating data within a preset time period before and after the fault event occurs; the microcontroller is used to collect the operating data of the power chassis domain control system and store the operating data in the flash memory; The fault diagnosis module is used to determine the fault diagnosis result based on the current operating data and / or the relevant operating data.
[0022] Fourthly, embodiments of this application provide a data writing device, which is applied to a vehicle's in-vehicle system. The device includes a microcontroller and a flash memory. The microcontroller is used to collect the operating data of the vehicle's power chassis domain control system and write the operating data to the flash memory of the vehicle system through a serial peripheral interface. The flash memory is used to store the operating data of the power chassis domain control system.
[0023] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to perform the data processing method of the first aspect or any corresponding embodiment described above, or the data writing method of the second aspect or any corresponding embodiment described above.
[0024] In a sixth aspect, this application provides a computer program product, including computer instructions, which are used to cause a computer to execute the data processing method of the first aspect or any corresponding embodiment thereof, or the data writing method of the second aspect or any corresponding embodiment thereof. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0026] Figure 1 This is a flowchart illustrating the data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the process for obtaining current running data and related running data provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the data writing method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the flash memory provided in the embodiments of this application; Figure 5 This is a schematic diagram of the data writing process provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of the computer device provided in the embodiments of this application. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0028] Intelligent driving, cockpit, and powertrain chassis have become core standard domains in automotive electronic architecture. However, with the continuous increase in the complexity and integration of each domain, troubleshooting software issues has gradually become a critical problem. Due to the stringent requirements for functional safety and real-time performance, the powertrain chassis domain control cannot utilize high-performance system-on-a-chip (SoC) and large-capacity general-purpose flash memory like the in-vehicle infotainment system and intelligent driving domains. This allows for convenient troubleshooting of various software issues by storing large amounts of operational logs on storage media. Currently, powertrain chassis domain control is mainly implemented based on microcontroller units (MCUs). However, the non-volatile memory storage space of the MCU is relatively limited. Troubleshooting methods still primarily rely on the diagnostic fault code freeze frame data preset by the unified diagnostic service for basic diagnosis and problem identification. But with the exponential growth in the complexity of current functional software, relying solely on the limited data stored in the diagnostic fault code freeze frames is insufficient to accurately locate the fault.
[0029] This application provides a data processing method embodiment to solve the above-mentioned problems. It should be noted that the flowcharts shown in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the execution may be carried out in a different order than that shown or described here.
[0030] Figure 1 This is a flowchart illustrating the data processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, this data processing method is applied to a diagnostic device in a vehicle, which is connected to the vehicle's onboard system. The data processing method includes the following: S101: When a fault event occurs in the vehicle's power chassis domain control system, obtain the current operating data of the power chassis domain control system from the microcontroller of the on-board system, and / or obtain relevant operating data from the flash memory of the on-board system.
[0031] In this embodiment, the relevant operational data includes operational data within a preset time period before and after the occurrence of a fault event. The preset time period can be set and modified according to actual needs. The microcontroller is used to collect the operational data of the power chassis domain control system and store the operational data in a flash memory. The microcontroller has an internal cache area that can cache the operational data of the power chassis domain control system in real time.
[0032] In this embodiment, the operating data of the powertrain chassis domain control system may include engine speed, accelerator pedal opening, brake pedal travel, power battery voltage, current, temperature, and transmission gear position signals. This data directly reflects the state of power output and control and can be used to troubleshoot problems such as abnormal power response and shift jerking. It may also include steering angle, electronic stability program operating status, suspension adjustment signals, and wheel speeds. This data can be used to locate software logic issues related to chassis handling stability and steering precision.
[0033] In this embodiment, the flash memory can be connected to the microcontroller via a serial peripheral interface. As an example, the flash memory can be NAND flash. The diagnostic device is a dedicated device used to troubleshoot faults in the vehicle's powertrain chassis domain control system. As an example, it can be an on-board diagnostic tool or an external test computer. The diagnostic device can establish a communication connection with the vehicle's on-board system via a CAN bus or network. In this embodiment, the method for determining whether a fault event exists in the power chassis domain control system is not limited. Conventional methods in the art can be used to determine it. For example, sensors deployed in the power chassis domain control system for monitoring key parameters, such as oil pressure sensors, brake pressure sensors, motor speed sensors, and steering angle sensors, can be used. The microcontroller will collect the analog or digital signals output by these sensors in real time and convert them into physical quantities such as oil pressure, pressure, and speed values. These values are then compared with the system's preset safety threshold ranges, such as the normal oil pressure threshold of 2.0-4.0 bar and the normal brake pressure threshold of 10-15 MPa. If a parameter exceeds the threshold range for multiple consecutive acquisition cycles (e.g., three consecutive 100ms cycles), a fault event is determined to exist, such as low oil pressure or abnormal brake pressure, and a corresponding Diagnostic Trouble Code (DTC) is generated.
[0034] S102: Determine the fault diagnosis result based on the current operating data and / or relevant operating data.
[0035] In this embodiment, the diagnostic device can also display current operating data and / or relevant operating data, which can be displayed in the form of charts, text, etc. The fault diagnosis results can at least include the fault phenomenon, the fault cause, and maintenance suggestions. For example, fault phenomenon: low oil pressure in the power chassis domain control system. Fault cause: aging of the oil pump drive motor, leading to a decrease in speed and a gradual decrease in oil pressure. Maintenance suggestion: replace the oil pump drive motor and check the motor power supply line.
[0036] In the embodiments of this application, the accuracy of the fault diagnosis result determined based on relevant operating data (or current operating data and relevant operating data) is higher than the accuracy of the fault diagnosis result determined based on current operating data. In this application, it is preferred to determine the fault diagnosis result based on relevant operating data (or current operating data and relevant operating data).
[0037] As an example, fault diagnosis results can be determined based on current operating data.
[0038] For example, if only a current oil pressure of 1 bar is detected, which is lower than the normal threshold of 3 bar, the fault diagnosis result may be: Low oil pressure in the powertrain chassis control system. The cause of the fault is: Abnormal oil pressure sensor signal or an abnormality in the oil circuit. The repair suggestion is to check the oil pressure sensor and oil circuit connections. Fault diagnosis results determined based on current operating data are only based on instantaneous data and cannot distinguish between sensor problems and oil circuit malfunctions, making the cause analysis rather broad.
[0039] As an example, fault diagnosis results can be determined based on relevant operational data.
[0040] For example, the relevant operational data shows that 30 seconds before the fault, the oil pressure gradually decreased from 3 bar to 1 bar, and the oil pump speed simultaneously decreased from 2000 rpm to 800 rpm. The fault diagnosis result may be: Fault symptom: Gradual decrease in oil pressure in the powertrain chassis control system. Fault cause: Decreased oil pump drive capability, presumably due to motor aging. Repair recommendation: Check the performance of the oil pump drive motor and replace it if necessary. By analyzing historical trend data, sudden faults can be ruled out, and the root cause of the fault can be determined.
[0041] As an example, fault diagnosis results can be determined based on current operating data and relevant operating data.
[0042] For example, if the current oil pressure is 1 bar and the sensor signal is normal, combined with the continuous drop in oil pressure and motor speed before the fault, and the current fluctuation in the motor power supply voltage, the fault diagnosis result may be: low oil pressure in the power chassis domain control system and unstable motor power supply. The cause of the fault is: aging of the oil pump drive motor accompanied by poor contact in the power supply line. Repair recommendations: replace the aging motor and inspect the power supply line connectors. Integrating the real-time status with the trend of changes in operating data before and after the fault event can yield more accurate fault diagnosis results.
[0043] In this embodiment, even when there is no fault event in the vehicle's power chassis domain control system, the current operating data of the power chassis domain control system can be obtained from the microcontroller of the vehicle system, and / or relevant operating data can be obtained from the flash memory of the vehicle system. The operating data when the system is currently running normally can be viewed to understand the system's operating status. The historical operating data corresponding to historical fault events can be viewed to analyze the common patterns of fault events. Fault events can be predicted based on historical and current operating data to predict possible future fault events.
[0044] The method provided in this application is applied to a diagnostic device connected to the vehicle's onboard system, which includes a microcontroller and a flash memory. When a fault event occurs in the vehicle's powertrain chassis domain control system, the current operating data of the powertrain chassis domain control system collected by the microcontroller can be obtained from the onboard system's microcontroller, and the operating data stored in the flash memory for a preset time period before and after the fault event can be obtained from the flash memory. This expands the data source and scope. Because the microcontroller is responsible for continuously collecting operating data and storing it in the flash memory, the flash memory can hold a larger amount of continuous operating data, compensating for the storage limitations of the microcontroller and providing complete operating data for the moment of the fault or the trend of the process. Based on this, the diagnosis no longer relies solely on matching a single fault code, but rather on a comprehensive judgment based on the current operating data or the operating data for a preset time period before and after the fault event to determine the fault diagnosis result, accurately locating the fault location. At the same time, because the data is more comprehensive, it can also reduce misjudgments, enabling rapid subsequent fault diagnosis and reducing maintenance costs.
[0045] In one possible implementation, before acquiring current operating data from the microcontroller of the vehicle system and / or acquiring relevant operating data from the flash memory of the vehicle system, the data processing method further includes: The storage addresses corresponding to the data identifiers and / or routine identifiers related to the fault events are determined based on the diagnostic questionnaire.
[0046] In this embodiment of the application, the diagnostic survey form includes data identifiers, routine identifiers, and storage addresses corresponding to different fault events.
[0047] In this embodiment, the diagnostic questionnaire is custom-defined and can be expanded according to actual needs. The diagnostic questionnaire may include fault codes, data identifiers, routine identifiers, and storage addresses corresponding to fault events stored in a correspondence relationship. When writing data, the storage addresses of the corresponding running data can be written into the diagnostic questionnaire.
[0048] The method provided in this application can obtain data identifiers related to fault events, and then retrieve current operating data from the microcontroller based on these data identifiers. It can also obtain routine identifiers related to fault events and their corresponding storage addresses, and then retrieve relevant operating data from the flash memory based on the storage addresses corresponding to the routine identifiers. The data identifiers can be used to lock the current operating data related to the fault event in the microcontroller, avoiding interference from irrelevant data. The storage addresses of relevant operating data in the flash memory can be located based on the routine identifiers, enabling targeted retrieval. This precise identifier-based acquisition mechanism reduces data transmission volume and filtering costs, improving data acquisition efficiency and ensuring the specificity of diagnostic criteria, further enhancing the accuracy and timeliness of fault location.
[0049] In one possible implementation, step S101 involves obtaining current operating data from the microcontroller of the vehicle system and / or obtaining relevant operating data from the flash memory of the vehicle system, including steps Sa1 to Sa4.
[0050] Sa1 retrieves the storage address corresponding to the Data Identifier (DID) associated with the fault event.
[0051] Sa2 retrieves the current running data from the microcontroller based on the storage address.
[0052] In this embodiment, current operating data can be obtained from the microcontroller via the UDS 22 service. The process for obtaining current operating data from the microcontroller via the UDS 22 service is as follows: Figure 2 As shown.
[0053] In this embodiment, when the microcontroller includes an application module, an intermediate module, and a driver module, the diagnostic device initiates a UDS 22 service and sends a first read request to the intermediate module in the microcontroller. The first read request includes a data identifier related to the fault event. Based on the data identifier, the intermediate module retrieves the corresponding current operating data. It can fill the corresponding DID with the operating data (such as oil pressure, motor speed, etc.) based on the standardized mapping relationship stored in the standardized service dataset SSDS. The intermediate module then returns the data identifier and the corresponding current operating data to the diagnostic device. The standardized service dataset is a predefined, standardized data set that is strongly associated with diagnostic services (such as the UDS service) and data identifiers, and is used to fill the DID with operating data related to the fault event during the diagnostic interaction process.
[0054] Sa3 retrieves the storage address corresponding to the Routine Identifier (RID) associated with the fault event.
[0055] Sa4 retrieves relevant operational data from the flash memory based on the storage address.
[0056] In this embodiment, relevant runtime data can be obtained from flash memory via the UDS 31 service. The process for obtaining relevant runtime data from flash memory via the UDS 31 service is as follows: Figure 2 As shown, relevant runtime data can be retrieved from the flash memory based on the memory address corresponding to the routine identifier.
[0057] In this embodiment, when the microcontroller includes an application module, an intermediate module, and a driver module, the diagnostic device initiates a UDS 31 service, sending a second read request to the determination module in the microcontroller. The second read request includes the storage address corresponding to the routine identifier related to the fault event. The driver module can read relevant operational data from the flash memory before and after a preset time period before and after the fault event based on this storage address, where the storage address is the storage address of the relevant operational data. The driver module can generate a hardware-executable read operation instruction according to the second read request, specifying the storage address to be accessed. The storage address includes the address of the storage block (block address) and the range of storage pages (page range).
[0058] As an example, the second read request can also be used to read the status of the flash memory. The driver module can send a request to the flash memory to read its status and receive the returned status. The driver module can then return the relevant operational data and the flash memory status to the diagnostic device. As an example, the flash memory status may include whether writing is in progress, the progress of the erase operation, the presence of bad blocks, or whether the memory block corresponding to the memory address is currently being written to.
[0059] The method provided in this application solves the problem of time-consuming data identifier and address matching when a fault occurs by pre-constructing a diagnostic survey form and establishing a correspondence between fault events and data identifiers, routine identifiers, and the corresponding storage addresses of the routine identifiers. After a fault occurs, there is no need for temporary retrieval; the required data identifier and storage address can be quickly determined directly through the diagnostic survey form, significantly shortening the lead time for data acquisition. At the same time, the standardized correspondence avoids errors from manual matching, ensuring the accuracy of data retrieval. Pre-constructing the diagnostic survey form makes the data acquisition process more efficient and reliable, providing a guarantee for subsequent rapid fault diagnosis and improved location accuracy, and is particularly suitable for rapid response scenarios with multiple fault types in complex domain control systems.
[0060] Figure 3 This is a flowchart illustrating the data writing method provided in an embodiment of this application, as shown below. Figure 3 As shown, this data writing method is applied to a vehicle's onboard system, which is connected to the aforementioned diagnostic equipment. The data writing method includes: S301 collects the operating data of the vehicle's power chassis domain control system through the microcontroller of the vehicle system, and writes the operating data to the flash memory of the vehicle system through the serial peripheral interface.
[0061] In this embodiment, the flash memory is used to store the operating data of the power chassis domain control system.
[0062] The structure of flash memory is as follows Figure 4 As shown, the flash memory structure mainly consists of a serial NAND controller, a cache memory, a NAND storage core, and a status register. The serial NAND controller, as the control center of the entire structure, is responsible for receiving various control and data signals from external input, such as the SCLK clock signal, SI / SIO0 data / instruction input signals, SO / SIO1 data / instruction output signals, CS# chip select signal, HOLD# / SIO3 hold / status output signal, and WP# / SIO2 write protect / instruction input signal. After parsing these signals, it coordinates the work of internal modules to achieve overall management of read, write, and erase operations on the NAND storage core.
[0063] The cache memory acts as a data buffer, temporarily storing data before it is written to the NAND storage core, or loading data from the NAND storage core into the cache before reading it, thereby improving data transmission efficiency and reducing the wear and tear of frequent read and write operations on the NAND storage core.
[0064] The NAND flash memory core is the actual data storage carrier, used to store operational data and other information for a long time. Internally, it organizes storage space in a hierarchical structure of blocks and pages.
[0065] The status register is used to record the working status of the flash memory in real time (such as whether it is writing, the progress of the erase operation, whether there are bad blocks, etc.). External modules such as driver modules can obtain the current operating status of the device by reading this register.
[0066] External power is supplied by Vcc (positive power) and Vss (ground power), ensuring the power supply for the entire flash memory. This structure enables communication with external devices through a serial interface, balancing storage capacity and data transmission flexibility, making it suitable for applications such as automotive where space and reliability are critical.
[0067] The method provided in this application acquires operational data through a microcontroller and writes it to a flash memory via a serial peripheral interface. This overcomes the storage limitations of the microcontroller itself and utilizes the larger capacity of the flash memory to achieve continuous storage of operational data, providing a richer data foundation for diagnostic equipment. The high-speed characteristics of the serial peripheral interface ensure efficient and reliable data transmission, avoiding data loss or delay. This solves the data gap problem caused by insufficient storage in traditional microcontrollers, allowing complete data before and after a fault to be preserved, providing a data reserve guarantee for accurate diagnosis.
[0068] In one possible implementation, when the microcontroller includes an application module APP / BSW, a middleware module (X-BE / Base), and a driver module, S301 collects the operating data of the vehicle's power chassis domain control system through the microcontroller of the vehicle system, and writes the operating data to the flash memory of the vehicle system through a serial peripheral interface, including steps Sb1 to Sb3.
[0069] Sb1 collects the operating data of the vehicle's power chassis domain control system through the application module and transmits the operating data to the intermediate module through the Run Time Environment (RTE) interface.
[0070] Sb2 determines the storage method corresponding to the running data through the intermediate module.
[0071] In this embodiment of the application, the storage method is determined based on whether a fault event has occurred in the power chassis domain control system, and when a fault event occurs, the time elapsed between the current moment and the occurrence of the fault event.
[0072] In this embodiment, the storage method may include dynamic rolling storage or fault event-triggered storage. After receiving the operating data, the intermediate module determines whether a fault event has occurred in the power chassis domain control system. If no fault event has occurred, dynamic rolling storage is used. If a fault event has occurred, a diagnostic checklist can be used to determine whether the operating data is related to the fault event. If no correlation exists, dynamic rolling storage is used. If a correlation exists, the time elapsed between the current moment and the occurrence of the fault event is determined. If this time elapsed is less than or equal to a time threshold, fault event-triggered storage is used to ensure that data within a preset time period before and after the fault is preferentially retained. If this time elapsed is greater than the time threshold, dynamic rolling storage is used. The time threshold can be set and modified according to actual needs.
[0073] Sb3 determines the storage address corresponding to the running data through the driver module, and writes the running data to the corresponding storage address based on the storage method through the serial peripheral interface.
[0074] In this embodiment, as an example, in the dynamic rolling storage method, the driver module tracks the current write position of the dynamic rolling storage area through a circular pointer. The initial pointer points to the starting address of the rolling area. Each write operation uses the current pointer value as the storage address. After writing, the pointer increments according to the data length. When the pointer exceeds the end address of the rolling area, it is automatically reset to the starting address, realizing the cyclic overwriting of the oldest running data by the new running data. In the fault event triggered storage method, the driver module allocates an independent storage block for each fault event. It calculates the starting address of the storage block based on the fault number (the starting address of the fault area plus the product of the number and the single block size), prioritizes storing fault metadata (fault code, occurrence time of the fault event, etc.), and then writes the relevant running data for a preset time period before the fault occurs (e.g., 10s) and a preset time period after the fault occurs (e.g., 20s) in chronological order. The storage address increments sequentially from the starting position of the storage block. The storage address is determined based on the starting address of the data block, the amount of already stored running data (the write offset of the storage block), and the amount of running data to be stored. The system writes runtime data in blocks via the SPI interface and attaches verification information, ensuring that the storage blocks are not overwritten by subsequent data, thus guaranteeing the complete retention of runtime data before and after a failure.
[0075] In this embodiment, before writing the runtime data to the corresponding storage address via the serial peripheral interface based on the storage method, a Cyclic Redundancy Check (CRC) calculation is performed on the runtime data to be written, generating a first checksum which is sent along with the runtime data. After receiving the data, the flash memory performs a second CRC check and compares the first and second checksums to ensure the accuracy of the data transmission. As another example, the driver module can also generate an Error Correction Code (ECC) for the runtime data, which is stored in the flash memory along with the runtime data. During subsequent reading or verification, the error correction code can detect and correct data errors caused by the physical characteristics of the flash memory. Thus, a dual verification mechanism is formed in both the data transmission and data storage stages using CRC and ECC respectively, ensuring the accuracy and integrity of the written data.
[0076] The method provided in this application embodiment achieves intelligent data storage management through layered collaboration of the application module, intermediate module, and driver module within a microcontroller. The application module is responsible for data acquisition, the intermediate module dynamically determines the storage method based on the fault state and time difference, and the driver module accurately locates the storage address and completes the writing, forming a closed-loop control from acquisition to storage. This layered architecture ensures both the professionalism of data acquisition and the preservation of critical data (such as data before and after a fault) through dynamic storage strategies, improving the targeting and effectiveness of data storage and laying the foundation for subsequent efficient diagnosis.
[0077] Figure 5 This is a schematic diagram of the data writing process provided in the embodiments of this application, such as... Figure 5 As shown, the application module first sends the runtime data to be stored to the intermediate module. The intermediate module processes the storage logic for different cycles, determines the storage method corresponding to the runtime data (such as dynamic rolling storage or fault event triggered storage), and then calls the complex driver's write interface to pass the instructions to the driver module. The driver module performs erase and write operations and obtains the flash memory status through hardware driver (SPI driver), file system processing (address mapping, bad block management), and data verification mechanisms. Finally, it writes the runtime data to the flash memory, realizing layered collaboration and reliable control from data processing to storage, ensuring the efficiency and accuracy of the runtime data writing process.
[0078] In one possible implementation, as another example, when the storage method includes dynamic rolling storage and fault event triggered storage, and the corresponding flash memory includes a first storage area corresponding to dynamic rolling storage and a second storage area corresponding to fault event triggered storage, the storage address corresponding to the running data is determined by the driver module in Sb3, including steps Sb31 to Sb34.
[0079] Sb31, based on the storage method, determines the target storage area for running data through the driver module.
[0080] In this embodiment of the application, the target storage area is either a first storage area or a second storage area.
[0081] In this embodiment, the dynamic rolling storage method corresponds to the first storage area, and the fault event triggered storage method corresponds to the second storage area.
[0082] Sb32 retrieves the basic storage information of each storage block in the target storage area, and determines the target storage block based on the basic storage information of each storage block.
[0083] Sb33 retrieves the basic storage information of each storage page in the target storage block, and determines the target storage page based on the basic storage information of each storage page.
[0084] In this embodiment, the basic storage information includes the number of times the running data has been written, the total storage capacity, and the currently remaining available storage space. In this embodiment, the target storage page and the page range within the target storage page are determined based on the basic storage information of each storage page.
[0085] In this embodiment, the driver module traverses the basic storage information of each storage block in the target storage area, prioritizing storage blocks with fewer write cycles, sufficient remaining available storage space, and a total storage capacity that matches the amount of data being processed, in order to balance storage block lifespan and space utilization. When determining the target storage page, the module further filters within the target storage block for storage pages with fewer write cycles, sufficient remaining available storage space to accommodate the current processing data, and a matching total storage capacity, ensuring reasonable space utilization after data writing and reducing the impact of frequent erase / write operations on the storage page lifespan.
[0086] Sb34 determines the storage address corresponding to the running data based on the target storage area, target storage block, and target storage page.
[0087] In this embodiment of the application, the target storage area, the target storage block, the target storage page, and the specific page range are used as storage addresses.
[0088] The method provided in this application divides the flash memory space into a first storage area for dynamic rolling storage and a second storage area for fault-triggered storage. It determines the storage address by combining basic information such as the write count and capacity of storage blocks and pages, thus achieving fine-grained management of flash memory space. Dynamic rolling storage avoids invalid occupancy, fault-triggered storage ensures the retention of critical data, and address selection based on storage block / page status optimizes space utilization efficiency, reduces storage fragmentation, ensures efficient and orderly data writing, and provides a structured foundation for subsequent rapid data retrieval.
[0089] In one possible implementation, after writing the runtime data to the corresponding memory address via the serial peripheral interface based on the storage method, the data writing method further includes: Based on the importance level of the running data and the basic storage information of the target storage block, the erase priority of the target storage block in the dynamic priority queue is adjusted. When the total remaining available storage space of the flash memory is less than the global threshold, the erase operation is performed according to the adjusted dynamic priority queue until the total remaining available storage space of the flash memory is greater than or equal to the global threshold. Before erasing any storage block, if there is running data in the storage block with an importance level higher than the preset threshold, the running data with an importance level higher than the preset threshold is backed up.
[0090] In this embodiment, the dynamic priority queue includes all storage blocks sorted by erase priority from high to low and the erase priority corresponding to each storage block. The importance level is determined based on the correlation between the operational data and the safe operation of the vehicle; the importance level and the correlation are positively correlated. The erase priority is negatively correlated with the importance level, total storage capacity, and currently remaining storable space, but positively correlated with the number of writes to the target storage block.
[0091] In this embodiment, the drive module first determines the importance level based on the correlation between the operating data and the safe operation of the vehicle; the higher the correlation, the higher the importance level. Then, combined with the basic storage information of the target storage block (number of writes, total storage capacity, and current remaining available storage space), the module dynamically adjusts the position of the target storage block in the dynamic priority queue according to the rule that the erase priority is negatively correlated with the importance level, total storage capacity, and remaining space, and positively correlated with the number of writes. When the total remaining available storage space of the flash memory is less than the global threshold, the erase operation is performed in descending order of erase priority in the queue until the total remaining available storage space reaches the threshold. Before erasing, if there is operating data in the storage block with an importance level higher than the preset threshold, it is first backed up to a safe storage area, such as a predetermined number of storage blocks as the safe storage area.
[0092] As an example, the importance level of operational data is calculated as follows: a quantitative score is given based on the correlation between the operational data and vehicle functions and safety. For example, core data that directly affects driving safety, such as power output parameters and braking pressure, has the highest correlation and is set to the highest importance level. Data that indirectly affects safety, such as ambient temperature and the status of non-critical sensors, has a lower correlation and is set to a medium-low importance level. This establishes the level classification standard. In this embodiment, different scoring ranges and corresponding importance levels can be set. As an example, when there are three scoring ranges, the importance levels can be set to high, medium, and low.
[0093] The method provided in this application manages storage block erasure through a dynamic priority queue. It adjusts the erasure priority based on data importance level and storage block status, erasing data according to priority when flash memory space is insufficient, and backing up high-importance operational data. This ensures that flash memory always has sufficient space to store new data, while also ensuring that critical operational data is not accidentally deleted through logic linking importance levels to vehicle safety. It balances storage efficiency and data security, resolving the contradiction between data retention and updates under limited flash memory space.
[0094] This application utilizes an external flash memory connection via a microcontroller to periodically / trigger critical operational data in NAND flash. When a software malfunction occurs in the vehicle, the NAND flash data is read and analyzed for troubleshooting and problem localization. Hardware-wise, the MCU communicates with the NAND flash via SPI for read, write, and erase operations, and CRC checks ensure the accuracy of written data, resolving hardware communication and data reliability issues. The storage strategy divides the system into a dynamic rolling storage area and a fault event-triggered storage area, combining ECC checks and dynamic balancing technology to achieve balanced and maximized NAND flash lifespan, addressing storage resource allocation and device lifespan concerns. For data interaction, flash data is read via UDS22 / 31 services, and the fault diagnosis results are dynamically displayed using host computer analysis tools (diagnostic equipment), enabling efficient reading and visual analysis of fault diagnosis results. Compared to traditional technologies and DTC troubleshooting, this application offers greater flexibility and can extract multiple sets of operational data before and after the fault as needed, rather than simply freezing data at the time of the problem. Compared to vehicle cloud big data investigation, this application is not limited by vehicle cloud communication bandwidth and rate, and can support problem investigation with short cycle and high real-time requirements, avoiding the limitations of investigation caused by limited data volume and long cycle.
[0095] This embodiment also provides a diagnostic device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the diagnostic device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0096] The diagnostic device connects to the vehicle's onboard system and includes: The data acquisition module is used to acquire current operating data of the powertrain chassis domain control system from the microcontroller of the on-board system, and / or acquire relevant operating data from the flash memory of the on-board system when a fault event occurs in the powertrain chassis domain control system. The relevant operating data includes operating data within a preset time period before and after the fault event. The microcontroller is used to collect the operating data of the powertrain chassis domain control system and store the operating data in the flash memory.
[0097] The fault diagnosis module is used to determine the fault diagnosis results based on the current operating data and / or relevant operating data.
[0098] In one possible implementation, the data acquisition module includes: The first data acquisition unit is used to acquire data identifiers related to fault events. Based on these data identifiers, it retrieves current operating data from the microcontroller.
[0099] The second data acquisition unit is used to acquire the storage address corresponding to the routine identifier related to the fault event. Based on the storage address, it retrieves the relevant runtime data from the flash memory.
[0100] In one possible implementation, the diagnostic device further includes a lookup module for determining the storage addresses corresponding to data identifiers and / or routine identifiers related to fault events based on a diagnostic questionnaire. The diagnostic questionnaire includes data identifiers, routine identifiers, and the storage addresses corresponding to the routine identifiers for different fault events.
[0101] This embodiment also provides a data writing device, which is used to implement the above embodiments and preferred embodiments. Details that have been described will not be repeated here.
[0102] In this embodiment, the diagnostic device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above-mentioned functions.
[0103] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0104] This embodiment provides a data writing device applied to a vehicle's in-vehicle system, including a microcontroller and a flash memory.
[0105] The microcontroller is used to collect the operating data of the vehicle's power chassis domain control system and write the operating data to the flash memory of the vehicle system through a serial peripheral interface.
[0106] Flash memory is used to store the operating data of the power chassis domain control system.
[0107] In one possible implementation, the microcontroller includes an application module, an intermediate module, and a driver module.
[0108] The application module is used to collect the operating data of the vehicle's power chassis domain control system and transmit the operating data to the intermediate module through the runtime environment interface.
[0109] The intermediate module is used to determine the storage method for the operational data. The storage method is determined based on whether a fault event has occurred in the power chassis domain control system, and if so, the time elapsed between the current moment and the occurrence of the fault event.
[0110] The driver module is used to determine the storage address corresponding to the running data and write the running data to the corresponding storage address through the serial peripheral interface based on the storage method.
[0111] In one possible implementation, the driver module includes a first processing unit.
[0112] The first processing unit is configured to determine the target storage area for the running data based on the storage method, using a driver module, when the storage method includes dynamic rolling storage and fault event triggered storage, and the corresponding flash memory includes a first storage area corresponding to dynamic rolling storage and a second storage area corresponding to fault event triggered storage. The target storage area is either the first storage area or the second storage area.
[0113] Obtain the basic storage information of each storage block in the target storage area, and determine the target storage block based on the basic storage information of each storage block.
[0114] Obtain the basic storage information for each storage page in the target storage block, and determine the target storage page based on the basic storage information for each storage page. The basic storage information includes the number of write operations, total storage capacity, and currently remaining available storage space.
[0115] The storage address corresponding to the running data is determined based on the target storage area, target storage block, and target storage page.
[0116] In one possible implementation, the driver module also includes a second processing unit.
[0117] The second processing unit, after writing the runtime data to the corresponding storage address via the serial peripheral interface based on the storage method, adjusts the erase priority of the target storage block in the dynamic priority queue based on the importance level of the runtime data and the basic storage information of the target storage block. When the total remaining available storage space of the flash memory is less than the global threshold, the erase operation is performed according to the adjusted dynamic priority queue until the total remaining available storage space of the flash memory is greater than or equal to the global threshold. Before erasing any storage block, if there is runtime data in the storage block with an importance level higher than the preset threshold, the runtime data with an importance level higher than the preset threshold is backed up.
[0118] The dynamic priority queue includes all storage blocks sorted by erase priority from highest to lowest, and the erase priority corresponding to each storage block. Importance level is determined based on the correlation between operational data and vehicle safety operation; importance level and correlation are positively correlated. Erase priority is negatively correlated with importance level, total storage capacity, and currently remaining storable space, but positively correlated with the number of writes to the target storage block.
[0119] This application also provides a computer device; please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of this application, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.
[0120] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.
[0121] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.
[0122] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function. The data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transient memory, such as at least one disk storage device, flash memory device, or other non-transient solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0123] Memory 20 may include volatile memory, such as random access memory. Memory may also include non-volatile memory, such as flash memory, hard disk drive, or solid-state drive. Memory 20 may also include combinations of the above types of memory. The computer device also includes a communication interface 30 for communicating with other devices or communication networks.
[0124] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc. Further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.
[0125] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0126] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.
Claims
1. A data processing method, characterized in that, The method is applied to a diagnostic device in a vehicle, the diagnostic device being connected to the vehicle's onboard system, and the method includes: When a fault event occurs in the power chassis domain control system of the vehicle, the current operating data of the power chassis domain control system is obtained from the microcontroller of the vehicle system, and / or relevant operating data is obtained from the flash memory of the vehicle system; wherein, the relevant operating data includes operating data within a preset time period before and after the fault event occurs; the microcontroller is used to collect the operating data of the power chassis domain control system and store the operating data in the flash memory; The fault diagnosis result is determined based on the current operating data and / or the relevant operating data.
2. The method according to claim 1, characterized in that, The step of obtaining current operating data from the microcontroller of the vehicle system and / or obtaining relevant operating data from the flash memory of the vehicle system includes: Obtain the data identifier associated with the fault event; The current operating data is obtained from the microcontroller based on the data identifier; Obtain the storage address corresponding to the routine identifier associated with the fault event; Relevant operational data is obtained from the flash memory based on the storage address.
3. The method according to claim 2, characterized in that, Before acquiring current operating data from the microcontroller of the vehicle system and / or acquiring relevant operating data from the flash memory of the vehicle system, the method further includes: The diagnostic questionnaire determines the storage addresses corresponding to the data identifiers and / or routine identifiers related to the fault events; the diagnostic questionnaire includes data identifiers, routine identifiers, and storage addresses corresponding to the routine identifiers for different fault events.
4. A data writing method, characterized in that, The method is applied to a vehicle's onboard system, the onboard system being connected to the diagnostic device in the method of any one of claims 1 to 3, the method comprising: The microcontroller of the vehicle system collects the operating data of the vehicle's power chassis domain control system and writes the operating data to the flash memory of the vehicle system through a serial peripheral interface; the flash memory is used to store the operating data of the power chassis domain control system.
5. The method according to claim 4, characterized in that, When the microcontroller includes an application module, an intermediate module, and a driver module, the step of collecting operating data of the vehicle's power chassis domain control system through the microcontroller of the in-vehicle system and writing the operating data to the flash memory of the in-vehicle system through a serial peripheral interface includes: The application module collects the operating data of the vehicle's power chassis domain control system and transmits the operating data to the intermediate module through the runtime environment interface. The intermediate module determines the storage method corresponding to the operating data; the storage method is determined based on whether a fault event has occurred in the power chassis domain control system, and when a fault event occurs, the time elapsed between the current moment and the occurrence of the fault event. The driver module determines the storage address corresponding to the running data, and writes the running data to the corresponding storage address through the serial peripheral interface based on the storage method.
6. The method according to claim 5, characterized in that, When the storage method includes a dynamic rolling storage method and a fault event triggered storage method, and the corresponding flash memory includes a first storage area corresponding to the dynamic rolling storage method and a second storage area corresponding to the fault event triggered storage method, determining the storage address corresponding to the running data through the driver module includes: Based on the storage method, the target storage area for the running data is determined by the driver module; the target storage area is either the first storage area or the second storage area. Obtain the basic storage information of each storage block in the target storage area, and determine the target storage block based on the basic storage information of each storage block; Obtain the basic storage information of each storage page in the target storage block, and determine the target storage page based on the basic storage information of each storage page; wherein, the basic storage information includes the number of times running data is written, the total storage capacity, and the current remaining storage space; The storage address corresponding to the running data is determined based on the target storage area, the target storage block, and the target storage page.
7. The method according to claim 6, characterized in that, After writing the runtime data to the corresponding storage address via the serial peripheral interface based on the storage method, the method further includes: Based on the importance level of the operational data and the basic storage information of the target storage block, the erase priority of the target storage block in the dynamic priority queue is adjusted; wherein, the dynamic priority queue includes all storage blocks sorted by erase priority from high to low and the erase priority corresponding to each storage block; the importance level is determined based on the degree of correlation between the operational data and the safe operation of the vehicle, and the importance level and the degree of correlation are positively correlated; the erase priority is negatively correlated with the importance level, the total storage capacity and the current remaining storable space, and positively correlated with the number of writes to the target storage block; When the total remaining available storage space of the flash memory is less than the global threshold, an erase operation is performed according to the adjusted dynamic priority queue until the total remaining available storage space of the flash memory is greater than or equal to the global threshold. Before erasing any storage block, if there is running data in the storage block with an importance level higher than a preset threshold, the running data with an importance level higher than the preset threshold is backed up.
8. A diagnostic device, characterized in that, The diagnostic device is connected to the vehicle's onboard system, and the diagnostic device includes: The data acquisition module is used to acquire the current operating data of the power chassis domain control system from the microcontroller of the vehicle system and / or acquire relevant operating data from the flash memory of the vehicle system when a fault event occurs in the power chassis domain control system of the vehicle; wherein, the relevant operating data includes operating data within a preset time period before and after the fault event occurs; the microcontroller is used to collect the operating data of the power chassis domain control system and store the operating data in the flash memory; The fault diagnosis module is used to determine the fault diagnosis result based on the current operating data and / or the relevant operating data.
9. A data writing device, characterized in that, The device is used in a vehicle's in-vehicle system, and the device includes: a microcontroller and a flash memory; The microcontroller is used to collect the operating data of the vehicle's power chassis domain control system and write the operating data to the flash memory of the vehicle system through a serial peripheral interface. The flash memory is used to store the operating data of the power chassis domain control system.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the data processing method of any one of claims 1 to 3 or the data writing method of any one of claims 4 to 7.