Method and apparatus for real-time processing of ecu data stream, and electronic device

Abstract

The application discloses a kind of automobile ECU data stream real-time processing method, device and electronic equipment, is related to vehicle diagnostic technical field.The method comprises: receiving ECU original signal data and adding time stamp and source identification, generates data to be cached;According to the mapping table of diagnostic importance, determine priority, first priority data is written into high-frequency cache area, and second priority data is written into regular cache area;When the idle capacity of cache area is insufficient, the comprehensive value score of stored data is calculated by integrating access frequency, time decay factor and diagnostic importance score, and new data is written after the lowest score data is eliminated.The application retains key diagnostic data in limited cache space by hierarchical caching and multi-dimensional value elimination mechanism, guarantees data acquisition capability in offline scenario, and reduces response delay.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a method and electronic device for real-time processing of automotive ECU data streams. Background Technology

[0002] As automotive electronics become increasingly sophisticated, the number of ECUs (Electronic Control Units) within vehicles continues to rise, generating a wide variety and massive amount of signal data during operation. On-board diagnostic systems typically acquire this signal data, such as engine speed, vehicle speed, and fault codes, via the vehicle's communication bus. Common diagnostic protocol stacks often employ a polling method to periodically collect signals from the bus when reading this data.

[0003] When diagnostic scenarios place high demands on sampling frequency, such as requiring millisecond-level data acquisition intervals, existing solutions face the following problems. First, the transmission bandwidth of the vehicle communication bus is limited. Under high-frequency sampling conditions, the continuous transmission of large amounts of raw signal data on the bus can easily lead to excessive communication load, affecting the normal message exchange of other control units. Second, in the end-to-end path from signal data acquisition to the diagnostic device displaying the data, if the data flow process is not effectively optimized, the response delay may exceed acceptable limits, making it difficult to meet the real-time requirements of debugging or driver assistance scenarios. Third, some diagnostic tools rely on network connections to external servers to complete data processing. In environments where the network is unavailable, the ability to play back historical high-frequency data cannot be provided to users, and the availability of diagnostic functions is constrained by network conditions. Summary of the Invention

[0004] This application provides a method and electronic device for real-time processing of automotive ECU data streams, which can solve the problems of excessive communication load, large response delay, and offline unavailability caused by reliance on network connections in high-frequency sampling scenarios in the prior art. The technical solution is as follows: In a first aspect, embodiments of this application provide a real-time data stream processing method for an automotive ECU, the method comprising: The vehicle edge node receives raw signal data from at least one vehicle communication bus sent by each electronic control unit (ECU), adds a local receiving timestamp and source ECU identifier to each raw signal data, and generates data to be cached. Based on the preset diagnostic importance mapping table, determine the priority of each piece of data to be cached; When the free capacity of either the high-frequency cache or the regular cache is greater than or equal to a preset threshold, the data to be cached is written to the cache corresponding to the priority according to the priority. Specifically, the data to be cached with the first priority is written to the high-frequency cache, and the data to be cached with the second priority is written to the regular cache. The first priority is greater than the second priority. When the free capacity of either the high-frequency cache or the regular cache is less than the preset threshold, writing to that cache is paused, and the comprehensive value score of each piece of data is calculated based on the access frequency, time decay factor, and diagnostic importance score of each piece of data already stored in that cache. Remove the data with the lowest overall value score from the cache area to free up storage space, and write the data to be cached into the cache area.

[0005] Secondly, embodiments of this application provide a real-time data stream processing device for an automotive ECU, the device comprising: The receiving module is used to receive raw signal data sent by each electronic control unit (ECU) from at least one vehicle communication bus, add a local receiving timestamp and source ECU identifier to each piece of raw signal data, and generate data to be cached. The determination module is used to determine the priority of each piece of data to be cached based on a preset diagnostic importance mapping table; The writing module is used to write the data to be cached into the cache area corresponding to the priority when the free capacity of either the high-frequency cache area or the regular cache area is greater than or equal to a preset threshold, according to the priority. The data to be cached with the first priority is written into the high-frequency cache area, and the data to be cached with the second priority is written into the regular cache area. The first priority is greater than the second priority. The pause module is used to pause writing to the cache area when the free capacity of either the high-frequency cache area or the regular cache area is less than the preset threshold, and to calculate the comprehensive value score of each piece of data based on the access frequency, time decay factor and diagnostic importance score of each piece of data already stored in the cache area. The removal module is used to remove the data with the lowest comprehensive value score from the cache area to free up storage space, and write the data to be cached into the cache area.

[0006] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, embodiments of this application provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0008] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: This application utilizes vehicle edge nodes to complete signal data acquisition, caching, and hierarchical management locally. Diagnostic devices can directly obtain the required data from the edge nodes without relying on a network connection to a cloud server. This solves the problem that diagnostic tools are unusable in the absence of a network in existing technologies and ensures data acquisition capabilities in offline scenarios.

[0009] By setting a pre-defined diagnostic importance mapping table to determine the priority of each piece of data to be cached, the first priority data with higher diagnostic value is written into the high-frequency cache area, and the second priority data with lower diagnostic value is written into the regular cache area. This allows the diagnostic device to quickly obtain key signals from the high-frequency cache area when querying data, shortening the end-to-end data response path, helping to reduce response latency in high-frequency sampling scenarios, and meeting the diagnostic needs with high real-time requirements.

[0010] When cache space is insufficient, this application does not simply evict data based on time order or a single dimension. Instead, it calculates a comprehensive value score for each data item based on three dimensions: access frequency, time-depreciation factor, and diagnostic importance score. Data with the lowest value is then evicted based on this score. Specifically, the introduction of the time-depreciation factor reduces the value of outdated data over time; the introduction of the diagnostic importance score gives fault-related signals a higher retention weight; and the introduction of access frequency ensures that frequently accessed data has a longer retention time. These three factors work together to make the cache eviction results more closely reflect the actual data usage patterns in vehicle diagnostic scenarios. This achieves priority retention of critical diagnostic data within limited cache space, overcoming the shortcomings of conventional eviction strategies that do not consider the differences in data diagnostic value.

[0011] By performing data caching and priority management locally at the vehicle edge node, the need to transmit large amounts of raw data to the outside under high-frequency sampling conditions is reduced, alleviating the load pressure on the vehicle communication bus and external communication links, and reducing the impact of data transmission congestion on the normal message interaction of other control units. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a real-time data stream processing method for an automotive ECU provided in an embodiment of this application; Figure 3 This is a schematic diagram of the process for calculating the comprehensive value score provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a real-time data stream processing device for an automotive ECU provided in this application; Figure 5 This is a schematic diagram of a computer storage medium provided in this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] It should be noted that the real-time processing method for automotive ECU data streams provided in this application is generally executed by a diagnostic terminal, and correspondingly, the real-time processing device for automotive ECU data streams is generally installed in the target vehicle 102.

[0016] Figure 1 An exemplary system architecture is shown that can be applied to the real-time processing method or apparatus for automotive ECU data streams in this application.

[0017] Specifically, the system architecture includes: diagnostic terminal 100, cloud server 101, and target vehicle 102.

[0018] The diagnostic terminal 100 is an electronic device used for fault diagnosis and data reading of the target vehicle 102. In one embodiment, the diagnostic terminal 100 can be a handheld diagnostic instrument with a built-in diagnostic application, establishing a communication connection with the vehicle edge node in the target vehicle 102 via wired or wireless means. The handheld diagnostic instrument is equipped with a display screen, input buttons, or a touch screen. The technician selects the signal to be read or the diagnostic function to be performed through the operating interface. The diagnostic terminal 100 generates a corresponding subscription request message and sends the subscription request to the vehicle edge node in the target vehicle 102. In another embodiment, the diagnostic terminal 100 can be a tablet-type diagnostic device running vehicle diagnostic software. This device establishes a connection with the target vehicle 102 via wireless communication protocols such as WiFi or Bluetooth, sends a subscription request carrying the target signal identifier to the vehicle edge node, and receives signal data returned by the vehicle edge node. In yet another embodiment, the diagnostic terminal 100 can be a client device in a remote diagnostic platform. This client device communicates with a cloud server 101 via the Internet, and the cloud server 101 then forwards the subscription request to the vehicle edge node in the target vehicle 102, realizing remote diagnostic functionality. After receiving data returned by the vehicle edge node, the diagnostic terminal 100 presents the data to the operator in the form of numerical values, charts, or diagnostic reports. The diagnostic terminal 100 can also be configured to display a message indicating that the data is temporarily unavailable to the operator when it receives a null value or prompt message returned by the vehicle edge node, and re-initiate the subscription request according to a preset retry interval.

