A cloud computing-based agricultural data service interface method, device and medium

Abstract

This invention discloses a cloud computing-based agricultural data service interface method, device, and medium, relating to the fields of smart agriculture and edge computing technology. The method includes: performing time-series pattern analysis on network service request logs using a Long Short-Term Memory (LSTM) network to predict the content and parameters of network service requests initiated by agricultural edge devices to the cloud service interface within a future time window, generating a predictive set of network service requests; based on the predictive set of network service requests and the latest real-time status data, collaboratively arbitrating a set of service processing strategies, and dynamically determining the service mode and interface cooperation method for each predictive network service request, generating network service interface cooperation instructions. This invention, by employing a LSM network to perform time-series pattern analysis on network service request logs and generating a service request prediction probability matrix, achieves proactive prediction of future service requests from agricultural edge devices, significantly improving the foresight of resource scheduling.

Description

Technical Field

[0001] This invention relates to the fields of smart agriculture and edge computing technology, and in particular to a cloud computing-based agricultural data service interface method, device and medium. Background Technology

[0002] Against the backdrop of the deep integration of industrial cloud computing and smart agriculture, agricultural data service interfaces serve as a crucial hub connecting cloud computing capabilities with real-time edge operations. Their processing efficiency directly impacts the overall service responsiveness. Conventional methods primarily focus on collecting and storing real-time status data reported by agricultural edge devices, and responding instantly and logging received network service requests. The cloud platform, based on preset resource allocation strategies or load balancing algorithms, schedules and processes the received network service requests, completing basic computing task distribution and data interaction, thus providing fundamental support for the access and data aggregation of large-scale agricultural equipment.

[0003] However, conventional methods have limitations when dealing with agricultural service requests that have time-series characteristics; resource allocation based on the statistical characteristics or static rules of historical requests fails to delve into the time-series patterns in network service request logs, resulting in insufficient predictive ability for future requests; in the resource allocation process, the focus is on matching immediate demand, and there is a lack of a forward-looking arbitration mechanism for changes in the future resource status of equipment and potential resource competition between multiple predictive requests. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a cloud computing-based agricultural data service interface method to solve the problems of insufficient accuracy in time-series prediction of agricultural service requests and low efficiency in resource coordination when multiple requests are concurrent.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a cloud computing-based agricultural data service interface method, comprising: a cloud service interface collecting and maintaining real-time status data periodically reported by multiple agricultural edge devices, and simultaneously recording network service request logs arriving at the cloud service interface; performing time-series pattern analysis on the network service request logs using a Long Short-Term Memory (LSTM) network to predict the content and parameters of network service requests initiated by agricultural edge devices to the cloud service interface within a future time window, thereby generating a predictive network service request set; generating a candidate execution node list and implementing node pre-allocation based on a predefined edge device status registry and real-time status data, through matching and evaluation of requested resource requirements and device comprehensive capabilities, thereby generating a service processing strategy set; performing collaborative arbitration on the service processing strategy set based on the predictive network service request set and the latest real-time status data, and dynamically determining the service mode and interface cooperation method for each predictive network service request, thereby generating a network service interface collaboration instruction; and, according to the network service interface collaboration instruction, having the cloud service interface and the corresponding agricultural edge device service interface collaboratively execute predictive data processing and pre-transmission to generate a predictive service data set.

[0007] In a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the steps for recording network service request logs arriving at the cloud service interface are as follows: The real-time status data includes the computing load, storage availability, network bandwidth utilization, and request response latency of agricultural edge devices; The cloud service interface receives and parses network service requests, extracts the request method, URL endpoint, request header information and payload data, and associates and formats them with the server response status, session identifier and request arrival time to generate network service request logs.

[0008] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the step of performing time-series pattern analysis on network service request logs through a Long Short-Term Memory (LSTM) network to predict the content and parameters of network service requests initiated by agricultural edge devices to the cloud service interface within a future time window, and generating a predictive network service request set, is as follows: Clean the network service request logs and extract service behavior features to generate request behavior time-series feature data; The temporal feature data of request behavior is input into a long short-term memory network, and the periodicity and dependency relationship in the historical request sequence is learned through a gated recurrent mechanism to generate a service request prediction probability matrix. High-probability prediction points exceeding a preset confidence threshold are selected from the service request prediction probability matrix, and service interface protocol decoding and request parameter mapping are performed to generate an initial predictive request set. The initial predictive request set is subjected to compliance verification and service logic conflict resolution based on agricultural business rules to generate a predictive network service request set.

[0009] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the step of generating a candidate execution node list by matching and evaluating the request resource requirements with the comprehensive capabilities of the equipment includes the following steps: Extract the resources required for the service interface call of each predictive network service request from the predictive network service request set, and generate a request resource requirement parameter set; Extract the static capability configuration of each agricultural edge device from the edge device status registry, and associate it with the latest real-time status data to generate a snapshot of the device's overall capabilities. The resource requirement parameter set is compared with the snapshot of the overall equipment capabilities to calculate the suitability of each agricultural edge device as a response node for the corresponding predictive network service request, and a request-equipment feasibility assessment matrix is ​​generated. All agricultural edge devices with a fit score higher than the fit score threshold are selected from the request-device feasibility assessment matrix and organized into a candidate execution node list.

