A shadow thread-based memory automatic recovery method for a vehicle-mounted SOME / IP protocol stack

Abstract

This application discloses an automatic memory reclamation method for an in-vehicle SOME / IP protocol stack based on shadow threads, relating to the field of vehicle system development. The method includes: S1: Data reception and timestamp injection: When the protocol stack receives network data packets and allocates memory blocks to cache data, it injects a timestamp into the memory block while storing the data content; S2: Starting a background shadow thread: During the SOME / IP protocol stack initialization phase, a low-priority background shadow thread, independent of the main communication logic of the protocol stack, is started; the shadow thread scans all data cache memory blocks within the protocol stack at a preset period; S3: Timeout determination and forced reclamation triggering: The shadow thread traverses all cache memory blocks and calculates the time difference Δt between the current system time and the memory block timestamp; if Δt is greater than or equal to a preset safety threshold, and it is detected that the upper-layer application has not yet called the Get interface to read the memory block data, then the memory block is determined to be a timeout unread memory block, triggering a forced reclamation mechanism.

Description

Technical Field

[0001] This application relates to the field of vehicle system development, and in particular to an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, an automatic memory reclamation system for in-vehicle SOME / IP protocol stack based on shadow threads, electronic devices, storage media, and vehicle development platforms. Background Technology

[0002] In the current intelligent connected vehicle electronic and electrical architecture, the QNX system is widely used as a high real-time operating system. The SOME / IP (Scalable service-Oriented Middleware over IP) protocol stack, as middleware, is responsible for transmitting data between the server and clients (such as instrument ICs, central control screens (IVI), HUDs, etc.). Existing communication mechanisms typically follow a "producer-consumer" model: after receiving network data, the protocol stack allocates memory space to store the data and notifies the upper-layer application (App) to process it; the application layer retrieves data from the buffer and releases memory by calling the Get or Receive API interface. The existing memory management mechanism relies entirely on the application layer's proactive actions. If the upper-layer application (App) fails to call the API interface to retrieve data in a timely manner due to logical errors, deadlocks, priority preemption, or process suspension, the memory space allocated by the protocol stack will not be released.

[0003] This mechanism has the following serious flaws:

[0004] High risk of memory leak: Unretrievable data continues to accumulate in memory, causing the memory occupied by the protocol stack to increase continuously.

[0005] System-level crash: Over time, memory leaks can exhaust the available memory of the QNX system (OOM), causing critical system processes to be killed.

[0006] Serious consequences: Ultimately, this can lead to fatal malfunctions such as the dashboard and central control screen going black, seriously affecting driving safety.

[0007] Reliance on manual maintenance: Existing solutions lack automated memory fallback mechanisms and rely entirely on the robustness of application-layer code, resulting in high costs for troubleshooting and repair. Summary of the Invention

[0008] The purpose of this invention is to provide a method for automatic memory reclamation of the vehicle SOME / IP protocol stack based on shadow threads, a system for automatic memory reclamation of the vehicle SOME / IP protocol stack based on shadow threads, electronic devices, storage media, and vehicle development platforms, thereby solving at least one of a number of technical problems.

[0009] Memory management depends on the application layer: After the SOME / IP protocol stack memory is allocated in the vehicle QNX system, it completely depends on the upper layer application to actively call Get / ReceiveAPI to retrieve and release data. When the application layer fails to retrieve data in time due to logical errors, deadlocks, priority preemption and other anomalies, memory blocks continue to accumulate, causing memory leaks.

[0010] System crash risk: Long-term accumulation of memory leaks can lead to QNX system OOM (out of memory), causing core processes to be terminated and resulting in fatal malfunctions such as dual black screens on the dashboard and central control screen, threatening driving safety;

[0011] Lack of automated fallback: The existing mechanism has no proactive memory reclamation capability and relies entirely on the robustness of the application layer code, resulting in high costs for troubleshooting and repairing memory problems.

[0012] This invention provides the following solution:

[0013] According to a first aspect of the present invention, a method for automatic memory reclamation of an in-vehicle SOME / IP protocol stack based on shadow threads is provided. This method is implemented within the SOME / IP protocol stack and includes the following steps:

[0014] S1: Data reception and timestamp injection:

[0015] When the protocol stack receives a network data packet and allocates a memory block to cache the data, it injects a timestamp into the memory block while storing the data content.

[0016] The timestamp records the system time when data enters the protocol stack buffer;

[0017] S2: Start a background shadow thread:

[0018] During the SOME / IP protocol stack initialization phase, a low-priority background shadow thread, independent of the main communication logic of the protocol stack, is started.

[0019] The shadow thread scans all data cache memory blocks inside the protocol stack at a preset period.

[0020] S3: Timeout Detection and Forced Reclaim Trigger:

[0021] The shadow thread iterates through all cached memory blocks and calculates the time difference Δt between the current system time and the timestamp of the memory block.

