Method, system, device and media for virtual terminal resource preloading and caching management based on ISOBUS standard

Abstract

This application provides a method, system, device, and medium for virtual terminal resource preloading and caching management based on the ISOBUS standard. This application innovatively constructs a multi-level caching architecture and combines a Markov chain-based resource prediction engine with adaptive memory management technology to achieve intelligent preloading and efficient caching of interface resources. Addressing the pain points of existing ISOBUS VT systems, such as high resource loading latency, low cache hit rate, and insufficient memory utilization, this invention provides a targeted technical solution. Experimental data verifies that this technical solution can reduce resource loading time by 50% to 70%, increase cache hit rate to over 92%, improve memory utilization by 40%, and reduce system crash rate by over 80%.

Description

Technical Field

[0001] This application relates to the field of electronic control technology for agricultural machinery, and in particular to a method, system, device, and medium for preloading and caching virtual terminal resources based on the ISOBUS standard. Background Technology

[0002] ISOBUS Virtual Terminal (VT) requires the management of numerous interface resources during operation. These resources encompass object pools, image resources, font resources, multilingual resources, and softkey masks. The object pool defines the overall structure of the interface and the attribute parameters of various objects. Image resources include visual graphic data such as icons, background images, and charts. Font resources support text rendering with different font types, sizes, and display styles. Multilingual resources adapt to string content in different language versions. Softkey masks standardize the layout and appearance of softkeys. Through the systematic management of these resources, ISOBUS VT enables flexible configuration and rapid retrieval of interface elements. This not only meets the diverse human-computer interaction needs of applications such as agricultural machinery but also improves the smoothness of terminal operation and resource utilization efficiency, providing reliable interface support for the intelligent operation of equipment.

[0003] However, the existing resource management mechanism has the following shortcomings:

[0004] Firstly, there's the latency issue caused by passive loading. The core drawback of this mechanism is that resources are not prepared in advance, but are only retrieved from storage devices or requested via the CAN bus when actually needed. Taking the scenario of a user switching to the fertilizer settings interface as an example: the entire process requires sequentially completing steps such as receiving the click command, resource missing detection, image reading (200ms), data decoding (50ms), and interface rendering (30ms), resulting in a total latency of up to 280ms, which is directly perceptible to the user. This passive loading mode not only causes slow user operation response and a degraded interactive experience, but also consumes system resources and affects overall operating performance due to frequent I / O interactions, making it difficult to meet the real-time requirements of the terminal interface in agricultural machinery operation scenarios.

[0005] Secondly, there's the inefficiency of simple caching strategies. Existing ISOBUS VT resource caching mechanisms generally employ LRU (Least Recently Used) or FIFO (First-In, First-Out) strategies, which are unsuitable for the specific usage patterns of agricultural operations. In agricultural production scenarios, resource access exhibits clear seasonal and periodic characteristics. For example, during the sowing season, operations on sowing-related interfaces account for up to 80%, the overview interface needs to be checked hourly, while the settings interface is only accessed 2-3 times per day. However, traditional caching strategies frequently discard seasonal resources, making it difficult to cache the periodically accessed overview interface for long-term use. Furthermore, the indiscriminate management of different resource types, such as large images and small icons, ultimately leads to the overview interface being likely discarded before each access, requiring reloading and rendering the cache nearly ineffective. This poorly adaptable caching strategy directly results in a low cache hit rate (typically below 60%), not only wasting resources through repeated loading and increasing system I / O burden, but also causing unstable user operation responses due to frequent resource retrieval, further deteriorating the human-computer interaction experience.

[0006] Furthermore, there is the problem of inadequate memory management. Because these embedded devices have very limited memory resources, typically only 256MB-512MB, and the system lacks both a mechanism for dynamically adjusting cache size based on operating status and an effective degradation strategy when memory is scarce, there is also the issue of cached data and runtime data competing for memory space. This crude memory management approach can lead to a series of serious consequences. Not only is it prone to causing system crashes due to memory overflow, but it also results in an imbalance where cache space is either idle and wasted or insufficient, ultimately leading to a significant decrease in the overall stability of the ISOBUS VT system, making it difficult to adapt to the continuous operation requirements of agricultural scenarios.

[0007] Finally, there is the problem of lack of predictive preloading. The existing ISOBUS VT resource management mechanism does not have the ability to predict user operation behavior. It neither utilizes the predictable user operation patterns in agricultural operation scenarios, nor can it preload related resources that may be needed later. At the same time, it wastes the idle time of the device. This not only makes it impossible to eliminate avoidable interface loading delays, but also limits the room for improvement in system response performance, ultimately making it difficult to substantially optimize the user interaction experience. Summary of the Invention

[0008] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a solution to the technical problems of latency caused by passive loading, inefficiency of simple caching strategies, unreasonable memory management, and lack of predictive preloading.

[0009] To achieve the above and other related objectives, the first aspect of this application provides a virtual terminal resource preloading and caching management system based on the ISOBUS standard. This system can predict user behavior and preload resources, implement a multi-level efficient caching mechanism, dynamically adjust caching strategies based on memory pressure, and optimize resource scheduling for agricultural operation scenarios. The system includes: a multi-level caching module for managing the promotion and demotion of ISOBUS virtual terminal resources among pre-set multi-level caches; a behavior prediction module for calculating the transition probability from the current state to each target state based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, and outputting the user's most likely next operation target; a preloading scheduling module for preloading the corresponding ISOBUS virtual terminal resources according to the predicted transition probabilities; and an adaptive memory management module for dynamically adjusting the caching strategy based on memory pressure.

[0010] In some embodiments of the first aspect of this application, the multi-level cache module includes a cache coordinator and a cache indexer; the cache coordinator is used to manage the flow of resources between multi-level caches according to the access frequency and lifecycle of the resources; the cache indexer is used to manage the storage location index of all resources in each level of cache; wherein, the multi-level cache structure set in the multi-level cache module is divided according to the access frequency.

[0011] In some embodiments of the first aspect of this application, the multi-level cache module has a three-layer cache structure, which are L1 cache, L2 cache and L3 cache in descending order of access frequency; wherein, the L2 cache manages the storage space based on the cache eviction algorithm and the time decay mechanism.

[0012] In some embodiments of the first aspect of this application, the L2 cache manages storage space based on a cache eviction algorithm and a time decay mechanism. The process includes: when a cache entry is accessed, obtaining the current time of the access; calculating the interval between the current time and the last access time of the resource, and decaying the original frequency value according to the decay coefficient; incrementing the access count for the entry and updating the last access time of the resource; performing a global decay operation on the cache entry, calculating an eviction score for each cache entry, and selecting the entry with the lowest score as the eviction target.