[0010] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the steps for generating the service processing strategy set are as follows: The candidate execution node list is dynamically weighted and sorted to generate a node optimization sequence; Based on the node selection sequence, a primary and backup execution node is assigned to each predictive network service request, and the corresponding service interface call process and communication protocol parameters are set according to the pre-set policy rule base to form a service processing policy set.

[0011] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the steps of collaborative arbitration of the service processing strategy set are as follows: The predictive network service request set, the service processing strategy set, and the latest real-time status data are integrated to form a collaborative arbitration input dataset; Based on the collaborative arbitration input dataset, the effectiveness and potential conflicts of various service processing strategies under the latest resource status are evaluated, and a strategy feasibility judgment table is generated.

[0012] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the steps for generating network service interface collaboration instructions are as follows: Based on the strategy feasibility assessment table, conflict resolution and global optimization are performed on each service processing strategy to determine the unique service mode for each predictive network service request and generate the final service mode allocation list. The final service mode allocation list is processed for service interface mapping to determine the specific interface call chain, data exchange format and collaboration sequence of each predictive network service request, and to generate an interface collaboration mode specification table. The final service mode allocation list and interface collaboration method specification table are integrated and encoded into network service interface collaboration instructions.

[0013] As a preferred embodiment of the cloud computing-based agricultural data service interface method of the present invention, the steps for generating the predictive service dataset are as follows: The network service interface collaborative instructions are collaboratively distributed to the cloud itself and the corresponding agricultural edge device service interfaces, and predictive data processing is performed in parallel to generate task processing result data blocks. The cloud service interface acts as a coordination center, aggregating and integrating all task processing result data blocks to generate a predictive service data set.

[0014] In a second aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein when the computer program is executed by the processor, it implements any step of the cloud computing-based agricultural data service interface method described in the first aspect of the present invention.

[0015] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the cloud computing-based agricultural data service interface method described in the first aspect of the present invention.

[0016] The beneficial effects of this invention are as follows: by using a long short-term memory network to perform time-series pattern analysis on network service request logs and generating a service request prediction probability matrix, proactive prediction of future service requests from agricultural edge devices is achieved, significantly improving the foresight of resource scheduling; by performing collaborative arbitration on the set of service processing strategies and generating collaborative instructions for network service interfaces, the resource contention problem during multiple concurrent requests is solved, and precise collaboration between cloud and edge services is achieved, ensuring the continuity of agricultural operation processes. Attached Figure Description

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

[0018] Figure 1 A flowchart of a cloud-based agricultural data service interface method.

[0019] Figure 2 A flowchart for generating a predictive set of network service requests for time series pattern analysis.

[0020] Figure 3 A flowchart for generating a set of service processing strategies for resource matching assessment.

[0021] Figure 4 A flowchart for generating collaborative instructions for the network service interface in collaborative arbitration. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0025] Reference Figures 1-4 This is one embodiment of the present invention, which provides a cloud computing-based agricultural data service interface method, including the following steps: S1, the cloud service interface collects and maintains real-time status data periodically reported by multiple agricultural edge devices, and records network service request logs arriving at the cloud service interface.

[0026] S1.1: Real-time status data includes the computing load, storage availability, network bandwidth utilization, and request response latency of agricultural edge devices.

[0027] It should be noted that computing load refers to the busyness of computing resources when agricultural edge devices process tasks, and is obtained by statistical calculation of processor working status, number of service processes being executed, and task scheduling queue length; available storage refers to the amount of remaining available storage space on agricultural edge devices, and is obtained through storage drive status; network bandwidth utilization is the ratio of the actual data transmission rate of the agricultural edge device's network connection at a specific moment to its maximum theoretical rate, and is obtained by reading the real-time throughput statistics of the device's network adapter; request-response latency refers to the time interval from when the agricultural edge device sends a complete request to the cloud service interface to when the device receives the first response byte returned by the cloud, and is obtained by timestamping the request arrival time and response return time and calculating the difference.

[0028] S1.2: The cloud service interface receives and parses network service requests, extracts the request method, URL endpoint, request header information and payload data, and associates and formats them with the server response status, session identifier and request arrival time to generate network service request logs.

[0029] Furthermore, the cloud service interface receives network service requests from agricultural edge devices, immediately records the arrival time of the network service request, and divides the network service request into request line segment, request header segment, and payload segment according to the HTTP protocol (Hypertext Transfer Protocol) format. The request line segment is split using spaces as delimiters to separate the request method and the URL endpoint containing the complete query string. The URL endpoint is further split into path and query parameter parts using question marks as delimiters. The request header segment is parsed line by line, with each line separated by colons and spaces to extract the field names and values ​​of the request header information. For the payload segment, based on the network service... The Content-Type field in the request header of the service request is parsed: if it is application / json (a lightweight data interchange format), the payload segment is parsed into structured data; otherwise, Base64 encoding is performed to generate a recordable payload data field, and the returned server response status is recorded. At the same time, the session identifier is determined based on the unique identifier carried in the network service request. The request method, URL endpoint, request header information, payload data, server response status, session identifier, and request arrival time of the network service request are aligned and combined at the field level and encapsulated to generate a network service request log.