[0019] The cloud server 101 is a computing and storage device deployed in the cloud, used to receive, store, and manage vehicle signal data uploaded from vehicle edge nodes in the target vehicle 102. In one embodiment, the cloud server 101 consists of a server cluster composed of multiple servers, including a data receiving server, a data storage server, and a data management server. The data receiving server is responsible for receiving data synchronization messages sent by the vehicle edge nodes at preset intervals, parsing and verifying the messages, and forwarding the data to the data storage server after successful verification. The data storage server is configured with a cloud database, which can be a relational database or a distributed storage system, used to persistently store the signal data uploaded by the vehicle edge nodes. Each stored data record includes information such as signal type, signal value, source ECU identifier, and local reception timestamp. The data management server provides data query, data analysis, and data visualization functions, supporting the diagnostic terminal 100 or remote diagnostic platform to query historical signal data of a specified vehicle within a specified time period through an application programming interface. The cloud server 101 is also responsible for receiving the data to be resumed sent by the vehicle edge node in the order of timestamps after the vehicle edge node network is restored, writing the resumed data into the cloud database, and returning a confirmation message of successful synchronization to the vehicle edge node to ensure the eventual consistency between the cloud data and the local data of the vehicle edge node.

[0020] The target vehicle 102 is a vehicle under diagnosis equipped with multiple electronic control units (ECUs) and vehicle edge nodes. The target vehicle 102 is internally configured with an in-vehicle network, through which the multiple ECUs communicate. The in-vehicle network may include one or more in-vehicle communication protocols such as Controller Area Network (CAN), Local Area Network (LAN), FlexRay bus, or in-vehicle Ethernet. Each ECU is responsible for the control functions of different subsystems within the target vehicle 102, such as the engine control unit, transmission control unit, anti-lock braking system (ABS) control unit, body control unit, and air conditioning control unit. During operation, each ECU continuously generates signal data, including but not limited to engine speed, coolant temperature, vehicle speed, brake pressure, gear status, fault codes, window positions, and air conditioning temperature, and broadcasts this signal data through the in-vehicle network.

[0021] The target vehicle 102 also includes a vehicle edge node, which is an edge computing device deployed on the target vehicle 102. The vehicle edge node can be a standalone hardware module, connected to the vehicle network via an on-board diagnostic interface or other communication interfaces. Internally, the vehicle edge node is configured with a processor, cache memory, and a communication module. The processor performs computational tasks such as prioritizing signal data, calculating comprehensive value scores, writing and evicting data from the cache, querying data, synchronizing data, and dynamically adjusting capacity allocation ratios. The cache memory is divided into a high-frequency cache area and a regular cache area, used to store signal data written after processing by the processor. The cache memory can be implemented using volatile or non-volatile memory, such as dynamic random access memory or flash memory. The communication module includes a first communication interface for communicating with the vehicle network and a second communication interface for communicating with the cloud server 101. The first communication interface is used to receive signal data broadcast by various electronic control units from the vehicle network, and the second communication interface is used to establish a network connection with the cloud server 101 via a mobile communication network or wireless local area network to perform operations such as data synchronization and disaster recovery.

[0022] In one embodiment, the vehicle edge node can also be integrated into the telematics control unit or in-vehicle infotainment system of the target vehicle 102, reusing the processor, memory, and communication module of the control unit or system to implement the functions of the vehicle edge node, thereby reducing hardware costs. In another embodiment, the vehicle edge node can also be integrated with a vehicle gateway device, which performs data caching management functions for the vehicle edge node while realizing protocol conversion between different in-vehicle networks.

[0023] The diagnostic terminal 100, cloud server 101, and target vehicle 102 work together to form the operating environment for the real-time data stream processing method for automotive ECUs in this application. The vehicle edge nodes in the target vehicle 102 are responsible for collecting signal data from each electronic control unit in real time, performing hierarchical caching and dynamic capacity adjustment based on diagnostic importance scores, providing hierarchical query services to the diagnostic terminal 100, and simultaneously synchronizing data and performing disaster recovery and retransmission with the cloud server 101. The diagnostic terminal 100, as a data consumer, initiates subscription requests to the vehicle edge nodes and obtains the required signal data. The cloud server 101, as a data backup and analysis terminal, stores the complete data uploaded by the vehicle edge nodes and provides support for remote diagnostics and historical data backtracking.

[0024] It should be understood that Figure 1 The number of diagnostic terminals, networks, and servers shown is for illustrative purposes only. The number of diagnostic terminals, networks, and servers can be any number, depending on the implementation requirements.

[0025] The following will be combined with the appendix Figure 2This application provides a detailed description of the real-time processing method for automotive ECU data streams provided in its embodiments. The real-time processing device for automotive ECU data streams in these embodiments may be... Figure 1 The diagnostic terminal shown.

[0026] Please see Figure 2 This is a flowchart illustrating a real-time data stream processing method for an automotive ECU, as provided in this application embodiment. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. The vehicle edge node receives raw signal data from at least one vehicle communication bus sent by each electronic control unit (ECU), adds a local receiving timestamp and source ECU identifier to each raw signal data, and generates data to be cached.

[0027] The vehicle edge node receives raw signal data from at least one in-vehicle communication bus sent by various Electronic Control Units (ECUs). The in-vehicle communication bus can be a Controller Area Network (Controller Area Network) bus, a Local Area Network (LAN) bus, or a FlexRay bus. The vehicle edge node adds a local reception timestamp and a source ECU identifier to each piece of raw signal data, generating cached data. The local reception timestamp records the precise moment the vehicle edge node received the raw signal data, and the source ECU identifier indicates which ECU sent the raw signal data. By adding the local reception timestamp and source ECU identifier, each piece of cached data has time and source attributes, facilitating subsequent data management, querying, and tracing.

[0028] For example, a vehicle edge node receives an engine speed signal from the engine control unit (ECU) via the CAN bus. The original value of this signal is 2500 revolutions per minute. Upon receiving this signal, the vehicle edge node records the current system time as 10:55:54.123 milliseconds on July 2, 2026 as a local reception timestamp and records the ECU identifier as ECU_ENG_01. The vehicle edge node combines the above information to generate a cached data entry, which includes the signal value 2500, the timestamp 20260702105554123, and the source identifier ECU_ENG_01. Similarly, the vehicle edge node also receives a window position signal from the body control unit (ECU) via the LIN bus and adds a corresponding timestamp and source identifier to this signal, generating another cached data entry.

[0029] S2. Determine the priority of each piece of data to be cached based on the preset diagnostic importance mapping table.

[0030] The vehicle edge nodes determine the priority of each piece of data to be cached based on a pre-defined diagnostic importance mapping table. This mapping table, pre-stored in the vehicle edge nodes, records the correspondence between ECU identifiers, signal types, and priority levels. The mapping table contains at least two columns: one for signal type and the other for the corresponding priority level. Signal types can include fault-related signals, safety-related signals, and routine status signals. Fault-related signals are those directly related to vehicle fault diagnosis, such as fault codes and malfunction indicator light status. Safety-related signals are those directly related to vehicle driving safety, such as brake pressure, steering angle, and collision sensor signals. Routine status signals are those related to the vehicle's daily operating status, such as window position, air conditioning temperature, and audio volume. The first priority corresponds to fault-related and safety-related signals, while the second priority corresponds to routine status signals; the first priority is higher than the second priority.

[0031] S3. When the free capacity of any cache area in the high-frequency cache area or the regular cache area is greater than or equal to the preset threshold, the data to be cached is written to the cache area corresponding to the priority according to the priority.

[0032] After determining the priority of the data to be cached, the vehicle edge node needs to check the free capacity status of the high-frequency cache and the regular cache. When the free capacity of either the high-frequency cache or the regular cache is greater than or equal to a preset threshold, it indicates that the cache has sufficient storage space. The vehicle edge node then writes the data to be cached into the corresponding cache according to its priority. Specifically, data with the highest priority is written to the high-frequency cache, and data with the second highest priority is written to the regular cache. The specific value of the preset threshold can be configured according to actual application requirements; for example, the preset threshold can be set to 10% or 20% of the total cache capacity. By writing data of different priorities into different caches, data is classified and stored. High-priority critical data is centrally stored in the high-frequency cache, facilitating rapid reading and fault analysis by diagnostic equipment.