[0013] In some embodiments of the first aspect of this application, the process of performing a global decay operation on cached entries is as follows: obtain the current time and traverse all cached entries; calculate the time interval and determine the decay condition, and perform frequency decay and limit the minimum value for entries that meet the decay condition; the decay condition is: for each entry, subtract the time of the last access to the entry from the current time to obtain the time interval, and divide it by the decay time unit to obtain the number of hours corresponding to the time interval; if the number of hours is greater than or equal to 1 hour, the decay condition is met and frequency decay needs to be performed; the process of performing frequency decay and limiting the minimum value for entries that meet the decay condition is as follows: first, multiply the current access frequency of the target entry by the decay factor raised to the power of hours to complete the frequency decay calculation; then compare the decayed access frequency with the minimum frequency threshold, and take the larger of the two as the new access frequency of the entry.

[0014] In some embodiments of the first aspect of this application, the behavior prediction module includes: an operation sequence recorder for recording the user's operation history and interface access sequence; a Markov chain builder for constructing a state transition probability matrix based on the operation history and interface access sequence; a transition probability calculator for calculating the transition probability from the current state to each target state based on the state transition probability matrix; an online learning engine for continuously updating the prediction model based on new user operations; and a context awareness system for optimizing the prediction results output by the prediction model by incorporating current agriculture-related contextual factors.

[0015] In some embodiments of the first aspect of this application, the execution process of the Markov chain builder includes: abstracting each operation interface or operation mode in the agricultural scenario into an independent state of the Markov chain; capturing user switching behavior between different states in real time to update the state transition count; optimizing the transition count using a time decay algorithm to give higher weight to recent operation sequences, and dynamically calculating the transition probability between any two states based on the decayed transition count to form a real-time updated state transition probability matrix; based on the state transition probability matrix, querying the probability values ​​of the current state pointing to all other states in the current state query matrix, and selecting the state with the highest probability as the most likely operation target for the next step; and combining the current agricultural scenario type with preset context adjustment factors, seasonal factors, time factors, and operation mode factors to perform scenario-based enhancement and optimization of the next state prediction result.

[0016] In some embodiments of the first aspect of this application, the adaptive memory management includes: a memory monitor for real-time monitoring of system memory usage; a stress level evaluator for evaluating the current memory stress level; a cache capacity adjuster for dynamically adjusting the cache capacity at each level according to memory stress; an emergency releaser for quickly releasing low-priority cache when memory is in a critical situation; and a resource compressor for compressing cache resources.

[0017] In some embodiments of the first aspect of this application, the system further includes: a resource lifecycle management module, which includes: a resource registrar, a reference counter, an expiration detector, a resource reclaimer, and a persistence manager; wherein the resource registrar manages the registration and indexing of resources; the reference counter tracks the reference status of resources; the expiration detector detects expired or invalid resources; the resource reclaimer reclaims unused resources to free up memory; and the persistence manager manages the persistent storage of resources.

[0018] To achieve the above and other related objectives, a second aspect of this application provides a method for preloading and caching virtual terminal resources based on the ISOBUS standard, comprising: managing the promotion and demotion of ISOBUS virtual terminal resources among pre-configured multi-level caches; calculating the transition probability from the current state to each target state based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, and outputting the user's most likely next operation target; preloading the corresponding ISOBUS virtual terminal resources according to the predicted transition probability; and dynamically adjusting the caching strategy according to memory pressure.

[0019] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the virtual terminal resource preloading and caching management method.

[0020] To achieve the above and other related objectives, a fourth aspect of this application provides a computer program product, which includes computer program code that, when executed on a computer, enables the computer to implement the virtual terminal resource preloading and caching management method.

[0021] To achieve the above and other related objectives, a fifth aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the virtual terminal resource preloading and cache management method.

[0022] As described above, the virtual terminal resource preloading and caching management method, system, device, and medium based on the ISOBUS standard of this application have the following beneficial effects: This application innovatively constructs a multi-level caching architecture and combines a Markov chain-based resource prediction engine with adaptive memory management technology to achieve intelligent preloading and efficient caching of interface resources. Addressing the pain points of existing ISOBUS VT systems, such as high resource loading latency, low cache hit rate, and insufficient memory utilization, this invention forms a targeted technical solution. Experimental data verifies that this technical solution can shorten resource loading time by 50% to 70%, increase cache hit rate to over 92%, improve memory utilization by 40%, and simultaneously reduce system crash rate by over 80%. Attached Figure Description

[0023] Figure 1 The diagram shown is a structural schematic of a virtual terminal resource preloading and caching management system based on the ISOBUS standard in one embodiment of this application.

[0024] Figure 2 The diagram shown is a schematic of a three-level cache structure of a multi-level cache module in one embodiment of this application.

[0025] Figure 3 The diagram shown is a schematic representation of the execution process based on a cache eviction algorithm and a time decay mechanism in one embodiment of this application.

[0026] Figure 4 The diagram shown is a structural schematic of a behavior prediction module in one embodiment of this application.

[0027] Figure 5 This diagram illustrates the process of a Markov chain builder constructing a state transition probability matrix in one embodiment of this application.

[0028] Figure 6 The diagram shown is a flowchart illustrating a virtual terminal resource preloading and caching management method based on the ISOBUS standard in one embodiment of this application.

[0029] Figure 7 The diagram shown is a structural schematic of a computer device according to an embodiment of this application. Detailed Implementation

[0030] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0031] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 This invention presents a schematic diagram of a virtual terminal resource preloading and caching management system based on the ISOBUS standard, as illustrated in an embodiment of the present invention.

[0032] It should be noted here that ISOBUS (Industrial Serial Optically Bus) refers to an industrial serial optical bus. The ISO 11783 standard system is a serial control and communication data network standard for agricultural machinery developed by the International Organization for Standardization. Its core function is to break down communication barriers between different brands and models of agricultural machinery, enabling cross-device interconnection and collaborative operation control. A Virtual Terminal (VT) is an interactive interface that simulates the functions of a traditional physical terminal using software technology. It does not rely on dedicated hardware and can run on general-purpose computing platforms (such as industrial PCs and tablets). It establishes a connection with the controlled device through standardized communication protocols, completing core terminal functions such as data display, command issuance, and status monitoring.

