Oil and gas field service management method and device

Abstract

The application discloses an oil and gas field service management and control method and device, and relates to the technical field of oil and gas data processing. The method comprises the following steps: obtaining a field data exchange model; checking the field data exchange model according to a field data knowledge graph, wherein the field data knowledge graph comprises one field graph and multiple cross-field data graphs; after the checking is passed, determining the interface, dependency relationship and performance index of the field data service to be generated according to the field data exchange model, and generating the field data service; and after the generated field data service is registered to an oil and gas field cloud platform for collaborative verification, the field data service is published to the oil and gas field cloud platform after the collaborative verification is passed. The application can generate high-standard, unified and highly-reliable field data services, and improve the field data use efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of oil and gas data processing, and in particular to an oil and gas field service management method and device. BACKGROUND

[0002] By constructing a unified oil and gas field cloud platform, real-time data sharing and collaboration between different regions and different business departments can be realized, greatly shortening the project decision-making cycle. However, the traditional monolithic software development mode has obvious shortcomings in scalability and flexibility, and it is difficult to meet the rapidly changing business needs of the industry. Therefore, developing an industry cloud native agile development and operation system and building an open and shared software operation ecosystem have become the inevitable direction of industry development.

[0003] The landing of the oil and gas field cloud platform cannot be achieved without perfect data ecological support. Although the oil and gas industry has basically realized the centralized management of geological, drilling, and production data assets through the construction of a data lake, there are still many pain points in data usage. The problem of data silos is particularly prominent. Due to the use of different data standards and interface specifications by various business systems, geological research data and production operation data cannot be effectively interconnected, forming an information chimney. For example, due to incompatible data formats, the geological modeling system of an oilfield and the oil production operation system cannot timely guide production decisions based on geological analysis results, resulting in resource waste and efficiency loss. This data flow obstacle seriously hinders the collaborative effect of software cloudization in the oil and gas industry, making it difficult to achieve the goal of stringing beads together. Therefore, unifying data service formats and standards, establishing an efficient data service management mechanism, and developing a technical solution that can provide accurate data services for customers have become key issues that need to be addressed to promote high-quality development of the oil and gas industry. SUMMARY

[0004] In a first aspect, an oil and gas field service management method is provided to generate high-standard, unified, and highly reliable field data services. Through field data services, field data can flow freely on the oil and gas field cloud platform, improving the efficiency of field data usage. The method includes:

[0005] Obtaining a field data exchange model;

[0006] According to the field data knowledge graph, the field data exchange model is checked. The field data knowledge graph includes a field graph and multiple cross-field data graphs. The field graph is used to describe the relationship between field data, and each field data corresponds to a cross-field data graph. The cross-field data graph is used to describe the relationship between field data and cross-field data. The design constraint conditions of each field data are saved in the field graph. The design constraint conditions and / or optimization strategies of each cross-field data on field data are saved in the cross-field data.

[0007] After the examination passes, interfaces, dependency relationships and performance indicators of the field data service to be generated are determined according to the field data exchange model, and the field data service is generated;

[0008] After the generated field data service is registered to the oil and gas field cloud platform, collaborative verification is performed, and after the collaborative verification passes, the field data service is published to the oil and gas field cloud platform.

[0009] In the second aspect, the embodiments of the present application also provide an oil and gas field service management and control device to generate high-standard, unified and high-reliable field data services, and further realize barrier-free flow of field data on the oil and gas field cloud platform through the field data services, and improve the use efficiency of field data.

[0010] The field data exchange model obtaining module is configured to obtain a field data exchange model.

[0011] The field data exchange model checking module is configured to check the field data exchange model according to a field data knowledge graph, the field data knowledge graph including one field graph and multiple cross-field data graphs, wherein the field graph is used to describe the relationship between field data, each field data corresponds to a cross-field data graph, the cross-field data graph is used to describe the relationship between field data and cross-field data, and the design constraint conditions of each field data are saved in the field graph; the design constraint conditions and / or optimization strategies of each cross-field data on field data are saved in the cross-field data.

[0012] The field data service generating module is configured to determine the interfaces, dependency relationships and performance indicators of the field data service to be generated according to the field data exchange model after the examination passes, and generate the field data service.

[0013] The field data service registration and publishing module is configured to perform collaborative verification after the generated field data service is registered to the oil and gas field cloud platform, and publish the field data service to the oil and gas field cloud platform after the collaborative verification passes.

[0014] In the third aspect, the embodiments of the present application also provide a computer device, which includes a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the oil and gas field service management and control method when executing the computer program.

[0015] In the fourth aspect, the embodiments of the present application also provide a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the oil and gas field service management and control method.

[0016] In a fifth aspect, the embodiments of the present application further provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the oil and gas field service management method.

[0017] In the embodiments of the present application, a field data exchange model is obtained; the field data exchange model is checked according to a field data knowledge graph, the field data knowledge graph comprises one field graph and a plurality of cross-field data graphs, wherein the field graph is used to describe the relationship between field data, each field data corresponds to a cross-field data graph, the cross-field data graph is used to describe the relationship between field data and cross-field data, and the design constraint condition of each field data is saved in the field graph; the design constraint condition of each cross-field data on the field data and / or the optimization strategy is saved in the cross-field data; after the checking is passed, the interface, the dependency relationship and the performance index of the field data service to be generated are determined according to the field data exchange model, and the field data service is generated; the generated field data service is registered to the oil and gas field cloud platform for collaborative verification, and the field data service is published to the oil and gas field cloud platform after the collaborative verification is passed. Through the above steps, the oil and gas field exchange model can be uniformly managed, the high-standard and unified field data service can be generated after the field data exchange model is checked with high quality, and the field data service registered on the oil and gas field cloud platform is collaboratively verified, so that the safety and reliability of the field data service are guaranteed, the field data flows freely on the oil and gas field cloud platform, the construction resources and cost burden of the oil and gas field cloud platform are effectively reduced, and the data use efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, brief descriptions will be given below to the drawings needed to be used in the embodiments or prior art descriptions. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort based on these drawings. In the drawings:

[0019] Figure 1 The flowchart of the oil and gas field service management method in the embodiments of the present application;

[0020] Figure 2 The structure example of the field data exchange model in the embodiments of the present application;

[0021] Figure 3 The flowchart of checking the field data exchange module in the embodiments of the present application;

[0022] Figure 4 The flowchart of additional verification of the field data exchange module in the embodiments of the present application;

[0023] Figure 5 Flowchart for generating a field data service in an embodiment of the present application;

[0024] Figure 6 Flowchart for performing collaborative verification on a field data service registered on an oil and gas field cloud platform in an embodiment of the present application;

[0025] Figure 7 Flowchart for generating a routing proxy strategy for a field data service in an embodiment of the present application;

[0026] Figure 8 Schematic diagram of an oil and gas field service management and control device in an embodiment of the present application;

[0027] Figure 9 Schematic diagram of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0028] To make the objectives, technical solutions and advantages of embodiments of the present application clearer, further detailed descriptions of the embodiments of the present application are given below with reference to the drawings. Here, the schematic embodiments of the present application and their descriptions are used to explain the present application but are not intended to limit the present application.

[0029] Figure 1 Flowchart of an oil and gas field service management and control method in an embodiment of the present application, comprising:

[0030] Step 101, obtaining a field data exchange model;

[0031] Step 102, checking the field data exchange model according to a field data knowledge graph, the field data knowledge graph comprising one field graph and multiple cross-field data graphs, wherein the field graph is used to describe the relationship between field data, each field data corresponds to a cross-field data graph, the cross-field data graph is used to describe the relationship between field data and cross-field data, and the design constraint conditions of each field data are saved in the field graph; the design constraint conditions and / or optimization strategies of each cross-field data on field data are saved in the cross-field data;

[0032] Step 103, after the checking passes, determining the interface, dependency relationship and performance index of the field data service to be generated according to the field data exchange model, and generating the field data service;

[0033] Step 104, registering the generated field data service to the oil and gas field cloud platform for collaborative verification, and publishing the field data service to the oil and gas field cloud platform after the collaborative verification passes.

[0034] In the embodiment of the present application, the oil and gas field exchange model can be uniformly managed, and after high-quality checking of the field data exchange model, high-standard and unified field data services are generated, and the registered field data services on the oil and gas field cloud platform are collaboratively verified, thereby realizing safe and reliable guarantee of the field data services, realizing barrier-free flow of the field data on the oil and gas field cloud platform, effectively reducing the construction resources and cost burden of the oil and gas field cloud platform, and improving the data use efficiency. Each step is described in detail below.

