ISOBUS virtual terminal multi-device collaborative scheduling system and method and terminal

Abstract

The invention provides an ISOBUS virtual terminal multi-device collaborative scheduling system and method and a terminal, and aims to accurately evaluate the health condition and the active state of devices by monitoring the message sending frequency, the bandwidth occupation and the message success rate of each ECU device connected with an ISOBUS virtual terminal in real time; according to the basic weight set by the equipment type, the bandwidth share of each ECU is calculated in combination with the healthy and active states, and the bandwidth which is not fully utilized is dynamically allocated to the high-demand equipment; eCU message sending time is predicted based on a historical sending mode, potential bus conflicts are detected in advance, and a sending delay adjustment scheme is formulated for low-priority equipment; and a token bucket mechanism is introduced to control the message sending rate of each ECU, and meanwhile, the bus congestion state is monitored in real time, and corresponding control measures are triggered. According to the method, equipment state monitoring, weighted fair bandwidth allocation, conflict prediction avoidance and token bucket flow control technologies are integrated, efficient cooperative communication of multiple ECUs and VT is realized, and the communication efficiency and the system stability of agricultural machinery multi-equipment cooperative operation are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of electronic control technology for agricultural machinery, and in particular to an ISOBUS virtual terminal multi-device collaborative scheduling system, method, and terminal. Background Technology

[0002] In modern precision agriculture, multi-device collaborative operation has become the norm. A single tractor often needs to simultaneously carry seeders, fertilizer applicators, sprayers, and other equipment, and connect to multiple electronic control units (ECUs) such as monitoring systems. All of these devices interact with virtual terminals (VTs) via the ISOBUS CAN bus. However, current ISOBUS systems generally use a bus bandwidth of 250 kbps, and this limited bandwidth resource has become a core constraint for supporting high-concurrency communication among multiple devices.

[0003] The existing ISOBUS system relies entirely on the native arbitration mechanism of the CAN bus for communication scheduling, lacking upper-layer intelligent management strategies. This leads to a series of key problems when multiple devices communicate concurrently. First, the lack of a bandwidth management mechanism means the system cannot dynamically allocate bandwidth based on the actual bandwidth requirements of each device. When multiple devices initiate data transmission simultaneously (e.g., seeders, fertilizer applicators, and monitoring systems with a total bandwidth requirement of 300 kbps connected to a 250 kbps bus), arbitration is based solely on CAN ID priority. Messages from low-ID devices continuously preempt bus resources, while messages from high-ID devices are frequently delayed. This not only causes a severe imbalance in bandwidth allocation and delays interface updates for some devices, but also directly results in a significant decrease in the overall system efficiency. Secondly, message conflict is a significant issue. When multiple ECUs send messages synchronously, bus conflicts are easily triggered. Failed messages require retransmission. Under high-load scenarios with 85% bus utilization, the average number of conflicts reaches 45 per second, with an average of 1.8 retransmissions per message. In the worst case, message latency exceeds 200ms, and 5% of messages are lost due to timeouts. Bus communication efficiency is severely weakened, and system real-time performance cannot be guaranteed. Thirdly, device status awareness is insufficient. The virtual terminal cannot obtain the real-time operating status of each access device. It lacks information on device activity, message sending frequency and patterns, device priority and importance, and the ability to predict dynamic changes in device bandwidth requirements. This prevents the system from implementing targeted resource optimization scheduling, making it difficult to proactively avoid communication congestion risks, resulting in poor adaptability and flexibility. Fourth, the flow control strategy is imperfect. The existing system does not have an effective flow control mechanism. High-load devices can send messages without restriction, and there is a lack of feedback adjustment mechanism to guide the sender to reduce the transmission rate. At the same time, the system cannot distinguish the priority of critical messages and ordinary messages. Once the bus is saturated, the communication of all devices will be affected. This not only poses a very high risk of bus overload, but may also cause critical business messages to be blocked, seriously threatening the stability of system operation. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide an ISOBUS virtual terminal multi-device collaborative scheduling system, method and terminal to solve the technical problems of uneven bandwidth allocation, frequent message conflicts and lack of flow control in existing ISOBUS multi-device communication.

[0005] To achieve the above and other related objectives, this invention provides an ISOBUS virtual terminal multi-device collaborative scheduling system. The system includes: a device status monitoring module, used to monitor in real time the message sending frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal, and to assess the health and activity status of each ECU device; a bandwidth allocation module, used to calculate the bandwidth share of each ECU device based on the basic weight determined by the device type of each ECU device and the health and activity status of each ECU device, and to reallocate underutilized bandwidth to ECU devices that require more bandwidth; a conflict prediction and avoidance module, used to predict the sending time of each ECU device based on historical sending patterns, detect potential conflicts, and generate sending delay adjustment schemes for low-priority devices; and a flow control module, used to control the message sending rate of each ECU device using a token bucket mechanism, detect bus congestion, and take corresponding control measures.

[0006] In one embodiment of the present invention, the device status monitoring module includes: an ECU registration manager for managing the registration, deregistration, and basic information of each ECU device connected to the ISOBUS virtual terminal; a status sampler for periodically sampling the message sending frequency and bandwidth usage of each ECU device; a health evaluator for evaluating the communication health status of the device based on the message success rate of each ECU device; an activity detector for detecting whether each ECU device is in an active usage state; and a demand predictor for predicting changes in the bandwidth demand of the device based on historical data.

[0007] In one embodiment of the present invention, the bandwidth allocation module includes: a weight calculator for calculating effective weights based on the device type, activity level, and health status of each ECU device; a fair share calculator for calculating the basic bandwidth share of each ECU device according to the effective weight ratio; and a remaining bandwidth reallocator for reallocating underutilized bandwidth to ECU devices that require more bandwidth based on the basic bandwidth share and bandwidth requirements of each ECU device.

[0008] In one embodiment of the present invention, the conflict prediction and avoidance module includes: a transmission time predictor, used to predict the next transmission time of the ECU device based on historical transmission patterns; wherein the historical transmission patterns include: a periodic pattern or a statistical pattern; a conflict detector, used to detect potential message conflicts within the prediction time window; and an avoidance strategy generator, used to generate a transmission delay adjustment scheme for low-priority devices.

[0009] In one embodiment of the present invention, the avoidance strategy generator is used to compare the effective weights of the conflicting devices. The ECU device with the higher weight is determined to be of high priority, and the ECU device with the lower weight is determined to be of low priority. The delay time is calculated so that the high-priority ECU device maintains its original transmission time, and the low-priority ECU device delays transmission based on the delay time.

[0010] In one embodiment of the present invention, the flow control module includes: a token bucket manager for maintaining a token bucket for each ECU device to limit the transmission rate; a congestion detector for detecting bus congestion status and obtaining the congestion level; and a flow control message generator for sending flow control commands to the target device according to the congestion level.

[0011] In one embodiment of the present invention, sending flow control instructions to the target device according to the congestion level includes: when the congestion level is mild congestion, sending a flow control instruction to reduce the bandwidth quota of the lowest priority device; when the congestion level is moderate congestion, sending a flow control instruction to reduce the bandwidth quota of multiple low-priority devices; and when the congestion level is severe congestion, sending a flow control instruction to enable emergency mode to allow only critical messages to be transmitted on the bus.