[0033] For example, suppose the total capacity of the high-frequency buffer is 100 megabytes, and the preset threshold is 10% of the total capacity, or 10 megabytes. If the current free capacity of the high-frequency buffer is 50 megabytes, which is greater than the preset threshold, the vehicle edge node writes the first-priority data to be cached into the high-frequency buffer. If the current free capacity of the regular buffer is 30 megabytes and the preset threshold is also 10 megabytes, which is greater than the preset threshold, the vehicle edge node writes the second-priority data to be cached into the regular buffer. Through this writing strategy, the first-priority critical data is always stored in the high-frequency buffer, and the second-priority regular data is stored in the regular buffer. The two types of data are physically isolated from each other and do not interfere with each other.

[0034] S4. When the free capacity of any cache in the high-frequency cache or the regular cache is less than the preset threshold, writing to that cache is paused. Based on the access frequency, time decay factor and diagnostic importance score of each piece of data already stored in that cache, the comprehensive value score of each piece of data is calculated.

[0035] When the free capacity of any cache area, whether high-frequency or regular, falls below a preset threshold, it indicates that the cache area's storage space is about to be exhausted, and the vehicle edge node suspends writing new data to that cache area. At this point, the vehicle edge node needs to evaluate the value of each piece of data already stored in the cache area to determine which data should be removed to free up storage space. The evaluation is based on data access frequency, time-degradation factor, and diagnostic importance score. Access frequency refers to how frequently data is read from the cache area, which can be obtained by counting the number of times the data is read within a preset time window. The time-degradation factor measures the freshness of the data; the longer the data resides in the cache area, the smaller its time-degradation factor, indicating lower data timeliness. The diagnostic importance score is a quantitative score determined based on data priority; first-priority data has a higher diagnostic importance score, and second-priority data has a lower diagnostic importance score. The vehicle edge node is weighted by access frequency (first weight), time-depreciation factor (second weight), and diagnostic importance score (third weight), and the weighted results of these three factors are summed to obtain the comprehensive value score of the data. The specific values ​​of the first, second, and third weights can be configured according to the actual application scenario. For example, the first weight can be set to 0.3, the second weight can be set to 0.3, and the third weight can be set to 0.4.

[0036] S5. Remove the data with the lowest comprehensive value score from the cache area to free up storage space, and write the data to be cached into the cache area.

[0037] After calculating the comprehensive value score of each piece of data in the cache, the vehicle edge node removes the data with the lowest comprehensive value score to free up storage space. The data with the lowest comprehensive value score indicates that it has the lowest value at the current stage, and removing it has the least impact on the overall system functionality. After freeing up storage space, the vehicle edge node writes the data to be cached into the cache, completing the data write operation. Through this value-driven data eviction mechanism, the vehicle edge node can prioritize retaining data with high diagnostic value, high access frequency, and high timeliness when cache space is scarce, ensuring that the cache always stores the most valuable data for vehicle diagnosis and fault analysis.

[0038] The real-time processing method for automotive ECU data streams provided in this embodiment divides the cache memory into a high-frequency cache area and a regular cache area, and determines the priority of each piece of data to be cached according to a diagnostic importance mapping table, thus achieving classified storage of data with different priorities. When cache space is tight, a comprehensive value score is calculated by comprehensively evaluating the data's access frequency, time decay factor, and diagnostic importance score, and the data with the lowest comprehensive value score is removed, realizing a value-driven data eviction mechanism. This ensures that the cache area always retains the data most valuable to vehicle diagnosis and fault analysis, improving the utilization efficiency of cache storage space and the response speed of data retrieval.

[0039] In one possible embodiment, the cache memory further includes an archive cache area; The data with the lowest overall value score removed from this cache includes: S51. When the score of the data with the lowest comprehensive value score is higher than the preset archiving threshold, the data is moved from the cache area where the data is currently located to the archive cache area.

[0040] Once the vehicle edge node identifies the data with the lowest overall value score, it first compares that score with a preset archiving threshold. The preset archiving threshold is a pre-configured scoring threshold used to determine whether data is worth archiving. When the score of the data with the lowest overall value score is higher than the preset archiving threshold, it indicates that although the data ranks low in the current cache, its overall value is still relatively high, and directly discarding it might result in the permanent loss of valuable information. In this case, the vehicle edge node does not discard the data directly, but instead migrates it from its current cache to the archive cache. The migration process is as follows: the vehicle edge node reads the complete content of the data from the current cache, writes the data to the archive cache in the cache storage, and after successful writing, deletes the data from the current cache, thereby freeing up storage space in the current cache.

[0041] In one example, assume the preset archiving threshold is set to 30. Data D in the high-frequency cache has a comprehensive value score of 35, the lowest score in the high-frequency cache, but higher than the preset archiving threshold of 30. The vehicle edge node determines that data D's comprehensive value score is higher than the preset archiving threshold, therefore it does not discard data D, but migrates data D from the high-frequency cache to the archive cache. After the migration, the storage space originally occupied by data D is released in the high-frequency cache, and the vehicle edge node can continue to write new data to be cached into the high-frequency cache. Data D remains in the archive cache, which is also part of the cache memory, and its storage space is managed uniformly by the vehicle edge node. If this data needs to be retrieved during subsequent diagnostics, the vehicle edge node can retrieve and read it from the archive cache.

[0042] S52. When the score of the data with the lowest comprehensive value score is lower than or equal to the preset archiving threshold, the data is discarded directly.

[0043] When the score of the data with the lowest overall value score is lower than or equal to the preset archiving threshold, it indicates that the overall value of the data is already at a low level. Its diagnostic importance, access frequency, and timeliness have all significantly decreased, making long-term storage of this data meaningless. In this case, the vehicle edge node directly discards the data and does not migrate it to the archiving cache. The specific process of discarding is as follows: the vehicle edge node marks the storage space occupied by the data in the current cache as available space, and subsequent new data can overwrite this space. The discarded data is no longer retained in any area of ​​the cache memory, achieving complete release of storage space.

[0044] Continuing the example from step S51, assume that the overall value score of data E in the regular cache is 15, which is the lowest score in the regular cache, and 15 is lower than the preset archiving threshold of 30. The vehicle edge node determines that the overall value score of data E is lower than the preset archiving threshold and directly discards data E without migrating it to the archive cache. After data E is discarded, the storage space it occupied is released, and the vehicle edge node writes new data to be cached into the regular cache. Similarly, if the overall value score of data F is exactly equal to the preset archiving threshold of 30, the vehicle edge node also directly discards data F, because the judgment condition for the preset archiving threshold is migration when it is higher than the threshold and discarding when it is lower than or equal to the threshold; the case where the score is equal to the threshold is classified as discarding.

[0045] A tiered eviction mechanism was introduced for vehicle edge nodes during cache space-constrained eviction processes. The archive cache, an independently partitioned area within the cache memory, works in conjunction with the high-frequency and regular caches. Data with high overall value scores but still requiring removal from the current cache is migrated to the archive cache for long-term storage, preventing the permanent loss of valuable data and providing a data foundation for subsequent in-depth fault analysis and historical data backtracking. Data with low overall value scores is directly discarded to free up storage space, preventing the archive cache from quickly filling up with low-value data. This tiered eviction strategy maximizes data value retention under the constraints of limited cache memory resources, while simultaneously ensuring efficient operation of the current cache and secure archiving of historical data.

[0046] In one optional implementation, the size of the three buffers can be determined based on the actual vehicle configuration and data characteristics. First, the capacity of the high-frequency buffer can be estimated based on the number of Electronic Control Units (ECUs) configured in the vehicle and the number of signal types marked as first priority in the diagnostic importance mapping table. This ensures that the high-frequency buffer can accommodate the amount of data generated by all fault-related and safety-related signals within a preset acquisition cycle, with a certain buffer margin. Second, the capacity of the regular buffer can be estimated based on the number of second-priority regular status signals in the vehicle and their data generation rate. Typically, the capacity of the regular buffer is larger than that of the high-frequency buffer to handle the large variety and quantity of regular status signals. Finally, the capacity of the archive buffer can be estimated based on the preset data archiving retention time and the average amount of data migrated from the high-frequency and regular buffers to the archive buffer per unit time. This ensures that the archive buffer can store valuable historical data generated within at least one complete driving cycle or one preset diagnostic cycle. In actual deployment, the capacity configuration of the above three buffers can be preset during vehicle edge node initialization according to the specific vehicle model and diagnostic requirements. It can also be dynamically adjusted subsequently based on the cache hit rate and elimination frequency during actual operation.

[0047] In one possible embodiment, the priority of each piece of data to be cached is determined according to a preset diagnostic importance mapping table, including: S21. Obtain the source ECU identifier and signal type corresponding to the data to be cached.