[0022] If Δt is greater than or equal to the preset safety threshold, and it is detected that the upper-layer application has not yet called the Get interface to read the memory block data, then the memory block is determined to be an expired unread memory block, triggering the forced reclamation mechanism;

[0023] S4: Exception handling and memory resource release:

[0024] For memory blocks that have been determined to have timed out and not read according to step S3, a forced reclamation operation is performed to release the system resources occupied by the memory blocks, and an automatic memory reclamation error log is recorded at the same time.

[0025] Furthermore, including:

[0026] In step S2, low priority includes scheduling priorities lower than the protocol stack main communication logic and vehicle core services, in order to avoid preempting system CPU resources.

[0027] Furthermore, including:

[0028] In step S3, if Δt is less than the safety threshold, it is determined that the upper-layer application is processing or about to process data normally, and the corresponding memory block and cache data are retained.

[0029] Furthermore, including:

[0030] In step S4, the automatic memory reclamation error log includes the log type, the corresponding service ID, and the event ID;

[0031] The log type is marked for automatic memory reclamation.

[0032] Furthermore, including:

[0033] In step S1, the memory block is the system memory space temporarily allocated by the SOME / IP protocol stack for caching network data packets;

[0034] The timestamp is the system clock time of the QNX operating system.

[0035] Furthermore, including:

[0036] In step S3, before performing timeout determination and forced reclamation operations, a mutex lock is added to the memory block to avoid concurrent race conditions between the shadow thread's reclamation operation and the upper-layer application's Get interface data retrieval operation.

[0037] Release the mutex lock after the recycling or data retrieval operation is completed.

[0038] According to a second aspect of the present invention, a shadow thread-based automatic memory reclamation system for in-vehicle SOME / IP protocol stacks is provided. The shadow thread-based automatic memory reclamation system for in-vehicle SOME / IP protocol stacks is deployed within the SOME / IP protocol stack and includes:

[0039] Data processing module: When the protocol stack receives network data packets and allocates a memory block buffer, it injects a timestamp recording the precise system time into the memory block while storing the data content;

[0040] Shadow Thread Module: Used to start low-priority background shadow threads during the protocol stack initialization phase;

[0041] The shadow thread is independent of the main communication logic of the protocol stack and scans all data cache memory blocks inside the protocol stack at a preset period.

[0042] Timeout determination module: Communicates with the shadow thread module and is used to traverse the cache memory block and calculate the time difference Δt between the current system time and the memory block timestamp;

[0043] If Δt is greater than or equal to the preset safety threshold, and it is detected that the upper-layer application has not called the Get interface to retrieve data, then it is determined that the memory block has timed out and a forced reclamation signal is triggered.

[0044] Memory reclamation module: Communicates with the timeout determination module to receive forced reclamation signals, perform forced release operations on timeout unread memory blocks, and record memory automatic reclamation error logs.

[0045] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0046] The memory stores computer programs, which, when executed by the processor, cause the processor to perform steps such as the automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads.

[0047] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs steps such as a shadow thread-based automatic memory reclamation method for in-vehicle SOME / IP protocol stack.

[0048] According to a fifth aspect of the present invention, a vehicle development platform is provided, comprising:

[0049] Electronic devices, for implementing steps such as a shadow thread-based automatic memory reclamation method for in-vehicle SOME / IP protocol stacks;

[0050] The processor runs programs, and when the programs are running, it executes steps such as the automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads, based on data output from electronic devices.

[0051] Storage medium used to store programs that, when running, perform steps such as automatic memory reclamation of the vehicle's SOME / IP protocol stack based on shadow threads on data output from electronic devices.

[0052] The above solution achieves the following beneficial technical effects:

[0053] This application uses shadow thread periodic scanning and timeout-based forced reclamation to automatically back up memory from the protocol stack layer, preventing infinite memory accumulation caused by application layer exceptions, solving the memory leak problem at its root, and completely avoiding memory leaks.

[0054] This application avoids fatal malfunctions such as QNX system crashes and dual blackouts of the instrument panel / central control screen caused by memory overflow, significantly improving the operational stability and driving safety of the vehicle system and ensuring system operation safety.

[0055] This application does not rely on the robustness of the application layer code, and automates memory monitoring, recycling, and exception logging, greatly reducing the workload of troubleshooting and repairing memory problems and lowering manual maintenance costs. Attached Figure Description

[0056] Figure 1 This is a flowchart of an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, provided by one or more embodiments of the present invention.

[0057] Figure 2 This is a structural diagram of an in-vehicle SOME / IP protocol stack memory automatic recycling system based on shadow threads, provided by one or more embodiments of the present invention.

[0058] Figure 3 This is a schematic diagram of automatic memory reclamation of the vehicle protocol stack using a "shadow thread" according to a specific embodiment of the present invention.

[0059] Figure 4 This is a block diagram of an electronic device structure for an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, provided by one or more embodiments of the present invention. Detailed Implementation

