Cloud integration method and device for oil and gas industry software

Abstract

The application discloses a cloud integration method and device for oil and gas industry software, and the method comprises the following steps: receiving an operation instruction of the oil and gas industry software sent by a user terminal; when the operation instruction is a software starting instruction, screening an optimal software instance from a software instance resource pool; based on a preset remote desktop protocol, establishing a persistent bidirectional communication connection with a remote application program service; starting the screened software instance; when the operation instruction is not the software starting instruction, converting the operation instruction through the preset remote desktop protocol and then sending the converted operation instruction to the started software instance; receiving a real-time picture of the started software instance sent by the started software instance through the preset remote desktop protocol, converting the real-time picture into a browser interface rendering format of the user terminal, and then pushing the converted real-time picture to the user terminal. The oil and gas industry software can be directly accessed through the browser.

Description

Technical Field

[0001] This invention relates to the field of oil and gas industry software technology, and in particular to a cloud-based integration method and apparatus for oil and gas industry software. Background Technology

[0002] Currently, core professional software relied upon in the oil and gas industry (such as mainstream reservoir numerical simulation software and high-precision geological modeling software) generally suffers from a high degree of dependence on local deployment. These software programs require the user's local high-performance computer or professional graphics workstation to run. For example, reservoir numerical simulation software needs to perform complex calculations on massive amounts of geological and fluid flow data, while high-precision geological modeling software needs to construct high-precision three-dimensional geological models. Therefore, the hardware performance requirements are extremely stringent. This requirement makes the software installation and configuration process extremely cumbersome. Technicians must not only ensure compatibility between the operating system and the software version, but also precisely debug various drivers, especially for the underlying hardware configurations of GPUs, CPUs, and large amounts of memory, requiring repeated parameter adjustments to ensure normal software operation. This not only consumes a significant amount of time and energy but also requires technicians to possess profound professional knowledge. Moreover, users have to invest heavily in purchasing professional graphics workstations to meet the software's operating requirements. These workstations are not only expensive to purchase, but their subsequent maintenance and upgrade costs are also considerable, including the regular replacement of aging hardware and software license upgrades, further increasing the burden on enterprises.

[0003] Traditional remote desktop solutions, such as direct RDP (Remote Desktop Protocol) or VNC (Virtual Network Computing) connections, have significant shortcomings in terms of convenience. Users wishing to remotely use related software must pre-install specific client programs locally. This means different software may require different clients, necessitating additional time and effort for installation and management. For oil and gas industry professionals who frequently work on-site, repeatedly installing clients on different devices is inconvenient and makes it difficult to meet the need for direct browser access anytime, anywhere, severely limiting work flexibility and convenience, and failing to meet the demands of modern, efficient office work.

[0004] In the remote transmission of graphical user interfaces (GUIs), especially in scenarios involving complex 3D rendering, such as the 3D visualization of complex geological structures in fine geological modeling software and the dynamic 3D simulation of multiphase fluid flow in reservoirs in reservoir numerical simulation software, data transmission latency and bandwidth consumption are prominent issues. When users perform real-time operations such as rotating, zooming in, and viewing details in remote operation software, high latency leads to untimely response to operation commands and severe screen lag, seriously affecting users' observation and analysis of the model, reducing the real-time operation experience and work efficiency, and hindering the efficient exploration and development research of complex oil and gas reservoirs.

[0005] Faced with the aforementioned challenges, while existing virtualization platform solutions offer users remote access capabilities to some extent, they still have significant shortcomings in several key areas. Regarding protocol conversion efficiency, optimization for professional graphics applications is lacking. Oil and gas professional software generates massive and complex graphical data, and existing virtualization platforms cannot efficiently process this data during protocol conversion, leading to degraded graphics display quality and increased operational latency. In terms of native compatibility with modern web browsers, they fail to fully leverage the browser's functional advantages, often resulting in limited functionality and abnormal interface display when users access the software through a browser.

[0006] Therefore, there is a need for a solution that allows users to directly access and use complex professional oil and gas industry software using only a standard browser. This solution should also enable efficient protocol conversion, support multi-tenant sharing and coexistence of multiple software version instances, and provide good display quality. Summary of the Invention

[0007] This invention provides a cloud integration method for oil and gas industry software, enabling direct access and use of complex professional oil and gas industry software through a standard browser. It achieves efficient protocol conversion and provides excellent display quality. The method includes:

[0008] Receive operation instructions for oil and gas industry software sent by user terminals;

[0009] When the operation instruction is a software startup instruction, the optimal software instance is selected from the pre-built software instance resource pool according to the software parameters of the operation object in the operation instruction; a persistent bidirectional communication connection is established with the remote application service based on the preset remote desktop protocol; and the selected software instance is started so that the selected software instance is integrated into the remote application service.

[0010] When the operation command is not a software startup command, obtain the software instance that has been started for the operation object, convert the operation command through a preset remote desktop protocol, and send it to the started software instance; receive the real-time screen of the software instance sent by the started software instance through the preset remote desktop protocol, convert the real-time screen into the browser interface rendering format of the user terminal, and push it to the browser interface of the user terminal.

[0011] This invention also provides a cloud-based integration device for oil and gas industry software, which allows direct access and use of complex professional oil and gas industry software through a standard browser. It enables efficient protocol conversion and provides excellent display quality. The device includes:

[0012] The operation instruction receiving module is used to receive operation instructions for oil and gas industry software sent by the user terminal;

[0013] The software startup module is used to forward the operation command to the authentication center for authentication through a pre-configured service gateway when the operation command is a software startup command; after successful authentication, it selects the optimal software instance from the pre-built software instance resource pool according to the software parameters of the operation object in the operation command; establishes a persistent bidirectional communication connection with the remote application service based on a preset remote desktop protocol; and starts the selected software instance so that the selected software instance is integrated into the remote application service.

[0014] The interaction module is used to obtain the software instance that has been launched when the operation command is not a software launch command, convert the operation command through a preset remote desktop protocol and send it to the launched software instance; receive the real-time screen of the software instance sent by the launched software instance through the preset remote desktop protocol, convert the real-time screen into the browser interface rendering format of the user terminal and push it to the browser interface of the user terminal.

[0015] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0016] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0017] The present invention also provides a computer program product, the computer program product comprising a computer program that, when executed by a processor, implements the above-described method.

[0018] In this embodiment of the invention, receiving operation commands from user terminals enables real-time data transmission. Compared to the traditional HTTP polling mechanism, this reduces server load, avoids issues such as decreased response speed and memory leaks caused by frequent requests, and improves the efficiency and stability of command transmission. When the operation command is a software startup command, the optimal software instance can be selected from the resource pool based on software parameters. This helps to rationally allocate resources, avoid resource waste, improve software operating efficiency, ensure that oil and gas industry software starts in the most suitable environment, and improve overall performance. Establishing a persistent bidirectional communication connection based on a preset remote desktop protocol ensures stable interaction with remote application services, enabling software instances to be stably integrated into remote application services, providing reliable support for the remote operation of oil and gas industry software, suitable for scenarios in the oil and gas industry that may involve remote operation and monitoring. For operation commands that are not software startup commands, the system can obtain the already started software instance and convert the command for transmission, flexibly responding to various operational needs. Whether it is daily software operation or specific function call, it can be executed in a timely and accurate manner, enhancing the practicality and flexibility of the system. The software instance's real-time screen is converted into a browser interface rendering format and pushed to the user's terminal, allowing users to directly view the software's running screen in the browser without the need to install a complicated client. This makes it convenient for users to access and operate oil and gas industry software on different devices, lowers the barrier to entry, and improves user experience and ease of operation. Attached Figure Description

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

[0020] Figure 1 This is a flowchart of the cloud integration method for oil and gas industry software in an embodiment of the present invention;

[0021] Figure 2 This is a flowchart illustrating the management of the software instance resource pool in an embodiment of the present invention;

[0022] Figure 3 This is a flowchart of the preprocessing operation instruction matching process in an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of the structure of the cloud integration device for oil and gas industry software in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0026] To better understand and implement the technical solutions of the present invention, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. These embodiments are only for illustrating the present invention and are not intended to limit its scope. Without departing from the spirit of the present invention, those skilled in the art can make appropriate adjustments and modifications to the technical details in the embodiments according to actual needs.

[0027] Figure 1 This is a flowchart of a cloud integration method for oil and gas industry software in an embodiment of the present invention. The method is applied to a backend service cluster and mainly includes the following steps:

[0028] Step 101: Receive the operation instructions of the oil and gas industry software sent by the user terminal;

[0029] Step 102: When the operation instruction is a software startup instruction, select the optimal software instance from the pre-built software instance resource pool according to the software parameters of the operation object in the operation instruction; establish a persistent bidirectional communication connection with the remote application service based on the preset remote desktop protocol; start the selected software instance so that the selected software instance is integrated into the remote application service.

[0030] Step 103: When the operation instruction is not a software startup instruction, obtain the software instance that has been started for the operation object, convert the operation instruction through a preset remote desktop protocol, and send it to the started software instance; receive the real-time screen of the software instance sent by the started software instance through the preset remote desktop protocol, convert the real-time screen into the browser interface rendering format of the user terminal, and push it to the browser interface of the user terminal.

[0031] In step 101, the operation instructions of the oil and gas industry software sent by the user terminal are received;

[0032] In this embodiment of the invention, the operation instructions are obtained through user interaction, including left-clicking, right-clicking, scrolling, and inputting specific keys on the keyboard. The operation instructions include an identity token, interaction action type, operation object (such as a permeability parameter input box or a pressure curve adjustment slider in reservoir numerical simulation software), operation value (such as the specific value of parameter adjustment), and timestamp.