[0012] In one embodiment of the present invention, the system further includes: an emergency message processing module, comprising: an emergency message identifier for identifying emergency messages such as alarms and security alerts; an emergency bandwidth reserver for reserving a portion of the bus bandwidth specifically for emergency messages; and a fast channel manager for enabling emergency messages to skip the normal queue and be transmitted immediately.

[0013] To achieve the above and other related objectives, this invention provides a multi-device collaborative scheduling method for ISOBUS virtual terminals. The method includes: real-time monitoring of the message transmission frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal, and evaluating the health status and activity status of each ECU device; calculating the bandwidth share of each ECU device based on the basic weight determined by the device type of each ECU device and the health status and activity status of each ECU device, and reallocating underutilized bandwidth to ECU devices requiring more bandwidth; predicting the transmission time of each ECU device based on historical transmission patterns, detecting potential conflicts, and generating transmission delay adjustment schemes for low-priority devices; using a token bucket mechanism to control the message transmission rate of each ECU device, detecting bus congestion status, and taking corresponding control measures.

[0014] To achieve the above and other related objectives, the present invention provides an electronic terminal, comprising: one or more memories and one or more processors; the one or more memories are used to store a computer program; the one or more processors are connected to the memories and are used to run the computer program to execute the ISOBUS virtual terminal multi-device collaborative scheduling method.

[0015] As described above, this invention is an ISOBUS virtual terminal multi-device collaborative scheduling system, method, and terminal, which has the following beneficial effects: This invention accurately assesses the health and activity status of devices by real-time monitoring of the message sending frequency, bandwidth usage, and message success rate of each ECU connected to the ISOBUS virtual terminal; it calculates the bandwidth share of each ECU based on the basic weight set by device type, combined with health and activity status, and dynamically allocates underutilized bandwidth to high-demand devices; it predicts ECU message sending time based on historical sending patterns, detects potential bus conflicts in advance, and formulates sending delay adjustment schemes for low-priority devices; it introduces a token bucket mechanism to control the message sending rate of each ECU, while simultaneously monitoring bus congestion status in real time and triggering corresponding control measures. This invention integrates device status monitoring, weighted fair bandwidth allocation, conflict prediction and avoidance, and token bucket flow control technologies to achieve efficient collaborative communication between multiple ECUs and VTs, significantly improving the communication efficiency and system stability of multi-device collaborative operation in agricultural machinery. Attached Figure Description

[0016] Figure 1 The diagram shown is a structural schematic of an ISOBUS virtual terminal multi-device collaborative scheduling system according to an embodiment of the present invention.

[0017] Figure 2 The diagram shown is a structural schematic of an ISOBUS virtual terminal multi-device collaborative scheduling system according to an embodiment of the present invention. Figure 3 The diagram shown is a flowchart illustrating the ISOBUS virtual terminal multi-device collaborative scheduling method according to an embodiment of the present invention.

[0018] Figure 4 The diagram shown is a structural schematic of an electronic terminal according to an embodiment of the present invention. Detailed Implementation

[0019] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention 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 the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0020] It should be noted that in the following description, reference is made to the accompanying drawings, which illustrate several embodiments of the invention. It should be understood that other embodiments may also be used, and changes in mechanical composition, structure, electrical system, and operation may be made without departing from the spirit and scope of the invention. The following detailed description should not be considered limiting, and the scope of the embodiments of the invention is defined only by the claims of the published patents. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. Spatially related terms, such as “upper,” “lower,” “left,” “right,” “below,” “below,” “lower part,” “above,” “upper part,” etc., may be used herein to illustrate the relationship between one element or feature shown in the figures and another element or feature.

[0021] Throughout this specification, when it is said that a part is "connected" to another part, this includes not only "direct connection" but also "indirect connection" by placing other elements in between. Furthermore, when it is said that a part "includes" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather means that other constituent elements may also be included.

[0022] The terms "first," "second," and "third," etc., used herein are for the purpose of describing various parts, components, regions, layers, and / or segments, but are not limiting. These terms are used only to distinguish one part, component, region, layer, or segment from others. Therefore, the "first part," "component," "region," "layer," or "segment" described below may refer to a "second part," "component," "region," "layer," or "segment" without departing from the scope of this invention.

[0023] Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of the stated feature, operation, element, component, item, kind, and / or group, but do not preclude the presence, occurrence, or addition of one or more other features, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition arise only when combinations of elements, functions, or operations are inherently mutually exclusive in some manner.

[0024] This invention provides an ISOBUS virtual terminal multi-device collaborative scheduling system. By real-time monitoring of the message sending frequency, bandwidth usage, and message success rate of each ECU connected to the ISOBUS virtual terminal, it accurately assesses the health and activity status of the devices. Based on the basic weights set by device type, and combined with health and activity status, it calculates the bandwidth share of each ECU, dynamically allocating underutilized bandwidth to high-demand devices. It predicts ECU message sending time based on historical sending patterns, detects potential bus conflicts in advance, and develops sending delay adjustment schemes for low-priority devices. A token bucket mechanism is introduced to manage the message sending rate of each ECU, while simultaneously monitoring bus congestion status and triggering corresponding control measures in real time. This invention integrates device status monitoring, weighted fair bandwidth allocation, conflict prediction and avoidance, and token bucket flow control technologies to achieve efficient collaborative communication between multiple ECUs and VTs, significantly improving the communication efficiency and system stability of multi-device collaborative operations in agricultural machinery.

[0025] The present invention will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can readily implement it. The present invention can be embodied in many different forms and is not limited to the embodiments described herein.

[0026] like Figure 1 This invention presents a schematic diagram of the structure of an ISOBUS virtual terminal multi-device collaborative scheduling system according to an embodiment of the present invention.

[0027] In modern precision agriculture operations, multiple agricultural machines often need to operate simultaneously. For example, a tractor may be connected to multiple electronic control units (ECUs), such as seeders, fertilizer applicators, sprayers, and monitoring systems. These devices communicate with virtual terminals (VTs) via the ISOBUS CAN bus, sharing the limited bus bandwidth.

[0028] The ISOBUS virtual terminal multi-device collaborative scheduling system includes:

[0029] Device status monitoring module 1 is used to monitor the message sending frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal in real time, and to evaluate the health status and activity status of each ECU device.

[0030] The bandwidth allocation module 2 is used to calculate the bandwidth share of each ECU device based on the basic weight determined by the device type of each ECU device and the health status and activity status of each ECU device, and to reallocate the underutilized bandwidth to ECU devices that need more bandwidth.

[0031] The conflict prediction and avoidance module 3 is used to predict the transmission time of each ECU device based on historical transmission patterns, detect potential conflicts, and generate transmission delay adjustment schemes for low-priority devices.

[0032] The flow control module 4 is used to control the message sending rate of each ECU device using the token bucket mechanism, monitor the bus utilization, and take corresponding control measures according to the bus congestion level.