[0060] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Figure 1 This is a flowchart of an automatic code generation method for SOME / IP data types provided by one or more embodiments of the present invention.

[0062] like Figure 1The shadow thread-based automatic memory reclamation method for the in-vehicle SOME / IP protocol stack, as shown, is applied to the QNX real-time operating system of intelligent connected vehicles. It solves the technical problem of SOME / IP protocol stack memory accumulation and system OOM (Out of Memory) crashes caused by upper-layer applications failing to call the Get / Receive API interface to read data in a timely manner. The shadow thread-based automatic memory reclamation method for the in-vehicle SOME / IP protocol stack is implemented within the SOME / IP protocol stack and includes the following steps:

[0063] S1: Data reception and timestamp injection: When the protocol stack receives a network data packet and allocates a memory block to cache the data, it injects a timestamp into the memory block while storing the data content;

[0064] The timestamp records the precise system time when data enters the protocol stack buffer;

[0065] S2: Start background shadow thread: During the SOME / IP protocol stack initialization phase, start a low-priority background shadow thread that is independent of the main communication logic of the protocol stack; the shadow thread scans all data cache memory blocks inside the protocol stack at a preset period;

[0066] S3: Timeout determination and forced reclamation trigger: The shadow thread traverses all cached memory blocks and calculates the time difference Δt between the current system time and the memory block timestamp; if Δt is greater than or equal to the preset safety threshold, and it is detected that the upper-layer application has not yet called the Get interface to read the memory block data, then the memory block is determined to be a timeout unread memory block, and the forced reclamation mechanism is triggered;

[0067] S4: Exception handling and memory resource release: Perform a forced reclamation operation on the memory block that was determined to have timed out and not read in step S3, release the system resources occupied by the memory block, and record the memory automatic reclamation error log; and when the upper layer application attempts to call the Get interface to read the data in the future, return the data expired status code to the application layer.

[0068] In this embodiment, step S2 includes a preset scanning period of 100ms for the shadow thread, and low priority includes scheduling priorities lower than those of the protocol stack main communication logic and vehicle core services, in order to avoid preempting system CPU resources.

[0069] In this embodiment, step S3 includes: a preset security threshold of 500ms. If Δt is less than the security threshold, it is determined that the upper-layer application is processing or about to process data normally, and the corresponding memory block and cache data are retained.

[0070] In this embodiment, step S4 includes the following: the automatic memory reclamation error log includes the log type, the corresponding service ID, and the event ID.

[0071] The log type is marked as automatic memory reclamation, which facilitates problem tracing and troubleshooting of upper-layer applications.

[0072] In this embodiment, step S1 includes: the memory block is a system memory space temporarily allocated by the SOME / IP protocol stack for caching network data packets; the timestamp is the system clock time of the QNX operating system, which has microsecond-level time accuracy.

[0073] In this embodiment, the preset scanning period of the shadow thread and the preset security threshold for timeout determination are configurable parameters that can be dynamically adjusted according to the security level and real-time requirements of the vehicle signal / service.

[0074] In this embodiment, the following measures are taken: for services corresponding to high-safety-level / high-real-time signals in vehicles, such as braking and steering, a larger preset safety threshold is configured; for services corresponding to comfort signals such as media volume and ambient lighting, a smaller preset safety threshold is configured, taking into account both data processing security and memory reclamation efficiency.

[0075] In this embodiment, step S3 includes: before performing timeout determination and forced reclamation operations, a mutex lock is added to the memory block to avoid concurrent race conditions between the shadow thread's reclamation operation and the Get interface's data retrieval operation of the upper-layer application; after the reclamation operation or data retrieval operation is completed, the mutex lock is released.

[0076] In this embodiment, the method further includes a shadow thread health monitoring step, which detects the running status of the shadow thread in real time. If the shadow thread is detected to be suspended, crashed, or continuously preempted, causing the scan to be interrupted, the shadow thread automatic restart mechanism is immediately triggered to restore the memory scanning and reclamation functions.

[0077] In this embodiment, the following steps are included: For scenarios where multiple upper-layer application clients subscribe to the same cached data, step S3 requires checking whether all subscribing clients have not called the Get interface to read the data. Only when all clients have not read the data and the data has timed out will the forced reclamation mechanism be triggered; if any client has read the data, the memory block will be retained.

[0078] In this embodiment, in step S4, while performing forced reclamation of memory blocks, the memory space of the protocol stack buffer is defragmented, and the free discrete memory blocks are merged into contiguous memory blocks to improve the memory utilization of the QNX system.

[0079] In this embodiment, the automatic memory reclamation error log also includes at least one of the following: memory block size, data accumulation time, physical address of memory block, system load at reclamation time, and vehicle operating status, enriching the dimensions of log information and supporting in-depth investigation of upper-layer application anomalies.