[0033] In the embodiments of this application, the virtual terminal resource preloading and caching management system 10 includes: a multi-level caching module 11, a behavior prediction module 12, a preloading scheduling module 13, an adaptive memory management module 14, and a resource lifecycle management module 15. The multi-level caching module 11 manages the promotion and demotion of ISOBUS virtual terminal resources among preset multi-level caches; the behavior prediction module 12 calculates the transition probability from the current state to each target state based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, and outputs the user's most likely next operation target accordingly; the preloading scheduling module 13 preloads the corresponding ISOBUS virtual terminal resources according to the predicted transition probabilities; and the adaptive memory management module 14 dynamically adjusts the caching strategy according to memory pressure.

[0034] It should be noted here that the virtual terminal resource metadata structure is a systematic definition of the full lifecycle attributes of various core resources in the smart agriculture scenario. The basic identification dimension uniquely identifies resources through resource numbers, resource types distinguish agricultural-specific categories such as sensor data, crop models, agricultural machinery parameters, and irrigation plans, and work set numbers are associated with the business set to which the resource belongs (such as a planting unit of a certain plot or a crop management module of a certain type), so as to achieve precise positioning and classification management of agricultural resources. The storage information dimension records the original size, compressed size and checksum of the resource, which not only reflects the storage occupancy characteristics of agricultural resources (such as the compressed storage characteristics of massive sensor time-series data), but also verifies the integrity of the resource during transmission or storage through checksum, so as to avoid damage to key agricultural data such as sensor data and control parameters. The caching and access dimensions are the core of this structure's adaptation to smart agriculture scenarios. The cache level enumeration value clearly defines the state of a resource: uncached, first-level cache, second-level cache, or third-level cache. This provides a core basis for the promotion and elimination of agricultural resources across different cache levels (e.g., frequently accessed real-time sensor data is stored in the first-level cache, while periodically accessed crop growth models are stored in the second-level cache). Access statistics fields include access count, decay frequency, first access time, and last access time. This quantifies the access popularity of agricultural resources (e.g., frequently accessed irrigation schemes during irrigation season), timeliness characteristics (e.g., crop parameters at a certain growth stage), and popularity decay trends, serving as a key basis for determining the priority of agricultural resource cache elimination. Furthermore, the dependency dimension constructs a relationship graph between agricultural resources through a list of dependent resource IDs and a list of dependent resource IDs (e.g., crop yield models depend on soil sensor data and meteorological data). The relationship status dimension records the status of the agricultural scenario interface to which the resource belongs (e.g., plot monitoring interface, agricultural machinery scheduling interface). This supports both the traceability and control of agricultural resource dependencies and enables refined resource management in conjunction with agricultural business scenarios, adapting to the operational needs of complex caching systems in smart agriculture.

[0035] The accompanying resource type enumeration standardizes the value range of resource type fields for smart agriculture scenarios, covering nine core agricultural resource types: sensor data, crop models, agricultural machinery parameters, irrigation plans, soil attribute data, meteorological data, fertilizer configuration parameters, crop variety information, and plot management datasets. This ensures the uniformity and scalability of agricultural resource type identification and avoids confusion in type definitions. This enumeration complements the resource metadata structure, further strengthening the standardization of resource metadata management in smart agriculture scenarios and ensuring a high degree of alignment between the attribute descriptions of various agricultural resources and the needs of agricultural business management.

[0036] The following sections will provide a detailed explanation and description of each module in the ISOBUS-based virtual terminal resource preloading and caching management system, outlining the operational logic of each module and its relationships with other modules. This will help those skilled in the art to more comprehensively understand the overall architecture and implementation principles of the ISOBUS-based virtual terminal resource preloading and caching management system.

[0037] The multi-level caching module 11 is used to manage the promotion and demotion of ISOBUS virtual terminal resources among the pre-configured multi-level caches. It aims to achieve efficient management of resources with different access frequencies through differentiated storage media, capacity ratios and access latency.

[0038] In some examples, the multi-level cache module 11 is selected. Figure 2 The three-layer caching structure shown consists of L1, L2, and L3 caches, used to cache resources with high, medium, and low access frequencies, respectively. Specifically: L1 cache, as a hotspot cache, stores frequently accessed resources, occupying 3% to 8% of system memory, with access latency below 1ms. It can respond to high-frequency requests extremely quickly and is the core layer for improving overall system performance. L2 cache, as a general-purpose cache, handles resources with medium access frequency, increasing its capacity to 8% to 15%, with access latency controlled within 5ms. It supplements L1 cache, preventing high-frequency resources from consuming too much memory. L3 cache, as an archive cache, is used for historically used resources that may be reused. It uses disk as storage media, its capacity is not limited by memory, and its access latency is below 50ms. It ensures resource traceability without consuming memory resources.

[0039] In some examples, the multi-level caching module 11 also includes a cache coordinator 111 and a cache indexer 112. The cache coordinator 111 manages the flow of resources among the three levels of cache based on the access frequency and lifecycle of the resources. For example, it promotes hot resources from L2 or L3 cache to L1 cache, or demotes resources with decreasing access frequency from L1 cache to L2 or L3 cache, to achieve optimal allocation of cache resources. The cache indexer 112 manages the storage location index of all resources in each level of cache, so as to quickly locate the cache level where the target resource is located when a resource is received, avoiding cross-level traversal and further reducing access time.

[0040] For example, the L1 cache, configured as a hotspot cache, occupies 5% of system memory and has a maximum entry limit of 200. It is implemented based on a HashMap + doubly linked list data structure. The eviction policy combines LRU (Least Recently Used) and access frequency weighting, prioritizing the removal of long-unused resources while also retaining frequently accessed resources. The L1 cache mainly stores three types of core content: all resources of the current active interface, resources accessed in the last minute, and small, frequently accessed resources (such as icons) less than 10KB. The core of HashMap + doubly linked list is to combine the fast lookup characteristics of hash tables with the ordered nature of doubly linked lists. HashMap is responsible for mapping key-value pairs to corresponding buckets (array positions) through hash functions, achieving O(1) level fast access; the doubly linked list connects the elements (or globally ordered nodes) in each bucket, supporting fast traversal of the predecessor and successor of nodes, as well as efficient insertion and deletion operations.