[0033] In this embodiment of the invention, operation instructions can be received via the WebSocket protocol, and the real-time screen can be converted into the browser interface rendering format of the user terminal and then pushed to the browser interface of the user terminal.

[0034] In one embodiment, before selecting the optimal software instance from a pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction, the method further includes:

[0035] The operation instructions are forwarded to the authentication center for authentication through a pre-configured service gateway;

[0036] Based on the software parameters of the operation object in the operation instruction, the optimal software instance is selected from a pre-built software instance resource pool, including:

[0037] After successful authentication, the optimal software instance is selected from the pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction.

[0038] Upon receiving the operation command, the backend service cluster first forwards the request to the authentication center for identity verification through a pre-configured service gateway. During this process, the authentication center decodes and verifies the identity token in the operation command, including but not limited to checking the validity of the signature, the expiration of the identity token, and the trustworthiness of the issuer. Simultaneously, the authentication center parses the user identity information carried in the identity token, such as the user ID, username, department, user role, and the user's list of permissions. If the identity token verification is successful and the user has permission to access the requested resource, the authentication center returns a successful verification response, and the backend service cluster continues executing subsequent business logic. Conversely, if the identity token verification fails (e.g., invalid token, expired token, or insufficient user permissions), the authentication center returns the corresponding error code, the backend service cluster immediately terminates the current request processing flow, and returns an authentication failure message to the user terminal. After successful identity authentication, step 102 is executed.

[0039] In step 102, the optimal software instance is selected from the pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction.

[0040] The software parameters include the software name and software version;

[0041] In this embodiment of the invention, a software instance resource pool containing physical machines, virtual machines, or containerized instances is pre-built. The pool stores detailed information about each version of oil and gas industry software instance (such as software type, version number, host location, current load status, license information, etc.).

[0042] In this embodiment of the invention, a dynamic resource health assessment system is constructed. The system monitors in real time the hardware status (e.g., CPU temperature, memory failure rate) and software stability of physical machines, virtual machines, and containerized instances in the resource pool, and quantifies and scores resource health. When resource health falls below a threshold, a maintenance or replacement mechanism is automatically triggered to ensure the efficient and stable operation of the resource pool. Simultaneously, a software instance preheating function is introduced. Based on historical usage data, software usage demand at different times is predicted, and corresponding software instances are started and basic data is loaded in advance, reducing user waiting time.

[0043] Figure 2 This is a flowchart illustrating software instance resource pool management in an embodiment of the present invention. In one embodiment, the method further includes:

[0044] Step 201: Receive status data of the devices deployed in the software instance;

[0045] Step 202: Calculate the health index values ​​of each device based on the collected status data, and calculate the overall health of each device based on all health index values.

[0046] Step 203: Add software instances on devices with a comprehensive health score greater than a preset health score threshold to the software instance resource pool;

[0047] Step 204: Remove software instances from the software instance resource pool on devices with an overall health score lower than the preset health score threshold.

[0048] Hardware monitoring agents can be deployed on each physical machine to collect real-time status data such as CPU temperature and disk status via sensors or hardware interfaces; monitoring plugins can be integrated into virtual machine management platforms and container orchestration systems to obtain status data of virtual resources and containers; and log collection modules can be embedded in software instances to capture status data such as error logs and response times in real time. All monitoring nodes adopt a lightweight design to avoid consuming excessive system resources (CPU utilization is controlled within 5%).

[0049] The aforementioned status data is sent to the backend service cluster via an encrypted channel (such as TLS 1.3) and stored in a time-series database, indexed by unique device identifiers (such as physical machine UUIDs and container IDs) and timestamps. For example, CPU temperature data is collected every 10 seconds, and memory failure rate data is collected every 30 seconds.

[0050] The collected status data undergoes preprocessing, including outlier removal (e.g., a sudden CPU temperature change to 10°C due to sensor malfunction), missing value imputation (using linear interpolation to fill in data missing for short periods), and unit standardization (e.g., converting disk I / O speeds to MB / s). Qualitative status data (e.g., error log levels) is converted into quantitative values ​​(e.g., fatal errors are scored as 10 points, and warning errors as 3 points).

[0051] The principles for selecting health indicators are as follows:

[0052] Hardware status metrics selection: Key hardware status metrics are selected for software instances on physical machines, virtual machines, and containers within the software instance resource pool. For software instances on physical machines, these include CPU temperature (normal range is typically 30-80℃), CPU utilization, memory failure rate (e.g., memory check error counts / hour), memory utilization, disk I / O read / write speed, number of bad sectors on disk, network bandwidth utilization, and network packet loss rate. For software instances on virtual machines and containers, in addition to the metrics associated with the host physical machine, virtual CPU utilization, virtual memory allocation utilization, and container image storage utilization are also included.

[0053] Software operational stability metrics are defined, encompassing software instance startup success rate (number of successful startups per unit time / total number of startups), operational interruption frequency (number of unexpected terminations per unit time), response latency (average time for processing user requests), error log generation volume (number of error entries recorded per unit time), and license verification success rate. For example, a response latency exceeding 5 seconds in reservoir numerical simulation software is considered an abnormal metric.

[0054] Dynamic weight allocation for metrics: The Analytic Hierarchy Process (AHP) or expert scoring method is used to assign weights based on the degree of impact of different health metrics. For physical machines, CPU temperature and memory failure rate have higher weights (e.g., 20% each); for software operational stability, the weight of operational interruption frequency can be set to 25%. Simultaneously, it supports dynamic adjustment of weights based on resource type (physical machine / virtual machine / container) and business scenario (e.g., focusing on response latency during peak periods). For example, during peak user access periods, the weight of response latency can be increased from 15% to 25%.

[0055] Single health indicator value calculation: Quantitative calculation rules are set for each health indicator, using a percentage system. For example, CPU temperature is scored as follows: 30-60℃ = 100 points, 60-70℃ = 80 points, 70-80℃ = 60 points, and above 80℃ = 0 points; memory failure rate is scored as follows: 0 times / hour = 100 points, 1-2 times / hour = 60 points, 3 times or more = 0 points. In software stability indicators, response latency ≤2 seconds = 100 points, 2-5 seconds = 70 points, 5-10 seconds = 30 points, and above 10 seconds = 0 points.

[0056] Based on the indicator weights, the overall health of the equipment is calculated using a weighted summation formula: Overall health = Σ (single health indicator value × corresponding weight).

[0057] Set three health thresholds, such as a health threshold (≥80 points), an alert threshold (60-79 points), and a fault threshold (<60 points). Different thresholds can be set for different resource types. For example, containerized instances, due to their short lifecycle, can have a fault threshold of 50 points, lower than the 60 points for physical machines. The thresholds can be manually adjusted through the administrator interface or automatically optimized based on historical fault data (e.g., if a certain type of resource fails multiple times at 60 points, the fault threshold will be automatically raised to 65 points).

[0058] The service cluster can then calculate the overall health of the device once per second and compare it with a preset threshold.

[0059] Add software instances on devices with an overall health score greater than a preset health threshold to the software instance resource pool;

[0060] Remove software instances from the software instance resource pool on devices whose overall health is below the preset health threshold.

[0061] When the overall health status is lower than the warning threshold, a warning message (such as an email or SMS) is sent to the administrator, including the device identifier, abnormal indicators and current score; when it is lower than the fault threshold, an emergency alarm is triggered.

[0062] For devices with an overall health level below the fault threshold but that are repairable, the maintenance process is automatically initiated. For example, if the physical machine's CPU temperature is too high, the fan speed is automatically adjusted or unnecessary processes are closed; if the virtual machine's memory usage is too high, the virtual memory is automatically expanded; if the software instance's response latency is too high, the software instance is restarted and its cache is cleared. During maintenance, user request allocation for the device is suspended, and requests are transferred to other healthy devices.

[0063] If the overall health score does not recover after automatic maintenance (e.g., the score remains <60 after three consecutive maintenance cycles), the device replacement mechanism is triggered. For physical machines, the virtual machines on them are automatically migrated to other healthy physical machines; for containerized instances, the faulty containers are automatically destroyed and recreated on healthy nodes; for software instances, the faulty instance is terminated and a backup instance is called from the resource pool. After the replacement is completed, the faulty resource is marked as "pending repair," and operations personnel are notified to perform manual repair.

[0064] In one embodiment, the method further includes:

[0065] The software instance prediction model is obtained by inputting data from past software instances of a second preset duration into the software instance prediction model to obtain the required number of software instances for a third preset duration in the future. The software instance prediction model is obtained by training a machine learning model.

[0066] Calculate the hardware resources required for each software instance based on the resource consumption of each software instance on the device;

[0067] The preset start time for each software instance is determined based on its startup time and data loading time.

[0068] Lock the hardware resources required by each software instance for the fourth preset duration before the warm-up start time, and mark them as preheating occupancy.

[0069] When the warm-up time window arrives, the corresponding software instance is launched, automatic verification is performed, and after the verification is successful, it enters the standby state.

[0070] Upon receiving the software launch command, the software instance is changed from standby to running state so that it can be integrated into the remote application service.

[0071] The method for constructing a software instance prediction model is as follows:

[0072] Collect software instance usage data over a period of time (e.g., 6 months), including user access time (accurate to the minute), software type and version accessed, number of concurrent users, startup time of each instance, and basic data loading time. For example, record that the average number of users accessing the software instance between 8:00 and 9:00 AM each day is 20, the average instance startup time is 45 seconds, and the basic data loading time is 1 minute.