[0048] After generating the data to be cached, the vehicle edge node extracts the source ECU identifier and signal type from the data. The source ECU identifier, added to the original signal data in step S1, indicates which electronic control unit (ECU) issued the data. The signal type is an attribute carried by the original signal data itself, indicating the physical quantity or state category represented by the signal, such as engine speed, coolant temperature, brake pressure, fault code, collision sensor status, etc. The vehicle edge node obtains this information by parsing the data structure of the data to be cached and reading the source ECU identifier and signal type fields. The combination of the source ECU identifier and signal type uniquely determines the source and nature of the data to be cached, providing an accurate matching basis for subsequent priority queries.

[0049] S22. Query the preset diagnostic importance mapping table, which stores the correspondence between ECU identifier, signal type and priority level.

[0050] After obtaining the source ECU identifier and signal type of the data to be cached, the vehicle edge node queries a pre-defined diagnostic importance mapping table. The diagnostic importance mapping table is a pre-stored data table in the vehicle edge node, containing the correspondence between ECU identifiers, signal types, and priority levels. Each row in the diagnostic importance mapping table corresponds to a mapping relationship, and each row contains at least three fields: ECU identifier, signal type, and priority level. Using the source ECU identifier and signal type obtained in step S21 as query conditions, the vehicle edge node performs a matching search in the diagnostic importance mapping table. Once it finds a row that matches the query conditions, it reads the priority level field from that row to determine the priority of the data to be cached. The diagnostic importance mapping table can be set by technicians during vehicle edge node deployment based on the specific vehicle configuration and diagnostic requirements, or it can be adjusted remotely during vehicle operation.

[0051] S23. When the signal type corresponding to the data to be cached is a fault-related signal or a safety-related signal, the priority is set to the highest priority.

[0052] When the signal type matched by the vehicle edge node in step S22 is a fault-related signal or a safety-related signal, the priority of the data to be cached is determined to be the highest priority. Fault-related signals refer to signal types directly related to vehicle fault diagnosis, specifically including fault codes, fault indicator light status, fault counters, etc. Safety-related signals refer to signal types directly related to vehicle driving safety, specifically including brake pressure, steering angle, collision sensor signals, airbag status, electronic stability program status, etc. Fault-related signals and safety-related signals are pre-configured as the highest priority in the diagnostic importance mapping table because these two types of signals are directly related to the safe operation and fault diagnosis of the vehicle, and need to be read and processed first during the diagnostic process. The highest priority data will be written to the high-frequency cache area in subsequent cache writing steps, enjoying priority storage space and the fastest read response speed.

[0053] In one possible embodiment, see Figure 3 As shown, Figure 3 This is a flowchart illustrating the calculation of the comprehensive value score provided in an embodiment of this application, which specifically includes the following steps: S41. Obtain the priority corresponding to each data point as the base score value for the diagnostic importance score.

[0054] The vehicle edge node first obtains the priority corresponding to each piece of stored data and converts this priority into a base score value for diagnostic importance scoring. Diagnostic importance scoring is a numerical indicator used to quantify the diagnostic value of data; its base score value is directly derived from the priority level determined in step S2. The correspondence between priority and base score value can be pre-configured; for example, the base score value corresponding to the highest priority can be set to 100 points, and the base score value corresponding to the normal priority can be set to 50 points. The higher the base score value, the greater the reference value of the data for vehicle diagnosis under normal conditions. The vehicle edge node records a diagnostic importance score field for each piece of stored data in the cache; initially, the value of this field is the base score value.

[0055] S42. When a diagnostic fault code is detected to be activated, query the preset fault code and signal association table to determine the target signal type and source ECU identifier associated with the diagnostic fault code.

[0056] When a vehicle edge node detects that a diagnostic fault code has been activated, it triggers a dynamic adjustment process for the diagnostic importance score. A diagnostic fault code is a fault identification code generated by the vehicle's own diagnostic system when an anomaly is detected. The activation of a diagnostic fault code indicates a specific fault in the vehicle. After detecting the activation of a diagnostic fault code, the vehicle edge node queries a pre-stored fault code and signal association table. This table is a pre-stored data table within the vehicle edge node, containing the associations between diagnostic fault codes and target signal types and source ECU identifiers. Each association records one or more related signals corresponding to a diagnostic fault code; these related signals are key data to focus on when troubleshooting and locating the cause of the fault. The vehicle edge node uses the currently activated diagnostic fault code as a query condition to match and search the fault code and signal association table to determine the target signal type and source ECU identifier associated with that diagnostic fault code.

[0057] S43. Based on the target signal type and the source ECU identifier, locate the matching stored data in the buffer area, and increase the diagnostic importance score of the successfully matched stored data from the basic score value to the preset maximum score value; if the maximum score value is greater than the basic score value, the increased diagnostic importance score will be restored to the basic score value after the diagnostic fault code is cleared.

[0058] After determining the target signal type and source ECU identifier, the vehicle edge node locates matching stored data in the cache based on these two pieces of information. Specifically, the vehicle edge node iterates through all stored data in the cache, comparing the source ECU identifier and signal type of each data point with the target source ECU identifier and target signal type to find a perfect match. For successfully matched stored data, the vehicle edge node increases its diagnostic importance score from the base score to a preset maximum score. The maximum score is a pre-set upper limit, for example, set to 200 points. This score is greater than all base scores to ensure that the increased diagnostic importance score has an absolute advantage in the overall value score calculation. The increased diagnostic importance score is only valid during the period when the diagnostic fault code is active. When the vehicle edge node detects that the diagnostic fault code has been cleared, it restores the diagnostic importance score corresponding to the matching data to the base score. This dynamic adjustment mechanism ensures that data closely related to the currently active fault receives higher retention priority during the fault's duration, preventing it from being discarded.

[0059] S44. Calculate the access frequency of each piece of data in the cache and the time decay factor corresponding to each piece of data.