[0041] The resource promotion rule for L1 cache is as follows: resources that are accessed more than 3 times consecutively in L2 cache, or resources that are accessed again within 30 seconds after a single access, will be promoted to L1. The resource degradation rule for L1 cache is as follows: when the L1 cache capacity reaches the limit, resources at the tail of the LRU list will be moved to L2, and resources that have not been accessed for more than 3 minutes will also be actively degraded to L2, so as to ensure that L1 cache always stores high-value hot resources.

[0042] For example, the L3 cache, as an archive cache, primarily handles the storage and management of historically inactive resources. Its configuration parameters include a capacity range of 500MB to 2GB (based on disk space allocation), and a maximum of 10,000 entries, balancing storage scale with system resource consumption. The eviction policy integrates FIFO (First-In, First-Out) and last access time dimensions, adhering to the time-series logic of resource storage while also considering actual access activity to determine eviction priority, ensuring the effectiveness of cached resources. The data structure combines a file system and SQLite indexes. The file system handles the actual storage of compressed large resources, seasonally / periodically used resources, and historically accessed but currently inactive resources. The SQLite indexes provide efficient retrieval dimensions for these resources, ensuring efficient resource location.

[0043] In terms of resource lifecycle management, the rules for resource promotion and deletion in L3 cache include the following: When a stored resource is accessed, it will be automatically promoted to L2 frequently used cache, realizing dynamic flow from the archive layer to the active layer and improving the response efficiency of frequently accessed resources; The deletion mechanism is based on two dimensions: time and space. For example, resources that have not been accessed for more than 30 days will be cleaned up. At the same time, when disk space is insufficient, the oldest resources will be deleted according to FIFO logic to prevent expired and invalid resources from occupying storage space and to ensure that the cache capacity is always within the set range, maintaining the stable operation of the archive cache.

[0044] For example, the L2 cache, used as a regular cache, is configured to occupy 10% of system memory, with a maximum number of entries limited to 1000, and uses a HashMap + min-heap data structure. The L2 cache stores: UI resources with moderate access frequency, preloaded resources of related UIs, and resources accessed within the last 10 minutes.

[0045] It should be noted that the HashMap + min-heap combination data structure is a hybrid structure that combines a hash table (HashMap) and a min-heap. The HashMap is responsible for quickly storing and looking up cache entries (such as data in the L2 cache) in key-value pairs. It can locate the target entry in O(1) time complexity, which meets the core requirement of fast cache access. The min-heap maintains the priority of the cache entries based on the key dimensions of the cache entries (such as access time, usage frequency, etc.). The top of the heap is always the entry with the lowest priority (such as the least used or least used). When the L2 cache reaches the 10% system memory usage limit or the maximum number of entries of 1000, the entry with the lowest priority can be quickly removed from the top of the heap and the corresponding key-value pair in the HashMap can be deleted simultaneously. This realizes the efficient lookup and eviction strategy of the cache, taking into account both access performance and cache capacity management.

[0046] Preferably, the L2 cache manages storage space based on the cache eviction algorithm (LFU-Aging) and the time decay mechanism. It prioritizes the removal of resources with low access frequency, and weakens the weight of early high-frequency but later idle resources through time decay, thus solving the problem that traditional cache eviction algorithms cannot adapt to changes in access patterns.

[0047] The specific execution process based on the cache eviction algorithm (LFU-Aging) and time decay mechanism is as follows: Figure 3 As shown, it includes the following steps:

[0048] Step 11a) When a cached entry is accessed, obtain the current time when the access occurred; calculate the interval between the current time and the last access time of the resource, and attenuate the original frequency value according to the attenuation coefficient; increment the access count for the entry and update the last access time of the resource.

[0049] Specifically, the time interval between two accesses is obtained by subtracting the last access time of the cached entry from the current time. This time interval is then divided by the decay time unit to obtain the corresponding number of hours. A power operation is performed using the decay factor as the base and this number of hours as the exponent. The current access frequency of the entry is multiplied by the result to complete the time decay of the frequency, preventing resources that were frequently used in the early stages but were idle for a long time from continuously occupying high weight. An access count is added to the entry frequency after time decay to record the current access behavior and increase the entry's access frequency. Finally, the last access time of the resource needs to be updated. For example, the original last access time of the entry is replaced with the current time obtained this time, ensuring that subsequent accesses to the entry are calculated based on the latest time.

[0050] Step 11b) Perform a global decay operation on the cache entries (e.g., globally adjust the basic attributes of the cache entries such as access frequency), calculate the eviction score for each cache entry, and select the entry with the lowest score as the eviction target.

[0051] In some examples, a global decay operation is performed on cached entries. The specific steps are as follows: First, obtain the current time; then, iterate through all cached entries to ensure that all entries participate in this global decay calculation; next, calculate the time interval and determine the decay condition. For example, for each entry, subtract the time when the entry was last accessed from the current time to obtain the time interval, and then divide it by the decay time unit (e.g., 1 hour) to calculate the number of hours corresponding to the interval; if the number of hours is greater than or equal to 1, it means that the entry has been accessed for more than 1 hour and frequency decay needs to be performed; finally, perform frequency decay and limit the minimum value. For example, for entries that meet the decay condition, multiply their current access frequency by the decay factor (DECAY_FACTOR) raised to the power of the number of hours to complete the frequency decay calculation; then compare the decayed frequency with the minimum frequency threshold, and take the larger value as the new access frequency for the entry to avoid the frequency decaying too low.

[0052] Understandably, the rules for calculating the elimination score determine the elimination priority of an item. The elimination score is composed of access frequency, recent access reward, and size penalty; the lower the score, the easier it is to be eliminated. Access frequency is directly included in the score (lower frequency, lower score); the recent access reward is tiered based on the last access time, for example, items accessed within 1 minute receive an additional 2.0, those accessed between 1 and 5 minutes receive an additional 1.0, and those accessed more than 5 minutes receive an additional 0.0, providing protection for recently accessed items; the size penalty is calculated by multiplying the item's size by 0.5 based on the ratio of its size to the average size. Larger items will have a higher penalty value, lowering their total score and making them more likely to be eliminated, thus prioritizing the freeing up cache space for smaller resources.

[0053] The behavior prediction module 12 is used to calculate the transition probability from the current state to each target state based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, and output the most likely operation target of the user's next step.