[0080] In this embodiment, a data fault tolerance step is also included. For unread data of the vehicle core business that has timed out, the data is backed up to the temporary backup queue of the protocol stack before memory reclamation is performed. If the upper layer application subsequently reports data loss, the data can be restored from the backup queue and the retransmission mechanism of the SOME / IP protocol can be triggered.

[0081] In this embodiment, a memory reclamation statistics and early warning step is also included. The number of memory reclamation times, the cumulative reclamation memory size, and the frequency of timeout accumulation for each service / event are counted in real time. When the number of reclamation times for a certain service reaches a preset early warning threshold, an abnormal early warning information is reported to the vehicle diagnostic system to indicate that there is an abnormality in the upper-layer application.

[0082] Specifically, regarding the above solutions, the risks include: detailed design for engineering implementation, coverage of complex scenarios, deep compatibility with in-vehicle systems, and data fault tolerance.

[0083] 1. Rigidity of parameters: Core time parameters (scanning cycle, timeout threshold) are inflexible and cannot adapt to the real-time requirements of different services and the differences in vehicle operation scenarios, which may lead to the accidental or untimely reclamation of core data.

[0084] 2. Concurrency and reliability risks: There is a race condition between data retrieval at the application layer and shadow thread recycling, and low-priority shadow threads are easily preempted or crash, causing the recycling mechanism to fail.

[0085] 3. Incomplete coverage of memory leaks: Leak scenarios other than "timeout unread" are not covered, such as data not being released after being retrieved at the application layer, abnormal protocol stack buffers, and virtual memory accumulation.

[0086] 4. Data and system compatibility issues: Directly reclaiming timed-out data without fault tolerance mechanism can easily lead to the loss of core data; insufficient compatibility with QNX memory partitioning and virtual memory mechanisms may trigger system protection.

[0087] 5. Accuracy issues in troubleshooting and judgment: Insufficient dimensions of error log information make it difficult to trace the root cause of application layer anomalies; system time jumps cause inaccurate timestamps, leading to timeout judgment errors.

[0088] Further strategies to address the aforementioned risks are disclosed in another specific embodiment:

[0089] For example, it also includes a timestamp synchronization calibration step. When the QNX system performs system time synchronization adjustment through GPS / vehicle gateway, it synchronously updates the timestamps of all cache memory blocks, calculates the clock offset, and compensates for the time difference Δt to avoid timeout judgment errors caused by system time jumps.

[0090] For example, a full lifecycle status flag can be set for each memory block, including three states: "not read", "read but not released", and "released". When the shadow thread scans, it identifies memory blocks in the "read but not released" state. If the duration of this state exceeds the preset release threshold, a forced reclamation operation is directly triggered to solve the problem of memory leakage caused by the upper-layer application not releasing memory after retrieving data.

[0091] For example, when scanning with a shadow thread, the status of the SOME / IP protocol stack send / receive buffer queue is detected synchronously. Abnormal memory blocks without application layer association caused by queue overflow or node hangup are identified. Forced reclamation is performed directly without timeout judgment, and the error log is marked with the type "protocol stack buffer exception".

[0092] For example, the method is compatible with the virtual memory / swap partition mechanism of the QNX system. The shadow thread supports scanning cached memory blocks mapped to the virtual memory / swap partition, performing forced reclamation on timed-out unread memory blocks and unmapping the virtual memory, thus avoiding data accumulation in the virtual memory.

[0093] For example, a threshold for batch reclamation of accumulated memory can be set. When the number of timeout unread memory blocks for the same service / event reaches the threshold, batch reclamation and batch defragmentation can be performed to reduce the overhead of a single reclamation operation and improve the processing efficiency of shadow threads.

[0094] For example, the preset scan cycle and preset safety threshold can be adaptively adjusted according to the real-time operation scenario of the vehicle. In high-load scenarios such as parking and urban driving, the scan cycle is increased and the safety threshold is appropriately increased; in low-load scenarios such as high-speed cruising, the scan cycle is decreased and the safety threshold is appropriately decreased.

[0095] For example, the automatic memory reclamation error log also records the running status of the corresponding upper-layer application process, including whether the process is hanging / deadlocked, the process's CPU / memory usage, and process priority information, providing direct evidence for locating the root cause of unread data in the application layer.

[0096] For example, the temporary backup queue of the protocol stack can be set with a data expiration threshold. If the backup data stays in the queue for longer than the threshold, it will be automatically cleaned up to avoid memory usage problems caused by the accumulation of data in the backup queue itself.

[0097] For example, a minimum scan frequency guarantee mechanism can be set for shadow threads. When the QNX system is under high load and the shadow thread is continuously preempted, the minimum frequency scan trigger logic is triggered to ensure that the shadow thread completes at least one full scan every preset maximum interval, thus avoiding long-term memory accumulation.

[0098] For example, in a multi-client subscription scenario, each client can be set with an independent data retrieval status flag and timeout threshold. If only some clients have not read the data and have reached their own timeout threshold, those clients are marked as "data expired" and a memory block is reserved for subsequent processing by the clients that have already read the data, thus avoiding overall data loss due to abnormalities in some clients.