[0060] Vehicle edge nodes track the access frequency of each data item in the cache and calculate the corresponding time-depreciation factor for each data item. Access frequency refers to how frequently data is read from the cache. Each vehicle edge node can maintain an access counter for each data item, incrementing the counter by 1 for each read operation. The vehicle edge node can count the number of accesses within a preset time window, such as the number of accesses within the last hour, as the access frequency for that data. The time-depreciation factor measures the freshness of the data. It is negatively correlated with the data's residence time in the cache; the shorter the residence time, the larger the time-depreciation factor, indicating fresher data; conversely, the longer the residence time, the smaller the time-depreciation factor, indicating lower timeliness. The time-depreciation factor can be calculated using a negative exponential decay model, for example, as: Time-depreciation factor = e^(-λ·Δt), where Δt is the data's residence time in the cache, λ is the decay coefficient (the value of λ is set according to the data's priority; higher priority results in smaller λ), and e is a natural constant. The value of λ can be set according to the priority of the data. The λ value of the highest priority data is smaller, so that the decay rate of the time-related decay factor of the high priority data is slower and can be retained in the cache for a longer time.

[0061] S45. The comprehensive value score of the data is obtained by weighting and summing the access frequency, time decay factor and diagnostic importance score.

[0062] After obtaining the access frequency, timeliness decay factor, and diagnostic importance score for each piece of data, the vehicle edge node performs a weighted sum of these three indicators to obtain a comprehensive value score for that data. The specific weighted summation method is as follows: multiply the access frequency by a first weight, the timeliness decay factor by a second weight, and the diagnostic importance score by a third weight, then add the three products together. The specific values ​​of the first, second, and third weights can be configured according to actual application needs, and their sum is 1.0. For example, the first weight can be set to 0.2, the second weight to 0.2, and the third weight to 0.6, making the diagnostic importance score dominate the comprehensive value score. Through weighted summation, the vehicle edge node integrates information from the three dimensions of access frequency, timeliness, and diagnostic value into a comprehensive value score. The higher the comprehensive value score, the more worthwhile the data is to retain at the current stage.

[0063] In one possible embodiment, the method further includes: S6. Receive a subscription request sent by the vehicle diagnostic terminal. The subscription request carries a target signal identifier, which includes at least the target signal type and the source ECU identifier.

[0064] The vehicle edge node receives a subscription request from the vehicle diagnostic terminal. The vehicle diagnostic terminal is a diagnostic device used by repair personnel or diagnostic engineers, such as a handheld diagnostic tool, tablet diagnostic device, or remote diagnostic platform. Communication between the vehicle diagnostic terminal and the vehicle edge node can be via wired or wireless connections. Wired connections can be made through an onboard diagnostic interface, while wireless connections can be made via Wi-Fi or Bluetooth. The subscription request carries a target signal identifier, which indicates which specific signal data the vehicle diagnostic terminal needs to retrieve. The target signal identifier includes at least two information fields: target signal type and source ECU identifier. The target signal type specifies the category of the signal to be queried, such as engine speed, coolant temperature, brake pressure, or fault code. The source ECU identifier indicates which electronic control unit in the vehicle issued the signal. Through the combination of the target signal type and the source ECU identifier, the vehicle edge node can uniquely identify the data object requested by the vehicle diagnostic terminal.

[0065] S7. Based on the target signal identifier, first check if there is any matching latest data in the high-frequency buffer. If it exists, read it from the high-frequency buffer and return it.

[0066] After parsing the target signal identifier, the vehicle edge node prioritizes querying the high-frequency buffer for matching, up-to-date data. The high-frequency buffer stores first-priority data, namely fault-related signals and safety-related signals, which have the highest diagnostic value. The reason for prioritizing the high-frequency buffer is that the data there is crucial for vehicle diagnostics. If the target data exists in the high-frequency buffer, the edge node can return it to the vehicle diagnostic terminal as quickly as possible, improving diagnostic efficiency. The query process is as follows: the edge node iterates through all the data stored in the high-frequency buffer, comparing the source ECU identifier and signal type of each data entry with the target signal type and source ECU identifier in the target signal identifier. If a complete match is found, it further determines whether the data is the latest. Latest data refers to data with the latest local reception timestamp in the high-frequency buffer; that is, the data is the latest record belonging to that signal type in the high-frequency buffer. If matching, up-to-date data exists in the high-frequency buffer, the edge node reads the complete content of the data from the buffer and returns it to the vehicle diagnostic terminal.

[0067] S8. If the latest matching data is not found in the high-frequency cache, query and read it from the regular cache and return it.

[0068] If no matching data is found in the high-frequency buffer, the vehicle edge node continues its search from the regular buffer. There are two scenarios where no matching data is found in the high-frequency buffer: one is that the signal type corresponding to the target signal identifier is not of first priority, so its data is always written to the regular buffer instead of the high-frequency buffer; the other is that although the signal type corresponding to the target signal identifier is of first priority, its data in the high-frequency buffer has been eliminated or migrated. In this case, the vehicle edge node expands its search to the regular buffer. The regular buffer stores second-priority data, i.e., regular status signals. The specific search process is similar to step S7: the vehicle edge node traverses all the data stored in the regular buffer, compares the source ECU identifier and signal type of each data with the target signal identifier, finds matching data, selects the one with the latest local receiving timestamp as the latest data, reads it from the regular buffer, and returns it to the vehicle diagnostic terminal. Although the search speed of the regular buffer is slightly lower than that of the high-frequency buffer, it is still sufficient to meet diagnostic needs.

[0069] S9. If no matching data is found in either the high-frequency buffer or the regular buffer, return a null value or a prompt message to the vehicle diagnostic terminal.

[0070] If the vehicle edge node fails to find matching data in both the high-frequency cache and the regular cache, it indicates that the requested signal data is not currently stored in the cache. Possible reasons for this include: the signal type data has not yet been received and cached by the vehicle edge node; the signal type data has been evicted and not migrated to the archive cache; or the signal type data was discarded directly because its overall value score is below a preset archiving threshold. In this case, the vehicle edge node returns a null value or a prompt message to the vehicle diagnostic terminal. A null value is a specific marker indicating that the data does not exist; upon receiving a null value, the vehicle diagnostic terminal can identify that no data is currently available. A prompt message is a text description used to inform the vehicle diagnostic terminal that the currently requested data does not exist in the cache; for example, it could return the prompt message "The requested signal data is temporarily unavailable." After receiving a null value or a prompt message, the vehicle diagnostic terminal can wait for a period of time and then re-initiate the subscription request, or obtain the signal data through other diagnostic methods.

[0071] The vehicle edge node provides a hierarchical data subscription service to the vehicle diagnostic terminal. Upon receiving a subscription request, the edge node searches for the latest matching data level by level, prioritizing the high-frequency cache and then the regular cache. This fully leverages the high-frequency cache's advantages of fast response and high data value, ensuring the diagnostic equipment can obtain the most critical data in the shortest possible time. If neither cache level matches, the edge node promptly returns a null value or a warning message, preventing the diagnostic equipment from waiting for extended periods. This hierarchical query mechanism, combined with the aforementioned partitioned storage and value-driven eviction strategy, centrally stores high-priority critical data in the high-frequency cache, ensuring priority matching during queries. This forms a complete closed loop from data writing and eviction management to data retrieval, effectively improving the efficiency and accuracy of data retrieval during vehicle diagnostics.

[0072] In one possible embodiment, it also includes: A1. Under normal operating conditions, the vehicle edge node synchronizes the data in the high-frequency cache and the regular cache to the external cloud server according to a preset period, and records the timestamp of the last successful synchronization.

[0073] Under normal operating conditions, the vehicle edge node synchronizes data from its high-frequency buffer and regular buffer to an external cloud server at preset intervals, and records the timestamp of the last successful synchronization. Normal operating conditions mean that the network connection between the vehicle edge node and the cloud server is normal, and the vehicle edge node is in a normal data reception and buffer management state. The preset interval is a pre-configured time interval, for example, it can be set to synchronize every 5 minutes. The specific synchronization process is as follows: at the end of each preset interval, the vehicle edge node packages all currently stored data in the high-frequency buffer and regular buffer into a data synchronization message and sends it to the cloud server via the network connection. After receiving the data synchronization message, the cloud server stores the data in its cloud database and returns a synchronization success confirmation message to the vehicle edge node. After receiving the confirmation message, the vehicle edge node records the current timestamp as the timestamp of the last successful synchronization. This timestamp is persistently saved for determining data resumption after subsequent network interruption recovery.

[0074] For example, the vehicle edge node is configured to synchronize data every 5 minutes. At 11:15:00 on July 2, 2026, the vehicle edge node performs its 12th data synchronization operation, packaging 3 data entries from the high-frequency cache and 8 data entries from the regular cache and sending them to the cloud server. After successfully receiving and storing the data, the cloud server returns a synchronization success confirmation message to the vehicle edge node. The vehicle edge node records the timestamp of the last successful synchronization as 11:15:00 on July 2, 2026. At 11:20:00 on July 2, 2026, the vehicle edge node continues to perform its 13th data synchronization, updating the timestamp of the last successful synchronization to 11:20:00 on July 2, 2026. Through this method, the vehicle edge node always maintains an accurate latest synchronization time, providing a time benchmark for subsequent disaster recovery.

[0075] A2. Network connection status between vehicle edge node monitoring and cloud server.

[0076] Vehicle edge nodes continuously monitor the network connection status with the cloud server. This monitoring can employ a combination of active probing and passive monitoring. Active probing involves the vehicle edge node sending heartbeat packets or probe messages to the cloud server at a preset probing period. If a response is received from the cloud server within a preset timeout period, the network connection is considered normal; if no response is received multiple times consecutively, the network connection is considered interrupted. Passive monitoring involves the vehicle edge node sensing the network connection status through state change events in the underlying network protocol stack. For example, when the network interface status changes to disconnected, the vehicle edge node can directly determine that the network connection is interrupted. The vehicle edge node maintains a network connection status flag in real time; this flag indicates a normal state when the network connection is normal, and an interrupted state when the network connection is interrupted.

[0077] For example, the vehicle edge node is configured to send a heartbeat packet to the cloud server every 30 seconds, with a timeout of 5 seconds. Under normal conditions, the vehicle edge node sends a heartbeat packet every 30 seconds, and the cloud server responds within 2 seconds, maintaining the vehicle edge node's network connection status as normal. At a certain point, if the vehicle edge node sends three consecutive heartbeat packets without receiving a response from the cloud server, and the cumulative timeout exceeds 15 seconds, the vehicle edge node determines that the network connection is interrupted and updates the network connection status flag to an interrupted state. As another example, if the vehicle edge node connects to the cloud server via a wireless network module, and the wireless network module detects a signal loss event, the underlying network protocol stack triggers a network interruption event. Upon receiving this event notification, the vehicle edge node directly updates its network connection status flag to an interrupted state.

[0078] A3. When a network connection interruption is detected, switch to local disaster recovery mode.

[0079] When a vehicle edge node detects a network connection interruption, it switches to local disaster recovery mode. Local disaster recovery mode is a special operating mode activated by the vehicle edge node when the network is unavailable. Its core objective is to ensure that critical diagnostic data is not lost during network outages by sacrificing storage space for regular data. When the vehicle edge node detects that the network connection status flag has changed from normal to interrupted, it immediately triggers a mode switching operation, marks the current operating mode as local disaster recovery mode, and begins executing a series of data management strategies under local disaster recovery mode.

[0080] For example, the vehicle edge node detected a network connection interruption with the cloud server at 11:25:00 on July 2, 2026, with the last successful synchronization timestamp being 11:20:00 on July 2, 2026. The vehicle edge node immediately switched its operating mode to local disaster recovery mode and recorded the disaster recovery mode activation timestamp. From this moment on, the vehicle edge node no longer attempts to send data synchronization messages to the cloud server, but instead enables localized data protection strategies to ensure that critical data generated during the network outage is not discarded due to insufficient cache space.

[0081] A4. In local disaster recovery mode, the vehicle edge node suspends data writing to the regular cache area. For the received data to be cached, when the diagnostic importance score of the data to be cached is higher than the preset score threshold, the data to be cached is written to the high-frequency cache area, and historical data with diagnostic importance scores lower than the preset score threshold in both the high-frequency cache area and the regular cache area are cleared.

[0082] In local disaster recovery mode, vehicle edge nodes implement a localized data protection strategy, which includes three aspects: pausing write operations, selective write operations, and clearing low-value data. First, vehicle edge nodes pause data writing to the regular cache. In local disaster recovery mode, due to network interruptions preventing data synchronization to the cloud server, the total remaining space in the cache storage is limited. To prioritize the storage of critical diagnostic data, vehicle edge nodes no longer write newly received data to be cached to the regular cache; the regular cache only retains data stored before the mode switch. Second, for received data to be cached, vehicle edge nodes determine whether its diagnostic importance score is higher than a preset score threshold. The preset score threshold is a pre-configured score threshold value, which can be set to be consistent with the base score value corresponding to the highest priority in the aforementioned steps, for example, set to 100 points. When the diagnostic importance score of the data to be cached is higher than the preset score threshold, it indicates that the data is critical diagnostic data, and the vehicle edge node writes the data to be cached to the high-frequency cache. If the high-frequency cache space is insufficient, the data with the lowest comprehensive value score is evicted from the high-frequency cache according to the comprehensive value score elimination mechanism in step S5, freeing up space before writing. Third, the vehicle edge node clears historical data with diagnostic importance scores below a preset threshold from both the high-frequency cache and the regular cache. This clearing operation involves directly discarding stored data with diagnostic importance scores below the preset threshold, freeing up storage space for storing newly received critical data. Through these three strategies, the vehicle edge node maximizes storage space release in local disaster recovery mode, ensuring that high-value diagnostic data can be continuously written to and retained.

[0083] For example, in local disaster recovery mode, the vehicle edge node has a preset scoring threshold of 100 points. The vehicle edge node receives a piece of data to be cached; its signal type is engine speed, and the source ECU is identified as ECU_ENG_01. This data is determined to be of the highest priority in step S2, and its base score for diagnostic importance is 100 points, which is exactly equal to the preset scoring threshold. Since the preset scoring threshold is determined by writing only when the score is higher than the threshold, the case where the score equals the threshold is not within the writing range. Therefore, this engine speed data is not written to the high-frequency cache. The vehicle edge node receives another piece of data to be cached; its signal type is a fault code, and the source ECU is identified as ECU_ENG_01. This data is also of the highest priority, but at this time, diagnostic fault code P0301 is active. According to the dynamic adjustment mechanism in step S43, the diagnostic importance score of this data is increased to 200 points, which is higher than the preset scoring threshold of 100 points. The vehicle edge node writes this fault code data to the high-frequency cache. Meanwhile, the vehicle edge node traverses the stored data in the high-frequency cache and the regular cache, finds data with a diagnostic importance score of less than 100. For example, if the diagnostic importance score of a window position data in the regular cache is 50, which is lower than the preset score threshold, the vehicle edge node will remove the window position data from the regular cache and release the storage space it occupies.

[0084] A5. When the network connection is detected to be restored, the vehicle edge node obtains the timestamp of the last successful synchronization, filters out data with timestamps later than that timestamp from the high-frequency cache, and synchronizes the filtered data to the cloud server one by one in the order of timestamps.

[0085] Once the vehicle edge node detects that the network connection has been restored, it executes the data recovery and synchronization process. The vehicle edge node first obtains the timestamp of the last successful synchronization recorded in step A1. This timestamp identifies the latest time point of the data stored in the cloud server. The vehicle edge node then filters data with timestamps later than this timestamp from the high-frequency buffer, i.e., data newly generated after the last successful synchronization and still retained in the high-frequency buffer. The filtering is based on the local reception timestamp of each data item, which was added when the data to be cached was generated in step S1. The vehicle edge node sorts the filtered data according to the order of its timestamps and sends each data item to the cloud server for synchronization, starting with the earliest data. After receiving each data item, the cloud server stores it in the cloud database and returns a confirmation message of successful synchronization. During the synchronization process, the vehicle edge node can record the synchronization status of each data item. If the synchronization of a data item fails, it can temporarily store the data and retry it later. Once all the selected data has been synchronized, the vehicle edge node updates the timestamp of the last successful synchronization to the current synchronization completion time, and switches back from local disaster recovery mode to normal operation, restoring data writing to the regular cache and the normal periodic synchronization mechanism.

[0086] Following the examples in steps A3 and A4, the vehicle edge node detected network connection recovery at 11:35:00 on July 2, 2026, with the last successful synchronization timestamp being 11:20:00 on July 2, 2026. The vehicle edge node filters data from the high-frequency buffer whose local received timestamp is later than 11:20:00 on July 2, 2026. Assuming the filtering result is 5 data entries, their timestamps are 11:21:15 on July 2, 2026, 11:23:40 on July 2, 2026, 11:25:10 on July 2, 2026, 11:28:05 on July 2, 2026, and 11:32:50 on July 2, 2026. The vehicle edge nodes synchronize data to the cloud server in chronological order, starting with data at 11:21:15 AM on July 2, 2026. Once the cloud server confirms successful reception, the next data entry is synchronized, continuing until all five data entries are synchronized. After synchronization is complete, the vehicle edge nodes update the timestamp of the last successful synchronization to 11:35:00 AM on July 2, 2026, exit local disaster recovery mode, switch back to normal operation, and resume regular data writing to the cache and the 5-minute periodic synchronization function.

[0087] In one possible embodiment, the method further includes: B1. Vehicle edge nodes acquire the current operating status information of the vehicle, which includes at least the vehicle speed, gear status, and whether there are active diagnostic fault codes.

[0088] The vehicle edge node acquires the vehicle's current operating status information. This operating status information is a set of key parameters collected in real-time from the vehicle bus by the vehicle edge node, characterizing the vehicle's current driving and health status. The operating status information includes at least vehicle speed, gear position, and the presence of active diagnostic fault codes. Vehicle speed can be obtained from the vehicle speed sensor signal or the speed signal emitted by the anti-lock braking system control unit; gear position can be obtained from the gear signal emitted by the transmission control unit; and the presence of active diagnostic fault codes can be determined by querying the diagnostic fault code activation status flag maintained internally by the vehicle edge node. Before each dynamic adjustment judgment, the vehicle edge node first collects the above three operating status information items as input for subsequent trigger condition judgments.

[0089] For example, at 11:30:00 on July 2, 2026, the vehicle edge node executes a dynamic adjustment judgment process. First, it reads the current vehicle speed signal from the CAN bus, obtaining a speed of 85 km / h. It then reads the gear position signal from the transmission control unit, finding the current gear to be drive (D). Finally, it checks the internally maintained diagnostic fault code status table and finds that diagnostic fault code P0301 is active. The vehicle edge node summarizes these three pieces of information into its current operating status information for use in subsequent step B2. At another moment, the vehicle edge node reads a vehicle speed of 0 km / h, a gear in park (P), and no active diagnostic fault codes. This operating status information indicates that the vehicle is in a stationary and fault-free normal state.

[0090] B2. Determine whether the operating status information meets the preset dynamic adjustment trigger conditions. The dynamic adjustment trigger conditions are: the existence of an active diagnostic fault code, or the vehicle speed exceeding the preset vehicle speed threshold.

[0091] The vehicle edge node determines whether the operating status information obtained in step B1 meets the preset dynamic adjustment trigger conditions. The dynamic adjustment trigger conditions are a set of pre-configured judgment rules in the vehicle edge node, used to determine whether to initiate dynamic adjustment of the buffer capacity allocation ratio. Specifically, the dynamic adjustment trigger conditions are: the presence of an active diagnostic fault code, or the vehicle speed exceeding a preset speed threshold. Meeting either of these conditions determines that the operating status information meets the dynamic adjustment trigger conditions. The preset speed threshold is a pre-set speed threshold value, which can be configured according to the vehicle's diagnostic needs, for example, set to 60 km / h or 80 km / h. When the vehicle is traveling at high speed, the amount of safety-related signal data generated by the vehicle increases significantly, requiring more storage space to be allocated to the high-frequency buffer; when the vehicle has an active diagnostic fault code, it is necessary to prioritize storing key data related to fault diagnosis, also requiring more storage space to be allocated to the high-frequency buffer. The design of the dynamic adjustment trigger conditions is based on these two typical scenarios to ensure that key data receives sufficient storage resources.

[0092] For example, the preset vehicle speed threshold is set to 80 kilometers per hour. The operating status information obtained by the vehicle edge node in step B1 is a vehicle speed of 85 kilometers per hour, gear in D, and diagnostic fault code P0301 activated. First, it checks if an activated diagnostic fault code exists; the result is yes, so the condition is met. Then, it checks if the vehicle speed exceeds 80 kilometers per hour; the result is also yes, so this condition is also met. Since at least one of the two conditions is met, the vehicle edge node determines that the operating status information meets the dynamic adjustment trigger condition. As another example, the operating status information obtained by the vehicle edge node is a vehicle speed of 40 kilometers per hour, gear in D, and no activated diagnostic fault code. It checks if an activated diagnostic fault code exists; the result is no. It checks if the vehicle speed exceeds 80 kilometers per hour; the result is no. Since neither condition is met, the vehicle edge node determines that the operating status information does not meet the dynamic adjustment trigger condition.

[0093] B3. When the running status information meets the dynamic adjustment triggering conditions, the target capacity allocation ratio is determined as the first allocation ratio, in which the capacity ratio of the high-frequency cache area is greater than that of the regular cache area.

[0094] When the operating status information in step B2 meets the dynamic adjustment triggering conditions, the vehicle edge node determines the target capacity allocation ratio as the first allocation ratio. The first allocation ratio is a capacity allocation scheme for fault diagnosis or high-speed driving scenarios, where the capacity proportion of the high-frequency buffer is greater than that of the conventional buffer. The specific value of the first allocation ratio can be pre-configured; for example, the capacity proportion of the high-frequency buffer can be set to 80% of the total cache memory capacity, and the capacity proportion of the conventional buffer can be set to 20%. A larger capacity proportion for the high-frequency buffer means that during fault diagnosis or high-speed driving, the vehicle edge node can provide more storage space for critical data such as fault-related signals and safety-related signals, reducing the probability of critical data being discarded due to insufficient space, thereby ensuring that diagnostic equipment can obtain a complete sequence of critical data upon access.

[0095] For example, the total capacity of the cache memory is 1000 megabytes, and the first allocation ratio is configured as 80% for the high-frequency cache and 20% for the regular cache. In step B2, the vehicle edge node determines that the operating status information meets the dynamic adjustment trigger condition and sets the target capacity allocation ratio as the first allocation ratio. At this time, the target capacity of the high-frequency cache is 1000 megabytes multiplied by 80%, which equals 800 megabytes, and the target capacity of the regular cache is 1000 megabytes multiplied by 20%, which equals 200 megabytes. During fault diagnosis or high-speed driving, the high-frequency cache obtains 800 megabytes of storage space, which is much larger than the 200 megabytes of the regular cache, and can accommodate more critical diagnostic data.

[0096] B4. When the running status information does not meet the dynamic adjustment triggering conditions, the target capacity allocation ratio is determined to be the second allocation ratio, in which the capacity ratio of the high-frequency cache area is equal to the default configuration value.

[0097] When step B2 determines that the operating status information does not meet the dynamic adjustment triggering conditions, the vehicle edge node determines the target capacity allocation ratio as the second allocation ratio. The second allocation ratio is a capacity allocation scheme for normal driving and fault-free conditions, where the capacity ratio of the high-frequency buffer is equal to the default configuration value. The default configuration value refers to the conventional capacity allocation ratio preset by the vehicle edge node during initialization; for example, the high-frequency buffer capacity ratio can be set to the default configuration value of 50%, and the conventional buffer capacity ratio can be set to 50%. Under normal driving and fault-free conditions, the amount of fault-related signals and safety-related signals generated by the vehicle is relatively small, and it is not necessary to allocate too much storage space to the high-frequency buffer. Maintaining the default balanced allocation ratio is sufficient to meet daily data storage needs, while also reserving enough storage space for conventional status signals.

[0098] For example, the total capacity of the cache memory is 1000 megabytes, with a default configuration of 50% for the high-frequency cache and 50% for the regular cache. In step B2, the vehicle edge node determines that its operating status information does not meet the dynamic adjustment trigger conditions; that is, the vehicle currently has no active diagnostic fault codes and its speed does not exceed a preset speed threshold, indicating normal driving. The target capacity allocation ratio is then set to the second allocation ratio. At this point, the target capacity for the high-frequency cache is 1000 megabytes multiplied by 50%, which equals 500 megabytes, and the target capacity for the regular cache is also 500 megabytes. The two caches achieve a balanced allocation of storage resources, balancing the storage needs of both critical and regular data.

[0099] B5. In the next write cycle, the vehicle edge node re-divides the physical storage space of the high-frequency cache area and the regular cache area in the cache memory according to the target capacity allocation ratio.

[0100] After determining the target capacity allocation ratio, the vehicle edge node reallocates the physical storage space of the high-frequency cache and the regular cache in the cache memory according to the target capacity allocation ratio in the next write cycle. A write cycle is the smallest time unit for the vehicle edge node to perform cache data write operations. After the vehicle edge node completes the writing of the current batch of data in a write cycle, it performs a cache capacity reallocation operation during the interval before the start of the next write cycle. The specific reallocation process is as follows: the vehicle edge node calculates the target capacity values ​​for the high-frequency cache and the regular cache according to the target capacity allocation ratio, and then adjusts the physical storage space boundaries occupied by the two caches in the cache memory. If the target capacity of the high-frequency cache is greater than its current capacity, the vehicle edge node allocates a portion of the remaining space in the regular cache to the high-frequency cache; if the target capacity of the high-frequency cache is less than its current capacity, the vehicle edge node returns the excess space in the high-frequency cache to the regular cache. During the repartitioning process, if there is already stored data in the reduced buffer area and this data exceeds the target capacity, the vehicle edge node can remove the data with the lowest comprehensive value score from the buffer area according to the comprehensive value score elimination mechanism in step S5, until the amount of data in the buffer area does not exceed the target capacity.

[0101] For example, in the current write cycle, the vehicle edge node determines the target capacity allocation ratio as the first allocation ratio, with a target capacity of 800 megabytes for the high-frequency cache and 200 megabytes for the regular cache. Currently, the actual capacity of both the high-frequency and regular caches is 500 megabytes. In the next write cycle, the vehicle edge node performs a repartitioning operation, allocating 300 megabytes of space from the regular cache to the high-frequency cache, expanding the high-frequency cache capacity to 800 megabytes and reducing the regular cache capacity to 200 megabytes. The regular cache, which originally occupied 500 megabytes, now retains only 200 megabytes. The vehicle edge node then eliminates the lowest-scoring data entries in the regular cache according to their comprehensive value score, from lowest to highest, until the data volume in the regular cache does not exceed 200 megabytes. As another example, after troubleshooting, if the operating status information returns to not meeting the trigger conditions, the vehicle edge node determines the target capacity allocation ratio as the second allocation ratio, with both the high-frequency and regular caches having a target capacity of 500 megabytes. In the next write cycle, the vehicle edge node returns the extra 300 megabytes of space in the high-frequency cache to the regular cache, restoring a balanced capacity allocation.

[0102] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0103] Please see Figure 4 This illustration shows a schematic diagram of a real-time data stream processing device for an automotive ECU provided in an exemplary embodiment of this application, hereinafter referred to as device 4. Device 4 can be implemented as all or part of a vehicle through software, hardware, or a combination of both. Device 4 includes: The receiving module 401 is used to receive raw signal data sent by each electronic control unit (ECU) from at least one vehicle communication bus, add a local receiving timestamp and source ECU identifier to each piece of raw signal data, and generate data to be cached. The determining module 402 is used to determine the priority of each piece of data to be cached according to a preset diagnostic importance mapping table; The writing module 403 is used to write the data to be cached into the cache corresponding to the priority when the free capacity of either the high-frequency cache or the regular cache is greater than or equal to a preset threshold, wherein the data to be cached with the first priority is written into the high-frequency cache, and the data to be cached with the second priority is written into the regular cache, and the first priority is greater than the second priority. The pause module 404 is used to pause writing to the cache area when the free capacity of either the high-frequency cache area or the regular cache area is less than the preset threshold, and to calculate the comprehensive value score of each piece of data based on the access frequency, time decay factor and diagnostic importance score of each piece of data already stored in the cache area. The removal module 405 is used to remove the data with the lowest comprehensive value score from the cache area to free up storage space, and write the data to be cached into the cache area.