[0054] The structure of behavior prediction module 12 is as follows: Figure 4 As shown, the system includes an operation sequence recorder 121, a Markov chain builder 122, a transition probability calculator 123, an online learning engine 124, and a context-aware device 125. The operation sequence recorder 121 records the user's operation history and interface access sequences; the Markov chain builder 122 constructs a state transition probability matrix based on the operation history and interface access sequences; the transition probability calculator 123 calculates the transition probabilities from the current state to each target state based on the state transition probability matrix; the learning engine 124 continuously updates the prediction model based on new user operations; and the context-aware device 125 optimizes the prediction results output by the prediction model by incorporating current agricultural-related contextual factors.

[0055] The operation sequence recorder 121 captures and stores user operations and the sequence of interface accesses on the system or device, aiming to completely reconstruct the user's interaction trajectory and provide traceable raw data for behavior analysis, process optimization, fault diagnosis, or compliance auditing. Taking an agricultural scenario as an example: if a farmer on a smart greenhouse control system performs a series of operations—"login to the system → select tomato planting area → adjust the greenhouse temperature to 25℃ → turn on the carbon dioxide generator → check soil moisture sensor data → set irrigation equipment to start on a timer"—the operation sequence recorder 121 will record the type of each operation, execution time, involved functional modules, and interface jump path in chronological order. Technical personnel can then analyze these records to understand the farmer's operating habits and optimize the platform's interaction logic. When irrigation anomalies occur in the greenhouse, the operation sequence can be traced back to investigate whether the problem was caused by incorrect parameter settings.

[0056] The specific process by which the Markov chain builder 122 constructs the state transition probability matrix based on the operation history and interface access sequence is as follows: Figure 5 As shown, it includes the following steps:

[0057] Step 122a) Abstract each operation interface or operation mode in the agricultural scenario into an independent state of a Markov chain. For example, in an intelligent greenhouse management system, "tomato planting parameter setting interface", "soil moisture monitoring mode", "irrigation equipment control interface", etc. can all be defined as different discrete states. This step is the foundation for constructing a Markov chain, ensuring that the subsequent state transition analysis has clear objects and boundaries.

[0058] Step 122b) Real-time capture of user switching behavior between different states to update state transition counts; optimization of the transition counts using a time decay algorithm to give higher weight to recent operation sequences, and dynamic calculation of the transition probability between any two states based on the decayed transition counts, forming a real-time updated state transition probability matrix. This ensures the model aligns with the user's latest operating habits. For example: when a user switches from the current state (main menu) to another state (planting settings), the count of that transition path is first accumulated; then, a time decay rule is applied to all possible transition records in that initial state. If the last update time of a record is earlier than the current day, the count will decay by 5% daily and the last update time will be updated, thus weakening the impact of long-standing transition behaviors on the probability; finally, by calculating the sum of the counts of all transition paths in that initial state, the count of each path is converted into a percentage-based transition probability, reflecting the likelihood of state switching under the current user operating habits. In this way, the system can learn and adapt to user behavior in real time. The time decay mechanism ensures that the probability distribution focuses on recent operation preferences and avoids interference from outdated data. The dynamic recalculation of probability allows the system to predict the user's next operation tendency (for example, if the user frequently enters the job monitoring from the main menu, the probability of this transition will remain high), providing data support for interface interaction optimization (such as quick access recommendations) or operation process simplification. At the same time, the structured matrix storage of transition counts and probabilities ensures the traceability and computability of state transition logic.

[0059] It is worth noting that the state transition probability matrix in this embodiment is the core data structure used to store state transition data of the agricultural operation control system interface. This data structure adopts a hierarchical structure of nested key-value pairs, organizing information with state as the core dimension. The outer layer uses each state as the primary key, and the corresponding value is the set of all target states to which that state can transition. Each target state is associated with three core attributes: count (an integer, recording the number of state transitions from one state to another), probability (a floating-point number, representing the probability value of the transition path), and lastUpdate (a timestamp, marking the last update time of the transition record). This embodiment clearly defines the hierarchical relationship of state transitions through this structured design, and can also record the core characteristics of transition behavior through different types of attributes. For example, count and probability quantify the frequency and probability of transitions, supporting the system's online learning and operation preference analysis, while lastUpdate provides a key basis for the execution of the time decay rule, ensuring that the transition probability dynamically matches the user's recent operating habits.

[0060] Step 122c) Based on the state transition probability matrix, the model queries the probability values ​​of the current state pointing to all other states in the current state query matrix, and selects the state with the highest probability as the most likely operation target for the next step. For example, when the user is currently in the "greenhouse temperature adjustment interface" state, the model will query the probability values ​​of the current state pointing to all other states in the transition matrix, and select the state with the highest probability (such as "ventilation equipment control interface") as the most likely operation target for the user's next step.

[0061] Step 122d) Combining the current agricultural scenario type, and based on preset context adjustment factors, seasonal factors, time factors, and operation mode factors, the next state prediction results are enhanced and optimized in a scenario-based manner. Specifically, multi-dimensional factors are introduced to improve prediction accuracy. Among them, the context adjustment factor is used to combine the user's recent continuous operation preferences; the seasonal factor is used to emphasize irrigation-related operations during the rainy season and temperature control-related operations during winter; the time factor is used to emphasize monitoring during the day and automatic control at night; and the operation mode factor is used to consider different operation tendencies during the seedling stage and the mature plant stage. Then, the prediction results superimposed with these factors are normalized so that the sum of the prediction probabilities of all possible states is 1, and finally, a more accurate next state prediction result that fits the actual application scenario is output.

[0062] The following case study, based on an agricultural scenario, will illustrate the entire process of calculating state transition probability, predicting the next state, and optimizing contextual enhancement, using user operation data from an agricultural operation control system as a foundation.

[0063] First, the user's operation history from the "Main Menu" state in the past week totaled 200 times, as follows:

[0064] Main Menu → Seeding Settings: 85 times;

[0065] Main menu → Weather information: 62 times;

[0066] Main menu → Job monitoring: 45 times;

[0067] Main menu → System Settings: 8 times.

[0068] Secondly, the state transition probabilities for each target state are calculated as follows:

[0069] P (Main Menu → Seeding Settings) = 85 / 200 = 0.425;

[0070] P (Main Menu → Weather Information) = 62 / 200 = 0.310;

[0071] P (Main Menu → Job Monitoring) = 45 / 200 = 0.225;

[0072] P (Main Menu → System Settings) = 8 / 200 = 0.040.

[0073] Subsequently, predictions were filtered using a probability threshold of 0.2, discarding system settings with a probability of only 0.040. Seeding settings, weather information, and operation monitoring were listed as prediction results and sorted in descending order of probability. The system can then preload these three types of states to improve the speed of interactive response.