[0030] S2. By performing time-series pattern analysis on network service request logs through a long short-term memory network, the content and parameters of network service requests initiated by agricultural edge devices to cloud service interfaces within future time windows are predicted, generating a predictive set of network service requests.

[0031] S2.1: Clean the network service request logs and extract service behavior features to generate request behavior time-series feature data.

[0032] Furthermore, records with server response status codes of error (e.g., 4xx or 5xx), missing session identifiers, and empty payload data fields are removed from the network service request logs. The request arrival time field is also standardized. From the cleaned network service request logs' URL endpoints, dynamic parameters such as numbers and string IDs are matched and replaced using regular expressions to extract hierarchical path templates with a fixed structure. Finally, the request methods in the network service request logs are mapped to operation type codes (e.g., GET is mapped to 1, POST to 2, PUT to 3, and DELETE to 4). The system parses the load data field of the network service request log, identifies the parameter names and extracts the corresponding parameter values, and converts the combination of parameter names and parameter values ​​into a numerical vector. It calculates the time difference of the request arrival time field in two consecutive network service request log entries as the time sequence interval feature, and sorts the network service request log entries under the same session identifier according to the request arrival time to form a session sequence with an order number. It then arranges and combines the hierarchical path template, operation type encoding, load vector, time sequence interval feature and session sequence identifier in the order of request arrival time to generate request behavior time sequence feature data.

[0033] It should be noted that when converting the combination of parameter names and parameter values ​​into a numerical vector, a complete set of parameter names is obtained in advance based on the statistics of historical network service request logs, a parameter name dictionary is constructed, and the parameter name dictionary is numbered in a fixed order. When parsing the load data of each network service request log, the corresponding parameter value is mapped to a fixed-dimensional vector position according to the number position of the parameter name in the parameter name dictionary. For parameter names that do not appear in the current load data, a default value (such as zero) is filled in the corresponding vector position. When the parameter value is a numeric type, the normalized numerical representation is used directly. When the parameter value is a non-numeric type, the parameter value is converted into the corresponding numerical code, so that the load data of different network service request logs have a unified dimensional structure after vectorization, generating a load vector that can be used for time series modeling.

[0034] S2.2: Input the temporal feature data of the request behavior into the Long Short-Term Memory network, and learn the periodicity and dependency relationship in the historical request sequence through the gated recurrent mechanism to generate a service request prediction probability matrix.

[0035] It should be noted that the training of the Long Short-Term Memory (LSTM) network is as follows: Historical request behavior temporal feature data is collected and divided into continuous training sequences with fixed time steps. The actual network service request type corresponding to the feature data of the last time step of each training sequence is used as the training label. All training sequences are randomly divided into training and validation sets according to a fixed ratio. In the training set, the training sequences with the last label removed are input into the LTM network. The training sequences are processed step-by-step through a gated loop mechanism consisting of a forget gate, an input gate, and an output gate to obtain the predicted probability distribution of the network service request type for the next time step. By comparing the difference between the predicted probability distribution and the true label, the prediction error is calculated using the cross-entropy loss function, and the Adam optimization algorithm is used to iteratively update the parameters of the LTM network through backpropagation. In the validation set, the trained LTM network is periodically used for forward inference to calculate the validation error. Training is terminated when the validation error no longer decreases over multiple consecutive training cycles, resulting in the trained LTM network.

[0036] Furthermore, the request behavior temporal feature data is organized into a request sequence of fixed time step length according to the order of request arrival time. After processing each feature dimension in the request behavior temporal feature data using the min-max normalization method, it is sequentially input into the Long Short-Term Memory (LSTM) network. At each time step, the LSM network receives the corresponding request behavior temporal feature vector. The forget gate determines which information to discard from the network's internal memory state of the previous time step (e.g., forgetting the feature pattern of device data query requests that occurred a week ago and are irrelevant to the current prediction time). The input gate determines which new information in the request behavior temporal feature data of the current time step to store in the network's internal memory state (e.g., storing the latest specific load parameter vector pattern used for device control command issuance requests). The output gate generates the hidden state output of the current time step based on the updated LSM network unit state. By iterating the above process along the time sequence, the LSM network learns the periodic patterns and dependencies implicit in the historical request sequence. The hidden state output of the last time step is passed to a fully connected layer, processed by the softmax activation function, to generate a service request prediction probability matrix representing various possible future network service requests and their corresponding probabilities of occurrence.

[0037] It should be noted that the service request prediction probability matrix defines all possible network service request types through column dimensions, defines future time windows through row dimensions, and quantifies the probability of each network service request occurring at each future moment through matrix element values ​​(probabilities). It reflects the temporal patterns and rules learned from historical request behavior, and provides a direct and accurate probabilistic basis for the subsequent generation of executable predictive network service request sets.