[0033] In one embodiment, such as Figure 2 The device status monitoring module 1 includes:

[0034] The ECU Registration Manager manages the registration, deregistration, and basic information of all ECU devices connected to the ISOBUS virtual terminal. When a new ECU device connects to the virtual terminal, it initiates a registration process, recording detailed information such as the device's model and unique identifier, and adding the device to the system's management scope. This process ensures the system can accurately identify and track each newly connected device. When a device needs to disconnect, the ECU Registration Manager executes a deregistration process, precisely removing the device's relevant information from the system, ensuring the accuracy and real-time nature of system data. Through this rigorous registration and deregistration management mechanism, the system can clearly understand the list of currently connected devices, providing a solid data foundation for subsequent monitoring.

[0035] The state sampler is used to periodically collect the message sending frequency and bandwidth usage of each ECU device. Its core collection metrics are clearly defined: message sending frequency is measured in "messages / second," and bandwidth usage is measured in "%." The sampling period is flexible and can be configured according to actual business needs, with a default setting of 100ms. This design satisfies the requirements of real-time data, enabling the system to promptly capture device state changes, while also ensuring data continuity, providing a reliable basis for subsequent analysis. During sampling, the state sampler uses a hash table to store the state information of all ECUs, where the key is the ECU address and the value is the corresponding ECU state structure. To ensure secure data access in a multi-threaded environment, a mutex lock is provided. Sampling parameters can be set, with a sampling interval of 100 milliseconds and a statistical time window of 10 seconds.

[0036] The `initialize()` method starts an independent monitoring thread that continuously runs the `monitorLoop()` monitoring loop. Within each monitoring loop, the following steps are executed sequentially at fixed sampling intervals: First, the loop start timestamp is recorded to provide a baseline for subsequent time calculations; then, all registered ECU devices are traversed, and their status statistics are updated one by one, including updating global bus status information and detecting device status changes; if a scheduler update is deemed necessary, a notification is promptly sent to ensure the system can respond to device status changes in a timely manner; finally, the loop duration is calculated, and the start time of the next sampling is adjusted based on the calculation result to ensure that sampling is performed strictly at a fixed interval of 100 milliseconds, guaranteeing the regularity and accuracy of data collection. Specifically, the `updateDeviceStats()` method is responsible for updating the detailed status of a single ECU. It acquires message statistics data from the device within the most recent 10-second time window and calculates and updates key metrics such as message sending frequency per second (total number of messages divided by the time window), bandwidth utilization (total number of bytes divided by the time window), message success rate (the proportion of successful messages to total messages), and average message latency (total latency divided by the number of messages). The sampled data is uploaded to the system database in real time, providing raw data support for subsequent analysis.

[0037] A health evaluator is used to assess the communication health status of devices based on the message success rate of each ECU device.

[0038] The communication health of the devices is assessed based on the message success rate of each ECU. It establishes a detailed set of device health classification standards, dividing device health into five levels:

[0039] EXCELLENT: A message success rate greater than 99% indicates that the device communication status is excellent, message transmission has almost no problems, and the device can operate stably and efficiently.

[0040] Good: The message success rate is between 95% and 99%, the device communication is relatively stable, and only a few message transmission anomalies occur occasionally, which have little impact on the normal operation of the device.

[0041] Fair: The message success rate is in the range of 90% - 95%. There is a certain degree of fluctuation in device communication. It is necessary to closely monitor its status changes and promptly investigate potential problems to prevent them from worsening.

[0042] Poor (POOR): The message success rate is between 80% and 90%. The device communication is poor, and there may be frequent message transmission failures, which will affect the normal operation of some functions of the device. Timely measures need to be taken to repair it.

[0043] Critical: The message success rate is less than 80%, indicating a serious problem with device communication that may severely affect the normal operation of the device. Immediate emergency measures must be taken to investigate and repair the problem in order to avoid serious consequences such as device damage or data loss.

[0044] The activity detector is used to detect whether each ECU device is in active use. It sets three key identifiers and records: indicating whether the device is active (isActive), indicating whether the user is currently interacting with the device (isUserInteracting), and recording the timestamp of the last user action (lastUserActionTime).

[0045] When determining device activity, `lastMessageTime` is used to check for communication activity, updating the `isActive` flag accordingly. Simultaneously, `isUserInteracting` and `lastUserActionTime` are combined to identify user interaction status. Based on this information, device activity is categorized into four levels:

[0046] High: if isUserInteracting is true, it indicates that the user is interacting with the device and the device is in a highly active state. At this time, the device needs more system resources to meet the user's needs.

[0047] In the context of "isActive is true but there is no user interaction", it means that the device is running, but the user is not interacting with it directly. The activity level is moderate, and the device may be performing some background tasks.

[0048] Low: if isActive is false but the device is online, it means that although the device is connected to the network, there are no obvious signs of activity recently, the activity level is low, and the device may be idle.

[0049] Hibernation: The device is offline and in a completely inactive state. At this time, the device does not participate in any system interaction or task execution.

[0050] These activity detection results will provide a priority basis for subsequent bandwidth allocation, ensuring that the system can allocate bandwidth resources reasonably according to the activity level of the devices. Simultaneously, the detection results will be updated to the corresponding fields in the structure, enabling the system to promptly grasp the activity status of the devices and provide accurate information for system resource management and scheduling.

[0051] The demand forecaster is used to predict changes in device bandwidth demand based on historical data. Specifically, the BandwidthPredictor class in the demand forecaster predicts future bandwidth demands based on historical data. Its data storage structure is designed as follows: a hash table is used to store the historical bandwidth data of each ECU, using the ECU address as the key for easy and quick retrieval and access to historical data for a specific device. Each ECU corresponds to a double-ended queue used to store timestamped bandwidth samples, recording changes in bandwidth data over time. The maximum storage size of historical data is set to, for example, 600 samples, covering approximately 10 minutes of data, ensuring sufficient historical data for analysis while avoiding excessive data volume that consumes too many storage resources.

[0052] Its core prediction capabilities encompass two parts: data collection and management, and bandwidth prediction algorithms.

[0053] Data Collection and Management: The `addSample()` method is responsible for receiving new bandwidth samples, which contain the current timestamp and bandwidth value. New samples are added to the end of the historical queue of the corresponding ECU. When the amount of historical data exceeds the maximum limit, the system automatically removes the oldest sample data to ensure that the amount of historical data remains within a reasonable range.

[0054] Bandwidth prediction algorithm: The `predictBandwidth()` method predicts the bandwidth requirement of a specified ECU several seconds in the future. First, it checks the amount of historical data. If there are fewer than 10 samples, it directly returns the most recent sample value to ensure that it still provides a certain predictive reference when data is insufficient. When sufficient historical data is available, it performs a three-step prediction:

[0055] Trend Calculation: Linear regression analysis is used to analyze data trends. The `calculateTrend()` method selects up to 60 recent sample data points, performs linear regression with time as the independent variable (X) and bandwidth as the dependent variable (Y), and calculates the slope of the regression line. This slope reflects the trend of bandwidth change. After normalizing the slope, the bandwidth change rate per minute is obtained. The returned trend value can be used to predict the magnitude of future bandwidth demand growth or decline.