[0104] For other details regarding the implementation of the above technical solution by each module in the above-mentioned real-time processing device for automotive ECU data stream, please refer to the description in the real-time processing method for automotive ECU data stream provided in the above-mentioned application embodiments, which will not be repeated here.

[0105] It should be noted that the above-described embodiment of the device 4, when executing the real-time processing method for automotive ECU data streams, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. Furthermore, the real-time processing device for automotive ECU data streams provided in the above embodiment and the embodiment of the real-time processing method for automotive ECU data streams belong to the same concept, and their implementation process is detailed in the method embodiment, which will not be repeated here.

[0106] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0107] See Figure 5 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 5 The computer program shown above), the instructions are adapted to be loaded and executed as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0108] This application also provides a computer program product that stores at least one instruction, which is loaded and executed to implement the real-time processing method for automotive ECU data streams as described in the above embodiments.

[0109] Please see Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 may include: at least one 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602.

[0110] The communication bus 602 is used to enable communication between these components.

[0111] The user interface 603 may include input units such as a mouse and keyboard.

[0112] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0113] 601 may include one or more processing cores. 601 connects various parts within the electronic device 600 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 605, and by calling data stored in memory 605. Optionally, 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). 601 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into 601 and may be implemented as a separate chip.

[0114] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0115] exist Figure 6 In the illustrated electronic device 600, the user interface 603 is primarily used to provide an input interface for the user and to acquire user input data; while 601 can be used to call the application program stored in the memory 605 and specifically execute, for example... Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0116] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0117] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for real-time processing of automotive ECU data streams, characterized in that, The method is applied to vehicle edge nodes, wherein the vehicle edge nodes are configured with a cache memory, the cache memory being at least divided into a high-frequency cache area and a regular cache area; the method includes: The vehicle edge node receives raw signal data from at least one vehicle communication bus sent by each electronic control unit (ECU), adds a local receiving timestamp and source ECU identifier to each raw signal data, and generates data to be cached. Based on the preset diagnostic importance mapping table, determine the priority of each piece of data to be cached; When the free capacity of either the high-frequency cache or the regular cache is greater than or equal to a preset threshold, the data to be cached is written to the cache corresponding to the priority according to the priority. Specifically, the data to be cached with the first priority is written to the high-frequency cache, and the data to be cached with the second priority is written to the regular cache. The first priority is greater than the second priority. When the free capacity of either the high-frequency cache or the regular cache is less than the preset threshold, writing to that cache is paused, and the comprehensive value score of each piece of data is calculated based on the access frequency, time decay factor, and diagnostic importance score of each piece of data already stored in that cache. Remove the data with the lowest overall value score from the cache area to free up storage space, and write the data to be cached into the cache area.