[0038] S2.3: Select high-probability prediction points that exceed the preset confidence threshold from the service request prediction probability matrix, and perform service interface protocol decoding and request parameter mapping to generate an initial predictive request set.

[0039] Furthermore, points with element values ​​greater than the confidence threshold are selected from the service request prediction probability matrix as high-probability prediction points. Based on the network service request type encoding corresponding to the column index and in conjunction with the HTTP protocol specification, the type encoding is decoded into specific request methods (such as GET or POST) and URL path templates. According to the load vector and path parameter pattern recorded in the time-series feature data of the request behavior at the last time step of the Long Short-Term Memory network processing sequence, the load vector is restored to key-value pair request parameters (e.g., device_id: 123, command: "irrigate") through reverse lookup. A structured request object containing future time points, request methods, URL endpoints, and load data is generated for each high-probability prediction point and integrated to generate an initial predictive request set.

[0040] It should be noted that the confidence threshold is set as follows: The 70th to 95th percentile interval of all probability values ​​in the service request prediction probability matrix corresponding to the validation set is calculated as the baseline interval. Within the baseline interval, a set of candidate confidence thresholds is generated with a fixed step size (e.g., 0.01). For each candidate confidence threshold, prediction points higher than the candidate confidence threshold are selected from the service request prediction probability matrix and compared with the actual network service requests that occurred in the validation set. Precision and recall are calculated separately, and a precision-recall curve is plotted. Finally, the value corresponding to the balance point on the precision-recall curve that simultaneously satisfies the minimum requirement of precision (e.g., not lower than 85%) and the optimal recall is selected as the confidence threshold. An exemplary value range is 0.7 to 0.95. If it is higher than 0.95, there are too few effective prediction points, which may miss more potential request types and reduce the coverage of future request changes by the initial predictive request set. If it is lower than 0.7, it may increase the risk of invalid calculations and errors in the subsequent compliance verification and resource matching process.

[0041] S2.4: Perform compliance verification and service logic conflict resolution based on agricultural business rules on the initial predictive request set to generate a predictive network service request set.

[0042] Furthermore, based on agricultural business rules, the request method, URL endpoint, load data, and corresponding business semantics of each predictive request in the initial predictive request set are verified item by item to determine whether the predictive requests meet the time period constraints, device status constraints, business sequence constraints, and resource consumption constraints, and predictive requests that violate agricultural business rules are removed. For predictive requests that pass the compliance verification, service logic conflict resolution processing is performed. According to the order of request arrival time, predictive requests with the same URL endpoint and the same operation object, or those that generate mutually exclusive control commands to the same agricultural edge device, are compared. Predictive requests with higher priority or more reasonable time sequence are retained, and predictive requests with conflicts are removed. The predictive requests that have passed the agricultural business rule verification and completed service logic conflict resolution are summarized to generate a predictive network service request set.

[0043] It should be noted that agricultural business rules are used to describe the permissible scope and execution order of network service requests in agricultural production scenarios at the time, object, and operation levels. These rules are jointly determined by agricultural production process specifications, agricultural equipment usage specifications, and historical operational experience, and are explicitly specified in the form of rule entries during the business configuration phase. These rules include: operation time constraints, which limit predictive requests to occur only within permitted agricultural operation time windows (e.g., 05:00–09:00, 17:00–21:00); device status constraints, which limit predictive requests to be executed only when the agricultural edge device is in the corresponding operating or controllable state; business sequence constraints, which limit the sequential dependencies between different predictive requests to avoid violating the calling order of agricultural operation processes; resource consumption constraints, which limit the number of data processing requests that an agricultural edge device can simultaneously handle within the same time window; and mutual exclusion operation constraints, which limit the simultaneous existence of conflicting predictive requests targeting the same agricultural edge device or the same operation object.

[0044] S3. Based on the predefined edge device status registry and real-time status data, generate a candidate execution node list by matching and evaluating the resource requirements with the overall capabilities of the devices, implement node pre-allocation, and generate a set of service processing strategies.

[0045] S3.1: Extract the resources required for the service interface call of each predictive network service request from the predictive network service request set, and generate a request resource requirement parameter set.

[0046] Furthermore, based on the predictive network service request set, the URL endpoint of each predictive network service request is extracted. The required service type is determined according to the URL endpoint path structure (e.g., " / analyze / " for data analysis service, " / control / " for device control service). Combined with specific parameters in the load data (e.g., resolution) and referring to historical resource consumption data, the computing resource requirements, including the number of CPU cores and computing time, are derived. The storage resource requirements are determined based on the data volume field (e.g., size:2048) explicitly identified in the predictive network service request. Based on the request method of the predictive network service request (POST method means a large amount of upstream data, GET method means a large amount of downstream data) and the load data volume, the required network bandwidth is estimated with reference to historical transmission rates to form the network resource requirements. The business fields (e.g., "max_delay", "deadline") in the load data are checked, and the maximum allowable response time is extracted as the latency requirement. The computing resource requirements, storage resource requirements, network resource requirements, and latency requirements of each predictive network service request are integrated into a structured record to form a request resource requirement parameter set.