[0056] Periodic detection: Identify periodic patterns in data, such as job cycles, to more accurately grasp the periodic changes in bandwidth demand.

[0057] Baseline prediction: Calculate the moving average of the most recent 30 samples as the baseline prediction value.

[0058] Combining the above three factors, a final predicted value is generated, calculated using the formula: Base value × (1 + Trend × Time factor) × Periodicity factor, while ensuring that the predicted result is not negative. This prediction mechanism can effectively adapt to the dynamic changes in equipment bandwidth requirements, providing strong data support for subsequent bandwidth allocation decisions.

[0059] In one embodiment, such as Figure 2 The bandwidth allocation module 2 includes:

[0060] The weight calculator calculates effective weights for each ECU device based on its device type, activity level, and health status. Specifically, it first accurately retrieves the base weight value from a pre-defined mapping table based on the device type of each ECU. For example, the base weight is preset to 2.0 for safety controllers, 1.5 for seeding / fertilizing controllers, 1.0 for monitoring systems, and 0.5 for diagnostic devices. These base weight settings for different device types reflect their importance in the system and their fundamental differences in bandwidth requirements. Next, the activity status of the ECU devices detected by the activity detector is checked to determine if user interaction exists. If a user is interacting with the device, an activity bonus of 0.5 is added to the device; if the device is only active (with communication activity but no direct user interaction), an activity bonus of 0.2 is added. This bonus mechanism ensures that devices that users are currently using or frequently interact with have a greater advantage in bandwidth allocation. Finally, the health status of the ECU devices is obtained from the health evaluator, and corresponding health factors are assigned according to the health level. Health levels are categorized as Excellent, Good, Average, Poor, and Critical, with corresponding health factors of 1.0, 0.95, 0.9, 0.8, and 0.7, respectively. Healthy devices receive priority access to more bandwidth resources to ensure stable operation. The base weight and activity bonus are added together and then multiplied by the health factor to obtain the final weight for each ECU device. Simultaneously, the final weights of all devices are aggregated to calculate the total weight, providing a proportional basis for subsequent bandwidth allocation based on weight. For example, if there are three devices, ECU1, ECU2, and ECU3, with final weights of 2.0, 1.615, and 1.2, respectively, the total weight is 4.815.

[0061] The fair share calculator is used to calculate the basic bandwidth share of each ECU device according to its effective weight ratio. Specifically, a certain percentage of emergency bandwidth is reserved from the total system bandwidth, with a default reserve of 10%. This reservation mechanism is to cope with emergencies and ensure the normal operation of critical functions. After deducting the reserved emergency bandwidth, the remaining bandwidth is the bandwidth actually available for ordinary message transmission. For example, if the total bandwidth is 250kbps, after reserving 10%, the allocable bandwidth is 28125 bytes / second. The allocable bandwidth is initially allocated according to the proportion of each ECU device in the total weight. Each device receives a corresponding bandwidth share according to this proportion. For example, in the scenario of the three devices mentioned above, ECU1 receives 11682 bytes / second (28125×(2.0÷4.815)), ECU2 receives 9432 bytes / second (28125×(1.615÷4.815)), and ECU3 receives 7011 bytes / second (28125×(1.2÷4.815)).

[0062] The remaining bandwidth reallocator is used to redistribute underutilized bandwidth to ECU devices that need more bandwidth; specifically, it iterates through each ECU device and compares its bandwidth demand predicted by its demand forecaster with the allocated bandwidth in detail.

[0063] If a device is allocated more bandwidth than it needs, the excess bandwidth is released into the "remaining bandwidth pool" so that it can be redistributed to devices that need it more later.

[0064] If a device's bandwidth requirement exceeds its allocated bandwidth, the device will be marked as "needing more bandwidth" and will wait for subsequent allocation of remaining bandwidth.

[0065] Calculate the total weight of all devices that "need more bandwidth" to define the basis for allocation ratios. Based on the weight ratio of each device "needing more bandwidth," redistribute the bandwidth in the "remaining bandwidth pool." During the allocation process, ensure that the additional bandwidth allocated to each device does not exceed its actual shortage. Use a minimum function to prevent over-allocation and ensure the rationality and accuracy of the allocation. For example, if device A has a shortage of 1000 B / s and device B has a shortage of 800 B / s, device A will not be allocated more than 1000 B / s of additional bandwidth when allocating remaining bandwidth.

[0066] After bandwidth allocation is completed, relevant components are promptly notified that the bandwidth allocation has been updated to ensure that all modules in the system receive the latest information synchronously and operate in a coordinated and stable manner. The final bandwidth allocation results for each ECU device are compiled, including allocated bandwidth, token bucket parameters, and other information, and a detailed notification is generated. Through the system's preset communication mechanism, the notification information is sent to all components related to bandwidth allocation, such as the data transmission module and device control module. Upon receiving the notification, the relevant components return confirmation information and adjust their operating parameters according to the new bandwidth allocation scheme to ensure that the entire system operates in a coordinated manner under the new bandwidth allocation.

[0067] Through the close collaboration and detailed execution steps of the above key components, the bandwidth allocation module 2 achieves a dynamic, fair, and efficient bandwidth management mechanism. It can intelligently adjust resource allocation according to the actual needs of the equipment and the system status, thereby improving the overall performance and stability of the system.

[0068] In one embodiment, such as Figure 2 Conflict prediction and avoidance module 3 includes:

[0069] The transmission time predictor is used to predict the next transmission time of ECU devices based on historical transmission patterns. Specifically, it iterates through the device's historical message records, analyzing the historical message transmission records of each device, mainly divided into periodic patterns and statistical patterns. Periodic pattern: For devices exhibiting periodic transmission patterns, the future transmission time is accurately calculated based on their last transmission time and detection cycle. A high confidence level of 0.9 is set for this prediction result. Each predicted event includes detailed information such as transmission time, duration (default setting is 10ms), and probability of occurrence. Predictions are continuously performed until the time window exceeds 100ms. Statistical pattern: For devices with non-periodic transmission, the expected transmission time is calculated using the average message interval method, with a confidence level set at 0.6. Furthermore, the interval value is dynamically updated using an exponentially weighted moving average, thus flexibly adapting to changes in device behavior. During the prediction process, when the start time of a subsequent predicted event is detected to be later than the end time of the current event, the inner loop is terminated early, effectively reducing invalid calculations and improving prediction efficiency.

[0070] A conflict detector is used to detect potential message conflicts within the prediction time window. Specifically, all predicted events are sorted in ascending order of sending time, and a quicksort algorithm is used to ensure O(n log n) time complexity. A double loop checks whether adjacent events overlap. The overlap criterion is that the end time of the preceding event must be greater than the start time of the following event. When overlap is detected, conflict details are recorded: timestamp, involved devices, overlap duration, and conflict probability (confidence product). After generating the conflict list, conflict events with a probability lower than 0.3 are automatically filtered to avoid ineffective scheduling.