[0099] For example, following the QNX system's Adaptive Partitioning resource management rules, the allocation, release, and reclamation of memory blocks are all performed within the memory partition to which the protocol stack belongs. After reclamation, the resource statistics of the QNX system's memory partition are updated synchronously to avoid triggering the system's memory protection mechanism.

[0100] For example, the memory reclamation statistics and early warning steps also support uploading statistical data to the vehicle cloud platform to achieve fleet-level memory anomaly data analysis, providing big data support for optimizing the scanning cycle and safety threshold parameters of different vehicle models.

[0101] Figure 2 This is a structural diagram of an automatic code generation system for SOME / IP data types provided by one or more embodiments of the present invention.

[0102] like Figure 2 The shadow thread-based automatic memory reclamation system for the in-vehicle SOME / IP protocol stack, shown here, is applied to the QNX real-time operating system of intelligent connected vehicles. The system is deployed within the SOME / IP protocol stack and includes:

[0103] Data processing module: Used to store data content when the protocol stack receives network data packets and allocates a memory block buffer, and to inject a timestamp of the precise system time into the memory block to record the data in the buffer.

[0104] Shadow Thread Module: Used to start a low-priority background shadow thread during the protocol stack initialization phase. The thread is independent of the main communication logic of the protocol stack and scans all data cache memory blocks inside the protocol stack at a preset period.

[0105] Timeout determination module: It communicates with the shadow thread module and is used to traverse the cached memory block, calculate the time difference Δt between the current system time and the memory block timestamp. When Δt is greater than or equal to the preset safety threshold and the upper layer application is detected not to call the Get interface to retrieve data, it is determined that the memory block has timed out and a forced reclamation signal is triggered.

[0106] Memory reclamation module: Communicates with the timeout determination module to receive forced reclamation signals, perform forced release operations on timeout unread memory blocks, record automatic memory reclamation error logs, and return a data expiration status code to the upper-layer application when it attempts to retrieve data.

[0107] In this embodiment, a parameter configuration module is also included, which is communicatively connected to the shadow thread module and the timeout determination module. It is used to configure and dynamically adjust the preset scanning cycle of the shadow thread and the preset safety threshold of the timeout determination, and supports setting differentiated parameters according to the security level and real-time requirements of the vehicle service / signal.

[0108] In this embodiment, a locking and mutual exclusion module is also included, which is communicatively connected to the timeout determination module and the memory reclamation module. It is used to add a mutual exclusion lock to the memory block to avoid concurrent race conditions between the reclamation operation and the data retrieval operation of the upper layer application, and to achieve mutual exclusion execution of the operation.

[0109] In this embodiment, a thread monitoring module is also included, which is connected to the shadow thread module to detect the running status of the shadow thread in real time. When a thread is detected to be suspended, crashed, or the scan is interrupted, the shadow thread is automatically restarted.

[0110] In this embodiment, the timeout determination module also includes a multi-client determination submodule, which is used to detect the data retrieval status of all subscribing clients in the scenario where multiple clients subscribe to the same data, and only triggers forced recycling when all clients have not read the data and the data has timed out.

[0111] In this embodiment, the memory reclamation module also includes a memory fragmentation submodule, which is used to merge and organize the free discrete memory of the protocol stack buffer into contiguous memory blocks after the memory blocks are released; it also includes a log enhancement submodule, which is used to enrich the information dimensions of the automatic memory reclamation error log, and record information such as memory block size, accumulation time, and system load.

[0112] In this embodiment, the system also includes a data fault tolerance module, which is communicatively connected to the memory reclamation module. It is used to temporarily back up the timed-out unread data of the vehicle core business and to trigger the SOME / IP protocol retransmission mechanism to restore the data when it receives feedback of data loss from the upper layer application.

[0113] In this embodiment, the system also includes a statistical early warning module, which is connected in communication with the memory reclamation module. It is used to collect memory reclamation-related data for each service and report abnormal early warning information to the vehicle diagnostic system when the number of reclamation times reaches the early warning threshold.

[0114] In this embodiment, the system also includes a time synchronization module, which is communicatively connected to the data processing module. This module is used to perform system clock synchronization calibration on the timestamp, offsetting the impact of QNX operating system time calibration on the accuracy of the timestamp and ensuring the correctness of the timeout determination.

[0115] In this embodiment, the system is compatible with the memory partition management mechanism of the QNX operating system. The allocation and release of memory blocks follow the memory partition resource management rules of the QNX system to avoid triggering the system memory protection mechanism.

[0116] Specifically, regarding the above solutions, further risks exist in areas such as detailed design for engineering implementation, coverage of complex scenarios, deep compatibility with in-vehicle systems, and data fault tolerance.