[0035] In step 101, the field data exchange model is obtained.

[0036] In the embodiment of the present application, the obtained field data exchange model can be one or multiple, and when multiple field data exchange models exist, the oil and gas field service management and control scheme can be implemented on each field data exchange model in sequence.

[0037] The field data exchange model is usually designed by a joint field authority business team, and the design can be performed according to a preset template and rules.

[0038] The template defines the format, for example, the JSON format is defined, the JSON Schema specification Draft7 version is followed, the template defines the fields, for example, the exchange model id, the data type, the name, the model reference format, the mandatory item, the primary key, and the model attribute can be included, and each field has a corresponding design rule. In addition, JSON-LD (JSON for Linked Data) can be used to enhance the semantic expression ability of the data, so that the field data exchange model can be better combined with the semantic web technology. At the same time, for some complex data structures, the custom extension mechanism of the JSON Schema can be used to extend the specification to meet specific data service needs.

[0039] The rules followed by the editing of the field data exchange model include: judging whether the model is referenced, mainly judging by the state, if the state is published, modification is not allowed, if modification is needed, the version number is modified, a new record of the exchange model is added, and another version exists.

[0040] For example, the seismic trace set description exchange model can normalize the field data provided by the service provider of each query trace set description data service, and realize the unified access mode of the data consumer to call and use the data service of the service provider.

[0041] Figure 2 For the structure example of the field data exchange model in the embodiment of the present application, the field data exchange model adopts the JSON format.

[0042] In step 102, the field data exchange model is checked according to a field data knowledge graph, the field data knowledge graph including a field graph and a plurality of cross-field data graphs, wherein the field graph is used to describe the relationship between field data, each field data corresponds to a cross-field data graph, the cross-field data graph is used to describe the relationship between the field data and the cross-field data, and the design constraint conditions of each field data are saved in the field graph; the design constraint conditions and / or optimization strategies of each cross-field data on the field data are saved in the cross-field data.

[0043] The field data exchange model needs to be checked by expert knowledge, and the expert knowledge includes field expert knowledge and cross-field expert knowledge.

[0044] Figure 3 For the flowchart for checking the field data exchange module in the embodiment of the application, in an embodiment, the cross-field data graph includes a first-level cross-field data graph and a second-level cross-field data graph, each field data in the field graph corresponds to a first-level cross-field data graph and a second-level cross-field data graph, the first-level cross-field data graph is used to describe the relationship between the field data and the first-level related cross-field data, the second-level cross-field data graph is used to describe the relationship between the field data and the second-level related cross-field data, the design constraint conditions of each cross-field data on the field data are saved in the first-level cross-field data graph; and the optimization strategies of each cross-field data on the field data are saved in the second-level cross-field data.

[0045] According to the field data knowledge graph, the field data exchange model is checked, including:

[0046] In step 301, the knowledge graph is queried to obtain the field graph corresponding to the field of the field data exchange model.

[0047] Taking the field data exchange model as an example, the field data in the field model of the wellbore model includes all data related to the wellbore, the first-level cross-field data graph describes the cross-field data most related (first-level relatedness, or highest-level relatedness) to the wellbore field of each field data, such as data in the logging field and the seismic analysis field, and the second-level cross-field data graph describes the cross-field data in the data security field and the data governance field that are not related to the oil field, such as the data related to each field data, which is the second-level relatedness, that is, the relatedness of the cross-field data in the first-level cross-field data graph. For example, the data security expert knowledge can evaluate the security of the model in the data transmission and storage process, propose corresponding security strategies and measures, and ensure that the data is not leaked or tampered with; the data governance expert knowledge can review the model from the aspects of data quality and data standards to ensure the consistency and standardization of the data.

[0048] The knowledge graph is established according to the standard terms. The standard terms can query the term management system. The term management system can uniformly manage the terms in the field, including the definition, source, applicable scope and other information of the terms. At the same time, the terms are updated and maintained regularly to adapt to the development and changes of the industry. In the design process of the field data exchange model, the terms in the term management system are strictly followed to avoid confusion or inconsistency of the terms.

[0049] Taking the wellbore field as an example, when checking whether the metadata of the field data exchange model covers the field data in the field graph, in addition to the conventional geological data and production data of the wellbore, whether the related metadata such as environmental monitoring data and equipment maintenance data are included in the field data exchange model is checked to realize more comprehensive data service management. During the coverage checking, the term standardization checking is also performed. If the terms are not standardized, the standardized terms are directly replaced, and a first prompt message is generated;

[0050] Step 302, when the metadata of the field data exchange model covers the field data in the field graph, it is judged whether the metadata meets the design constraint condition of the corresponding field data in the field graph;

[0051] Step 303, when each metadata meets the design constraint condition of the corresponding field data in the field graph, a first-level cross-field data graph corresponding to the corresponding field data of each metadata in the field graph is queried to obtain the design constraint condition of each cross-field data for each metadata;

[0052] Step 304, when the design constraint condition of each cross-field data for each metadata is met, a second-level cross-field data graph corresponding to the corresponding field data of each metadata in the field graph is queried to obtain the optimization strategy for each metadata;

[0053] Step 305, the optimization strategy is sent to the field expert, and the field data exchange model fed back by the field expert is obtained;

[0054] Specifically, the field expert can select the feedback after optimization. In addition, the prompt information can be generated each time when the design constraint condition is not met; and the above steps can be repeatedly executed to obtain the field data exchange model which is no longer optimized by the field expert.

[0055] In an embodiment, the method further comprises:

[0056] A timestamp is added to each field data, cross-field data and relationship edge in the field graph and the cross-field data graph;

[0057] According to the business needs and actual situation, a business scenario label is added to each field data, cross-field data and relationship edge in the field graph and the cross-field data graph.

[0058] The method further includes: judging whether the metadata meets the design constraint condition of the corresponding domain data in the domain graph, including: screening the design constraint condition of the domain data in the domain graph according to the time stamp and the business scenario label, and judging whether the metadata meets the screened design constraint condition.

[0059] The method further includes: querying the first cross-domain data graph corresponding to the domain data corresponding to each metadata in the domain graph, and obtaining the design constraint condition of each cross-domain data for each metadata, including: querying the first cross-domain data graph corresponding to the domain data corresponding to each metadata in the domain graph, and screening the design constraint condition of each cross-domain data for each metadata according to the time stamp and the business scenario label.

[0060] In the oilfield development scenario, when a new development stage is entered, such as a transition from the exploration stage to the exploitation stage, a new time stamp is marked for the corresponding data node and relationship edge, so as to record the state and relationship change of the data in different stages. For example, in the oilfield development, business scenario labels such as conventional exploitation and special geological exploitation are set, and the data nodes and relationship edges meeting the specific scenario are marked with the corresponding labels. Through the time stamp and the business scenario label, dynamic association and evolution of the constraint condition are realized, and the corresponding design constraint condition is automatically called in different times and scenarios, and is used for checking the domain data exchange model.

[0061] Figure 4 For the flowchart of the additional verification process of the domain data exchange module in the embodiment of the application, in an embodiment, the method further includes:

[0062] Step 401: confidence degree annotation is performed on the relationship edge between the domain data and the cross-domain data in the cross-domain data graph.

[0063] Taking the relationship between the well logging data and the wellbore data as an example, the confidence degree value of the relationship between the two is determined through historical data statistics, expert evaluation and the like.

[0064] Step 402: when the confidence degree of the relationship edge is lower than the confidence degree threshold, an additional verification process is triggered.

[0065] The additional verification process can include increasing the verification times, adopting more stringent verification rules and the like, so as to ensure that the data interaction and model design under the low confidence degree relationship meet the requirements.

[0066] In addition, metadata bloodline tracking can be established. In the term management system, the source, processing process and destination of the metadata are combed to establish the bloodline relationship chain of the metadata. For example, a metadata about oilfield production records the device for its initial collection, the data processing algorithm passed and the application scenario finally applied, and the like, to form a complete bloodline relationship chain. When the term in the term management system is updated, the system automatically traces along the metadata bloodline relationship chain to identify the domain data exchange model affected by the change of the term. In this way, the part of the model that needs to be rechecked and adjusted can be quickly located, and the efficiency of data management and model verification is improved.

[0067] In step 103, after the check passes, the interface, dependency relationship and performance index of the domain data service to be generated are determined according to the domain data exchange model, and the domain data service is generated.