[0074] Finally, enhancements and optimizations are made by incorporating the context of "the current planting season," ensuring that the prediction results are not only based on historical operational data but also align with the seasonal characteristics of agricultural production. This makes the prediction logic more relevant to actual usage needs. The specific weight adjustments to the prediction results are as follows:

[0075] Seeding settings (42.5% × 1.2 = 51.0%): High-priority preloading

[0076] Weather information (31.0% × 1.1 = 34.1%): Preloaded

[0077] Job monitoring (22.5%): Preloaded.

[0078] The preloading scheduling module 13 includes a preloading decision-maker 131, a resource dependency analyzer 132, a priority sorter 133, a background loading executor 134, and a loading canceller 135. Specifically, the preloading decision-maker 131 determines whether to preload resources based on transition probabilities; the resource dependency analyzer 132 analyzes the dependencies between interface states and resources; the priority sorter 133 sorts preloading tasks by importance; the background loading executor 134 asynchronously executes preloading when the system is idle; and the loading canceller 135 cancels unnecessary preloading when prediction errors occur. The specific execution flow is as follows:

[0079] First, the background loader 134 checks the system status, allowing preloading only when system resources are sufficient. It first determines CPU usage, then checks memory status (if system memory pressure is marked "High," it indicates memory shortages and insufficient space for preloading). Through these two key pre-checks of CPU usage and memory pressure, scenarios with insufficient system resources are filtered out, ensuring that preloading operations only occur when the system is idle and resources are plentiful, preventing core business operations from being affected by preloading consuming resources.

[0080] Secondly, the preloading decision-maker 131 determines whether to preload resources based on the transition probability. It first initializes an empty candidate list, then iterates through the predicted data containing states and corresponding probabilities, retaining only states with probabilities not lower than a preset minimum preloading probability threshold. Next, it acquires all resources required for that state, filters out cached resources, and retains only the uncached portions to avoid duplicate loading. For each uncached resource, the system supplements it with multi-dimensional key information (including its state, predicted state probability, resource priority, estimated loading time, and resource size), and adds the integrated resource information to the candidate list, ultimately forming a preloading candidate set containing complete attributes, providing a comprehensive resource dimension reference for subsequent preloading decisions.

[0081] Next, the priority sorter 133 sorts the preloading candidate resources by importance, quantifying the preloading priority of resources through multi-dimensional weighted scoring. First, it iterates through all candidate resources, calculating a comprehensive score based on four dimensions and assigning different weights. For example, the weight of state prediction probability is 0.4, with higher probability resulting in a higher base priority score; the resource's own priority weight is 0.3, reflecting its business importance; the resource size weight is 0.2, with smaller sizes scoring higher, prioritizing lightweight resources; and the estimated loading time weight is 0.1, with shorter loading times scoring higher. Finally, the scores of each dimension are summed to obtain the comprehensive priority, which is then assigned to the candidate resources. All candidate resources are sorted in descending order of comprehensive priority to ensure that high-priority resources are listed first. Several of the top-ranked resources are selected as the final preloading tasks. This quantity limit avoids overloading too many resources and consumes system resources, while ensuring that only the most critical and highest-priority resources are preloaded.

[0082] Finally, after determining the final pre-loading tasks, the resource dependency analyzer 132 further processes the dependencies between resources to ensure a reasonable loading order. Specifically, it performs topological sorting on the selected pre-loading tasks based on a preset dependency graph to ensure that the underlying resources that are depended upon in the dependency relationship are loaded first, and the upper-level resources that depend on them are loaded later, avoiding resource loading failures or malfunctions due to improper loading order.

[0083] The adaptive memory management module 14 includes a memory monitor 141, a stress level evaluator 142, a cache capacity adjuster 143, an emergency releaser 144, and a resource compressor 145. The memory monitor 141 monitors system memory usage in real time; the stress level evaluator 142 assesses the current memory stress level; the cache capacity adjuster 143 dynamically adjusts the capacity of each cache level according to memory stress; the emergency releaser 144 quickly releases low-priority caches when memory is critical; and the resource compressor 145 compresses cache resources to save space.

[0084] First, the stress level evaluator 142 calculates memory availability based on data monitored by the memory monitor 141, thereby quantifying the system memory stress level. Before classifying the levels, the availability rate is calculated based on the available memory capacity and the total memory capacity (i.e., available memory capacity divided by total memory capacity). Then, different stress levels are classified according to the range of availability. The specific judgment rules are as follows: when the availability rate is greater than 0.4, the memory stress is normal; when the availability rate is between 0.2 and 0.4, the memory stress is moderate; when the availability rate is between 0.1 and 0.2, the memory stress is high; and when the availability rate is less than or equal to 0.1, the memory stress is critical. This classification method gradually defines the degree of memory resource strain from lenient to strict, and can intuitively reflect the system memory usage status.

[0085] Secondly, the cache capacity adjuster 143 first calculates the base cache value based on the total memory capacity. The base value for L1 cache is 5% of the total memory capacity, and the base value for L2 cache is 10% of the total memory capacity. Then, it dynamically adjusts the cache configuration according to the memory pressure level. The specific adjustment rules are as follows: Under normal pressure, if the cache hit rate is lower than 0.8, the L1 and L2 caches are increased to 1.2 times the base value (not exceeding their respective maximum limits maxL1 and maxL2). If the hit rate reaches the target, the base value is maintained, and preloading is enabled. Under moderate pressure, the base cache configuration is maintained and preloading is retained. Under high pressure, the L1 cache is reduced to 70% of the base value, and the L2 cache is reduced to 50%. Preloading is disabled and L2 to L3 cache migration is triggered. Under critical pressure, the cache is further reduced, preloading is disabled, and emergency cache refresh is performed. Through differentiated cache adjustment strategies, different memory pressure scenarios are adapted to balance cache efficiency and memory usage.

[0086] Next, the emergency releaser 144 quickly releases low-priority caches when memory is critical. Specifically, it adjusts the cache eviction thresholds based on memory pressure levels to adapt to different levels of memory stress. The adjustment rules for the cache eviction thresholds are as follows: when memory pressure reaches or exceeds the high level, the L1 and L2 cache eviction thresholds are lowered, with the L1 cache eviction threshold lower than the L2 cache eviction threshold; when memory pressure is below the high level, the L1 and L2 cache eviction thresholds are raised, with the L1 cache eviction threshold still lower than the L2 cache eviction threshold. For example, when memory pressure reaches or exceeds the high level, a more aggressive eviction strategy is employed, such as setting the L1 cache eviction threshold to 1 minute and the L2 cache eviction threshold to 3 minutes, accelerating cache cleanup to release memory; if memory pressure is below the HIGH level (i.e., normal or moderate), a normal eviction strategy is adopted, with the L1 cache eviction threshold at 3 minutes and the L2 cache eviction threshold at 10 minutes, preserving cached data as much as possible to improve access efficiency while ensuring controllable memory usage.