[0117] For example, the time synchronization module also includes a clock offset compensation unit, which is used to calculate the clock offset when the QNX system time is adjusted, synchronize and update the timestamps of all cache memory blocks, and compensate and correct the time difference Δt of the timeout judgment module based on the offset, so as to avoid judgment deviation caused by system time jump.

[0118] For example, the data processing module also includes a memory status marking unit, which assigns a full lifecycle status mark of "not read", "read but not released" and "released" to each memory block; the timeout determination module also includes a non-release identification unit, which is used to identify memory blocks in the "read but not released" state, and if the state exceeds the preset release threshold, it will trigger forced reclamation.

[0119] For example, the shadow thread module also includes a buffer detection unit, which is used to scan the SOME / IP protocol stack send / receive buffer queue, identify abnormal memory blocks such as queue overflow and node hang, send a forced reclamation signal to the memory reclamation module, and mark the exception type in the log.

[0120] For example, the shadow thread module also includes a virtual memory scanning unit, which supports scanning cache memory blocks in the QNX system's virtual memory / swap partition. The memory reclamation module also includes a virtual memory release unit, which is used to reclaim timed-out unread memory blocks in virtual memory and unmap virtual memory.

[0121] For example, the memory defragmentation submodule also includes a batch processing unit, which sets a threshold for batch reclamation of accumulated memory. When the timeout memory blocks of the same service / event reach the threshold, batch reclamation and batch defragmentation are performed to improve processing efficiency.

[0122] For example, the parameter configuration module also includes a scene adaptation unit, which is used to obtain the real-time operating scene of the vehicle (parking / highway / city driving) and automatically adjust the shadow thread scanning cycle and timeout judgment safety threshold according to the scene to adapt to different system load states.

[0123] For example, the log enhancement submodule also includes a process status recording unit, which is used to collect and record the process running status of the corresponding upper-layer application, including process hang / deadlock status, CPU / memory usage, and process priority information.

[0124] For example, the temporary backup queue of the data fault tolerance module is configured with a backup cleanup unit, which sets a backup data expiration threshold and automatically performs cleanup operations on backup data that exceeds the threshold to avoid the backup queue memory from accumulating.

[0125] For example, the thread monitoring module also includes a minimum scan guarantee unit, which sets the maximum scan interval for shadow threads. When a shadow thread is continuously preempted for more than this time, the forced scan logic is triggered to ensure that the shadow thread completes a full scan.

[0126] For example, the multi-client determination submodule also includes an independent status marking unit, which sets an independent data retrieval status mark and timeout threshold for each subscribing client, marks the "data expired" of clients that have not been read within the timeout period, and reserves memory blocks for other clients that have read the data.

[0127] For example, it also includes a memory partition statistics unit, which communicates with the memory reclamation module and the QNX system memory partition management module. After the memory block is reclaimed, it synchronously updates the resource statistics of the memory partition to which the protocol stack belongs, ensuring consistency with the system memory management mechanism.

[0128] For example, the statistical early warning module also includes a cloud upload unit, which is used to upload memory reclamation statistics to the vehicle cloud platform to support fleet-level abnormal data analysis and parameter optimization.

[0129] For example, all modules of the system run in the dedicated memory space of the SOME / IP protocol stack, without occupying the memory resources of the upper layer applications, and the CPU overhead of the module operation accounts for a preset threshold of ≤5%, so as to avoid affecting the core business of the vehicle.

[0130] In this application, by supporting dynamic adjustment of the scanning cycle and timeout threshold according to service security level, real-time requirements and vehicle operation scenarios (parking, high-speed cruising, etc.), the system balances data security and retrieval efficiency, and improves the flexibility of parameter adaptation.

[0131] In this application, a mutex lock is used to avoid conflicts between data retrieval and garbage collection. A shadow thread health monitoring and restart mechanism and a minimum scanning frequency guarantee ensure the continued effectiveness of the garbage collection mechanism, thus solving the problems of concurrency and mechanism reliability.

[0132] This application not only addresses the "timeout unread" leakage, but also covers scenarios such as application layer data retrieval failure, protocol stack buffer anomalies, and virtual memory accumulation, achieving full-scenario governance of memory leaks and providing comprehensive coverage of memory leak scenarios.

[0133] In this application, a backup and retransmission mechanism before core business data reclamation is used to avoid data loss; it is compatible with QNX memory partitioning and virtual memory / swap partitioning mechanisms, does not trigger system memory protection, and enhances data fault tolerance and system compatibility.

[0134] In this application, by enriching the dimensions of error logs and recording memory block information, application layer process status, vehicle operation scenarios, etc., direct evidence is provided for locating the root cause of application layer anomalies, supporting accurate problem investigation.

[0135] In this application, timestamp synchronization calibration and clock offset compensation are used to avoid timeout judgment errors caused by system time jumps, ensuring that the recycling operation is accurate and controllable and guaranteeing judgment accuracy.