[0068] When the domain data service is generated, the other services, data resources and the like on which the service depends can be recorded, so that the dependency management can be accurately performed when the service is called; the response time, throughput and the like of the service are recorded as performance indexes, so that the performance of the service can be evaluated and optimized.

[0069] Figure 5 For the flowchart of generating the domain data service in the embodiment of the application, in an embodiment, the interface, dependency relationship and performance index of the domain data service to be generated are determined according to the domain data exchange model, and the domain data service is generated, including:

[0070] In step 501, all the domain data in the domain graph corresponding to the domain of the domain data exchange model and the relationship between the domain data are obtained, and the structure and flow direction of the domain data are determined.

[0071] In step 502, at least one domain data service to be generated and the corresponding function index and performance index are determined according to the business requirement, function requirement and performance requirement of the domain of the domain data exchange model, and the performance index at least includes one of response time, throughput, availability and resource utilization.

[0072] According to the business requirement of the domain of the domain data exchange model, it is determined which domain data services are needed. For example, based on the logging data exchange model, information query service, request data creation service, information update service and the like can be needed. The operation and processing requirement of the domain data in the business process are analyzed to ensure that the data service can meet the function requirement of the business scenario.

[0073] For the determined domain data service, define the function of the service in detail, including input, processing logic and output. For example, the input of the information query service may be the ID of the well, the processing logic is to retrieve the well information from the database, and the output is the detailed information of the well. According to the functional requirements and performance requirements of the determined domain data service, select a suitable technology stack, such as programming language, framework, database, etc. For example, for high-concurrency services, you can choose to use Go language and Gin framework, and use high-performance databases such as Redis for caching.

[0074] In specific implementation, a dynamic mapping mechanism based on domain graph and business scenario semantic model can be constructed. By analyzing the time, place, business type and other key elements (such as real-time data query demand in the peak season of oilfield exploitation) in the business demand text, combining the design constraint conditions and historical service invocation mode in the corresponding scene in the domain graph, the required generated domain data service type and function are automatically derived. Reinforcement learning algorithm is introduced, and according to the feedback of historical business demand and actual service use effect, the service demand derivation strategy is dynamically optimized.

[0075] The specific process includes:

[0076] Business demand text preprocessing: extract keywords and analyze semantic structure.

[0077] Knowledge graph matching: retrieve matching business scenarios and design constraint conditions in the domain data graph.

[0078] Service template generation: based on the matched business scenarios and design constraint conditions, select or combine from the pre-defined service template library to obtain the determined domain data service.

[0079] In the embodiment of the present application, a multi-dimensional technology stack evaluation model including performance indicators, data characteristics, security requirements, cost budget, etc. can be established. When selecting the technology stack in step 502, input the functional requirements, performance indicators (such as high concurrency and low latency requirements), data size and type (such as real-time stream data and structured data) of the domain data service, etc. The system calculates the weight of each dimension by analytic hierarchy process (AHP), and combines the preset technology stack capability matrix to automatically recommend the most suitable programming language, framework and database technology combination, and provide recommendation reasons and performance prediction report. It can avoid the blindness and experience dependence of manual selection of technology stack, shorten the selection time of technology stack by 60%, and improve the service performance compliance rate by 30%.

[0080] In the embodiment of the present application, the performance indicators include the following:

[0081] Response time: according to business requirements and user experience, set the maximum response time of the service, for example, the response time of the query platform data object service is required to be not more than 3 seconds.

[0082] Throughput: Determine the number of requests a service can handle per unit of time, for example, a drilling directional data acquisition service needs to achieve and maintain a throughput of at least 5000 records / second.

[0083] Availability: Set the availability index of the service, such as requiring the service to have an availability of 99.9% or above, ensuring that the service can run normally most of the time.

[0084] Resource utilization: Monitor the utilization of system resources (such as CPU, memory, disk I / O, etc.) by the service, set reasonable thresholds for resource usage, and avoid excessive resource consumption that may cause service performance degradation.

[0085] After determining the performance indicators, introduce machine learning algorithms to analyze the performance data of the service in real time. Establish a correlation model between performance indicators (such as response time, throughput) and system parameters (such as thread pool size, cache strategy), and automatically adjust system parameters for optimization when performance indicators deviate from preset thresholds. At the same time, according to the trend of business traffic, predict future performance requirements and perform resource expansion or contraction in advance.

[0086] Step 503, determine the interface parameters of each domain data service;

[0087] Interface design principles: Follow RESTful, SOAP, and other interface design specifications to ensure the ease of use, scalability, and maintainability of the interface. The interface should have clear naming and standardized parameter formats to facilitate the calling of other systems or services.

[0088] Define interface parameters: According to the function of the service, determine the input and output parameters of the interface. The input parameters should specify the type, format, and required items of the data, and the output parameters should define the data structure returned and possible error codes.

[0089] Interface documentation: Write detailed interface documentation, including interface function description, request method, request address, parameter description, return value description, etc., to facilitate developers to use and integrate.

[0090] The interface of the domain data service contains multiple description information, and the restful interface design specification provided by the unified data ecosystem is referred to;

[0091] In order to facilitate and unify management, the following requirements are defined for the parameters of the provided interface:

[0092] Domain: Adopt the unified domain naming system published by the platform, such as wellbore: drilling, logging, logging, etc.

[0093] Interface name: It is required to express according to the general terms of the industry content, and the interface name must match the interface content;

[0094] Interface path: format requirement / api / service class-interface name / version / service method, which reflects that the service type is based on domain data service (dms), covers interface name information, and reflects version and service class.

[0095] In implementation, semantic analysis can be performed on service function description based on natural language processing (NLP) and knowledge graph technology. When interface parameters are defined in step 503, key entities, attributes and relationships of input and output data are automatically extracted, and standard terms in the domain term management system are combined to generate interface parameters conforming to RESTful or SOAP specifications. A parameter conflict detection and resolution mechanism is introduced, and when there are naming conflicts or type inconsistencies in multiple service interface parameters, coordination and optimization are automatically performed.

[0096] For example, for the real-time data service of an oil well, the input parameter is automatically parsed as the oil well ID (integer type, mandatory), the output parameter is the real-time data of the oil well (JSON structure containing pressure, temperature and other attributes), and the standard interface document is generated.

[0097] In the embodiments of the application, an interface version dynamic evolution model can be designed, and a version identifier (such as / api / service class-interface name / version / service method in step 503) is embedded in the interface path. When the service function changes or performance is optimized, the system automatically determines whether a new interface version needs to be created according to the influence range of the change content. An interface compatibility detection algorithm is used to ensure smooth transition of the new version interface and the old version interface, and an interface version migration tool is provided to facilitate the upgrade of the calling party. The influence of interface changes on the calling party can be effectively reduced, the success rate of interface upgrade is improved to more than 95%, and system failures caused by interface incompatibility are reduced.

[0098] Step 504, analyze the dependency relationship of the domain data service, the dependency relationship including an internal dependency relationship and an external dependency relationship;

[0099] Internal dependency relationship: determine the internal dependency relationship of the domain data service, for example, a certain domain data service may depend on data or functions provided by other services. For example, a new attribute data object service may depend on a query attribute data object service to verify information such as seismic body object, work area object and project ID.

[0100] External dependency relationship: identify the dependency of the domain data service on external systems or third-party services. Analyze the stability and reliability of the dependency relationship, and develop corresponding coping strategies, such as backup solutions or degradation measures.

[0101] In step 504, when analyzing the dependency relationship, a probability relationship model is trained according to the relationship between cross-domain data in the cross-domain data graph, and the probability relationship model is used to probabilistically evaluate the stability of internal and external dependencies. Each dependency relationship is labeled with a confidence level and a risk level. When the confidence level of a dependency relationship is below a threshold or the risk level rises, a backup plan or a degradation measure is automatically triggered. A dependency relationship dynamic adjustment algorithm is introduced to optimize dependency relationships in real time based on actual service runtime conditions, such as automatically switching to local caching or backup data sources when external services are overloaded.

[0102] In step 505, the structure and flow direction of the domain data in the domain data service to be generated, performance indicators, functional indicators, interface parameters, and dependency relationships are implemented and tested.

[0103] Coding implementation: According to the design scheme, the selected technology stack is used for the coding implementation of the service. In the implementation process, good coding specifications and design patterns are followed to improve the quality and maintainability of the code.

[0104] Unit testing: Each service is unit tested to verify the correctness of the service's functionality and ensure that the service functions properly under various input conditions.

[0105] Integration testing: Integration testing between services is performed to verify the normality of dependency relationships and interface calls between services and ensure the functional integrity of the entire system.