[0087] The resource lifecycle management module 15 includes a resource registrar 151, a reference counter 152, an expiration detector 153, a resource reclaimer 154, and a persistence manager 155. The resource registrar 151 manages resource registration and indexing; the reference counter 152 tracks resource references; the expiration detector 153 detects expired or invalid resources; the resource reclaimer 154 reclaims unused resources to free up memory; and the persistence manager 155 manages the persistent storage of resources. These components work together to achieve full lifecycle management of resources, from registration and monitoring to reclamation and storage.

[0088] To help those skilled in the art better understand the virtual terminal resource preloading and caching management system based on the ISOBUS standard provided in this application, the following description will be based on specific scenario examples in the agricultural field.

[0089] In this scenario example, the user switches from the main menu to the seeding settings interface.

[0090] Prediction Phase (when the user is on the main menu interface): The system enters the prediction phase in advance (T=-2000ms). It analyzes the state transition probability using a Markov prediction model, combining historical data and the sowing season bonus to obtain prediction results for sowing settings (P=0.45), weather information (P=0.32), and operation monitoring (P=0.18). Since sowing settings have the highest probability, the preloading process is triggered. At T=-1800ms, the system completes the preloading decision. After confirming a system idle state with 35% CPU utilization and normal memory pressure, it identifies the uncached resources required for the sowing settings interface (25KB sowing icon set, 8KB sowing parameter configuration) and the cached font resources (L1 cache). It then generates and sorts the preloading tasks (sowing icon set priority 0.78, sowing parameter configuration priority 0.72). Then, the background preloading task starts (T=-1500ms), and loads the seeding icon set (80ms) and seeding parameter configuration (30ms) in sequence and stores them in the L2 cache. By T=-1000ms, all the resources required for the seeding settings interface are ready.

[0091] During the user operation phase: At T=0ms, the user clicks the "Sowing Settings" button, and the virtual terminal (VT) immediately receives the interface switching command; at T=5ms, the resource acquisition process begins. When the system queries the sowing icon set, the L1 cache misses but the L2 cache hits. Due to anticipated high-frequency use, the icon set is then promoted to the L1 cache. Similarly, the sowing parameter configuration is also promoted from the L2 cache to the L1 cache; at T=8ms, thanks to all resources being ready in advance, the system directly starts interface rendering, completing the interface display by T=15ms. Performance comparison data shows that the solution of this invention takes only 15ms (pre-loading hit), which is 88% shorter than the traditional real-time loading solution's 130ms, achieving a significant performance improvement.

[0092] Cache update phase: After the interface is displayed, the system starts the cache state update process: at T=20ms, the state transition behavior of "Main Menu → Seeding Settings" is recorded and counted, the transition probability matrix of the Markov model is updated synchronously, and the next round of state prediction is started; at T=25ms, a new prediction is completed based on the updated model, and high probability results of seeding depth setting (P=0.55) and seeding speed setting (P=0.35) are obtained, and the preloading task of related resources is immediately triggered to prepare resources in advance for subsequent user operations, forming a closed-loop workflow of "prediction-preloading-operation-update".

[0093] It should be understood that the specific processes by which each module performs the corresponding steps described above have been detailed in the above method embodiments, and will not be repeated here for the sake of brevity. It should also be understood that the module division in the embodiments of this application is illustrative and merely a logical functional division; other division methods may exist in actual implementation. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or have two or more modules integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0094] The foregoing has provided a detailed explanation of the structure and principle of a virtual terminal resource preloading and caching management system based on the ISOBUS standard provided in the embodiments of this application. The following will describe the virtual terminal resource preloading and caching management method, medium, and computer device based on the ISOBUS standard provided in other embodiments of this application.

[0095] Figure 6 This paper illustrates a flowchart of a virtual terminal resource preloading and caching management method based on the ISOBUS standard, provided by an embodiment of this application. The method includes the following steps:

[0096] Step S61: Manage the promotion and demotion of ISOBUS virtual terminal resources among the pre-configured multi-level caches.

[0097] Step S62: Based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, calculate the transition probability from the current state to each target state, and output the most likely operation target of the user's next step.

[0098] Step S63: Preload the corresponding ISOBUS virtual terminal resources according to the predicted transfer probability.

[0099] Step S64: Dynamically adjust the caching strategy based on memory pressure.

[0100] It should be noted that the implementation process of the virtual terminal resource preloading and cache management method based on the ISOBUS standard provided in this application embodiment is similar to that of the virtual terminal resource preloading and cache management system based on the ISOBUS standard described above, and will not be repeated here.

[0101] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. For example, "first XX" and "second XX" are merely used to distinguish different XXs and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that terms such as "first" and "second" do not necessarily imply that they are different.

[0102] It should be noted that, in the embodiments of this application, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0103] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0104] Figure 7 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Figure 7 As shown, the computer device includes at least one processor 701, a memory 702, at least one network interface 703, and a user interface 705. The various components in the device are coupled together via a bus system 704. It is understood that the bus system 704 is used to implement communication between these components. In addition to a data bus, the bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 7 The general will label all buses as bus systems.

[0105] The user interface 705 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0106] It is understood that memory 702 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0107] In this embodiment of the invention, the memory 702 is used to store various categories of data to support the operation of the computer device 700. Examples of this data include: any executable program for operation on the computer device 700, such as operating system 7021 and application program 7022; operating system 7021 includes various system programs, such as framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. Application program 7022 may include various applications, such as media player, browser, etc., for implementing various application services. The methods provided in this embodiment of the invention may be included in application program 7022.

[0108] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 701. Processor 701 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 701 or by instructions in software form. The processor 701 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 701 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 701 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0109] In an exemplary embodiment, the computer device 700 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to perform the aforementioned method.

[0110] According to the virtual terminal resource preloading and caching management method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when the computer program code is run on a computer, causes the computer to execute the virtual terminal resource preloading and caching management method.

[0111] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to perform the above-described method.