[0073] Time series analysis was used to uncover patterns in software usage during specific time periods. For example, it was found that peak usage occurred on weekdays from 9:00-11:00 and 14:00-16:00, while weekend usage was only 30% of weekday usage. Furthermore, the usage of a certain type of reservoir numerical simulation software surged at the beginning of each month (before the submission of exploration reports). Extracted features included daily, weekly, and monthly cycle characteristics, as well as usage deviations on special dates (such as holidays).

[0074] Long Short-Term Memory (LSTM) networks were chosen as the software instance prediction model. The input is hourly usage data over a past period, and the output is the number of software instances needed in the next 24 hours (by type and version). Historical data was divided into training and test sets in an 8:2 ratio. The model was trained and validated using the test set. Model parameters (such as the number of hidden layer neurons and the learning rate) were adjusted to keep the prediction error (MAE) below 5%. The model was updated weekly with newly generated usage data to ensure prediction accuracy.

[0075] After developing the software instance prediction model, the data from the second preset duration of software instances in the past is input into the model to obtain the required number of software instances for the third preset duration in the future. Combined with the resource consumption of each software instance (e.g., 2 CPU cores, 8GB memory), the required hardware resources (physical machines, number of virtual machines, or containers) for each software instance are calculated. For example, if it is predicted that 20 software instances will be needed at 9:00 AM tomorrow, each occupying 2 CPU cores, then 40 CPU cores need to be reserved.

[0076] Based on the startup time and data loading time of each software instance, a preset start time is determined for each software instance. For example, if the software instance takes 105 seconds to start and load data, the warm-up will begin 2 minutes before the predicted peak period (e.g., 9:00) (i.e., 8:57:55). For different time periods, a corresponding list of warm-up time windows is generated; for example, the warm-up window for 8:00-9:00 is 7:58-8:00, and the warm-up window for 14:00-15:00 is 13:58-14:00.

[0077] Within the fourth preset time period before the preheating start time, the hardware resources required for each software instance are locked and marked as preheating occupancy. If resources are insufficient (e.g., predicted demand exceeds 90% of the total resource pool capacity), the preheating plan is adjusted according to priority (e.g., high-priority software is reserved first), or resource expansion is automatically triggered (e.g., starting a backup physical machine). At the same time, 10% redundant resources are reserved to cope with additional demand caused by prediction deviations.

[0078] When the warm-up time window arrives, start the corresponding software instance.

[0079] After the software instance starts, an automatic verification process is executed, including software version correctness checks, basic function tests (such as whether model files can be opened normally), and database connection tests. Software instances that pass verification are marked as "warm-up complete" and enter standby mode; software instances that fail verification (such as errors occurring when loading data) are automatically destroyed and a new software instance is restarted, while the reason for the failure is recorded (such as corrupted data files).

[0080] Once preheated, instances remain in standby mode, operating at low power (e.g., reduced CPU frequency) while ensuring a response time of 1 second. If an instance remains unused for more than a preset time (e.g., 2 hours) and subsequent demand is predicted to be low, the instance and its occupied resources are automatically released to avoid waste. For example, an instance preheated for demand predicted at 10:00 AM will be automatically destroyed at 12:00 PM if it remains unused after 12:00 PM and afternoon demand is predicted to be low.

[0081] Record the time from when a user initiates an operation request to when the software instance becomes available (i.e., the waiting time), compare it with the historical average waiting time without preheating, and calculate the percentage of waiting time reduced by the preheating function. For example, the average waiting time for a software instance without preheating is 150 seconds, which drops to 10 seconds after preheating, a reduction of 93.3%.

[0082] Compare the predicted demand for software instances with the actual usage to calculate the prediction deviation rate (|predicted value - actual value| / actual value). If the deviation rate exceeds 15% for three consecutive days, the optimization process of the Soft Jia Nan Shi Li prediction model is triggered, which involves adding feature dimensions (such as incorporating external factors like weather and project progress) or adjusting the model structure.

[0083] The actual utilization rate of preheated software instances is calculated (number of preheated instances invoked by users / total number of preheated instances). If the utilization rate is below 60%, the preheating time window is adjusted or the number of preheated instances is reduced. If the utilization rate is above 90%, the preheating redundancy is increased (e.g., preheating 10% more software instances than predicted). Through continuous evaluation and iteration, the resource investment in the preheating function and the user experience are optimized to achieve the best balance.

[0084] In one embodiment, selecting the optimal software instance from a pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction includes:

[0085] After receiving operation instructions from multiple users simultaneously, the user priority is determined according to the identity token in the operation instructions;

[0086] According to the user's priority and corresponding weight value from large to small, the best software instance is selected from all the idle software instances in the software instance resource pool for each user. In each selection, the software instance with the highest comprehensive matching index value with the user is selected as the best software instance.

[0087] In the above embodiments, a user priority weight parameter is used to assign higher priority weights to users of important project groups or urgent tasks when allocating resources, ensuring that they can obtain the best software instance first.

[0088] Priority ranking: User priorities are divided into multiple levels based on project importance, task urgency, and user role. For example, core project team users in the critical phase of oil and gas field development are assigned to Level 1 (highest priority), users executing urgent tasks (such as troubleshooting) are assigned to Level 2, regular project team users are assigned to Level 3, and users with temporary access are assigned to Level 4 (lowest priority). Each level corresponds to a unique priority identifier (such as P1, P2, P3, P4), which is stored in the user information database.

[0089] Weighting Quantification Standard: Each priority level is assigned a corresponding weight value (range 0-100). The higher the weight value, the higher the priority of resource allocation. For example, P1 corresponds to a weight value of 90-100, P2 to 70-89, P3 to 40-69, and P4 to 0-39. Weight values ​​can be dynamically adjusted according to actual business needs. For example, during the critical phase of a project, the weight value of P1 for the core project team can be increased from 90 to 100. Simultaneously, weight adjustment permissions are set, allowing only system administrators or project leaders to modify weight values ​​through an approval process, ensuring security.

[0090] Dynamic weight adjustment trigger conditions: Set the trigger rules for temporary weight adjustments. When a user initiates an urgent task request (such as submitting an application marked with an urgent tag), their priority is automatically temporarily increased by one level (e.g., P3 temporarily becomes P2), and the original level is restored 24 hours after the task is completed; when the project enters a critical milestone stage (such as before the trial production of an oil and gas field), the weight values ​​of all users in the core project team are automatically increased by 10, and this continues until the milestone ends.

[0091] The optimal instance selection criteria are defined as follows: the quantitative indicator for the optimal software instance is the matching degree indicator. The matching degree indicator includes hardware configuration (such as CPU cores ≥8, memory ≥32GB, GPU memory ≥16GB), software version compatibility (consistent with the version requested by the user), current load rate (≤30%), historical response speed (average response time ≤2 seconds), etc. The weighted value of all the above matching degree indicators is calculated as the comprehensive matching degree indicator value. The software instance with the largest comprehensive matching degree indicator value is the optimal software instance. It can be seen that the optimal software instance is the one with the best performance among all idle software instances.

[0092] Priority weight and resource matching association rules: A weight-resource matching algorithm is established. When multiple users request resources simultaneously, their priority weight values ​​are compared first. Users with higher weight values ​​are given priority in the instance selection process. For example, user P1's request skips the queue and is matched with the best instance first. If multiple P1 users request simultaneously, the urgency of the task (e.g., deadline) is further compared, with those with more pressing deadlines being allocated priority.

[0093] The optimal software instance is assigned to the user and marked as occupied. At the same time, data such as allocation time, user information, priority weight, etc. are recorded.

[0094] Priority matching logs can be analyzed periodically (e.g., monthly) to assess the match between weight values ​​and actual resource needs. For example, if it is found that P2 users frequently experience task delays due to insufficient resources, their weight value range can be appropriately increased (e.g., from 70-89 to 75-94); if low-priority users are unable to obtain resources for a long period of time, a dedicated resource pool can be opened for them during off-peak hours (e.g., early morning).

[0095] Provide a user feedback portal (such as an in-app resource allocation feedback button) to collect user satisfaction data on instance allocation (e.g., priority access to high-performance instances, task interruption due to resource preemption). For frequently reported negative feedback, organize the technical team to analyze the reasons and adjust the matching rules (e.g., optimize the notification time for resource preemption).

[0096] In one embodiment, selecting the optimal software instance from a pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction includes:

[0097] If the operation instruction is a multi-version collaboration request, a version combination identifier is generated. The multi-version collaboration request includes software type, version combination, and collaboration scenario.

[0098] Based on the version combination identifier, the optimal software instance corresponding to each version in the version combination is selected from the software instance resource pool, and the version compatibility interface is called to verify the feasibility of data interaction between the optimal software instances.

[0099] If the verification passes, calculate the resource consumption for multiple optimal software instances of the version combination;

[0100] Compare the resource usage with the minimum required resource usage of this version combination in the resource demand matrix;

[0101] If the resource consumption of the version combination meets the minimum required resource consumption, a dedicated communication channel is established for multiple optimal software instances of the version combination.

[0102] In this embodiment of the invention, a software version hierarchy can be constructed in advance: the version iteration relationship of various oil and gas industry software can be sorted out, and a version hierarchy database can be established. For example, the version hierarchy of a software is 2019→2020→2022→2023, marking the release time of each version, the differences in core functions (such as the addition of a fracture modeling module in the 2022 version), and data format compatibility (such as the 2022 version can read the .pet file of the 2020 version, but the 2020 version cannot read the new data types added in the 2022 version).