[0047] S3.2: Extract the static capability configuration of each agricultural edge device from the edge device status registry, associate it with the latest real-time status data, and generate a snapshot of the device's comprehensive capabilities.

[0048] Furthermore, the static capability configuration of each agricultural edge device is read from the edge device status registry, based on the device identifier, including processor model and number of cores, total memory capacity, total storage capacity, and rated network interface bandwidth. Based on the unique identifier of each agricultural edge device, the latest periodically reported real-time status data collected and maintained by the cloud service interface is matched and associated, including computing load, storage availability, network bandwidth utilization, and request response latency. The static capability configuration is merged and assembled with the latest real-time status data to generate a comprehensive device capability snapshot for each agricultural edge device, which includes both static capabilities and real-time status.

[0049] It should be noted that the edge device status registry is used to record the basic static capability information of all agricultural edge devices. It is constructed by collecting and recording fixed configuration information such as device identifier, processor model and number of cores, total memory capacity, total storage capacity and rated bandwidth of network interface through the registration process when each agricultural edge device is first connected.

[0050] S3.3: Compare the requested resource requirement parameter set with the snapshot of the overall equipment capabilities, calculate the suitability of each agricultural edge device as a response node for the corresponding predictive network service request, and generate a request-equipment feasibility assessment matrix.

[0051] Furthermore, the computational resource requirements, storage resource requirements, network resource requirements, and latency requirements corresponding to each predictive network service request in the resource requirement parameter set are compared item by item with the available computing power, available storage, available network communication power, and request response latency corresponding to each agricultural edge device in the device comprehensive capability snapshot. During the comparison process, it is determined whether the resource requirements of the predictive network service request do not exceed the carrying capacity of the agricultural edge device under the current device comprehensive capability snapshot for each resource constraint dimension, and the corresponding suitability score is calculated based on the resource margin and latency satisfaction obtained from the comparison. The suitability scores of all agricultural edge devices under the same predictive network service request are summarized and filled into a two-dimensional structure to form a request-device feasibility assessment matrix with predictive network service requests as rows and agricultural edge devices as columns.

[0052] The expression for calculating the fit score is: ; in, Indicates a predictive network service request equipment at the edge of agriculture Compatibility rating on the platform; This indicates the total number of resource dimensions participating in the comparison. Indicates a predictive network service request For the first The demand for such resources, when When =1, it represents the computing resource requirement (such as the required number of CPU cores). When = 2, it represents the storage resource requirement (such as the required storage space size). When =3, it represents the network resource requirement (such as the required network bandwidth). Indicates agricultural edge equipment In the current snapshot of overall equipment capabilities, the first... The availability of class resources, when When =1, it represents available computing power (e.g., the number of available CPU cores). When =2, it represents the available storage capacity. When =3, it represents the available network communication capability (such as available network bandwidth). This indicates that all agricultural edge devices are in the first... The maximum available capacity on a resource class is used to normalize the difference between resource demand and resource capacity. Indicates a predictive network service request The latency requirement, i.e., the maximum allowable response time; Indicates agricultural edge equipment Current request response latency; This represents the maximum latency requirement among all predictive network service requests; Indexed by resource dimension; Index for predictive network service requests; Index for agricultural edge devices.

[0053] S3.4: Filter out all agricultural edge devices with a fit degree higher than the fit degree threshold from the request-device feasibility assessment matrix and organize them into a candidate execution node list.

[0054] Furthermore, the adaptation score corresponding to the agricultural edge device in the request-device feasibility assessment matrix is ​​compared with the adaptation threshold. For agricultural edge devices with an adaptation score greater than the adaptation threshold, it is determined that they meet the resource requirements and latency requirements of the predictive network service request under the current device comprehensive capability snapshot conditions, and a list of candidate execution nodes corresponding one-to-one with the predictive network service request is compiled.

[0055] It should be noted that the process of setting the suitability threshold is as follows: For historically completed predictive network service requests, the suitability score of the corresponding agricultural edge device is calculated, and the data is classified and statistically analyzed according to whether execution failure, resource overrun, or response timeout occurred, resulting in two types of suitability score distributions: "successful execution" and "execution risk". The overlap interval and separation trend of the two types of suitability score distributions are analyzed, and the boundary position that can effectively distinguish between requests that can stably bear requests and those with obvious execution risks is selected as the suitability threshold. An exemplary value range is 0.6 to 0.8. If it is higher than 0.8, it is easy to lead to insufficient selectable agricultural edge devices and reduce the coverage and fault tolerance of the predictive network service request set. If it is lower than 0.6, it is easy to select more agricultural edge devices with insufficient resource reserves and high latency risks, which will increase the probability of timeouts and failures in subsequent execution stages.

[0056] S3.5: Perform dynamic weighted evaluation and sorting of each execution node in the candidate execution node list to generate a node optimization sequence.