[0136] In this application, a memory defragmentation and batch recycling mechanism is used to reduce discrete memory usage, improve the memory utilization of the QNX system, reduce the consumption of invalid resources, and optimize memory utilization efficiency.

[0137] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0138] In one specific embodiment, an automatic memory reclamation method for the vehicle protocol stack based on "shadow threads" is disclosed to solve the technical problem in the existing vehicle QNX system where the SOME / IP protocol stack memory accumulates infinitely due to the application layer's failure to call the API to obtain data in a timely manner, eventually causing the system to crash due to OOM (out of memory).

[0139] The method in this embodiment is implemented within the SOME / IP protocol stack of the QNX system, and the specific steps are as follows:

[0140] S1: Data Reception and Timestamp Injection

[0141] When the protocol stack receives a network data packet and needs to allocate memory space for caching, it not only stores the data content but also injects a timestamp into the memory block. This timestamp records the precise system time when the data entered the buffer.

[0142] S2: Start the background shadow thread.

[0143] During protocol stack initialization, a low-priority background thread (i.e., a "shadow thread") is started. This thread runs independently of the main communication logic and periodically (e.g., every 100ms) scans all data buffer blocks inside the protocol stack.

[0144] S3: Timeout Detection and Forced Reclaim

[0145] The shadow thread iterates through all cache blocks and calculates the time difference (Δt) between the current time and the timestamp:

[0146] If Δt is less than the preset safety threshold (e.g., 500ms), it is determined that the application layer is processing normally or about to process, and the data is retained.

[0147] If Δt is greater than or equal to the safety threshold, and it is detected that the application layer has not yet called the Get interface to read the data, then it is determined that the application layer has encountered an error or is blocked.

[0148] S4: Exception Handling and Resource Release

[0149] For memory blocks determined to have "timed out", the protocol stack performs a forced reclamation operation:

[0150] Release the system resources occupied by this memory block.

[0151] Record an error log entry, marked as "Automatic memory reclamation" and including the corresponding service ID / event ID.

[0152] Instead of returning a "data expired" status code to the application layer (if the application subsequently attempts to get it), it should return an invalid pointer.

[0153] The unique feature of this embodiment is that it introduces an independent background monitoring thread (shadow thread) into the vehicle protocol stack (such as SOME / IP) to periodically scan the lifecycle of cached data.

[0154] This embodiment uses a timestamp-based memory reclamation determination method. Specifically, the time is recorded when data is pushed onto the stack, and a background thread calculates the time difference to determine whether forced reclamation should be triggered.

[0155] This embodiment includes a timeout circuit breaker mechanism. When the data resides for more than a preset threshold and is not read by the application layer, the protocol stack actively releases memory and records the log.

[0156] Technical background of this embodiment: SOA is a software architecture pattern that organizes and provides application functionality through services. In the automotive industry, SOA is widely used in the development of in-vehicle software systems to support the integration and interaction of various functions and services.

[0157] SOME / IP (Scalable service-oriented middleware over IP) is an IP-based communication protocol stack, particularly suitable for distributed systems in the automotive field. It aims to provide scalable, service-oriented middleware to support communication and interaction between various electronic control units (ECUs) within a vehicle.

[0158] The SOME / IP protocol stack provides a flexible communication mechanism that supports message publishing and subscription, as well as service discovery and invocation. It enables efficient message transmission and data exchange within the vehicle's internal network, allowing different software modules to work collaboratively and provide complex automotive functions.

[0159] Overall, the SOME / IP protocol stack plays a crucial role in realizing service-oriented architecture and communication within automobiles, providing a reliable solution for the development and integration of automotive software systems.

[0160] The number of stacks in the SOME / IP protocol stack (also known as the number of client services) usually varies depending on the specific implementation and application requirements, so there is no fixed standard value.

[0161] In the SOME / IP protocol stack, the number of client services is typically determined by the application's requirements and system design. Each service corresponds to a service interface; therefore, the number of services in the stack depends on the number of services and functions required in a specific automotive application.

[0162] Typically, the number of services in the service stack is determined based on the vehicle's internal functions and modular structure. These services may cover functions such as diagnostics, control, and communication. In actual development, engineers need to determine the number of services in the stack based on system design and application requirements, and configure and program accordingly.

[0163] Therefore, determining the number of stacks in the SOME / IP protocol stack requires analysis and decision-making based on the specific application scenario and system design.

[0164] Figure 4 This is a block diagram of an electronic device structure for an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, provided by one or more embodiments of the present invention.

[0165] like Figure 4 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0166] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of an automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads.

[0167] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a shadow thread-based automatic memory reclamation method for the vehicle-mounted SOME / IP protocol stack.

[0168] This application also provides a vehicle development platform, including:

[0169] Electronic devices, steps for implementing an automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads;

[0170] The processor runs a program, and when the program runs, it executes the steps of the shadow thread-based automatic memory reclamation method for the vehicle SOME / IP protocol stack memory based on the data output from the electronic device.