[0103] Collaborative Invocation Rule Definition: For collaborative scenarios involving different versions, association rules are defined. For example, comparative analysis scenarios require associating two consecutive versions (e.g., versions 2020 and 2022); data migration scenarios require associating lower and higher versions (e.g., migrating from version 2019 to version 2023); and compatibility testing scenarios require associating the target version with all historical versions. The rules clearly define the roles of each version (e.g., source version, target version) and the direction of data interaction (e.g., one-way import, two-way synchronization).

[0104] Instance resource requirement mapping: Defines the minimum resource requirements for multi-version collaborative calling scenarios. For example, when calling two versions of reservoir numerical simulation software instances simultaneously, a total CPU core count of ≥16, memory of ≥64GB, and network bandwidth of ≥1Gbps are required to ensure smooth data interaction. These requirements are stored in a resource requirement matrix, corresponding one-to-one with version combinations (e.g., software instance 2019 + software instance 2022).

[0105] Users initiate multi-version collaboration requests, selecting the required software type (e.g., reservoir numerical simulation software), version combination (e.g., reservoir numerical simulation software 2020 and reservoir numerical simulation software 2022), and collaboration scenario (e.g., comparative analysis). The system parses the request parameters and generates a version combination identifier (e.g., reservoir numerical simulation software 2020 + reservoir numerical simulation software 2022).

[0106] Based on the version combination identifier, the optimal software instance corresponding to the version combination identifier is selected from the software instance resource pool. The selection method is as described above. At the same time, the version compatibility interface is called to verify the feasibility of data interaction between instances. For example, it checks whether the reservoir numerical simulation software 2020 instance supports reading the intermediate data files generated by the reservoir numerical simulation software 2022 instance. If it does not support it, the combination is automatically excluded.

[0107] If the verification is passed, the total resource consumption (such as CPU, memory, network bandwidth) is calculated and compared with the minimum requirements in the resource demand matrix to ensure that the requirements of the collaborative scenario are met.

[0108] A dedicated communication channel is established for multiple optimal software instances of the version combination, using the WebSocket protocol to achieve real-time data interaction. The channel supports bidirectional data transmission; for example, the Reservoir Numerical Simulation Software 2020 instance sends raw geological data to the Reservoir Numerical Simulation Software 2022 instance, and the Reservoir Numerical Simulation Software 2022 instance returns optimized simulation results. Simultaneously, the channel is equipped with a data encryption mechanism (such as AES-256 encryption) to ensure the security of sensitive data (such as oil and gas reserve data).

[0109] In this embodiment of the invention, a data conversion middleware can be developed to automatically handle data format differences between different version instances. For example, when a 3D geological model software 2020 instance transfers a 3D geological model to a 3D geological model software 2022 instance, the middleware converts the .xml format model file of the 2020 version to the .json format supported by the 2022 version, and adds default values ​​for newly added fields (such as shale gas content). Real-time synchronization is supported; after a user modifies parameters in the 2022 version instance, the corresponding parameters in the 2020 version instance are automatically marked as updated, prompting the user to check the differences.

[0110] The system provides users with a unified collaborative operation interface. The left side displays the window for the lower version instance, the right side displays the window for the higher version instance, and the bottom shows a data difference comparison panel (such as parameter value differences and simulation result deviation rates). The interface supports cross-version operations (such as dragging and dropping data from the 2020 version window to the 2022 version window). Operation commands are converted through a dedicated protocol and sent to the corresponding instances to ensure operation synchronization.

[0111] In this embodiment of the invention, the communication status of multiple optimal software instances of a version combination can be monitored in real time, including indicators such as data transmission rate (target ≥ 10MB / s), interaction latency (target ≤ 100ms), and data verification success rate (target ≥ 99.9%). The monitoring data is displayed through a visual dashboard, and when the transmission rate is lower than 5MB / s, network bandwidth expansion is automatically triggered (e.g., from 1Gbps to 2Gbps).

[0112] When different versions of the instance make conflicting modifications to the same data (e.g., the 2020 version sets the penetration rate to 100mD, while the 2022 version sets it to 120mD), the conflict resolution mechanism is activated: if the user has set a priority (e.g., based on the 2022 version), the data from the higher priority version will be automatically adopted; otherwise, a pop-up window will prompt the user to select a retained value, and a conflict log will be recorded for subsequent analysis.

[0113] If a particular instance version fails (e.g., crashes or disconnects), all interactive operations on related instances are immediately suspended, and the current data state is saved (e.g., a snapshot file is generated). For recoverable failures (e.g., memory overflow), the failed instance is automatically restarted and the snapshot is loaded; for unrecoverable failures (e.g., disk corruption), a new instance of the same version is matched from the resource pool, historical data is synchronized through middleware, and the collaborative state is restored. Throughout the process, progress indicators are displayed to the user (e.g., "Restoring the 2022 version instance, estimated remaining 30 seconds").

[0114] Statistical analysis is conducted on metrics such as average response time (time from request to instance availability), data interaction success rate, and user operation completion efficiency (e.g., average time to complete a comparative analysis) for multi-version collaborative calls, and these are compared with those for single-version calls. The goal is for the response time of multi-version calls to be no more than 1.5 times that of single-version calls, and for the data interaction success rate to be ≥99.5%.

[0115] Regularly summarize data conversion errors and functional incompatibilities encountered during collaborative calls, and generate version compatibility reports. For example, if the model conversion error rate between software instance 2019 and 2023 is found to be as high as 5%, it is reported to the software development team to promote version adaptation and optimization; at the same time, the version combination is temporarily disabled in the system, and users are recommended to use an intermediate version (such as version 2020) as a transition.

[0116] Analyze the resource usage patterns of multiple version instances. If it is found that the network bandwidth consumption of a certain version combination accounts for 60%, it is recommended to increase the dedicated network bandwidth for that combination. If the memory usage rate exceeds 80% for a long period of time, adjust the resource requirement matrix and increase the minimum memory requirement for that combination.

[0117] Based on the preset remote desktop protocol, a persistent two-way communication connection is established with the remote application service;

[0118] The process of establishing a persistent bidirectional communication connection includes:

[0119] Load pre-configured transport parameters (WebSocketURL, port number, security protocol type such as wss: / / , etc.);

[0120] Send a connection request (including the transmission parameters) to the remote application service to initialize the connection and ensure its stability and security.

[0121] Once the connection is established, the backend service cluster maintains a long-term connection with the remote application service, enabling real-time transmission of operation commands and status information, thereby efficiently managing remote application interactions.

[0122] Upon receiving a connection request, the remote application service dynamically loads the corresponding professional configuration based on the transmission parameters and preset remote desktop protocols (such as RDP, VNC, etc.), including:

[0123] Protocol parameter parsing;

[0124] Protocol processor initialization;

[0125] Load necessary drivers and dependent libraries.

[0126] Once configured, the remote application service establishes a secure connection with the backend service cluster through a preset remote desktop protocol (such as RDP), providing basic support for application startup and session management.

[0127] The process of initiating the selection of software instances may involve a series of operations such as software initialization, license verification, and user session creation. This aims to provide users with a consistent and expected application experience.

[0128] The selected software instances will be integrated into the remote application service.

[0129] In step 103, when the operation instruction is not a software startup instruction, the software instance of the software involved in the operation object that has been started is obtained, the operation instruction is converted through a preset remote desktop protocol and sent to the started software instance; the real-time screen of the software instance sent by the started software instance through the preset remote desktop protocol is received, the real-time screen is converted into the browser interface rendering format of the user terminal and pushed to the browser interface of the user terminal.

[0130] The backend service cluster obtains real-time visuals (such as GDI or RemoteFX commands) from the software instance via an established, persistent bidirectional communication connection. It then converts the real-time visuals into a browser rendering format suitable for the user terminal (such as WebGL command sequences or optimized image patch data) and pushes it to the user's browser interface via the WebSocket protocol. Upon receiving operation commands via the WebSocket protocol and feeding them back to the backend service cluster, these commands are converted using a preset remote desktop protocol (e.g., converted to standard RDP input events, keyboard scan codes, mouse positions / actions) before being sent to the running software instance, thus achieving a smooth interactive experience for remote applications. Throughout this process, the backend service cluster continuously monitors the running status of the software instance and the network connection quality to ensure the stability and continuity of the user experience.

[0131] In this embodiment of the invention, different precision conversion formats can be automatically selected based on the performance of the user terminal (such as a mobile phone, tablet, or computer) and display requirements. For high-performance devices, WebGL instruction sequences are used to ensure high image quality; for low-performance devices, optimized image block data is converted to ensure smooth operation. Simultaneously, a bidirectional instruction verification mechanism is developed to perform bidirectional verification of the integrity and accuracy of instructions during the conversion process between WebSocket messages and remote desktop protocol messages, avoiding operational deviations caused by conversion errors.

[0132] In one embodiment, converting the real-time video feed into a browser interface rendering format for the user terminal includes:

[0133] A semantic segmentation algorithm is used to divide the real-time image into functional areas and record the boundary coordinates of each functional area.

[0134] Classify functional areas by importance;

[0135] Bind coordinate precision parameters to functional areas of different importance levels;

[0136] Obtain the screen resolution and window size of the user terminal, and calculate the fundamental transformation matrix between the global coordinate system of the real-time screen and the screen coordinate system of the user terminal.

[0137] Based on the coordinate precision parameters and basic transformation matrix bound to functional areas of different importance levels, the real-time screen is converted into the browser interface rendering format of the user terminal.