[0071] An avoidance strategy generator is used to generate transmission delay adjustment schemes for low-priority devices.

[0072] After generating the avoidance strategy, it needs to be executed through specific scheduling adjustments. Currently, there are two implementation schemes:

[0073] Option 1 (Proactive Coordination): Send a delay suggestion message to the ECU device, allowing the device to adjust its transmission time autonomously based on the suggestion. This option is currently used, as it fully leverages the autonomy of the device and improves system flexibility.

[0074] Option 2 (Passive Buffering): Messages from the ECU device are buffered on the virtual terminal side until the adjusted transmission time is reached before processing. This option is reserved as an alternative to address potential special circumstances and ensure system reliability.

[0075] In one embodiment, the avoidance strategy generator tailors a transmission delay adjustment scheme for low-priority devices based on the conflict detection results, so as to effectively avoid the occurrence of message conflicts.

[0076] Specifically, priority is determined by comparing the effective weights of the conflicting devices. The calculation of device weights comprehensively considers multiple factors, including the device type's base weight, activity bonus, and health factors. Devices with higher weights are classified as high-priority, while devices with lower weights must be avoided. For high-priority devices, their original transmission time remains unchanged; for low-priority devices, their delay is calculated using the formula: conflict overlap time + protection interval (set to 1 millisecond). The purpose of setting a protection interval is to ensure that time prediction errors do not trigger secondary conflicts, thus guaranteeing system stability.

[0077] In one embodiment, to achieve flexible control over bandwidth usage, a token bucket parameter is set to meet the data transmission needs of the device under different conditions. The specific steps are as follows: 20% of the bandwidth allocated to each ECU device is set as the token bucket capacity. This setting allows the device to perform burst transmissions within 200 milliseconds, meeting the burst data transmission needs of the device under certain special circumstances. For example, if the bandwidth allocated to a device is 10000B / s, its token bucket capacity is 2000B. A token filling rate is set, which is equal to the bandwidth value allocated to the ECU device, ensuring the device's continuous data transmission capability under normal conditions. For example, if the allocated bandwidth is 10000B / s, the token filling rate is also 10000B / s, meaning 10000B tokens are filled into the token bucket every second.

[0078] like Figure 2 The flow control module 4 includes:

[0079] The token bucket manager maintains a token bucket for each ECU device to limit the sending rate. Specifically, the token bucket manager is implemented by the FlowController class, which uses a token bucket-based algorithm for precise flow control of each ECU device. The FlowController class uses a hash table as its data storage medium to achieve unified management of the token bucket state for each ECU device. The efficient query characteristics of the hash table ensure that token bucket parameters can be quickly queried and updated, improving system response speed. A mutex mechanism is introduced to resolve concurrent access conflicts to token bucket state data in a multi-threaded environment. When multiple threads operate on the token bucket state simultaneously, the mutex ensures the atomicity and consistency of data operations, preventing data corruption and errors.

[0080] The token bucket parameter update method (updateTokenBucket()) is used to dynamically adjust the flow control parameters of the ECU device. The adjustment includes setting the token filling rate corresponding to the allocated bandwidth of the device and setting the token bucket capacity that determines the burst transmission capacity of the device. During the parameter adjustment process, the number of tokens in the current token bucket remains unchanged, but it will be limited to the newly set upper limit of the token bucket capacity to avoid the token over-limit.

[0081] The sending decision mechanism (checkAndConsume()) is the core logic for determining whether an ECU device message can be sent immediately. The execution process consists of four steps: First, the token replenishment algorithm (refillTokens()) is called to replenish the token bucket; second, the number of tokens in the current token bucket is checked to see if it is sufficient to cover the size of the message to be sent; third, if there are enough tokens, the number of tokens corresponding to the message size is deducted, allowing the message to be sent immediately; fourth, if there are insufficient tokens, the waiting time is calculated based on the token gap and the replenishment rate, and a decision to delay sending is returned. The returned sending decision contains two core pieces of information: a Boolean flag indicating whether immediate sending is allowed; and a parameter indicating the waiting time (in milliseconds), which is 0 if immediate sending is allowed.

[0082] The token replenishment algorithm (refillTokens()) calculates the number of tokens that should be replenished in the token bucket based on the time difference. The execution logic is as follows: First, calculate the time difference since the last token replenishment operation and convert it to seconds; second, calculate the amount of tokens to be replenished according to the formula "number of tokens to be replenished = time difference × filling rate"; finally, update the number of tokens in the token bucket (not exceeding the upper limit of the token bucket capacity) and refresh the timestamp of the last token replenishment.

[0083] The congestion detector is used to detect bus congestion status and obtain the congestion level. The congestion detector detects bus congestion status and obtains the congestion level through a bus status information structure. This structure is a data carrier describing the global operating status of the CAN bus and contains two core fields:

[0084] Capacity information fields: These fields cover four key parameters: total bus bandwidth (e.g., 250kbps corresponds to 31250 bytes / second), total bandwidth allocated to all devices, currently available bandwidth, and bandwidth reserved for emergency messages. These parameters comprehensively reflect the allocation and remaining status of bus resources, providing fundamental data support for congestion detection.

[0085] The utilization metrics field covers three floating-point metrics: current real-time utilization, average utilization, and peak utilization. By quantifying the bus load, these metrics help the detector accurately determine the bus congestion status, providing a basis for subsequent flow control measures.

[0086] The flow control message generator is used to send flow control commands to target devices based on congestion levels. By sending flow control commands at different levels, the target devices can be guided to adjust their data transmission behavior, such as reducing the transmission rate or pausing transmission, thereby effectively alleviating bus congestion and ensuring the stable operation of the entire communication system.

[0087] Through the coordinated operation of the token bucket mechanism, congestion detector, and flow control message generator, the flow control module 4 can flexibly control the bandwidth usage of the ECU device, ensuring the efficiency and stability of data transmission and meeting the communication needs of different scenarios.

[0088] In one embodiment, the congestion state is first divided into five levels based on the real-time bus utilization, with the specific classification criteria as follows:

[0089] No congestion (NONE): When the bus utilization rate is less than 50%, it is determined to be a no-congestion state. At this time, the bus resources are sufficient, each device can carry out data transmission normally and efficiently, the communication system operates smoothly, and no congestion control operation is required.

[0090] Mild congestion (LOW): If the bus utilization is between 50% (inclusive) and 70%, it is in a state of mild congestion. This indicates that the bus is beginning to experience some load, but the overall communication needs can still be maintained. At this time, taking slight rate limiting measures can effectively prevent the congestion from worsening.

[0091] Medium congestion: When the bus utilization rate is between 70% (inclusive) and 85%, it is considered medium congestion. At this time, the bus load increases significantly, communication efficiency decreases, and more significant rate limiting measures are needed to alleviate the pressure on the bus.

[0092] High Congestion: If the bus utilization rate is between 85% (inclusive) and 95%, it enters a high congestion state. At this time, the bus is operating at near full load, and communication is greatly affected. Strict rate limiting measures must be taken to prioritize the smooth communication of critical equipment.