[0057] Furthermore, based on the latest real-time status data of each execution node (i.e., agricultural edge device) in the device comprehensive capability snapshot, dynamic evaluation indicators for each execution node for the current predictive network service request are calculated, including real-time computing resource reserves, real-time storage resource reserves, real-time network resource reserves, and estimated request processing latency. According to the resource demand characteristics of the predictive network service request, appropriate weights are assigned to each dynamic evaluation indicator. Based on the assigned weights, the dynamic evaluation indicators of each execution node are weighted and calculated to obtain the comprehensive resource adaptation score of each execution node. Then, all execution nodes in the candidate execution node list are sorted in descending order of comprehensive resource adaptation score to generate a node optimization sequence.

[0058] It should be noted that the weight setting process used in the comprehensive score of resource adaptation is as follows: the dominant type of resource demand is determined based on the URL endpoint and request method of the predictive network service request; based on historical execution data, the Pearson correlation coefficient between each dynamic evaluation indicator in the comprehensive capability snapshot of the computing device and the success rate of similar request execution is calculated, and the minimum-maximum normalization process is performed. The normalized correlation coefficient value is used as the weight of the corresponding dynamic evaluation indicator, and the sum of the weights of each dynamic evaluation indicator is always 1.

[0059] S3.6: Based on the node optimization sequence, assign the preferred and backup execution nodes for each predictive network service request, and set the corresponding service interface call process and communication protocol parameters according to the preset policy rule base to form a service processing strategy set.

[0060] Furthermore, for each predictive network service request, the corresponding node preference sequence is read, and the agricultural edge device ranked first is selected as the primary execution node, while the agricultural edge device ranked second is selected as the backup execution node. Based on the request method, URL endpoint, and load data of the predictive network service request, the corresponding service interface call process is matched from the policy rule base, including the call steps, abnormal retry mechanism, and switching conditions between the primary / backup execution nodes. At the same time, communication protocol parameters are matched, including transmission timeout, maximum number of retransmissions, message encoding method, and encryption enable flag. The primary execution node, backup execution node, service interface call process rules, and communication protocol parameter rules corresponding to each predictive network service request are encapsulated into a complete policy record and integrated to form a service processing policy set.

[0061] It should be noted that the policy rule base is used to guide the execution strategy of predictive network service requests. It is constructed by summarizing common predictive network service request types and corresponding execution scenarios, organizing stable and reusable processing methods into rule entries and writing them into storage. This includes service interface call processes and communication protocol parameters for different service types and URL endpoints.

[0062] S4. Based on the predictive network service request set and the latest real-time status data, the service processing strategy set is coordinated and arbitrated, and the service mode and interface cooperation method are dynamically determined for each predictive network service request, generating network service interface cooperation instructions.

[0063] S4.1: Integrate the predictive network service request set, the service processing strategy set, and the latest real-time status data to form a collaborative arbitration input dataset.

[0064] Furthermore, for each predictive network service request, the request method, URL endpoint, and load data in the predictive network service request set, as well as the preferred execution node, backup execution node, service interface call process, and communication protocol parameters in the service processing strategy set, are read respectively. The latest real-time status data is associated with the device identifiers of the preferred execution node and the backup execution node, and combined according to the predictive network service request dimension to form a collaborative arbitration input dataset.

[0065] S4.2: Based on the collaborative arbitration input dataset, evaluate the effectiveness and potential conflicts of each service processing strategy under the latest resource status, and generate a strategy feasibility judgment table.

[0066] Furthermore, based on the collaborative arbitration input dataset, for each predictive network service request, the corresponding service processing strategy set is read, and combined with the latest real-time status data, the feasibility of the preferred execution node and the backup execution node executing the service interface call process under the current resource status is evaluated, and it is determined whether the service processing strategy meets the resource requirements and latency requirements of the predictive network service request. The service processing strategies corresponding to multiple predictive network service requests within the same time window are compared horizontally to identify whether there are resource competitions, latency conflicts, or execution order conflicts for the same agricultural edge device. After completing the item-by-item evaluation and conflict check, the executable status and conflict determination results of each service processing strategy are marked, and a strategy feasibility determination table is formed.

[0067] S4.3: Based on the strategy feasibility judgment table, resolve conflicts and optimize the global service processing strategies, determine the unique service mode for each predictive network service request, and generate the final service mode allocation list.

[0068] Furthermore, based on the strategy feasibility judgment table, for service processing strategies that have resource contention, latency conflicts, or execution order conflicts, the conflicting service processing strategies are selected according to the priority of the predictive network service request, service timing requirements, and the availability of candidate execution nodes. The execution method that meets resource constraints and does not conflict is selected. After the conflict is resolved, with the goal of minimizing global response latency and balancing the load on agricultural edge devices, the execution nodes and time windows of all service processing strategies are globally coordinated and adjusted. Finally, a service processing strategy containing the final execution node, call time window, and communication protocol parameters is determined as a unique service mode for each predictive network service request, and a final service mode allocation list is generated.