[0138] In the above embodiments, the dynamic coordinate space mapping can be upgraded to adaptive multi-resolution coordinate mapping. This not only adapts to different resolutions but also allows for local coordinate precision adjustments based on the importance of the graphic content. For example, higher precision coordinate mapping is used in critical areas of the 3D geological model (such as faults and reservoirs) to ensure operational accuracy, while precision is appropriately reduced in non-critical areas to minimize processing overhead.

[0139] First, a global coordinate space model is created for the real-time image processed by the software instance (such as a 3D geological model), determining the origin, axis directions, and coordinate range of the global coordinate system. For example, in a 3D geological model, a global coordinate system is established with a reference point as the origin, where the X, Y, and Z axes represent the horizontal direction and vertical depth, respectively, and the coordinate range covers the entire model area.

[0140] Image segmentation algorithms (such as deep learning-based semantic segmentation models) are used to automatically segment real-time images according to functional regions. For 3D geological models, different regions such as fault zones, reservoir zones, non-reservoir rock zones, and water areas can be segmented. Each functional region is assigned a unique identifier and boundary coordinates (e.g., top-left corner coordinates (x1, y1), bottom-right corner coordinates (x2, y2)), which are stored in a region attribute database. The semantic segmentation model can be trained using data including screenshots of interfaces in different scenarios (e.g., parameter adjustment interfaces during reservoir simulation, 3D model rotation interfaces), with each pixel labeled with its region level. After training, the model can output the importance level of each region in the image in real time, with an accuracy target of ≥95%, ensuring that key regions such as core parameter areas are identified without omission.

[0141] Based on the business needs and operational accuracy requirements of the oil and gas industry, a standard for classifying the importance levels of functional areas is established. For example, fault zones, reservoir zones, the core parameter display areas of the reservoir model (such as real-time numerical panels for permeability and porosity), and key structural areas of the 3D geological model (such as fault and reservoir distribution) are defined as Level 1 important areas (highest priority, highest accuracy requirement), as they directly affect reservoir numerical simulation and production scheme design; non-reservoir rock areas are defined as Level 2 important areas (medium accuracy requirement); and areas with less impact on operational accuracy, such as water bodies, background patterns (such as gray backgrounds on the software interface), and inactive toolbars are defined as Level 3 important areas (lowest priority, low accuracy requirement). Users can manually adjust the area boundaries and importance levels (e.g., by dragging the mouse to redefine the core parameter area), and the adjustment results are synchronized to the area importance database in real time. Meanwhile, when the software interface layout changes (such as when the user switches the display mode from parameter panel + model view to pure model view), the system automatically triggers a re-detection of the area boundaries. By comparing the changes in the position of interface elements (such as the toolbar moving from the left to the top), the coordinate boundaries of the first-level important area and the second-level important area are updated to avoid errors in level recognition caused by layout changes.

[0142] Set corresponding coordinate precision parameters for functional areas of different importance levels. First-level important areas use high precision parameters, such as a coordinate resolution of 0.01 meters per pixel; second-level important areas use medium precision parameters, with a resolution of 0.1 meters per pixel; and third-level important areas use low precision parameters, with a resolution of 1 meter per pixel. These parameters are stored in a precision configuration table and can be dynamically adjusted according to the actual application scenario.

[0143] The user terminal's screen resolution and window size can be obtained by including them in the initial software launch command. Based on the mapping between the global coordinate system and the user terminal's screen coordinate system, a basic coordinate transformation matrix is ​​calculated. For example, when the device screen resolution is 1920×1080, the three-dimensional coordinates in the global coordinate system are projected into two-dimensional screen coordinates to obtain the initial coordinate mapping.

[0144] During coordinate mapping, the importance level of each segmented functional area within the current display area is queried in real time, and the corresponding coordinate accuracy parameters are obtained from the accuracy configuration table. For first-level important areas, based on the basic coordinate transformation, the mapping accuracy of local coordinates is improved through interpolation algorithms (such as bilinear interpolation) to ensure the coordinate accuracy of subtle operations (such as clicking on a tiny pore within the reservoir). For third-level important areas, a downsampling algorithm is used to reduce the coordinate mapping accuracy and decrease the amount of data processing. For example, when displaying a 3D geological model, high-precision coordinate mapping is automatically enabled when the view is zoomed to the reservoir area; when the view is zoomed out to display the entire model, the accuracy of non-important areas is automatically reduced.

[0145] At the boundaries of functional areas of different importance levels, a smooth transition algorithm is used to handle the differences in coordinate mapping precision, avoiding coordinate jumps or distortions. For example, at the boundary between reservoir and non-reservoir areas, a gradual precision adjustment method is used to progressively transition the coordinates from high precision to low precision. Simultaneously, a multi-resolution coordinate caching mechanism is established to cache the coordinate mapping results of different areas. When the view re-displays the area, the cached data is directly retrieved, reducing the overhead of redundant calculations.

[0146] Furthermore, in this embodiment of the invention, when a user performs interactive operations (such as mouse clicks or drags) on the real-time screen, the screen coordinates are inversely mapped to coordinates in the global coordinate system using corresponding precision parameters based on the importance level of the area where the operation command is located. For operations in primary functional areas, strict coordinate verification is performed to ensure that the coordinate error after inversion is within the allowable range (e.g., ±0.01 meters); for operations in tertiary functional areas, the verification standard is appropriately relaxed to improve response speed.

[0147] In one embodiment, the method further includes:

[0148] After receiving the real-time screen of the software instance sent by the already started software instance through the preset remote desktop protocol, calculate the difference between the current graphic frame data and the previous graphic frame data of the real-time screen.

[0149] Based on the difference data, dirty rectangles are obtained, and noise reduction and merging are performed on the dirty rectangles.

[0150] The importance level of each dirty rectangle is determined based on its coordinate boundaries and the importance level of its functional area.

[0151] Sort the dirty rectangles in descending order according to their weight and area to form a transmission queue;

[0152] Converting real-time footage into the browser interface rendering format of the user terminal includes: for each dirty rectangle in the transmission queue, converting the dirty rectangle into the browser interface rendering format of the user terminal according to the coordinate precision parameters and basic transformation matrix bound to the functional area to which the dirty rectangle belongs;

[0153] Using the WebSocket protocol, dirty rectangles in browser rendering format are pushed to the user's browser interface according to the transmission queue order.

[0154] Graphics frame data is stored in the form of a pixel matrix (e.g., a 1920×1080 resolution frame contains 2,073,600 pixels). To reduce storage overhead, an incremental frame storage strategy is adopted, which only saves the differences from the previous graphics frame data, rather than the complete frame.

[0155] Pixel-level difference analysis is performed on two consecutive image frames. By calculating the RGB value difference of each pixel (e.g., a difference threshold of 10, i.e., |R1-R2|+|G1-G2|+|B2-B1|>10, a pixel is considered a changed pixel), the positions of all changed pixels are marked. An eight-connected-domain algorithm is used to merge adjacent changed pixels into continuous rectangular regions (i.e., dirty rectangles). Each dirty rectangle is described by its minimum boundary coordinates (x1, y1, x2, y2) and the number of changed pixels it contains.

[0156] Noise filtering is applied to dirty rectangles, removing rectangles with excessively small areas (e.g., area < 10 pixels, which may be random noise or a misjudgment). Dirty rectangles that are close together (e.g., center distance < 5 pixels) and belong to the same parent region (e.g., both belong to the core parameter region) are automatically merged into one large rectangle, reducing the number of rectangles (the number of dirty rectangles in a single target frame ≤ 20) and reducing the complexity of subsequent processing.

[0157] The coordinate boundaries of each dirty rectangle are matched with functional areas to determine its functional area. For example, if the center coordinates of a dirty rectangle fall within the boundary of a first-level functional area, it is marked as a first-level dirty rectangle; if there is partial overlap (e.g., more than 50% of the area is in a second-level functional area), the area with the highest proportion is used for classification. Dirty rectangles that do not match a functional area (such as temporary pop-up prompts) are marked as second-level by default to ensure that no potentially important information is missed.

[0158] Dirty rectangles of different importance levels are assigned transmission priority weights, with a weight of 1.0 (highest) for level 1, 0.6 for level 2, and 0.2 for level 3. Simultaneously, the weights are adjusted based on the degree of change in the dirty rectangles (e.g., the percentage of changed pixels; a higher percentage indicates a more significant content update). For example, if a level 1 dirty rectangle has 80% changed pixels, its weight is increased to 1.2 to ensure priority transmission of critical areas experiencing drastic changes.

[0159] All dirty rectangles are sorted in descending order by weight × area to form a transmission queue. For example, a first-level dirty rectangle (weight 1.0) with an area of ​​2000 pixels has a sorting score of 2000; a second-level dirty rectangle (weight 0.6) with an area of ​​5000 pixels has a score of 3000. The second-level dirty rectangle is ranked first because of its higher score (larger secondary areas may contain more auxiliary information, so priority needs to be balanced). The sorting results are updated in real time, and the queue is re-sorted every time a new frame of dirty rectangles is generated to ensure that it always reflects the latest transmission priority.

[0160] Dirty rectangles are processed sequentially according to the transmission queue. For Level 1 dirty rectangles, an immediate transmission strategy is adopted, and the delay from generation to transmission is controlled within 50ms. For Level 2 dirty rectangles, batch transmission is adopted, and they are sent once every 3 accumulated or at 100ms intervals. For Level 3 dirty rectangles, delayed transmission is adopted, and they are only sent when the network bandwidth utilization is less than 30%. If the bandwidth is continuously tight (e.g., >80%), it can be delayed until the next idle period (e.g., when user operation is paused).