[0093] Severe Congestion: When the bus utilization rate is greater than or equal to 95%, it is considered a severe congestion state. At this time, the bus is extremely congested, communication faces severe challenges, and emergency mode must be activated immediately to ensure the smooth transmission of critical messages.

[0094] The congestion control application method (applyCongestionControl()) adopts progressive control measures based on different congestion levels to ensure that the control intensity matches the degree of congestion. The specific strategies are as follows:

[0095] When experiencing mild congestion, the system sends a flow control command to reduce the bandwidth quota of the lowest priority device. Specifically, it selects one lowest-priority non-critical device and reduces its bandwidth quota by 20%, thus alleviating bus pressure through this small-scale rate limiting. For example, if the device was originally allocated 1000B / s bandwidth, a 20% reduction would reduce its bandwidth to 800B / s. The low-priority device rate limiting method (throttleLowestPriority()) is then called to execute the specific rate limiting operation.

[0096] During moderate congestion, the system sends flow control commands to reduce the bandwidth quotas of multiple low-priority devices. Specifically, it selects two of the lowest-priority non-critical devices and reduces their bandwidth quotas by 30%, thereby expanding the coverage and intensity of rate limiting. Assuming each device originally had an allocated bandwidth of 1000B / s, after a 30% reduction, the bandwidth becomes 700B / s, and then the low-priority device rate limiting method (throttleLowestPriority()) is called to perform rate limiting.

[0097] In cases of severe congestion, the system will send a flow control command to enable emergency mode, allowing only critical messages to be transmitted on the bus. Specifically, this involves performing flow limiting on all non-safety-critical ECU devices, uniformly reducing their bandwidth quotas by 50% to prioritize the communication resources of critical devices. For example, if a non-safety-critical device originally had a allocated bandwidth of 1000B / s, after a 50% reduction, the bandwidth becomes 500B / s. Simultaneously, the low-priority device flow limiting method (throttleLowestPriority()) is invoked to flow limit the relevant devices.

[0098] In the event of severe congestion, the system will immediately activate emergency mode. The specific process involves calling the emergency mode handling method (enableEmergencyMode()) to limit the bandwidth quota of all non-safety-critical ECU devices to the minimum value, i.e., 100 bytes / second, maximizing the release of bus resources. Simultaneously, it ensures unobstructed transmission channels for safety-critical messages, meeting the communication requirements for safe system operation. Furthermore, it records the time the system enters emergency mode, the triggering reason, and other key information, forming an event log for subsequent analysis.

[0099] The low-priority device rate limiting method (throttleLowestPriority()) is the core component of implementing a tiered rate limiting strategy. Its operation is as follows: First, determine the number of low-priority devices requiring rate limiting based on the current congestion level, such as 1 device for light congestion and 2 devices for moderate congestion. Next, reduce the bandwidth quota of the target devices according to a preset ratio, such as 20% for light congestion and 30% for moderate congestion. Then, by calling the token bucket parameter update method of the token bucket manager, synchronously adjust the token filling rate and bucket capacity corresponding to the target devices. For example, if the device's bandwidth quota is reduced, the token filling rate and bucket capacity are also reduced proportionally. Finally, send a flow control command to the controlled devices through the flow control message generator. The command contains the new bandwidth quota information, and the devices transmit data according to the new quota after receiving the command.

[0100] The emergency mode handling method (enableEmergencyMode()) is primarily used to address severe congestion scenarios. Its operation process is as follows: First, the bandwidth quota for all non-safety-critical ECU devices is limited to a minimum of 100 bytes / second, fully releasing bus resources to ensure critical devices have sufficient bandwidth for communication. Second, the transmission channels for safety-critical messages are guaranteed to be completely unobstructed, with no restrictions on their transmission to meet the communication requirements for safe system operation. Finally, the time when the system entered emergency mode, the triggering reason, and other key information are recorded to form an event log. These logs are crucial for subsequent analysis of the causes and patterns of system congestion, providing strong evidence for optimizing system design and congestion control strategies.

[0101] Through this hierarchical congestion control mechanism, the system can flexibly take corresponding control measures according to different bus load conditions, ensuring the quality of critical business communication while achieving reasonable allocation of bus resources, and ensuring stable operation of the system under various load conditions.

[0102] In one embodiment, the system further includes: an emergency message processing module, which includes:

[0103] The emergency message identifier is used to identify emergency messages such as alarms and safety incidents. Specifically, by meticulously analyzing key information such as the message's function code, parameter group number (PGN), or priority bit in the CAN ID, it can quickly and accurately determine whether a message falls into the emergency category. Its recognition range is broad, covering various types including alarm messages, audio signals, safety-critical messages, and emergency stops, ensuring that any emergency that may affect the system's safety and stable operation can be detected in a timely manner.

[0104] An emergency bandwidth reserveer is used to reserve a portion of bus bandwidth specifically for emergency messages. In situations where bus resources are limited, reserving dedicated bandwidth for emergency messages is a crucial measure to ensure their rapid transmission. This component pre-allocates a portion of the bus bandwidth specifically for emergency message transmission. This reservation mechanism avoids competition for bandwidth resources between emergency and regular messages, ensuring that emergency messages receive stable bandwidth support during transmission and guaranteeing their smooth and timely arrival at their destination.

[0105] The Fast Passage Manager enables urgent messages to skip the normal queue and be transmitted immediately. To ensure the fastest possible transmission of urgent messages, the Fast Passage Manager grants them the privilege of bypassing the normal queue. In traditional message transmission processes, messages must queue in a specific order, which can cause delays for urgent messages due to queuing. The Fast Passage Manager breaks this convention, allowing urgent messages to enter the fast processing channel directly for transmission without waiting, significantly reducing transmission time and improving system responsiveness.

[0106] To ensure that high-priority emergency messages, such as alarms and safety-critical instructions, can be sent smoothly with extremely low latency, the system employs a dedicated emergency message fast-channel algorithm. The detailed execution steps of this algorithm are as follows:

[0107] First, the emergency message identifier performs a comprehensive analysis of the message to be sent, determining whether it is an emergency message based on key information such as the message's function code, parameter group number (PGN), or priority bit in the CAN ID. This judgment process is accurate and efficient, quickly filtering out emergency messages that require priority processing and preventing ordinary messages from consuming emergency processing resources. The identifier clearly identifies the type of emergency message, including alarm messages, audio signals, safety-critical messages, emergency stops, etc. Different types of emergency messages may have different levels of urgency and processing requirements; accurate type identification helps to take targeted processing measures, improving processing efficiency and accuracy.

[0108] Once a message is identified as urgent, it skips the normal message queuing process and goes directly to the fast processing channel. This step is crucial for ensuring low-latency transmission of urgent messages, avoiding delays caused by queuing, and enabling urgent messages to be processed as quickly as possible.

[0109] Next, the emergency bandwidth reserver checks whether the reserved emergency bandwidth is sufficient to support the transmission of the emergency message. If the reserved emergency bandwidth is sufficient, the algorithm will immediately use this bandwidth to send the emergency message.