[0069] It should be noted that minimizing global response latency means prioritizing the combination of execution nodes and time windows that shortens the overall completion time of predictive network service requests when multiple conflict-free service processing strategies are available. Balancing the load on agricultural edge devices means avoiding the centralized allocation of multiple predictive network service requests to the same agricultural edge device while meeting resource constraints and service timing requirements. Instead, execution nodes are distributed based on the device's overall capability snapshot. For example, if multiple predictive network service requests exist within the same time window, and the device's overall capability snapshot shows that the computing load of a certain agricultural edge device is close to its limit, then some predictive network service requests are allocated to other agricultural edge devices with lower computing loads and that meet resource constraints, in order to avoid excessive concentration of load on a single agricultural edge device.

[0070] S4.4: Perform service interface mapping on the final service mode allocation list, determine the specific interface call chain, data exchange format and collaboration sequence for each predictive network service request, and generate an interface collaboration mode specification table.

[0071] Furthermore, based on the URL endpoints of the predictive network service requests and the execution nodes specified in the unique service mode, a specific call path from the cloud service interface to the agricultural edge device service interface is mapped, forming a service interface call chain. According to the load data content and business semantics of the predictive network service requests, the data exchange format used for interaction in each link of the service interface call chain is determined (e.g., data containing nested objects is mapped to JSON, while list data containing a large number of repetitive fields is mapped to Protocol Buffers format). Based on the start point of the call time window specified in the unique service mode, precise start times and waiting time limits are arranged for each step in the service interface call chain (e.g., cloud-initiated call, network transmission, edge device processing, and result feedback), clarifying the collaborative sequence. The service interface call chain, data exchange format, and collaborative sequence determined for each predictive network service request are integrated into a specification record and summarized to form an interface collaboration method specification table.

[0072] S4.5: Integrate the final service mode allocation list and the interface collaboration method specification table, and encode them into network service interface collaboration instructions.

[0073] Furthermore, each record in the final service mode allocation list (including the predictive network service request identifier and unique service mode) is merged with the corresponding request identifier record in the interface collaboration method specification table (including the service interface call chain, data exchange format, and collaboration sequence) to generate a complete collaboration description for each predictive network service request. Based on all merged collaboration descriptions, a tree-like instruction data structure is constructed with the collaboration execution time window as the framework and the execution node (agricultural edge device) as the dimension, ensuring that the time windows do not overlap or conflict and that the logical order conforms to business rules. This tree-like instruction data structure is serialized and encoded according to the JSON lightweight data exchange format, and encapsulated with instruction type identifier, version number, and generation timestamp to generate network service interface collaboration instructions.

[0074] S5. Based on the network service interface collaboration instructions, the cloud service interface and the corresponding agricultural edge device service interface collaborate to perform predictive data processing and pre-transmission, generating a predictive service data set.

[0075] S5.1: Coordinate the distribution of network service interface coordination instructions to the cloud itself and the corresponding agricultural edge device service interfaces, perform predictive data processing in parallel, and generate task processing result data blocks.

[0076] Furthermore, based on the execution node information contained in the network service interface collaboration instructions, the network service interface collaboration instructions are simultaneously distributed to the cloud service interface and the corresponding agricultural edge device service interface. After receiving the collaboration instructions, the cloud service interface starts the corresponding data processing task according to the specified service interface call chain and executes the data processing operation through the set time window. At the same time, after receiving the corresponding instructions, the agricultural edge device service interface executes the corresponding local processing task according to the timing arrangement and resource requirements in the collaboration instructions. During the parallel execution process, the cloud service interface and the agricultural edge device service interface respectively generate task processing result data blocks.

[0077] S5.2: The cloud service interface acts as a coordination center, aggregating and integrating all task processing result data blocks to generate a predictive service data set.

[0078] Furthermore, after receiving task processing result data blocks from various agricultural edge device service interfaces and its own, the cloud service interface performs format verification on each data block to ensure that all data blocks conform to the data exchange format set in the network service interface collaboration instructions; based on the request identifier contained in the task processing result data block, task processing result data blocks with the same request identifier are merged and recombined to generate a predictive service data set.

[0079] This embodiment also provides a computer device applicable to the cloud computing-based agricultural data service interface method, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the cloud computing-based agricultural data service interface method proposed in the above embodiment.

[0080] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0081] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the method for implementing a cloud-based agricultural data service interface as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0082] In summary, this invention achieves proactive prediction of future service requests from agricultural edge devices by using a Long Short-Term Memory (LSTM) network to perform time-series pattern analysis on network service request logs and generating a service request prediction probability matrix, thus significantly improving the foresight of resource scheduling. Furthermore, by coordinating and arbitrating a set of service processing strategies to generate collaborative instructions for network service interfaces, it solves the resource contention problem during concurrent requests, achieving precise collaboration between cloud and edge services and ensuring the continuity of agricultural operations.