[0161] In this embodiment of the invention, network bandwidth (e.g., if the current available bandwidth is <500kbps, it is determined to be low bandwidth) and transmission latency (e.g., if the round-trip latency is >200ms, it is determined to be high latency) are monitored in real time, and the transmission strategy is dynamically adjusted. In low-bandwidth scenarios, the transmission of the third-level dirty rectangle is suspended, and the first and second levels are prioritized; in high-latency scenarios, the first-level dirty rectangle is compressed and fragmented for transmission (e.g., using WebP format compression, with a fragment size of 100KB) to reduce the amount of data transmitted in a single transmission and reduce the impact of latency.

[0162] After receiving dirty rectangle data, the browser on the user terminal renders it in priority order: first, it renders the first-level dirty rectangles (such as those updated with core parameters) to ensure that the user can immediately see the key changes; then, it renders the second and third levels. At the same time, it records the transmission time and rendering completion time of each frame of dirty rectangles. If the rendering delay of the first-level dirty rectangle exceeds 100ms, it sends a priority upgrade request, triggering a temporary increase in the transmission weight of that area.

[0163] The system provides real-time statistics on dirty rectangle recognition accuracy (number of correctly recognized dirty rectangles / total number of dirty rectangles), classification accuracy (number of dirty rectangles correctly classified into different levels / total number of dirty rectangles), transmission latency in the primary functional area (average ≤50ms), and network bandwidth saving rate (the percentage of bandwidth reduction compared to full-screen transmission, target ≥60%). Monitoring data is used to generate reports periodically (e.g., hourly) via a backend service.

[0164] If the importance classification accuracy is below 90%, retrain the semantic segmentation model and increase the training samples for misclassified regions (e.g., add temporary prompts that are frequently misclassified as level 3 to level 1 samples); if the transmission delay of level 1 functional areas exceeds the standard, optimize the transmission queue sorting algorithm and increase the urgency factor (e.g., for the area that the user is currently operating, the urgency factor is increased by 0.5).

[0165] Provide an interface feedback entry point (such as a button to report image update delays) to collect user feedback on the timeliness of key area transmission. For example, if a user reports a delay in the update of the reservoir distribution area, the weight of that area will be temporarily increased by 0.2, and its feature weight will be increased in the next model training.

[0166] In this embodiment of the invention, the browser's rendering acceleration process utilizes WebGL hardware acceleration and adds a rendering task fragmentation function. Complex graphics rendering tasks are decomposed into multiple smaller tasks, which are then processed in parallel using the browser's multi-threading capabilities, improving rendering speed. For example, when rendering a large 3D geological model, the model is decomposed into regions and assigned to different threads for simultaneous rendering. Furthermore, a pre-generation mechanism for rendering results is developed. Based on the user's operation path, the potential graphic content to be displayed is predicted, and rendering results are generated and stored in the background in advance. When a user operation triggers the display, the pre-generated results are directly invoked, reducing real-time rendering time.

[0167] In this embodiment of the invention, in addition to real-time capture and conversion of common mouse and keyboard interactions, an intelligent command prediction mechanism can be introduced. By analyzing user operating habits and historical data, the mechanism can predict possible subsequent user actions in advance, further reducing response latency. For example, when a user frequently adjusts a parameter in reservoir numerical simulation software, it can predict that the user may continue to fine-tune that parameter, and prepare for command conversion in advance.

[0168] Figure 3 This is a flowchart of the preprocessing operation instruction matching process in an embodiment of the present invention. In one embodiment, the received operation instruction is a successfully matched preprocessing operation instruction.

[0169] The preprocessing instructions for a successful match are obtained by the user terminal using the following steps:

[0170] Step 301: Collect user operation data through the data collection module integrated into the browser page. The data collection module runs asynchronously.

[0171] Step 302: Form an operation sequence from the user operation data collected within the preset time period;

[0172] Step 303: Based on the operation sequence and the user operation prediction model, obtain the predicted set of operation instruction candidates;

[0173] Step 304: Select operation instructions with a probability higher than the first set threshold from the candidate set of operation instructions and use them as preprocessed operation instructions;

[0174] Step 305: Monitor the operation performed by the user. When the operation performed by the user matches a pre-processed operation instruction exactly, retrieve the successfully matched pre-processed operation instruction.

[0175] In one embodiment, a predicted set of candidate operation instructions is obtained based on the operation sequence and the user operation prediction model, including:

[0176] The operation sequence is compared with the features of the operation mode in the user operation prediction model to determine the operation mode corresponding to the operation sequence.

[0177] The operation mode and operation sequence are input into the user operation prediction model to obtain a predicted set of operation instruction candidates.

[0178] In this embodiment of the invention, after the user terminal receives the preprocessing operation instruction that has been successfully matched, it determines whether to trigger the preprocessing operation instruction based on the current network status and resource usage.

[0179] If so, the pre-processed operation instructions are converted into corresponding WetSocket protocol messages and sent to the backend service cluster according to the preset protocol specifications.

[0180] In this embodiment of the invention, if the user's actual operation and the unused pre-processed operation instructions do not match within a first preset time period, it is necessary to clean up the unused pre-processed messages.

[0181] The user operation data includes, but is not limited to, user identifier, interaction action type, operation object, operation value, and timestamp; the data acquisition module is lightweight and runs asynchronously, capturing the above user operation data in real time without interfering with the user's normal operation. For example, when the user clicks the parameter input box, the data acquisition module automatically records the time, location, and corresponding parameter name of the click event; when the user inputs parameter values ​​via the keyboard, it synchronously records the sequence of input values ​​and the input speed.

[0182] The collected user operation data is standardized and converted to a unified data format. For example, timestamps are converted to a unified UTC time format; interaction action types are encoded, such as using 001 to represent a left mouse click and 002 to represent keyboard numeric input; and operation objects are classified and labeled according to software function modules, such as reservoir parameter adjustment area - permeability, simulation result display area - pressure curve, etc. At the same time, invalid data (such as instantaneous operations caused by accidental touches) and duplicate data are filtered out to ensure the accuracy and validity of the data.

[0183] Standardized user action data is stored in a dedicated user action database, indexed according to user identifier and timestamp. The user action database employs an incremental update mechanism, receiving new user action data from the browser in real time to ensure the timeliness of the data and provide ample data sources for subsequent analysis and model training.

[0184] In this embodiment of the invention, user operation data in the user operation database is used for operation habit analysis and user operation prediction model construction. The steps for constructing the user operation prediction model include:

[0185] After collecting user operation data, it is stored in the user operation database;

[0186] User operation data is extracted from the user operation database according to a preset cycle;

[0187] Perform operation pattern recognition on user operation data;

[0188] Based on the identified operation patterns and operation sequences formed by user operation data, a machine learning model is trained to obtain a well-trained user operation prediction model.

[0189] User operation data is extracted from the user operation database according to a preset cycle, and data mining algorithms (such as sequence pattern mining algorithms) are used to mine the user operation data. For example, when a specific user adjusts parameters using reservoir numerical simulation software, the correlation between different parameter adjustments (e.g., porosity is often adjusted after permeability adjustment), the regularity of the numerical range of adjustments (e.g., the adjustment range is within ±5%), and the temporal distribution characteristics of the operations (e.g., parameters are adjusted intensively before the simulation calculation begins) can be analyzed.

[0190] Based on the mining results, typical operating modes were identified. For reservoir numerical simulation software, there may be parameter fine-tuning modes (such as the user making multiple small adjustments to a parameter consecutively), batch adjustment modes (such as adjusting multiple related parameters at once), and simulation-adjustment cycle modes (such as running the simulation first, adjusting the parameters based on the results, and then resimulating). Each operating mode contains a specific sequence of instructions, operating objects, and time characteristics.

[0191] Choose a suitable machine learning model (such as a recurrent neural network LSTM or a hidden Markov model HMM) and use the identified operation patterns and historical operation sequences as training data. The user operation prediction model takes the user's current and recent operation sequences as input and outputs possible future operation commands and probabilities. For example, when the input sequence is "fine-tune the penetration rate parameter 3 times consecutively, each time by 1%", the model outputs an 85% probability of "continue to fine-tune the penetration rate parameter, adjusting by 0.5%-1.5%".

[0192] The trained user action prediction model is evaluated using a validation set, and metrics such as prediction accuracy and recall are calculated. If the metrics are not up to standard, model parameters are adjusted or the algorithm is replaced and retrained. Simultaneously, as new user action data is continuously added, the model is iteratively optimized regularly (e.g., daily) with new data to ensure it adapts to changes in user behavior.

[0193] During the use of oil and gas industry software, every user action is captured in real time, and user operation data is collected to form an operation sequence. This operation sequence includes user operation data within a preset time period (such as the past 30 seconds). For example, if a user clicks the permeability input box at 10:00:00, enters the value "105" at 10:00:02, and clicks the input box again at 10:00:05 to prepare for modification, these operations will be recorded in real time and combined into an operation sequence.

[0194] Features are extracted from the operation sequence (such as the type of the most recent operation, the continuity of the operation object, and the trend of operation interval changes). These features are compared with the features of the operation mode in the user operation prediction model, and the matching degree is calculated. If the matching degree exceeds a set threshold (such as 70%), it is determined that the user is currently in that operation mode. For example, if the sequence of user continuous operation penetration rate input box above has a feature matching degree of 80% with the parameter fine-tuning mode, it is determined that the user is in that mode.