[0112] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0113] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0114] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0116] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0118] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs, etc.).

[0119] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0121] In summary, this application provides a method, system, device, and medium for virtual terminal resource preloading and caching management. This application innovatively constructs a multi-level caching architecture and combines a Markov chain-based resource prediction engine with adaptive memory management technology to achieve intelligent preloading and efficient caching of interface resources. Addressing the pain points of existing ISOBUS VT systems, such as high resource loading latency, low cache hit rate, and insufficient memory utilization, this invention provides a targeted technical solution. Experimental data verifies that this technical solution can shorten resource loading time by 50% to 70%, increase cache hit rate to over 92%, improve memory utilization by 40%, and reduce system crash rate by over 80%. Therefore, this application effectively overcomes the various shortcomings of existing technologies and has high industrial application value.

[0122] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A virtual terminal resource preloading and caching management system based on the ISOBUS standard, characterized in that, include: The multi-level caching module is used to manage the promotion and demotion of ISOBUS virtual terminal resources among the pre-configured multi-level caches; The behavior prediction module is used to calculate the transition probability from the current state to each target state based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, and output the most likely operation target of the user's next step. The pre-loading scheduling module is used to pre-load the corresponding ISOBUS virtual terminal resources based on the predicted transfer probability. The adaptive memory management module is used to dynamically adjust the caching strategy based on memory pressure.

2. The virtual terminal resource preloading and caching management system according to claim 1, characterized in that, The multi-level caching module includes a cache coordinator and a cache indexer; the cache coordinator is used to manage the flow of resources between multi-level caches according to the access frequency and lifecycle of the resources; the cache indexer is used to manage the storage location index of all resources in each level of cache; wherein, the multi-level cache structure set in the multi-level caching module is divided according to the access frequency.

3. The virtual terminal resource preloading and caching management system according to claim 2, characterized in that, The multi-level caching module has a three-layer caching structure, which are L1 cache, L2 cache and L3 cache in descending order of access frequency; among them, L2 cache manages storage space based on cache eviction algorithm and time decay mechanism.

4. The virtual terminal resource preloading and caching management system according to claim 3, characterized in that, The L2 cache manages storage space based on a cache eviction algorithm and a time decay mechanism. The process includes: When a cached entry is accessed, obtain the current time when the access occurred; calculate the interval between the current time and the last access time of the resource, and attenuate the original frequency value according to the attenuation coefficient; increment the access count for the entry and update the last access time of the resource. Perform a global decay operation on cached entries, calculate an eviction score for each cached entry, and select the entry with the lowest score as the eviction target.

5. The virtual terminal resource preloading and caching management system according to claim 4, characterized in that, The process of performing a global decay operation on cache entries is as follows: Get the current time and iterate through all cached entries; Calculate the time interval and determine the attenuation condition. For entries that meet the attenuation condition, perform frequency attenuation and limit the minimum value. The attenuation condition is as follows: for each entry, subtract the time when the entry was last accessed from the current time to obtain the time interval, then divide the time interval by the attenuation time unit to obtain the number of hours corresponding to the time interval; if the number of hours is greater than or equal to 1 hour, the attenuation condition is met and frequency attenuation needs to be performed. For entries that meet the attenuation conditions, frequency attenuation is performed and a minimum value is limited. The process is as follows: First, the current access frequency of the target entry is multiplied by the attenuation factor raised to the power of hours to complete the frequency attenuation calculation; then, the attenuated access frequency is compared with the minimum frequency threshold, and the larger of the two values ​​is taken as the new access frequency of the entry.

6. The virtual terminal resource preloading and caching management system according to claim 1, characterized in that, The behavior prediction module includes: An operation sequence recorder is used to record the user's operation history and interface access sequence; A Markov chain builder is used to construct a state transition probability matrix based on the operation history and interface access sequence; The transition probability calculator is used to calculate the transition probability from the current state to each target state based on the state transition probability matrix. An online learning engine is used to continuously update predictive models based on new user actions; A context-aware processor is used to optimize the prediction results output by the prediction model by incorporating current agricultural-related contextual factors.

7. The virtual terminal resource preloading and caching management system according to claim 6, characterized in that, The execution process of the Markov chain builder includes: Each user interface or operation mode in the agricultural scenario is abstracted into an independent state of a Markov chain. The state transition count is updated by capturing the user's switching behavior between different states in real time; the transition count is optimized using a time decay algorithm to give higher weight to recent operation sequences, and the transition probability between any two states is dynamically calculated based on the decayed transition count to form a state transition probability matrix that is updated in real time. Based on the state transition probability matrix, the probability values ​​of the current state pointing to all other states in the current state query matrix are used to select the state with the highest probability as the most likely target for the next operation. Based on the current agricultural scenario type, and using preset context adjustment factors, seasonal factors, time factors, and operation mode factors, the prediction results for the next state are enhanced and optimized in a scenario-based manner.

8. The virtual terminal resource preloading and caching management system according to claim 1, characterized in that, The adaptive memory management includes: A memory monitor is used to monitor system memory usage in real time. Stress level evaluator, used to assess the current memory stress level; A cache capacity adjuster is used to dynamically adjust the capacity of each cache level based on memory pressure. Emergency releasers are used to quickly release low-priority caches when memory is critical. Resource compressors are used to compress cached resources.

9. The virtual terminal resource preloading and caching management system according to claim 1, characterized in that, The system also includes: The resource lifecycle management module includes: a resource registrar, a reference counter, an expiration detector, a resource reclaimer, and a persistence manager. The resource registrar manages the registration and indexing of resources; the reference counter tracks the reference status of resources; the expiration detector detects expired or invalid resources; the resource reclaimer reclaims unused resources to free up memory; and the persistence manager manages the persistent storage of resources.

10. A method for preloading and caching virtual terminal resources based on the ISOBUS standard, characterized in that, include: Manage the promotion and demotion of ISOBUS virtual terminal resources across pre-configured multi-level caches; Based on the user's operation history and interface access sequence of the ISOBUS virtual terminal, the transition probability from the current state to each target state is calculated, and the most likely operation target of the user's next step is output accordingly. Preload the corresponding ISOBUS virtual terminal resources based on the predicted transfer probability; The caching strategy is dynamically adjusted based on memory pressure.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the virtual terminal resource preloading and cache management method based on the ISOBUS standard as described in claim 10.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the virtual terminal resource preloading and cache management method based on the ISOBUS standard as described in claim 10.

Images