[0083] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud computing-based agricultural data service interface method, characterized in that: include, The cloud service interface collects and maintains real-time status data periodically reported by multiple agricultural edge devices, and records network service request logs arriving at the cloud service interface. By performing time-series pattern analysis on network service request logs using Long Short-Term Memory (LSTM) networks, the content and parameters of network service requests initiated by agricultural edge devices to cloud service interfaces within future time windows are predicted, generating a predictive set of network service requests. Based on the predefined edge device status registry and real-time status data, a candidate execution node list is generated by matching and evaluating the requested resource requirements with the overall capabilities of the devices, and node pre-allocation is implemented to generate a set of service processing strategies. Based on the predictive network service request set and the latest real-time status data, the service processing strategy set is coordinated and arbitrated, and the service mode and interface cooperation method are dynamically determined for each predictive network service request, generating network service interface cooperation instructions. Based on the network service interface collaboration instructions, the cloud service interface and the corresponding agricultural edge device service interface collaborate to perform predictive data processing and pre-transmission, generating a predictive service data set.

2. The cloud computing-based agricultural data service interface method as described in claim 1, characterized in that: The steps for recording network service request logs arriving at the cloud service interface are as follows. The real-time status data includes the computing load, storage availability, network bandwidth utilization, and request response latency of agricultural edge devices; The cloud service interface receives and parses network service requests, extracts the request method, URL endpoint, request header information and payload data, and associates and formats them with the server response status, session identifier and request arrival time to generate network service request logs.

3. The cloud computing-based agricultural data service interface method as described in claim 1, characterized in that: The step of performing time-series pattern analysis on network service request logs using a Long Short-Term Memory (LSTM) network to predict the content and parameters of network service requests initiated by agricultural edge devices to the cloud service interface within future time windows, and generating a predictive set of network service requests, is as follows. Clean the network service request logs and extract service behavior features to generate request behavior time-series feature data; The temporal feature data of request behavior is input into a long short-term memory network, and the periodicity and dependency relationship in the historical request sequence is learned through a gated recurrent mechanism to generate a service request prediction probability matrix. High-probability prediction points exceeding a preset confidence threshold are selected from the service request prediction probability matrix, and service interface protocol decoding and request parameter mapping are performed to generate an initial predictive request set. The initial predictive request set is subjected to compliance verification and service logic conflict resolution based on agricultural business rules to generate a predictive network service request set.

4. The cloud computing-based agricultural data service interface method as described in claim 3, characterized in that: The process of generating a candidate execution node list by matching and evaluating resource requests with overall equipment capabilities involves the following steps: Extract the resources required for the service interface call of each predictive network service request from the predictive network service request set, and generate a request resource requirement parameter set; Extract the static capability configuration of each agricultural edge device from the edge device status registry, and associate it with the latest real-time status data to generate a snapshot of the device's overall capabilities. The resource requirement parameter set is compared with the snapshot of the overall equipment capabilities to calculate the suitability of each agricultural edge device as a response node for the corresponding predictive network service request, and a request-equipment feasibility assessment matrix is ​​generated. All agricultural edge devices with a fit score higher than the fit score threshold are selected from the request-device feasibility assessment matrix and organized into a candidate execution node list.

5. The cloud computing-based agricultural data service interface method as described in claim 4, characterized in that: The steps for generating the service processing strategy set are as follows: The candidate execution node list is dynamically weighted and sorted to generate a node optimization sequence; Based on the node selection sequence, a primary and backup execution node is assigned to each predictive network service request, and the corresponding service interface call process and communication protocol parameters are set according to the pre-set policy rule base to form a service processing policy set.

6. The cloud computing-based agricultural data service interface method as described in claim 5, characterized in that: The steps for collaborative arbitration of the service processing strategy set are as follows: The predictive network service request set, the service processing strategy set, and the latest real-time status data are integrated to form a collaborative arbitration input dataset; Based on the collaborative arbitration input dataset, the effectiveness and potential conflicts of various service processing strategies under the latest resource status are evaluated, and a strategy feasibility judgment table is generated.

7. The cloud computing-based agricultural data service interface method as described in claim 6, characterized in that: The steps for generating network service interface coordination instructions are as follows: Based on the strategy feasibility assessment table, conflict resolution and global optimization are performed on each service processing strategy to determine the unique service mode for each predictive network service request and generate the final service mode allocation list. The final service mode allocation list is processed for service interface mapping to determine the specific interface call chain, data exchange format and collaboration sequence of each predictive network service request, and to generate an interface collaboration mode specification table. The final service mode allocation list and interface collaboration method specification table are integrated and encoded into network service interface collaboration instructions.

8. The cloud computing-based agricultural data service interface method as described in claim 3, characterized in that: The steps for generating the predictive service dataset are as follows: The network service interface collaborative instructions are collaboratively distributed to the cloud itself and the corresponding agricultural edge device service interfaces, and predictive data processing is performed in parallel to generate task processing result data blocks. The cloud service interface acts as a coordination center, aggregating and integrating all task processing result data blocks to generate a predictive service data set.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the cloud computing-based agricultural data service interface method according to any one of claims 1 to 8.

10. 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 steps of the cloud computing-based agricultural data service interface method according to any one of claims 1 to 8.

Images