[0195] Based on the matched operation patterns and sequences, the user operation prediction model is invoked to generate a candidate set of possible future operation commands. This candidate set contains multiple possible operation commands, each with a predicted probability. For example, in parameter fine-tuning mode, the candidate set might include adjusting the penetration rate from 105 to 104 (probability 60%), adjusting the penetration rate from 105 to 106 (probability 30%), and clicking the "OK" button (probability 10%).

[0196] Operation commands with a probability higher than a first set threshold are selected from the candidate set and used as preprocessing commands. For the example of reservoir numerical simulation software, if the probability of further fine-tuning the permeability parameter is 85%, then the operation command is included in the preprocessing range.

[0197] Real-time monitoring of current network status (such as bandwidth utilization and network latency) and resource usage (such as CPU utilization and memory usage). When the network is idle (such as bandwidth utilization below 30%) and resources are sufficient (such as CPU utilization below 50%), the conversion and preprocessing of preprocessing operation instructions are triggered.

[0198] In this embodiment of the invention, operation instructions from the oil and gas industry software sent by the user terminal are received via the WebSocket protocol. The WebSocket protocol converts the operation instructions into corresponding protocol messages (e.g., WebSocket messages). For example, an operation instruction to adjust the penetration rate from 105 to 104 is converted into a JSON-formatted WebSocket message containing information such as the instruction type, operation object ID, and target value. On the user terminal, the converted WebSocket messages can also be preprocessed, including data compression (e.g., using the gzip algorithm to compress the message body), format validation (checking whether the message conforms to preset format specifications to ensure no syntax errors), and encryption (encrypting the message to ensure security if sensitive operations are involved). The WebSocket messages are temporarily stored in the user terminal's local cache, marked with the generation time and the corresponding operation instruction.

[0199] Continuously monitor the user's actual operations. When the user's operation matches a pre-processed operation instruction exactly (e.g., the user does adjust the penetration rate from 105 to 104), immediately retrieve the matching pre-processed operation instruction from the local cache and send it to the backend service cluster.

[0200] If the user's actual operation and the unused preprocessed operation instructions do not match within the first preset time period (e.g., the user adjusts the porosity parameter instead), the unused preprocessed operation instructions are cleared, the storage space is released, and the information of this prediction failure is recorded (including the predicted operation instructions, the actual operation instructions, the time, etc.).

[0201] The user's actual operation sequence, prediction results (success or failure), and related parameters (such as prediction probability) can be sent as feedback data to the user operation database to update historical data. For example, if the prediction fails, the record "predicted permeability adjustment, actual porosity adjustment" is added to the database to provide a basis for the next iteration of model optimization.

[0202] Based on the prediction failure cases in the feedback data, analyze the reasons for the failures (such as failure to identify new operation modes, users temporarily changing their operating habits, etc.). For frequently occurring failure types, trigger the emergency optimization process of the model, such as adding corresponding training samples and retraining some parameters of the model to improve the prediction accuracy for these types of operations.

[0203] Accordingly, embodiments of the present invention also provide a cloud-based integration device for oil and gas industry software, which can be used to execute any of the foregoing method embodiments. For example... Figure 4 As shown, the device includes:

[0204] The operation instruction receiving module 401 is used to receive operation instructions from the oil and gas industry software sent by the user terminal.

[0205] The software startup module 402 is used to forward the operation instruction to the authentication center for authentication through a pre-configured service gateway when the operation instruction is a software startup instruction; after successful authentication, it selects the optimal software instance from the pre-built software instance resource pool according to the software parameters of the operation object in the operation instruction; establishes a persistent bidirectional communication connection with the remote application service based on a preset remote desktop protocol; and starts the selected software instance so that the selected software instance is integrated into the remote application service.

[0206] The interaction module 403 is used to obtain the software instance that has been started when the operation instruction is not a software startup instruction, convert the operation instruction through a preset remote desktop protocol and send it to the started software instance; receive the real-time screen of the software instance sent by the started software instance through the preset remote desktop protocol, convert the real-time screen into the browser interface rendering format of the user terminal and push it to the browser interface of the user terminal.

[0207] In one embodiment, the device further includes an authentication module for:

[0208] Before selecting the optimal software instance from the pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction, the operation instruction is forwarded to the authentication center for authentication through the pre-configured service gateway;

[0209] Based on the software parameters of the operation object in the operation instruction, the optimal software instance is selected from a pre-built software instance resource pool, including:

[0210] After successful authentication, the optimal software instance is selected from the pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction.

[0211] In one embodiment, the software startup module is further configured to:

[0212] Receive status data from the devices deployed by the software instance;

[0213] Based on the collected status data, calculate the values ​​of each health indicator for each device, and calculate the overall health of each device based on all the health indicator values;

[0214] Add software instances on devices with an overall health score greater than a preset health threshold to the software instance resource pool;

[0215] Remove software instances from the software instance resource pool on devices whose overall health is below the preset health threshold.

[0216] In one embodiment, the software startup module is further configured to:

[0217] The software instance prediction model is obtained by inputting data from past software instances of a second preset duration into the software instance prediction model to obtain the required number of software instances for a third preset duration in the future. The software instance prediction model is obtained by training a machine learning model.

[0218] Calculate the hardware resources required for each software instance based on the resource consumption of each software instance on the device;

[0219] The preset start time for each software instance is determined based on its startup time and data loading time.

[0220] Lock the hardware resources required by each software instance for the fourth preset duration before the warm-up start time, and mark them as preheating occupancy.

[0221] When the warm-up time window arrives, the corresponding software instance is launched to perform automatic verification. After the verification is successful, it enters standby mode.

[0222] In one embodiment, the software startup module is further configured to:

[0223] After receiving operation instructions from multiple users simultaneously, the user priority is determined according to the identity token in the operation instructions;

[0224] According to the user's priority and corresponding weight value from large to small, the best software instance is selected from all the idle software instances in the software instance resource pool for each user. In each selection, the software instance with the highest comprehensive matching index value with the user is selected as the best software instance.

[0225] In the above embodiments, a user priority weight parameter is used to assign higher priority weights to users of important project groups or urgent tasks when allocating resources, ensuring that they can obtain the best software instance first.

[0226] In one embodiment, the software startup module is further configured to:

[0227] If the operation instruction is a multi-version collaboration request, a version combination identifier is generated. The multi-version collaboration request includes software type, version combination, and collaboration scenario.

[0228] Based on the version combination identifier, the optimal software instance corresponding to each version in the version combination is selected from the software instance resource pool, and the version compatibility interface is called to verify the feasibility of data interaction between the optimal software instances.

[0229] If the verification passes, calculate the resource consumption for multiple optimal software instances of the version combination;

[0230] Compare the resource usage with the minimum required resource usage of this version combination in the resource demand matrix;

[0231] If the resource consumption of the version combination meets the minimum required resource consumption, a dedicated communication channel is established for multiple optimal software instances of the version combination.

[0232] In one embodiment, the interaction module is used for:

[0233] A semantic segmentation algorithm is used to divide the real-time image into functional areas and record the boundary coordinates of each functional area.

[0234] Classify functional areas by importance;

[0235] Bind coordinate precision parameters to functional areas of different importance levels;

[0236] Obtain the screen resolution and window size of the user terminal, and calculate the fundamental transformation matrix between the global coordinate system of the real-time screen and the screen coordinate system of the user terminal.

[0237] Based on the coordinate precision parameters and basic transformation matrix bound to functional areas of different importance levels, the real-time screen is converted into the browser interface rendering format of the user terminal.

[0238] In one embodiment, the interaction module is used for:

[0239] After receiving the real-time screen of the software instance sent by the already started software instance through the preset remote desktop protocol, calculate the difference between the current graphic frame data and the previous graphic frame data of the real-time screen.

[0240] Based on the difference data, dirty rectangles are obtained, and noise reduction and merging are performed on the dirty rectangles.

[0241] The importance level of each dirty rectangle is determined based on its coordinate boundaries and the importance level of its functional area.

[0242] Sort the dirty rectangles in descending order according to their weight and area to form a transmission queue;

[0243] Converting real-time footage into the browser interface rendering format of the user terminal includes: for each dirty rectangle in the transmission queue, converting the dirty rectangle into the browser interface rendering format of the user terminal according to the coordinate precision parameters and basic transformation matrix bound to the functional area to which the dirty rectangle belongs;

[0244] Dirty rectangles in browser interface rendering format are pushed to the user's browser interface according to the transmission queue order.

[0245] In one embodiment, the received operation instruction is a preprocessed operation instruction that has been successfully matched;

[0246] The preprocessing instructions for a successful match are obtained by the user terminal using the following steps:

[0247] User operation data is collected through a data collection module integrated into the browser page, and the data collection module runs asynchronously.

[0248] The user operation data collected within a preset time period is used to form an operation sequence;

[0249] Based on the operation sequence and the user operation prediction model, a candidate set of predicted operation instructions is obtained;

[0250] Operation instructions with a probability higher than a first set threshold are selected from the candidate set of operation instructions and used as preprocessed operation instructions;

[0251] Monitor the user's actions, and when the user's actions completely match a pre-processed action instruction, retrieve the successfully matched pre-processed action instruction.

[0252] In one embodiment, a predicted set of candidate operation instructions is obtained based on the operation sequence and the user operation prediction model, including:

[0253] The operation sequence is compared with the features of the operation mode in the user operation prediction model to determine the operation mode corresponding to the operation sequence.