2. The method according to claim 1, characterized in that, The cache storage also includes an archive cache area; The removal of the data with the lowest overall value score from the cache includes: When the score of the data with the lowest comprehensive value score is higher than the preset archiving threshold, the data is migrated from the cache area where the data is currently located to the archive cache area; When the score of the data with the lowest comprehensive value score is lower than or equal to the preset archiving threshold, the data is discarded directly.

3. The method according to claim 1, characterized in that, The step of determining the priority of each piece of data to be cached according to a preset diagnostic importance mapping table includes: Obtain the source ECU identifier and signal type corresponding to the data to be cached; Query the preset diagnostic importance mapping table, which stores the correspondence between ECU identifier, signal type and priority level; When the signal type corresponding to the data to be cached is a fault-related signal or a safety-related signal, the priority is determined to be the highest priority.

4. The method according to claim 1, characterized in that, The comprehensive value score of each piece of data is calculated based on its access frequency, time-depletion factor, and diagnostic importance score, which are all factors considered in the cache. The priority of each data point is used as the base score for the diagnostic importance score; When a diagnostic fault code is detected to be activated, a preset fault code and signal association table is queried to determine the target signal type and source ECU identifier associated with the diagnostic fault code. Based on the target signal type and the source ECU identifier, the matching stored data is located in the buffer area, and the diagnostic importance score of the successfully matched stored data is increased from the base score value to a preset maximum score value; the maximum score value is greater than the base score value, and the increased diagnostic importance score is restored to the base score value after the diagnostic fault code is cleared; The access frequency of each piece of data in the cache is counted, and the time decay factor corresponding to each piece of data is calculated. The time decay factor is negatively correlated with the residence time of the data in the cache. The shorter the residence time of the data, the larger the time decay factor. The comprehensive value score of the data is obtained by weighting and summing the access frequency, the time decay factor, and the diagnostic importance score.