[0106] Performance testing: Performance testing tools are used to test the performance of the service to verify whether the service meets the set performance indicators. Performance optimization is performed based on the test results, such as adjusting algorithms and optimizing database queries.

[0107] Step 506: After the domain data service testing is passed, the service is deployed on the oil and gas domain cloud platform.

[0108] Deployment: The tested service is deployed to the production environment to ensure stable operation of the service. Containerization technology (such as Docker) and container orchestration tools (such as Kubernetes) can be used to simplify deployment and management.

[0109] Monitoring and alerting: Set up a monitoring system to monitor the performance indicators and running status of the service in real time. When the service has an exception or the performance indicators exceed the threshold, an alarm notification is sent in a timely manner to handle the problem in a timely manner.

[0110] In step 104, after the generated domain data service is registered to the oil and gas domain cloud platform, it is verified in collaboration, and after the collaborative verification is passed, the domain data service is published to the oil and gas domain cloud platform.

[0111] An automatic service registration process is adopted to realize automatic registration and update of services through integration with the oil and gas field cloud platform. When a new service is published or an existing service is changed, the service registration information is automatically synchronized to the service registration center, reducing manual intervention and improving registration efficiency and accuracy. At the same time, in order to ensure the security of service registration, an identity authentication and authorization mechanism is adopted to control the permissions of service registration operations.

[0112] The content of the service registration information is shown in Table 1.

[0113] Table 1

[0114]

[0115] The corresponding interface parameters need to be filled in during registration, and the interface document and field data service description document are filled in and uploaded according to the data ecological document template. Among them, the field data service description document should include the calling sequence of data, input and output data description, data service result assertion and other information.

[0116] The embodiment of the present application provides the registration of basic information and uploads the document during the registration of the field data service, which is the key reference for subsequent service verification and service audit, and is also to ensure that the provided data service can fully comply with the standards and specifications formulated by the data ecology, and to ensure that the data service can run effectively in the data ecology.

[0117] In step 105, the field data service registered on the oil and gas field cloud platform is verified in coordination, and the coordinated verification includes compliance verification, fault injection verification and chaos verification;

[0118] Figure 6 For the flowchart of the embodiment of the present application for the coordinated verification of the field data service registered on the oil and gas field cloud platform, in an embodiment, the coordinated verification of the field data service registered on the oil and gas field cloud platform includes:

[0119] In step 601, after the generated field data service is registered to the oil and gas field cloud platform, the field type, business process and compliance requirements of the field data service are extracted;

[0120] In step 602, the field type, business process and compliance requirements are input into the lightweight decision model to obtain the optimal verification combination, the optimal verification combination includes the actual verification index in the field data service verification index system, the actual fault injection scene, the actual fault injection strategy and the actual chaos parameter, and the lightweight decision model is obtained based on the verification index data, fault input strategy, chaos parameter and verification result of the historical field data service in the field of the field data service;

[0121] The verification indicators include one or any combination of a function compliance indicator, a performance compliance indicator, a security compliance indicator, a data privacy compliance indicator, a license compliance indicator, an operation compliance indicator, and a reliability compliance indicator.

[0122] The domain data service verification indicator system is a top-down multi-layer structure, covering function compliance indicators, performance compliance indicators, and security compliance indicators. First, three top-level indicators are constructed, and then sub-indicators under each top-level indicator are refined. Function compliance includes business rule compliance, etc. Performance compliance covers response time, throughput, resource utilization, and stability, etc. Security compliance includes access control, data encryption, identity verification, etc. Data privacy compliance focuses on the compliance of data collection, storage, processing, and sharing, including data sharing restrictions and user control, etc. License compliance includes license identification, compatibility, and updates, etc. Operation compliance covers software installation configuration, system updates, and log management, etc. At the same time, the entropy weight method is used to calculate the information entropy of each indicator to determine its weight in comprehensive evaluation, forming a scientific compliance evaluation method.

[0123] An indicator library monitoring mechanism can be established to periodically or real-time correct and supplement indicators according to business changes, regulatory adjustments, and system operation problems, and record rule change history through version management. Specifically, legal regulations, industry standards, and enterprise internal specifications can be collected and sorted, stored in a structured manner, regularly updated and maintained to ensure timeliness and accuracy of the content, and provide a basis for compliance verification.

[0124] Step 603, performing rule checking on the domain data service based on the actual verification indicators to obtain rule checking results;

[0125] During the execution, multi-dimensional rule correlation analysis is performed to focus on the correlation between rules and discover potential problems. At the same time, based on the compliance knowledge base, the compliance is verified, the service compliance is evaluated, and the high-risk indicator is determined through the risk assessment mechanism to focus on verification and monitoring.

[0126] Step 604, if the rule checking result includes abnormal rule checking data, marking the abnormal rule checking data as a trigger fault injection signal, in the actual fault injection scene, performing fault injection on the domain data service according to the actual fault injection strategy, when the fault is input, integrating the actual chaos parameter into the actual fault injection scene, monitoring the running state of the domain data service in real time, obtaining fault recovery data, and judging whether the fault recovery data meets the fault recovery requirements;

[0127] Fault injection is a method of actively introducing faults to test the behavior and recovery capabilities of services under abnormal conditions. By simulating various possible fault scenarios such as network delays, data loss, hardware failures, etc., the stability and fault tolerance capabilities of services under these conditions can be evaluated. Fault injection can help discover potential problems in services and ensure that services can operate normally under abnormal conditions.

[0128] In addition to common scenarios such as network delays, data loss, hardware failures, etc., further expand the diversity of fault scenarios. For example, simulate the return of abnormal data formats, data volume far exceeding expectations, etc. of third-party interfaces that services depend on, to more comprehensively test the fault tolerance capabilities of services.

[0129] For example, if the response time in the performance rule exceeds the preset threshold (such as 200ms), or the security rule detects an unauthorized access attempt, mark it as a trigger for fault injection signals.

[0130] If the recommended strategy contains high-priority network fault injection scenarios, prioritize related operations. Only when the rule check result is abnormal and there is a corresponding actual fault injection strategy in the intelligent strategy, will the fault injection start be triggered, avoiding unnecessary fault simulation.

[0131] Actual chaos parameters such as data read-write order chaos degree, data packet reordering probability, etc. will be integrated into actual fault injection scenarios. For example, when simulating a hard disk failure, introduce a chaotic factor with a 20% probability of data read-write order chaos.

[0132] In addition, special fault scenarios can be designed for third-party interfaces that services depend on, simulating the return of abnormal data formats (such as incorrect JSON structure), data volume far exceeding expectations (more than 3 times the normal amount), etc. to enrich the diversity of fault scenarios.

[0133] When performing actual fault injection, attention should be paid to the timing and frequency control of injection.

[0134] Timing strategy execution:

[0135] Service startup initial stage: After service initialization is completed, immediately perform low-frequency fault injection (such as 1 injection every 5 minutes) to detect the stability of the service startup phase.

[0136] High-concurrency running stage: By monitoring the number of concurrent requests of the service, when reaching the set threshold (such as 5000 times / second), increase the fault injection frequency (1 injection every 30 seconds) to test the service's ability to cope with high loads.

[0137] When the cloud platform resources in the oil and gas field are in short supply: real-time monitoring of resource indicators such as CPU usage, memory occupation, etc. When the CPU usage exceeds 80% or the memory remaining amount is less than 20%, start the customized fault injection strategy to increase the complexity of the fault.

[0138] Frequency dynamic adjustment: dynamically adjust the fault injection frequency according to the real-time state feedback of the service. If the service can quickly recover after two consecutive fault injections and the performance is not significantly affected, increase the injection frequency appropriately; otherwise, reduce the frequency or suspend the injection to avoid service crashes.

[0139] After fault injection, real-time monitoring of the running state of the service, recording the time nodes of the service from fault occurrence to recovery, whether the fault recovery data meets the fault recovery requirements, which can be judged by whether the service can automatically restart, whether the data is completely recovered, etc. Key indicators. Monitor the resource usage of the service during the fault recovery process, including the change trend of the occupation rate of resources such as CPU, memory, disk I / O, etc., and analyze the impact of resource bottlenecks on recovery efficiency.

[0140] Data consistency verification: compare the data state before and after the fault to verify the integrity and consistency of the data. For example, check whether the data records in the database are lost or incorrect to ensure the accuracy of the data after the service recovers.

[0141] Step 605, at the same time when the fault injection starts, start chaos verification, apply the actual chaos parameters to the field data service, and obtain the chaos verification result;