[0110] If the reserved emergency bandwidth is insufficient, the Fast Channel Manager will activate a bandwidth preemption mechanism. Based on a priority strategy, it selects the lowest-priority message among currently transmitting ordinary messages, pauses its transmission, and preempts its bandwidth resources for emergency message transmission. During bandwidth preemption, the manager minimizes the impact on ordinary message transmission, for example, by preempting during gaps in ordinary message transmission. In extreme cases, if preempting ordinary message bandwidth is still insufficient to meet the transmission needs of emergency messages, the Fast Channel Manager will temporarily suspend the communication of the lowest-priority active ECUs. It sends a pause command to these ECUs, causing them to stop sending and receiving messages, thereby freeing up more bandwidth resources for emergency messages. Once the emergency message transmission is complete, the manager will promptly restore normal communication to the suspended ECUs.

[0111] Once the emergency message is successfully sent, the fast-track manager notifies the emergency bandwidth reserver to replenish the reserved bandwidth pool, returning the previously occupied bandwidth resources to the pool. Simultaneously, if any low-priority ECUs were previously paused, the manager sends a recovery command to those ECUs, resuming normal communication. Furthermore, the manager records the emergency message transmission details, including transmission time and bandwidth used, for subsequent analysis and optimization.

[0112] To better describe the ISOBUS virtual terminal multi-device collaborative scheduling system, the following specific embodiments will be used for illustration.

[0113] Example: An ISOBUS virtual terminal multi-device collaborative scheduling system.

[0114] It is applicable to high-load collaborative operation scenarios involving multiple devices.

[0115] After system startup, initialization is completed at T = 0ms. Three ECU connections are detected initially: the seeder controller (ECU1), the fertilizer applicator controller (ECU2), and the operation monitoring system (ECU3). The initial status of each ECU is monitored to determine its activity level and any special needs, allowing for appropriate bandwidth allocation based on actual conditions. 10% (2.5kbps) of the total 250kbps bandwidth is reserved as emergency bandwidth. This ensures sufficient bandwidth for rapid transmission of emergency messages in case of emergencies, guaranteeing the system's safe and stable operation. Subtracting the reserved emergency bandwidth from the total bandwidth yields 22.5kbps available for normal message transmission.

[0116] At T = 100ms, calculate the weights of each ECU. ECU1 is in user interaction mode, and its weight is calculated as follows: The weight is 1.5, which is the base weight; 0.5 is the weight added due to user interaction; and 1.0 is a health factor. ECU2 is in an active state with a weight of [missing value]. 1.5 is the base weight, and 0.2 is the weight added for active status. ECU3 is also in an active state, with a weight of... 1.0 is the base weight, and 0.2 is the weight added for active states. Adding the weights of the three ECUs together gives a total weight of 4.9.

[0117] The available bandwidth of 22.5kbps is allocated based on the proportion of each ECU's weight to the total weight.

[0118] The bandwidth allocated to ECU1 is .

[0119] The bandwidth allocated to ECU2 is .

[0120] The bandwidth allocated to ECU3 is .

[0121] At T = 500ms, the system performs conflict prediction with a prediction window of 100ms to predict the message transmission status of each ECU within a future period, in order to detect potential message conflicts in advance. Therefore, it is predicted that ECU1 will send a message at T + 520ms and ECU2 will send a message at T + 518ms. Since the predicted transmission times of the two ECUs overlap by 2ms, a potential message conflict is detected.

[0122] At T = 505m, the avoidance method is determined based on the weight of each ECU. Since ECU1 has a higher weight, its original transmission time remains unchanged. The transmission time of ECU2 is delayed by 3ms (2ms overlap time plus a 1ms protection interval) to avoid message transmission conflicts with ECU1. The suggestion to delay transmission is sent to ECU2, so that it can send messages according to the new schedule.

[0123] At T = 1000ms, ECU2 requests an increase in bandwidth to 10kbps. At this point, the total demand exceeds the available bandwidth, triggering the reallocation mechanism. Checking ECU1's actual demand, it is found that its actual demand is 8kbps, lower than the previously allocated 9.18kbps, thus triggering reallocation.

[0124] At T = 1100ms, the released bandwidth is redistributed to ECU2, resulting in a new bandwidth allocation of ECU1 = 8kbps, ECU2 ≈ 8.99kbps, and ECU3 = 5.51kbps. This dynamic adjustment achieves rational utilization of bandwidth resources and meets the increased bandwidth requirements of ECU2.

[0125] At T = 2000ms, when the bus utilization rises to 88%, the system detects MEDIUM-level congestion. To alleviate congestion, ECU3, with its relatively low weight and less demanding real-time requirements, is slowed down by 30%. ECU3's new quota is 5.51 * (1 - 30%) ≈ 3.86kbps. A flow control message is sent to ECU3, instructing it to reduce its transmission rate to align with the system's congestion control strategy.

[0126] At T = 2500ms, ECU1 sends an alarm message, which the system identifies as an emergency message via the emergency message identifier. Emergency messages are transmitted using reserved emergency bandwidth, skipping the normal queue and eliminating the need to wait for other ordinary messages. Thanks to the guaranteed emergency bandwidth and fast-channel mechanism, emergency messages can be sent in an extremely short time (< 2ms), ensuring timely handling of emergencies.

[0127] At T = 3000ms, when the congestion eases and the utilization rate drops to 75%, the quota of ECU3 is restored to the original 5.51kbps, so that the system returns to normal operation.

[0128] Similar to the principles of the above embodiments, the present invention provides a method for multi-device collaborative scheduling of ISOBUS virtual terminals.

[0129] The following specific embodiments are provided in conjunction with the accompanying drawings:

[0130] like Figure 3 This document illustrates a flowchart of a multi-device collaborative scheduling method for ISOBUS virtual terminals, as described in an embodiment of the present invention. Applied to agricultural machinery, the method includes:

[0131] Step S1: Monitor the message sending frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal in real time, and assess the health status and activity status of each ECU device.

[0132] Step S2: Calculate the bandwidth share of each ECU device based on the basic weight determined by the device type of each ECU device and the health status and activity status of each ECU device, and reallocate the underutilized bandwidth to ECU devices that need more bandwidth;

[0133] Step S3: Predict the transmission time of each ECU device based on historical transmission patterns, detect potential conflicts, and generate transmission delay adjustment schemes for low-priority devices;

[0134] Step S4: Use the token bucket mechanism to control the message sending rate of each ECU device, detect bus congestion status, and take corresponding control measures.

[0135] Since the implementation principle of the ISOBUS virtual terminal multi-device collaborative scheduling method has been described in the previous embodiments, it will not be repeated here.

[0136] The ISOBUS virtual terminal multi-device collaborative scheduling system provided in this embodiment of the invention can be implemented on the terminal side or the server side. Regarding the hardware structure of the electronic terminal, please refer to... Figure 4 This is a schematic diagram of an optional hardware structure of an electronic terminal 1000 provided in an embodiment of the present invention. The terminal 1000 can be a mobile phone, computer device, tablet device, personal digital processing device, factory back-end processing device, etc. The terminal 1000 includes: at least one processor 1001, a memory 1002, at least one network interface 10010, and a user interface 1009. The various components in the device are coupled together through a bus system 1005. It is understood that the bus system 1005 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 1005 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 All buses are labeled as bus systems.

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