5. The method according to claim 1, characterized in that, Also includes: Receive a subscription request sent by a vehicle diagnostic terminal, wherein the subscription request carries a target signal identifier, and the target signal identifier includes at least the target signal type and the source ECU identifier; Based on the target signal identifier, first query the high-frequency buffer to see if there is any matching latest data. If there is, read it from the high-frequency buffer and return it. If no matching latest data is found in the high-frequency cache, then the data is queried from the regular cache and retrieved. If no matching data is found in either the high-frequency buffer or the regular buffer, a null value or a prompt message is returned to the vehicle diagnostic terminal.

6. The method according to claim 1, characterized in that, Also includes: Under normal operating conditions, the vehicle edge node synchronizes the data in the high-frequency cache area and the regular cache area to an external cloud server at a preset period, and records the timestamp of the last successful synchronization. The vehicle edge node monitors the network connection status between the vehicle and the cloud server; When a network connection interruption is detected, switch to local disaster recovery mode; In the local disaster recovery mode, the vehicle edge node suspends data writing to the regular cache area. For the received data to be cached, when the diagnostic importance score of the data to be cached is higher than the preset score threshold, the data to be cached is written to the high-frequency cache area, and historical data with diagnostic importance scores lower than the preset score threshold in the high-frequency cache area and the regular cache area are cleared. When the network connection is detected to be restored, the vehicle edge node obtains the timestamp of the last successful synchronization, filters out data with timestamps later than the last successful synchronization from the high-frequency cache, and synchronizes the filtered data to the cloud server one by one in the order of timestamps.

7. The method according to claim 1, characterized in that, The method further includes: The vehicle edge node acquires the vehicle's current operating status information, which includes at least vehicle speed, gear status, and whether there are active diagnostic fault codes. Determine whether the operating status information meets the preset dynamic adjustment triggering conditions, wherein the dynamic adjustment triggering conditions are: the existence of an active diagnostic fault code, or the vehicle speed exceeds a preset vehicle speed threshold; When the running status information meets the dynamic adjustment triggering condition, the target capacity allocation ratio is determined as the first allocation ratio, and the capacity ratio of the high-frequency cache area in the first allocation ratio is greater than the capacity ratio of the regular cache area. When the running status information does not meet the dynamic adjustment triggering condition, the target capacity allocation ratio is determined to be the second allocation ratio, and the capacity ratio of the high-frequency cache in the second allocation ratio is equal to the default configuration value. In the next write cycle, the vehicle edge node re-divides the physical storage space of the high-frequency cache area and the regular cache area in the cache memory according to the target capacity allocation ratio.

8. The method according to claim 1, characterized in that, The formula for calculating the time decay factor is: Time decay factor = e^(-λ·Δt), where Δt is the residence time of the data in the buffer, λ is the decay coefficient, the value of λ is set according to the priority of the data, the higher the priority, the smaller λ is, and e is a natural constant.

9. A real-time data stream processing device for automotive ECUs, characterized in that, The device includes: The receiving module is used to receive raw signal data sent by each electronic control unit (ECU) from at least one vehicle communication bus, add a local receiving timestamp and source ECU identifier to each piece of raw signal data, and generate data to be cached. The determination module is used to determine the priority of each piece of data to be cached based on a preset diagnostic importance mapping table; The writing module is used to write the data to be cached into the cache area corresponding to the priority when the free capacity of either the high-frequency cache area or the regular cache area is greater than or equal to a preset threshold, according to the priority. The data to be cached with the first priority is written into the high-frequency cache area, and the data to be cached with the second priority is written into the regular cache area. The first priority is greater than the second priority. The pause module is used to pause writing to the cache area when the free capacity of either the high-frequency cache area or the regular cache area is less than the preset threshold, and to calculate the comprehensive value score of each piece of data based on the access frequency, time decay factor and diagnostic importance score of each piece of data already stored in the cache area. The removal module is used to remove the data with the lowest comprehensive value score from the cache area to free up storage space, and write the data to be cached into the cache area.

10. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the real-time data stream processing method for an automotive ECU as described in any one of claims 1 to 9.

Images