[0254] The operation mode and operation sequence are input into the user operation prediction model to obtain a predicted set of operation instruction candidates.

[0255] In one embodiment, generating the protocol message corresponding to the preprocessed operation instruction includes:

[0256] Based on the current network status and resource usage, determine whether to trigger the preprocessing operation instruction;

[0257] If so, the pre-processed operation instructions are converted into corresponding protocol messages according to the preset protocol specifications.

[0258] In summary, receiving user terminal operation commands enables real-time data transmission. Compared to the traditional HTTP polling mechanism, this reduces server load, avoids issues like slow response times and memory leaks caused by frequent requests, and improves the efficiency and stability of command transmission. When the operation command is a software startup command, the optimal software instance can be selected from the resource pool based on software parameters. This helps to allocate resources rationally, avoid waste, improve software operating efficiency, ensure that oil and gas industry software starts in the most suitable environment, and enhance overall performance. Establishing a persistent bidirectional communication connection based on a preset remote desktop protocol ensures stable interaction with remote application services, enabling software instances to be stably integrated into remote application services, providing reliable support for the remote operation of oil and gas industry software, suitable for scenarios like the oil and gas industry that may involve remote operation and monitoring. For operation commands that are not software startup commands, the system can obtain the already started software instance and convert the command for transmission, flexibly responding to various operational needs. Whether it's routine software operation or specific function calls, the system can execute them promptly and accurately, enhancing the system's practicality and flexibility. The software instance's real-time screen is converted into a browser interface rendering format and pushed to the user's terminal, allowing users to directly view the software's running screen in the browser without the need to install a complicated client. This makes it convenient for users to access and operate oil and gas industry software on different devices, lowers the barrier to entry, and improves user experience and ease of operation.

[0259] This invention also provides a computer device. Figure 5 This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 500 includes a memory 510, a processor 520, and a computer program 530 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 530, it implements the above-mentioned cloud integration method for oil and gas industry software.

[0260] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cloud integration method for oil and gas industry software.

[0261] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned cloud integration method for oil and gas industry software.

[0262] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0263] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0264] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0265] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0266] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cloud-based integration method for oil and gas industry software, characterized in that, Applied to backend service clusters, including: Receive operation instructions for oil and gas industry software sent by user terminals; When the operation instruction is a software startup instruction, the optimal software instance is selected from the pre-built software instance resource pool according to the software parameters of the operation object in the operation instruction; a persistent bidirectional communication connection is established with the remote application service based on the preset remote desktop protocol; and the selected software instance is started so that the selected software instance is integrated into the remote application service. When the operation command is not a software startup command, the system obtains the software instance that has already been launched, converts the operation command through a preset remote desktop protocol, and sends it to the launched software instance. It receives the real-time screen of the launched software instance sent through the preset remote desktop protocol, calculates the difference between the current graphic frame data and the previous graphic frame data, obtains dirty rectangles based on the difference data, and performs noise reduction and merging on the dirty rectangles. It determines the importance level of each dirty rectangle according to its coordinate boundaries and the importance level of its functional area. It sorts the dirty rectangles in descending order according to their weight and area to form a transmission queue. For each dirty rectangle in the transmission queue, it converts it into the browser interface rendering format of the user terminal according to the coordinate precision parameters and basic transformation matrix bound to the functional area to which the dirty rectangle belongs. Finally, it pushes the dirty rectangles in the browser interface rendering format to the user terminal's browser interface according to the order of the transmission queue.

2. The method according to claim 1, characterized in that, Before selecting the optimal software instance from a pre-built pool of software instances based on the software parameters of the operation object in the operation instruction, the process also includes: The operation instructions are forwarded to the authentication center for authentication through a pre-configured service gateway; Based on the software parameters of the operation object in the operation instruction, the optimal software instance is selected from a pre-built software instance resource pool, including: After successful authentication, the optimal software instance is selected from the pre-built software instance resource pool based on the software parameters of the operation object in the operation instruction.

3. The method according to claim 1, characterized in that, Also includes: Receive status data from the devices deployed by the software instance; Based on the collected status data, calculate the values ​​of each health indicator for each device, and calculate the overall health of each device based on all the health indicator values; Add software instances on devices with an overall health score greater than a preset health threshold to the software instance resource pool; Remove software instances from the software instance resource pool on devices whose overall health is below the preset health threshold.

4. The method according to claim 1, characterized in that, Also includes: The software instance prediction model is obtained by inputting data from past software instances of a second preset duration into the software instance prediction model to obtain the required number of software instances for a third preset duration in the future. The software instance prediction model is obtained by training a machine learning model. Calculate the hardware resources required for each software instance based on the resource consumption of each software instance on the device; The preset start time for each software instance is determined based on its startup time and data loading time. Lock the hardware resources required by each software instance for the fourth preset duration before the warm-up start time, and mark them as preheating occupancy. When the warm-up time window arrives, the corresponding software instance is launched to perform automatic verification. After the verification is successful, it enters standby mode. Upon receiving the software launch command, the software instance is changed from standby to running state so that it can be integrated into the remote application service.

5. The method according to claim 1, characterized in that, Based on the software parameters of the operation object in the operation instruction, the optimal software instance is selected from a pre-built software instance resource pool, including: After receiving operation instructions from multiple users simultaneously, the user priority is determined according to the identity token in the operation instructions; Based on the user's priority and corresponding weight value from largest to smallest, the optimal software instance is selected from all available software instances in the software instance resource pool for each user. In each selection, the software instance with the highest comprehensive matching index value with the user is selected as the optimal software instance.

6. The method according to claim 1, characterized in that, Based on the software parameters of the operation object in the operation instruction, the optimal software instance is selected from a pre-built software instance resource pool, including: If the operation instruction is a multi-version collaboration request, a version combination identifier is generated. The multi-version collaboration request includes software type, version combination, and collaboration scenario. Based on the version combination identifier, the optimal software instance corresponding to each version in the version combination is selected from the software instance resource pool, and the version compatibility interface is called to verify the feasibility of data interaction between the optimal software instances. If the verification passes, calculate the resource consumption for multiple optimal software instances of the version combination; Compare the resource usage with the minimum required resource usage of this version combination in the resource demand matrix; If the resource consumption of the version combination meets the minimum required resource consumption, a dedicated communication channel is established for multiple optimal software instances of the version combination.

7. The method according to claim 1, characterized in that, Converting live feeds into a browser interface rendering format for the user's terminal, including: A semantic segmentation algorithm is used to divide the real-time video into functional areas and record the boundary coordinates of each functional area. Classify functional areas by importance; Bind coordinate precision parameters to functional areas of different importance levels; Obtain the screen resolution and window size of the user terminal, and calculate the fundamental transformation matrix between the global coordinate system of the real-time screen and the screen coordinate system of the user terminal. Based on the coordinate precision parameters and basic transformation matrix bound to functional areas of different importance levels, the real-time screen is converted into the browser interface rendering format of the user terminal.

8. The method according to claim 1, characterized in that, The received operation instruction is a pre-processed operation instruction that has been successfully matched; The preprocessing instructions for successful matching are obtained by the user terminal through the following steps: User operation data is collected through a data collection module integrated into the browser page, and the data collection module runs asynchronously. The user operation data collected within a preset time period is used to form an operation sequence; Based on the operation sequence and the user operation prediction model, a candidate set of predicted operation instructions is obtained; Operation instructions with a probability higher than a first set threshold are selected from the candidate set of operation instructions and used as preprocessed operation instructions; Monitor the user's actions, and when the user's actions match a pre-processed action instruction exactly, retrieve the matching pre-processed action instruction.

9. The method according to claim 8, characterized in that, Based on the operation sequence and the user operation prediction model, a candidate set of predicted operation instructions is obtained, including: The operation sequence is compared with the features of the operation mode in the user operation prediction model to determine the operation mode corresponding to the operation sequence. The operation mode and operation sequence are input into the user operation prediction model to obtain a predicted set of operation instruction candidates.

10. A cloud-based integration device for oil and gas industry software, characterized in that, Applied to backend service clusters, including: The operation instruction receiving module is used to receive operation instructions for oil and gas industry software sent by the user terminal; The software startup module is used to forward the operation command to the authentication center for authentication through a pre-configured service gateway when the operation command is a software startup command; after successful authentication, it selects the optimal software instance from the pre-built software instance resource pool according to the software parameters of the operation object in the operation command; establishes a persistent bidirectional communication connection with the remote application service based on a preset remote desktop protocol; and starts the selected software instance so that the selected software instance is integrated into the remote application service. The interaction module is used to: obtain the already launched software instance of the software involved in the operation object when the operation instruction is not a software startup instruction; convert the operation instruction through a preset remote desktop protocol and send it to the already launched software instance; receive the real-time screen of the software instance sent by the already launched software instance through the preset remote desktop protocol; calculate the difference data between the current graphic frame data and the previous graphic frame data of the real-time screen; obtain dirty rectangles based on the difference data; perform noise reduction and merging on the dirty rectangles; determine the importance level of each dirty rectangle according to the importance level of the coordinate boundary and functional area of ​​each dirty rectangle; sort the dirty rectangles in descending order according to the weight and area of ​​each dirty rectangle to form a transmission queue; convert each dirty rectangle in the transmission queue into the browser interface rendering format of the user terminal according to the coordinate precision parameters and basic transformation matrix bound to the functional area to which the dirty rectangle belongs; and push the dirty rectangles in the browser interface rendering format to the browser interface of the user terminal according to the order of the transmission queue.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

Images