[0138] It is understood that memory 1002 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), which serves 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.

[0139] In this embodiment of the invention, the memory 1002 is used to store various types of data to support the operation of the terminal 1000. Examples of this data include: any executable program for operation on the terminal 1000, such as the operating system 10021 and application program 10022; the operating system 10021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application program 10022 may contain various applications, such as media players, browsers, etc., for implementing various application services. The ISOBUS virtual terminal multi-device collaborative scheduling system provided in this embodiment of the invention can be included in the application program 10022.

[0140] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by the processor 1001. The processor 1001 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 1001 or by instructions in the form of software. The processor 1001 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. The processor 1001 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor 1001 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 a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0141] In an exemplary embodiment, the terminal 1000 may be used to execute the aforementioned method by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs).

[0142] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented using computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0143] In the embodiments provided in this application, the computer-readable and writable storage medium may include read-only memory, random access memory, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, flash memory, USB flash drive, portable hard drive, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Additionally, any connection may be appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. However, it should be understood that computer-readable and writable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are intended for non-transient, tangible storage media. The disks and optical discs used in the application include compact optical discs (CDs), laser optical discs, optical discs, digital multifunction optical discs (DVDs), floppy disks, and Blu-ray discs, where disks typically copy data magnetically, while optical discs use lasers to copy data optically.

[0144] In summary, the ISOBUS virtual terminal multi-device collaborative scheduling system, method, and terminal of this invention accurately assess the health and activity status of devices by real-time monitoring of the message sending frequency, bandwidth usage, and message success rate of each ECU connected to the ISOBUS virtual terminal. Based on the basic weights set by device type, and combined with health and activity status, the bandwidth share of each ECU is calculated, dynamically allocating underutilized bandwidth to high-demand devices. Based on historical sending patterns, ECU message sending time is predicted to detect potential bus conflicts in advance, and a sending delay adjustment scheme is developed for low-priority devices. A token bucket mechanism is introduced to manage the message sending rate of each ECU, while simultaneously monitoring bus congestion status and triggering corresponding control measures in real time. This invention integrates device status monitoring, weighted fair bandwidth allocation, conflict prediction and avoidance, and token bucket flow control technologies to achieve efficient collaborative communication between multiple ECUs and VTs, significantly improving the communication efficiency and system stability of multi-device collaborative operation in agricultural machinery. Therefore, this invention effectively overcomes the various shortcomings of existing technologies and has high industrial application value.

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

Claims

1. An ISOBUS virtual terminal multi-device collaborative scheduling system, characterized in that, Applied to agricultural machinery and equipment, including: The device status monitoring module is used to monitor the message sending frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal in real time, and to evaluate the health status and activity status of each ECU device. The bandwidth allocation module is used to calculate the bandwidth share of each ECU device based on the basic weight determined by the device type of each ECU device and the health status and activity status of each ECU device, and to reallocate the underutilized bandwidth to ECU devices that need more bandwidth. The conflict prediction and avoidance module is used to predict the transmission time of each ECU device based on historical transmission patterns, detect potential conflicts, and generate transmission delay adjustment schemes for low-priority devices. The flow control module is used to control the message sending rate of each ECU device using the token bucket mechanism, and to detect bus congestion and take corresponding control measures.

2. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 1, characterized in that, The device status monitoring module includes: The ECU Registration Manager is used to manage the registration, deregistration, and basic information of each ECU device connected to the ISOBUS virtual terminal. A status sampler is used to periodically sample the message transmission frequency and bandwidth usage of each ECU device; A health evaluator is used to assess the communication health status of devices based on the message success rate of each ECU device. Activity detectors are used to detect whether each ECU device is in an active operating state; Demand forecasters are used to predict changes in the bandwidth demand of devices based on historical data.

3. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 2, characterized in that, The bandwidth allocation module includes: The weight calculator is used to calculate effective weights based on the device type, activity level, and health status of each ECU device. Fair Share Calculator, used to calculate the base bandwidth share of each ECU device according to the effective weight ratio; The remaining bandwidth reallocator is used to redistribute underutilized bandwidth to ECUs that require more bandwidth, based on each ECU's base bandwidth share and bandwidth requirements.

4. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 3, characterized in that, The conflict prediction and avoidance module includes: A transmission time predictor is used to predict the next transmission time of the ECU device based on historical transmission patterns; wherein, historical transmission patterns include: periodic patterns or statistical patterns; A conflict detector is used to detect potential message conflicts within a prediction time window; An avoidance strategy generator is used to generate transmission delay adjustment schemes for low-priority devices.

5. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 4, characterized in that, The avoidance strategy generator is used to compare the effective weights of the conflicting devices. The ECU device with the higher weight is determined to be of high priority, and the ECU device with the lower weight is determined to be of low priority. The delay time is calculated so that the high-priority ECU device maintains its original transmission time, while the low-priority ECU device delays transmission based on the delay time.

6. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 5, characterized in that, The flow control module includes: The token bucket manager is used to maintain a token bucket for each ECU device to limit the sending rate; A congestion detector is used to detect bus congestion status and obtain the congestion level; The flow control message generator is used to send flow control commands to the target device based on the congestion level.

7. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 6, characterized in that, Sending flow control commands to the target device based on the congestion level includes: When the congestion level is mild, send a flow control command to reduce the bandwidth quota of the lowest priority device; When the congestion level is moderate, send flow control commands to reduce the bandwidth quotas of multiple low-priority devices. When the congestion level is severe, send a flow control command to enable emergency mode and allow only critical messages to be transmitted on the bus.

8. The ISOBUS virtual terminal multi-device collaborative scheduling system according to claim 7, characterized in that, The system further includes: an emergency message processing module, which includes: Emergency message recognizer, used to identify emergency messages such as alarms and security alerts; Emergency bandwidth reserveer, used to reserve a portion of bus bandwidth specifically for emergency messages; The Fast Passage Manager enables urgent messages to skip the normal queue and be transmitted immediately.

9. A method for multi-device collaborative scheduling of ISOBUS virtual terminals, characterized in that, Applied to agricultural machinery and equipment, the method includes: Real-time monitoring of message sending frequency, bandwidth usage, and message success rate of each ECU device connected to the ISOBUS virtual terminal, and assessment of the health status and activity status of each ECU device; The bandwidth share of each ECU device is calculated based on the basic weight determined by the device type of each ECU device, as well as the health status and activity status of each ECU device, and the underutilized bandwidth is reallocated to ECU devices that need more bandwidth; Based on historical transmission patterns, the transmission time of each ECU device is predicted, potential conflicts are detected, and a transmission delay adjustment scheme is generated for low-priority devices. The token bucket mechanism is used to control the message sending rate of each ECU device and to detect bus congestion and take corresponding control measures.

10. An electronic terminal, characterized in that, include: One or more memories and one or more processors; The one or more memories are used to store computer programs; The one or more processors are connected to the memory and are used to run the computer program to perform the method as described in claim 9.

Images