[0142] Chaos verification is a method of testing systems by introducing randomness and uncertainty. By simulating various possible abnormal situations such as network congestion, data packet loss, hardware failure, etc., the behavior and recovery ability of the service under these conditions can be evaluated. Chaos verification can help discover potential problems in the service and ensure that the service can run normally under abnormal conditions.

[0143] During chaos verification, collect the running data of the field data service at a high frequency (such as 10 times per second), including performance indicators such as response time, throughput, error rate, service call link information, and detailed data such as system logs, abnormal stack information, etc. Use data analysis algorithms to extract key indicators and features from the large amount of collected data, such as performance decline trend before service crash, specific interface call that causes error, etc., to obtain chaos verification results.

[0144] Chaos verification needs to combine qualitative analysis (phase diagram, time series) and quantitative indicators (Lyapunov exponent, fractal dimension, etc.). When the core indicators meet the chaos characteristics and are cross-verified by multiple methods, it is considered that the chaos verification is passed.

[0145] Chaotic verification can be characterized by the following indicators:

[0146] 1. Phase space trajectory:

[0147] Description: Show the geometric pattern of system motion by plotting the phase diagram of system state variables (e.g., trajectory in two-dimensional plane or three-dimensional space).

[0148] Characteristics: The phase trajectory of a chaotic system usually presents a strange attractor pattern that is irregular and never repeating, such as the butterfly structure of the Lorenz attractor.

[0149] 2. Time series characteristics:

[0150] Description: Record the output data sequence of the system over time.

[0151] Characteristics: Chaotic time series appears random, but contains deterministic rules, with non-periodicity and long-term unpredictability.

[0152] Chaotic verification generally requires the calculation of the following quantitative indicators:

[0153] 1. Lyapunov exponent:

[0154] Definition: Measure the exponential separation speed of adjacent trajectories in phase space, which is the core quantitative indicator of chaotic systems.

[0155] Result performance: There is at least one positive Lyapunov exponent, indicating that the system is extremely sensitive to initial conditions (e.g., in a three-dimensional system, the maximum Lyapunov exponent ).

[0156] 2. Fractal dimension:

[0157] Definition: Describe the complex geometric structure of the attractor, reflecting the space-filling characteristics of the system.

[0158] Common types and results:

[0159] Box dimension: The box dimension of a chaotic attractor is usually a non-integer, such as the Lorenz attractor with a dimension of about 2.06.

[0160] Correlation dimension: Used to describe the fractal characteristics of the attractor, the correlation dimension of a chaotic system is a fraction.

[0161] 3. Power spectral density:

[0162] Description: Analyze the energy distribution of time series in the frequency domain.

[0163] Features: the power spectrum of chaotic system presents continuous broadband characteristics, without obvious periodic peaks (different from the discrete spectrum of periodic system).

[0164] 4. Entropy:

[0165] Topological entropy: measures the complexity of system dynamics, the topological entropy of chaotic system is positive.

[0166] Kolmogorov-Sinai entropy (K-S entropy): represents the rate of uncertainty growth of long-term prediction of the system, the K-S entropy of chaotic system is positive.

[0167] Chaos verification generally includes the following statistical property analysis:

[0168] 1. Probability distribution: the probability density function of chaotic time series may present a specific shape (such as unimodal or multimodal), but it needs to be distinguished from random noise (the distribution of noise is mostly Gaussian).

[0169] 2. Autocorrelation: the autocorrelation function of chaotic sequence usually decays rapidly, indicating that the sequence has weak correlation in time.

[0170] The conditions for passing the chaos verification include that the core indicators meet the chaos characteristics, multiple methods are cross-verified, other system types are excluded, and the parameter robustness is verified, or in other words, the chaos verification result is chaos verification passed.

[0171] 1. Core indicators meet the chaos characteristics:

[0172] Lyapunov exponent is positive: this is a necessary condition for chaos, if the largest Lyapunov exponent , and other exponents meet the rules corresponding to the dimension of the system (such as in a three-dimensional system

[0173] Fractal dimension is non-integer: the fractal dimension (such as box dimension, correlation dimension) of the attractor is a fraction, and the value meets the service characteristics (such as the correlation dimension of logistic map is about 0.5).

[0174] 2. Multiple methods cross-verification

[0175] Phase diagram combined with time series: the phase trajectory presents the shape of chaotic attractor, while the time series is non-periodic and has no obvious rules.

[0176] Power spectrum and Lyapunov exponent complement each other: the power spectrum is continuous broadband, and the Lyapunov exponent is positive, excluding periodic or quasi-periodic services (periodic services have power spectrum peaks, and Lyapunov exponent is 0).

[0177] 3. Exclude other service types

[0178] Non-periodic but not chaotic: Some services (e.g., quasi-periodic services) can have non-periodic characteristics, but the Lyapunov exponent is 0, and the fractal dimension is an integer, which needs to be distinguished by indicators.

[0179] Noise interference: The Lyapunov exponent of random noise can be positive, but the power spectrum is uniformly distributed, and the fractal dimension does not have the characteristics of chaotic attractors, which can be excluded by statistical methods (such as surrogate data analysis) to exclude the influence of noise.

[0180] 4. Parameter robustness

[0181] Within a certain parameter range, the chaotic characteristics (such as positive Lyapunov exponent, fractal dimension) remain stable, and chaos only occurs at a single parameter.

[0182] The following is a typical case of chaos verification results of a service.

[0183] Logistic map: when the parameter , the service enters a chaotic state, and the maximum Lyapunov exponent , the phase diagram presents a bifurcation to chaos process, and the power spectrum is continuous.

[0184] Lorenz system: when the parameter , the service exhibits chaotic characteristics, the phase trajectory forms a butterfly-shaped attractor, and the maximum Lyapunov exponent is about 0.906.

[0185] In the embodiments of the present application, process collaborative control can be performed, specifically, finite state machines can be used.

[0186] State definition: define the states of three verification methods of rule checking, fault injection, and chaos verification, including initial state (rule checking waiting), running state, pause state, end state, etc., and clarify the meaning of each state and the corresponding operation.

[0187] Trigger condition setting: set the trigger condition for state transition, such as when the rule checking is completed and performance anomalies are found, trigger the state transition from rule checking to fault injection; after fault injection is completed, decide whether to transition to chaos verification state according to the result.

[0188] State transition logic: draw a state transition diagram to clearly show the transition relationship and conditions between states, and ensure that the verification process is executed according to the predetermined logic. For example, after chaos verification is completed, regardless of the result, it is transferred to the test report generation state.

[0189] Strict sequence control: At the beginning of verification, force the initial state into rule check, and only when the rule check is completed and certain conditions are met, allow transition to fault injection or chaos verification state according to the associated rules, avoiding confusion in the verification process.

[0190] Time interval setting: Set a reasonable time interval for switching between different verification methods to prevent the next verification method from starting before the previous one is completed. For example, wait for 5 seconds after rule check is completed before starting fault injection to ensure system stability.

[0191] The embodiment of the present application also proposes an exception handling and process rollback strategy.

[0192] Concurrent and serial control: According to the verification strategy and service characteristics, flexibly control the execution mode of the verification method. For some complex fault scenarios, fault injection and chaos verification can be executed concurrently to improve verification efficiency; for regular verification, use serial execution mode to ensure verification accuracy.

[0193] Exception detection mechanism: Set exception detection points at each stage of the verification process to monitor errors, timeouts and other exceptions in real time. For example, if the fault injection module fails to inject a fault within a specified time (e.g. 1 minute), it is determined to be an exception.

[0194] Exception response strategy: For different types of exceptions, formulate corresponding response strategies. If it is a recoverable exception (such as a temporary network interruption), automatically retry the current verification step; if it is a serious exception (such as service crash cannot be restarted), immediately suspend the verification process, record exception information, and trigger manual intervention process.

[0195] Process rollback operation: When an exception occurs and verification needs to be terminated, perform a process rollback operation to restore the service to its pre-verification state, release occupied resources, and avoid causing persistent impact on the service. At the same time, save the completed verification data for subsequent analysis and troubleshooting.

[0196] Record the execution trajectory, input and output, and service response data of the three verification methods during the verification process, generate a test report containing 3D verification trajectory, and display the rule check, fault injection, chaos verification results and service performance changes in visual charts.

[0197] In an embodiment, trigger rules are set between different verification indicators in the domain data service verification indicator system.

[0198] The method further comprises:

[0199] When performing the rule check on the domain data service based on the actual verification index, if the associated verification index of the actual verification index is triggered based on the triggering rule, performing the rule check on the domain data service based on the associated verification index.

[0200] In the above embodiment, not only the execution result of a single verification index is focused on, but also the correlation between different dimension verification indexes is analyzed, that is, the triggering rule between different verification indexes in the domain data service verification index system is determined, for example, when the performance compliance index is abnormal, the security compliance index and the function compliance index are associated and analyzed to determine whether there is a potential security vulnerability or function defect causing performance problems.

[0201] In an embodiment, after the cooperative verification is passed, the domain data service is published to the oil and gas field cloud platform, comprising:

[0202] Cooperatively verifying the domain data service registered on the oil and gas field cloud platform, the cooperative verification comprising cooperatively performing compliance verification, fault injection verification and chaos verification;

[0203] When the rule check result is a check pass, or the fault recovery data meets the fault recovery requirements, or the chaos verification result is a chaos verification pass, the domain data service is published to the oil and gas field cloud platform

[0204] In an embodiment, before publishing the domain data service to the oil and gas field cloud platform, the method further comprises:

[0205] Sending the domain data service to a domain expert, so that the domain expert calls an artificial intelligence model to analyze the business rationality and interface design rationality of the domain data service and gives an audit result of the domain data service;

[0206] After receiving the audit result feedback from the domain expert, the domain data service is published to the oil and gas field cloud platform.

[0207] The audit of the domain expert is based on the experience judgment of the authoritative domain expert in the industry. In order to assist the intelligent audit of the domain expert, artificial intelligence technology is introduced to assist the audit. For example, an artificial intelligence model is used to analyze and predict the business rationality and interface design rationality of the domain data service, and to provide a reference basis for expert audit. At the same time, an audit feedback mechanism is established to feedback the audit result to the service provider in a timely manner for improvement.

[0208] In addition, when auditing the domain data service, factors such as maintainability and scalability of the service should also be considered. For example, whether the code structure of the service is clear and easy to maintain is evaluated; whether the service has good scalability to adapt to the development and changes of business is evaluated.

[0209] The API interface of the published domain data service can provide services externally. The published services are uniformly aggregated into the data ecological service resource pool of the oil and gas field cloud platform. The services can be gradually pushed to users in a gray release, blue-green deployment, etc., to reduce the release risk. During the release process, the running state of the service is closely monitored, and problems that may occur are handled in a timely manner.

[0210] After the service is published, a complete service management and monitoring system is established. The running state of the service is monitored in real time, including response time, throughput, error rate, etc. When the service is abnormal, timely warning and processing are performed. At the same time, feedback from users is collected, and the service is continuously optimized and improved.

[0211] The published services are uniformly encapsulated by the data ecology, including:

[0212] Code sorting and modularization: The code of the domain data service is comprehensively sorted, and related functional modules are reasonably divided and encapsulated. Ensure that each module has single function and clear responsibility, and reduce the coupling degree between modules. For example, different functions such as data query, data processing and data storage are encapsulated into independent modules, which is convenient for subsequent maintenance and reuse.

[0213] Dependency management: Clearly define the third-party libraries, frameworks, tools, etc. that the service depends on, and manage the versions. Use package management tools (such as Maven, Gradle, etc.) to manage project dependencies to ensure consistency in different environments. At the same time, isolate the dependencies from the service code to avoid dependency conflicts affecting the normal operation of the service.

[0214] Build executable files or images: According to the technology stack used by the service, choose the appropriate way to build executable files or container images. If it is a Java service, it can be packaged into a JAR file; if it is based on containerized deployment, use Dockerfile to build Docker image. During the construction process, ensure that all necessary files and configurations are included, such as configuration files, log files, etc.

[0215] Figure 7 For the flowchart of generating a routing agent strategy for a domain data service in the embodiments of the present application, in an embodiment, after the domain data service is published to the oil and gas field cloud platform, it further includes:

[0216] Step 701, collecting request data, service instance running data, historical traffic data and security related data of the existing domain data service;

[0217] Among them, the request data such as URL, header information, user identity, service instance running data such as CPU, memory, disk I / O utilization, response time, response success rate, historical traffic data such as access volume of different time periods, regions, security related data such as request behavior log, threat detection record;

[0218] Step 702, based on the collected request data, service instance running data, historical traffic data and security related data, using time series prediction algorithm to predict the load and traffic trend of the domain data service;

[0219] The collected data can be cleaned to remove abnormal and repeated data, and standardized processing is carried out, and stored in the data warehouse to provide reliable data basis for subsequent analysis.

[0220] Step 703, determine the request corresponding to the domain data service;

[0221] Specifically, the initial routing direction corresponding to the request data of the request can be determined according to the preset routing parameter template, so as to determine the domain data service corresponding to the request.

[0222] Step 704, combined with the predicted load and traffic, determine the load balancing strategy of the domain data service for each request;

[0223] For example, if the performance of the domain data service is similar according to the traffic, a round robin strategy is adopted; for example, there are three same configuration domain data service instances A, B and C, request 1 is sent to A, request 2 is sent to B, request 3 is sent to C, request 4 is sent to A again, and so on. When the performance is different, weighted round robin strategy is applied, and the request distribution is dynamically adjusted according to the real-time weight; suppose the performance of instance A is stronger, and the weight is set to 3; the performance of instances B and C is slightly weaker, and the weight is set to 1. Then when distributing 10 requests, instance A may handle 6 times, and instances B and C handle 2 times respectively. According to the traffic distribution of different regions and time periods, the strategy based on traffic is implemented. For example, in the daytime, the access volume of the first region is large, more requests from the first region can be routed to the service instance deployed in the first region; in the evening, the traffic of the second region increases, and the routing strategy is adjusted accordingly.

[0224] Step 705, according to the predicted load and traffic, determine the priority execution strategy of the domain data service for high priority requests;

[0225] Specifically, high priority requests are preferentially routed to high performance and high stability service instances, and more resources are allocated; for low priority requests, delay or degradation processing is performed when resources are scarce. And the high performance and high stability service instance is the domain data service that can carry more load and traffic.

[0226] In addition, a health check strategy can also be adopted: periodically performing health check on the back-end domain data service instance to ensure that only healthy instances can receive requests. The health status of an instance can be determined by sending a heartbeat packet, performing simple business logic check, etc. If an instance does not respond or returns an error result in multiple checks, it is marked as unhealthy, and the request is suspended to it, and the operation and maintenance personnel are notified for processing.

[0227] In an embodiment, the method further comprises:

[0228] The change of the domain data service is implemented through the message change service.

[0229] After the domain data service is published, a data change service interface containing information such as name, request mode, path, and parameter needs to be provided to the oil and gas domain cloud platform, so that the oil and gas domain cloud platform can send a data push command, and each DMS sends data in real time through a real-time push channel in the cloudevent data format. The data change mechanism enables the oil and gas domain cloud platform to obtain the change of each domain service data in a timely manner and make a timely response, thereby ensuring the timeliness of the service data provided to the outside. For the message change service, in addition to using it when the published service changes, it can also be considered to actively trigger the message change service when the data changes abnormally. For example, when the oil and gas production data abnormally fluctuates, the oil and gas domain cloud platform automatically sends a message change notification to notify the relevant service to process. At the same time, in order to improve the reliability of the message change service, the message queue technology is used to cache and process the message, so as to ensure that the message is not lost or repeated.

[0230] The embodiment of the present application also proposes an oil and gas domain service management and control device, which has a similar principle to the oil and gas domain service management and control generation method, and will not be described here.

[0231] Figure 8 The schematic diagram of the oil and gas domain service management and control device in the embodiment of the present application comprises:

[0232] The domain data exchange model obtaining module 801 is configured to obtain a domain data exchange model.

[0233] The domain data exchange model checking module 802 is configured to check the domain data exchange model according to a domain data knowledge graph, wherein the domain data knowledge graph comprises a domain graph and a plurality of cross-domain data graphs, the domain graph is used to describe the relationship between domain data, each domain data corresponds to a cross-domain data graph, the cross-domain data graph is used to describe the relationship between the domain data and the cross-domain data, the design constraint condition of each domain data is saved in the domain graph, and the design constraint condition and / or optimization strategy of each cross-domain data on the domain data are saved in the cross-domain data.

[0234] The domain data service generation module 803 is configured to, after the check passes, determine the interface, dependency relationship and performance index of the domain data service to be generated according to the domain data exchange model, and generate the domain data service.

[0235] The domain data service registration and publishing module 804 is configured to perform collaborative verification after the generated domain data service is registered to the oil and gas domain cloud platform, and publish the domain data service to the oil and gas domain cloud platform after the collaborative verification passes.

[0236] In an embodiment, the cross-domain data graph includes a first cross-domain data graph and a second cross-domain data graph, and each domain data in the domain graph corresponds to a first cross-domain data graph and a second cross-domain data graph. The first cross-domain data graph is used to describe the relationship between the domain data and the cross-domain data of the first correlation degree, and the second cross-domain data graph is used to describe the relationship between the domain data and the cross-domain data of the second correlation degree. The first cross-domain data graph saves the design constraint condition of each cross-domain data to the domain data; and the second cross-domain data saves the optimization strategy of each cross-domain data to the domain data.

[0237] The domain data exchange model checking module is configured to:

[0238] query the knowledge graph to obtain the domain graph corresponding to the domain of the domain data exchange model;

[0239] when the metadata of the domain data exchange model covers the domain data in the domain graph, determine whether the metadata meets the design constraint condition of the corresponding domain data in the domain graph;

[0240] when each metadata meets the design constraint condition of the corresponding domain data in the domain graph, query the first cross-domain data graph corresponding to each cross-domain data corresponding to each metadata of the corresponding domain data in the domain graph, to obtain the design constraint condition of each cross-domain data to each metadata;

[0241] when the design constraint condition of each cross-domain data to each metadata is met, query the second cross-domain data graph corresponding to each cross-domain data corresponding to each metadata of the corresponding domain data in the domain graph, to obtain the optimization strategy for each metadata;

[0242] send the optimization strategy to a domain expert, and obtain the domain data exchange model fed back by the domain expert.

[0243] In an embodiment, the domain data exchange model checking module is further configured to:

[0244] add a time stamp to each domain data, cross-domain data and relationship edge in the domain graph and the cross-domain data graph;

[0245] According to the business needs and actual conditions, a business scenario label is added to each field data, cross-field data and relationship edge in the field graph and the cross-field data graph;

[0246] The metadata is determined whether to meet the design constraint condition of the corresponding field data in the field graph, including: in the field graph, the design constraint condition of the field data is filtered according to the timestamp and the business scenario label, and it is determined whether the metadata is filtered design constraint condition;

[0247] The first cross-field data graph corresponding to the field data corresponding to each metadata in the field graph is queried to obtain the design constraint condition of each cross-field data to each metadata, including: the first cross-field data graph corresponding to the field data corresponding to each metadata in the field graph is queried, and the design constraint condition of each cross-field data to each metadata is filtered according to the timestamp and the business scenario label.

[0248] In an embodiment, the field data exchange model checking module is further used for:

[0249] The relationship edge between the field data and the cross-field data in the cross-field data graph is annotated with confidence;

[0250] When the confidence of the relationship edge is lower than the confidence threshold, an additional verification process is triggered.

[0251] In an embodiment, the field data service generation module is used for:

[0252] All field data and the relationship between the field data in the field graph corresponding to the field of the field data exchange model are obtained, and the structure and flow direction of the field data are determined;

[0253] According to the business needs, functional requirements and performance requirements of the field where the field data exchange model is located, at least one field data service to be generated and corresponding functional indicators and performance indicators are determined, and the performance indicators at least include one of response time, throughput, availability and resource utilization;

[0254] The interface parameters of each field data service are determined;

[0255] The dependency relationship of the field data service is analyzed, including internal dependency relationship and external dependency relationship;

[0256] According to the structure and flow direction of the field data in the field data service to be generated, the performance indicators, the functional indicators, the interface parameters and the dependency relationship, the field data service is implemented and tested;

[0257] After the field data service test is passed, the field data service is deployed on the oil and gas field cloud platform.

[0258] In an embodiment, the domain data service registration and publishing module is further configured to:

[0259] After generating the domain data service registration and publishing module, the domain type, business process and compliance requirements of the domain data service are extracted;

[0260] The domain type, business process and compliance requirements are input into the lightweight decision model to obtain the optimal verification combination, which includes the actual verification index, actual fault injection scene, actual fault injection strategy and actual chaos parameter in the domain data service verification index system. The lightweight decision model is trained based on the historical domain data service verification index data, fault injection strategy, chaos parameter and verification result in the domain of the domain data service;

[0261] Based on the actual verification index, the rule check result of the domain data service is obtained;

[0262] If the rule check result includes abnormal rule check data, the abnormal rule check data is marked as a trigger fault injection signal. In the actual fault injection scene, the domain data service is fault injected according to the actual fault injection strategy. When fault input, the actual chaos parameter is integrated into the actual fault injection scene. The running state of the domain data service is monitored in real time to obtain fault recovery data. It is judged whether the fault recovery data meets the fault recovery requirement;

[0263] At the same time of starting fault injection, start chaos verification, apply actual chaos parameter to domain data service, and obtain chaos verification result.

[0264] In an embodiment, trigger rules are provided between different verification indexes in the domain data service verification index system;

[0265] The domain data service registration and publishing module is further configured to:

[0266] When performing rule check on the domain data service based on the actual verification index, if the associated verification index of the actual verification index is triggered based on the trigger rule, the rule check on the domain data service based on the associated verification index is performed.

[0267] In an embodiment, the domain data service registration and publishing module is further configured to:

[0268] The domain data service registered on the oil and gas field cloud platform is verified cooperatively, and the cooperative verification includes cooperative compliance verification, fault injection verification and chaos verification;

[0269] If the rule check result is check passed, or the fault recovery data meets the fault recovery requirement, or the chaos verification result is chaos verification passed, the domain data service is published to the oil and gas field cloud platform.

[0270] In an embodiment, the device further comprises an auditing module configured to:

[0271] Before publishing the domain data service to the oil and gas domain cloud platform, the domain data service is sent to a domain expert, so that the domain expert gives an auditing result of the domain data service after analyzing the business rationality and interface design rationality of the domain data service by calling an artificial intelligence model;

[0272] After receiving the feedback auditing result of the domain expert, the domain data service is published to the oil and gas domain cloud platform.

[0273] In an embodiment, the device further comprises a routing agent strategy determination module configured to, after publishing the domain data service to the oil and gas domain cloud platform, collect request data, service instance running data, historical traffic data and security related data of the existing domain data service;

[0274] Based on the collected request data, service instance running data, historical traffic data and security related data, a time series prediction algorithm is used to predict the load and traffic trend of the domain data service;

[0275] Determine the request corresponding to the domain data service;

[0276] Determine the load balancing strategy of the domain data service for each request in combination with the predicted load and traffic.

[0277] According to the predicted load and traffic, determine the priority execution strategy of the domain data service for high priority requests.

[0278] The embodiment of the present application further provides a computer device, Figure 9 The computer device 900 comprises a memory 910, a processor 920 and a computer program 930 stored in the memory 910 and executable on the processor 920, and the processor 920 implements the above-mentioned oil and gas domain service control method when executing the computer program 930.

[0279] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the above-mentioned oil and gas domain service control method.

[0280] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the above-mentioned oil and gas domain service control method.

[0281] Those skilled in the art will appreciate that embodiments of the present application can be readily used as software, hardware, or a combination of software and hardware. In a software embodiment, the present application can be implemented with computer programs (also referred to as software instructions, software code, computer code, and the like) that execute on programmable hardware including computer processors, digital signal processors, microprocessors, central processing units, microcontrollers, programmable hardware logic devices, and the like. Generally, the present application can be implemented in hardware, software, or any combination of hardware and software.

[0282] The present application is described in reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. 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 processing device 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, create means for implementing the functions specified in the flowchart Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

[0283] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

[0284] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks. Figure 1 one or more functions specified in the flowchart block or blocks.

[0285] The specific embodiments described above have been disclosed by way of example and that, obviously, any modifications and / or alterations to the disclosure here disclosed are possible without departing from the scope of the application, which is defined by the appended claims.

Claims

1. A method for managing services in the oil and gas sector, characterized in that, include: Obtain a domain data exchange model; Based on the domain data knowledge graph, the domain data exchange model is checked. The domain data knowledge graph includes a domain graph and multiple cross-domain data graphs. The domain graph is used to describe the relationship between domain data. Each domain data corresponds to a cross-domain data graph. The cross-domain data graph is used to describe the relationship between domain data and cross-domain data. The domain graph stores the design constraints of each domain data. After the inspection is passed, the interfaces, dependencies and performance metrics of the domain data services to be generated are determined according to the domain data exchange model, and the domain data services are generated. After registering the generated domain data service to the oil and gas domain cloud platform, it undergoes collaborative verification. Once the collaborative verification is successful, the domain data service is published to the oil and gas domain cloud platform. The cross-domain data graph consists of a first-level cross-domain data graph and a second-level cross-domain data graph. Each domain data in the domain graph corresponds to one first-level cross-domain data graph and one second-level cross-domain data graph. The first-level cross-domain data graph describes the relationship between the domain data and cross-domain data with first-level relevance, while the second-level cross-domain data graph describes the relationship between the domain data and cross-domain data with second-level relevance. The first-level cross-domain data graph stores the design constraints of each cross-domain data on the domain data; the second-level cross-domain data graph stores the optimization strategies of each cross-domain data on the domain data. Based on the domain data knowledge graph, the domain data exchange model is checked, including: querying the domain data knowledge graph to obtain the domain graph corresponding to the domain of the domain data exchange model; when the metadata of the domain data exchange model covers the domain data in the domain graph, determining whether each metadata item meets the design constraints of the corresponding domain data in the domain graph; if so, querying the first-level cross-domain data graph corresponding to the corresponding domain data in the domain graph for each metadata item to obtain the design constraints of each cross-domain data item on each metadata item; when the design constraints of each cross-domain data item on each metadata item are met, querying the second-level cross-domain data graph corresponding to the corresponding domain data in the domain graph for each metadata item to obtain the optimization strategy for each metadata item; and sending the optimization strategy to domain experts to obtain the domain data exchange model fed back by the domain experts.

2. The method according to claim 1, characterized in that, Also includes: Add timestamps to each domain data, cross-domain data, and relation edge in the domain graph and cross-domain data graph; Based on business needs and actual conditions, add business scenario tags to each domain data, cross-domain data, and relationship edge in the domain graph and cross-domain data graph; Determining whether the metadata meets the design constraints of the corresponding domain data in the domain graph includes: in the domain graph, the design constraints for filtering domain data according to timestamps and business scenario tags, and determining whether the metadata meets the selected design constraints; Query the first-level cross-domain data graph corresponding to the domain data of each metadata in the domain graph, and obtain the design constraints of each cross-domain data on each metadata. This includes: querying the first-level cross-domain data graph corresponding to the domain data of each metadata in the domain graph, and filtering the design constraints of each cross-domain data on each metadata according to timestamp and business scenario tags.

3. The method according to claim 1, characterized in that, Also includes: Confidence labels are applied to the relationship edges between domain data and cross-domain data in a cross-domain data graph. When the confidence level of a relation edge falls below the confidence threshold, an additional verification process is triggered.

4. The method according to claim 1, characterized in that, Based on the domain data exchange model, determine the interfaces, dependencies, and performance metrics of the domain data services to be generated, and generate the domain data services, including: Obtain all domain data and the relationships between domain data in the domain graph corresponding to the domain of the domain data exchange model, and determine the structure and flow direction of the domain data. Based on the business, functional, and performance requirements of the domain data exchange model, determine at least one domain data service to be generated, as well as corresponding functional and performance indicators. The performance indicators include at least one of response time, throughput, availability, and resource utilization. Determine the interface parameters for data services in each domain; Analyze the dependencies of domain data services, including internal dependencies and external dependencies; Implement and test the domain data service based on the structure and flow direction of the domain data, performance indicators, functional indicators, interface parameters and dependencies generated according to the requirements; After the domain data service passes the test, it will be deployed on the oil and gas domain cloud platform.

5. The method according to claim 1, characterized in that, After registering the generated domain data services to the oil and gas domain cloud platform, collaborative verification will be performed, including: After registering the generated domain data services to the oil and gas cloud platform, extract the domain type, business process, and compliance requirements of the domain data services. The domain type, business process, and compliance requirements are input into the lightweight decision model to obtain the optimal verification combination. The optimal verification combination includes the actual verification indicators, actual fault injection scenarios, actual fault injection strategies, and actual chaos parameters in the domain data service verification indicator system. The lightweight decision model is trained based on the historical domain data service verification indicator data, fault input strategies, chaos parameters, and verification results within the domain of the domain data service. Based on the actual verification metrics, perform rule checks on the domain data service to obtain the rule check results; If the rule check results include abnormal rule check data, the abnormal rule check data is marked as a trigger fault injection signal. In the actual fault injection scenario, fault injection is performed on the domain data service according to the actual fault injection strategy. When the fault is input, the actual chaotic parameters are integrated into the actual fault injection scenario. The running status of the domain data service is monitored in real time to obtain fault recovery data and determine whether the fault recovery data meets the fault recovery requirements. At the same time as fault injection begins, chaos verification is started, and the actual chaos parameters are applied to the domain data service to obtain the chaos verification results.

6. The method according to claim 5, characterized in that, The domain data service verification indicator system includes trigger rules between different verification indicators. The method further includes: When performing rule checks on domain data services based on the actual verification metrics, if a verification metric associated with the actual verification metric is triggered based on a triggering rule, then the rule checks on domain data services are performed based on the associated verification metric.

7. The method according to claim 1, characterized in that, After successful collaborative verification, the domain data service will be published to the oil and gas cloud platform, including: Collaborative verification is performed on domain data services registered on the oil and gas cloud platform. The collaborative verification includes collaborative compliance verification, fault injection verification, and chaos verification. If the rule check result is passed, or the fault recovery data meets the fault recovery requirements, or the chaos verification result is passed, the domain data service will be published to the oil and gas domain cloud platform.

8. The method according to claim 7, characterized in that, Before publishing the domain data service to the oil and gas cloud platform, the method further includes: The domain data service is sent to domain experts so that they can use artificial intelligence models to analyze the business rationality and interface design rationality of the domain data service and then give the review result of the domain data service. After receiving feedback and review results from domain experts, the domain data service will be published to the oil and gas cloud platform.

9. The method according to claim 7, characterized in that, After publishing domain data services to the oil and gas cloud platform, the following is also included: Collect request data, service instance runtime data, historical traffic data, and security-related data from existing domain data services; Based on the collected request data, service instance runtime data, historical traffic data, and security-related data, time series prediction algorithms are used to predict the load and traffic trends of the domain data service. Determine the request corresponding to the domain data service; Based on the predicted load and traffic, determine the load balancing strategy for each request for the domain data service; Based on the predicted load and traffic, determine the priority execution strategy for high-priority requests in the domain data service.

10. A service management and control device for the oil and gas sector, characterized in that, include: Domain data exchange model acquisition module, used to acquire domain data exchange model; The domain data exchange model checking module is used to check the domain data exchange model based on the domain data knowledge graph. The domain data knowledge graph includes a domain graph and multiple cross-domain data graphs. The domain graph is used to describe the relationship between domain data. Each domain data corresponds to a cross-domain data graph. The cross-domain data graph is used to describe the relationship between domain data and cross-domain data. The domain graph stores the design constraints of each domain data. The domain data service generation module is used to determine the interface, dependencies, and performance indicators of the domain data service to be generated based on the domain data exchange model after the check is passed, and then generate the domain data service. The domain data service registration and publishing module is used to register the generated domain data services to the oil and gas domain cloud platform for collaborative verification, and to publish the domain data services to the oil and gas domain cloud platform after the collaborative verification is passed. The cross-domain data graph consists of a first-level cross-domain data graph and a second-level cross-domain data graph. Each domain data in the domain graph corresponds to one first-level cross-domain data graph and one second-level cross-domain data graph. The first-level cross-domain data graph describes the relationship between the domain data and cross-domain data with first-level relevance, while the second-level cross-domain data graph describes the relationship between the domain data and cross-domain data with second-level relevance. The first-level cross-domain data graph stores the design constraints of each cross-domain data on the domain data; the second-level cross-domain data graph stores the optimization strategies of each cross-domain data on the domain data. Based on the domain data knowledge graph, the domain data exchange model is checked, including: querying the domain data knowledge graph to obtain the domain graph corresponding to the domain of the domain data exchange model; when the metadata of the domain data exchange model covers the domain data in the domain graph, determining whether each metadata item meets the design constraints of the corresponding domain data in the domain graph; if so, querying the first-level cross-domain data graph corresponding to the corresponding domain data in the domain graph for each metadata item to obtain the design constraints of each cross-domain data item on each metadata item; when the design constraints of each cross-domain data item on each metadata item are met, querying the second-level cross-domain data graph corresponding to the corresponding domain data in the domain graph for each metadata item to obtain the optimization strategy for each metadata item; and sending the optimization strategy to domain experts to obtain the domain data exchange model fed back by the domain experts.

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