[0171] Storage medium used to store programs that, when running, execute steps of an onboard SOME / IP protocol stack memory auto-reclamation method based on shadow threads for data output from electronic devices.

[0172] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0173] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0174] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0175] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0176] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0177] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0178] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0179] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0180] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatic memory reclamation of in-vehicle SOME / IP protocol stack based on shadow threads, characterized in that, include: S1: Data reception and timestamp injection: When the protocol stack receives a network data packet and allocates a memory block to cache the data, it injects a timestamp into the memory block while storing the data content. The timestamp records the system time when the data enters the protocol stack buffer; S2: Start a background shadow thread: During the SOME / IP protocol stack initialization phase, a low-priority background shadow thread, independent of the main communication logic of the protocol stack, is started. The shadow thread scans all data cache memory blocks inside the protocol stack at a preset period; S3: Timeout Detection and Forced Reclaim Trigger: The shadow thread iterates through all cached memory blocks and calculates the time difference Δt between the current system time and the timestamp of the memory block. If Δt is greater than or equal to the preset safety threshold, and it is detected that the upper-layer application has not yet called the Get interface to read the memory block data, then the memory block is determined to be an expired unread memory block, triggering the forced reclamation mechanism; S4: Exception handling and memory resource release: Forced reclamation is performed on memory blocks that have been determined to have timed out and not read according to step S3, releasing the system resources occupied by the memory blocks, and recording the memory automatic reclamation error log at the same time.

2. The method for automatic memory reclamation of the in-vehicle SOME / IP protocol stack based on shadow threads according to claim 1, characterized in that, include: In step S2, the low priority includes scheduling priorities lower than those of the protocol stack main communication logic and vehicle core services, in order to avoid preempting system CPU resources.

3. The method for automatic memory reclamation of the in-vehicle SOME / IP protocol stack based on shadow threads according to claim 1, characterized in that, include: In step S3, if Δt is less than the safety threshold, it is determined that the upper-layer application is processing or about to process data normally, and the corresponding memory block and cache data are retained.

4. The method for automatic memory reclamation of the in-vehicle SOME / IP protocol stack based on shadow threads according to claim 1, characterized in that, include: In step S4, the automatic memory reclamation error log includes the log type, the corresponding service ID, and the event ID; The log type is marked for automatic memory reclamation.

5. The method for automatic memory reclamation of the in-vehicle SOME / IP protocol stack based on shadow threads according to claim 1, characterized in that, include: In step S1, the memory block is a system memory space temporarily allocated by the SOME / IP protocol stack for caching network data packets; The timestamp is the system clock time of the QNX operating system.

6. The method for automatic memory reclamation of the in-vehicle SOME / IP protocol stack based on shadow threads according to claim 1, characterized in that, include: In step S3, before performing timeout determination and forced reclamation operations, a mutex lock is added to the memory block to avoid concurrent race conditions between the shadow thread's reclamation operation and the upper-layer application's Get interface data retrieval operation. Once the recycling or data retrieval operation is completed, the mutex lock is released.

7. A vehicle-mounted SOME / IP protocol stack memory automatic reclamation system based on shadow threads, characterized in that, include: Data processing module: When the protocol stack receives network data packets and allocates a memory block buffer, it injects a timestamp recording the precise system time into the memory block while storing the data content; Shadow Thread Module: Used to start low-priority background shadow threads during the protocol stack initialization phase; The shadow thread is independent of the main communication logic of the protocol stack and scans all data cache memory blocks inside the protocol stack at a preset period. Timeout determination module: Communicates with the shadow thread module and is used to traverse the cache memory block and calculate the time difference Δt between the current system time and the memory block timestamp; If Δt is greater than or equal to the preset safety threshold, and it is detected that the upper-layer application has not called the Get interface to retrieve data, then it is determined that the memory block has timed out and a forced reclamation signal is triggered. Memory reclamation module: Communicates with the timeout determination module to receive forced reclamation signals, perform forced release operations on timeout unread memory blocks, and record memory automatic reclamation error logs.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the shadow thread-based automatic memory reclamation method for the in-vehicle SOME / IP protocol stack as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the shadow thread-based automatic memory reclamation method for the in-vehicle SOME / IP protocol stack as described in any one of claims 1 to 6.

10. A vehicle development platform, characterized in that, include: An electronic device for implementing the steps of the shadow thread-based automatic memory reclamation method for in-vehicle SOME / IP protocol stack as described in any one of claims 1 to 6; The processor runs a program, and when the program runs, it executes the steps of the shadow thread-based automatic memory reclamation method for the vehicle-mounted SOME / IP protocol stack memory as described in any one of claims 1 to 6, based on data output from the electronic device. A storage medium for storing a program that, when running, performs the steps of the shadow thread-based automatic memory reclamation method for the vehicle-mounted SOME / IP protocol stack as described in any one of claims 1 to 6 on data output from an electronic device.

Images