Method and system for processing analytical tasks related to the computational analysis of industrial system data

Abstract

In order to evaluate the industrial system (10, 20, 30), data from the industrial system (10, 20, 30) is pre-stored in a data database (110), and the execution engine (301, 302, 303) a) collects execution parameters from a computational analysis computer program (311, 312, 313) corresponding to the analysis, b) extracts data from the industrial system to be processed by the computational analysis computer program from the data database (110) based on the collected execution parameters, c) creates an execution environment including the extracted data, and d) executes the computational analysis computer program using the created execution environment.

Description

Technical Field

[0004] , , , , ,

[0003]

[0001] The subject matter disclosed herein relates to methods and systems for performing evaluations on multiple industrial systems, and more particularly, to the execution of analysis tasks.

Background Art

[0002] It is common to perform evaluations on industrial systems (i.e., the entire system or its subsystems or its components) that are installed and operating. The "item" to be specifically evaluated may be, for example, an oil & gas plant or plant machinery, particularly turbomachinery, or a machine part. The evaluation may be a determination of some form of the state of the "item" (e.g., the efficiency of the machine considering its operation in the immediately preceding 1 hour or 1 day or 1 week), or some form of prediction regarding the item (e.g., how many hours the machine can operate before the next failure or abnormal state).

[0003] It is also common for the same evaluation to be repeated, for example, periodically (e.g., once a day or once a week or once a month).

[0004] A solution for evaluating an "installed product" is described in U.S. Patent No. 10,628,145. This document uses the expression "execute analytic model." This document generally refers to the possibility of evaluating multiple industrial systems, but focuses in the first aspect on the structure of the "execution platform" (see Figures 2 and 3), and in the second aspect on the analytic model and how to make it flexible (see Figures 5 to 9). As is clear from the above description, according to the invention, two or more "models" (which correspond roughly to "computational analysis" in the terminology used herein) are applicable to a single "installed product" (which corresponds roughly to an "industrial system" in the terminology used herein), and a single "model" can be divided into multiple "tasks" (which do not have a corresponding terminology in this specification and do not correspond to the "task" as used herein). Only one paragraph in this document states that the system can receive "data from at least one of the installed product." In light of the background information section, this document does not provide details on how to process multiple models simultaneously or how to process multiple installed products simultaneously.

[0005] Since all independent claims in this patent document are expressed as features necessary for the solution, the system and method require an "API wrapper" (which should not be confused with a simple API) associated with the analysis model and execution platform, the API wrapper including an interface to input information, an interface to output information, and an "art" (an interface to) as a package of the API, according to this document, the art may be a solution methodology, a method for generating specific values ​​of coefficients in a kernel, and a relationship between input and output.

[0006] More specifically, the solution in this patent document provides a storage device that stores program instructions for executing a function to communicate with an analysis model and an execution platform, and to transmit information between an analysis API wrapper and an execution platform API wrapper, and to deploy the analysis model to the execution platform based on the transmitted information.

[0007] Furthermore, the solution in this patent document provides that each analysis model can be wrapped in a "complete filesystem" in which a "container module" may contain everything necessary to run the model (e.g., code, runtime, system tools, system libraries, and anything that may be installed on the server). In practice, a model can be built on a local computer and then sent to another computer for execution. However, running a model on a computer different from where it was built may involve rewriting and debugging the model program, which can be very time-consuming and error-prone. This rewriting / debugging process may be repeated each time the model is run on a different system. Therefore, it is desirable to provide a system and method that facilitates the construction of models of physical systems in a more efficient and accurate manner. The "complete filesystem" described above contributes significantly to fulfilling the requirements described in U.S. Patent No. 10,628,145.

[0008] As far as can be understood from this patent document, there exists one execution platform with one execution module, and various analysis models are configured to directly act on input data via the input information of an API wrapper and directly act on output data via the output information of an API wrapper. The "API wrapper" of the analysis model and execution platform is essential to satisfy the requirements described in U.S. Patent No. 10,628,145. Furthermore, each analysis model is provided to be adapted to operate differently, depending on the technology of the API wrapper, possibly according to the specific requirements of one or more users. In this way, the analysis model can be customized in flight.

[0009] Companies may be interested in conducting several evaluations simultaneously across multiple industrial systems. In this specification, “at the same time” means during the same period and within the same timeframe, and not necessarily at the same time (even if simultaneity is not excluded). In fact, as disclosed herein, the level of simultaneity depends on when the analysis tasks are prepared and how they are performed.

[0010] Therefore, it is desirable to have methods and systems for conducting such evaluations. In particular, it is desirable that they be flexible and / or efficient and / or effective. [Overview of the project]

[0011] According to a first aspect, the subject matter disclosed herein relates to an evaluation method. Data from an industrial system is stored in a data database in advance, and the industrial system is evaluated. The execution engine a) collects execution parameters from a computational analysis computer program corresponding to the analysis, b) extracts data from the industrial system to be processed by the computational analysis computer program from the data database based on the collected execution parameters, c) creates an execution environment containing the extracted data, and d) executes the computational analysis computer program using the created execution environment.

[0012] According to a second aspect, the subject matter disclosed herein relates to an evaluation system. The system comprises an execution engine having access to at least one computational analysis computer program, and a data database storing data collected from an industrial system. To process an analysis task, the execution engine is configured to create an execution environment containing appropriate data extracted from the data database, and to execute a computational analysis computer program using the created execution environment. Preferably, the execution engine is configured to identify analysis tasks in an execution queue. Preferably, the execution engine is also configured to store the results of the execution in a results database.

[0013] According to such a system and method, the “execution environment” primarily includes data extracted from a data database (i.e., all data to be processed that has already been suitably selected and arranged) and, optionally, execution parameters. References to the computational analysis computer program to be executed (e.g., its name and / or a link to its code) or parts or all of the program may also be included in the “execution environment.” Thus, they follow an approach entirely different from the approach of U.S. Patent No. 10,628,145. [Brief explanation of the drawing]

[0014] Many of the disclosed embodiments of the present invention and their associated advantages will be better understood by referring to the following embodiments for carrying out the invention, and a more complete understanding will be easily obtained, as they will be better understood when considered in relation to the accompanying drawings. [Figure 1] Figure 1 shows a general schematic diagram of a system embodiment for performing evaluations on multiple industrial systems that provide both the preparation of analysis tasks and the execution of prepared analysis tasks. [Figure 2]Figure 2 shows a flowchart of one embodiment of a method for performing evaluations on multiple industrial systems, including the preparation of analysis tasks. [Figure 3] Figure 3 shows a flowchart of one embodiment of a method for performing evaluations on multiple industrial systems, including the execution of an analysis task. [Modes for carrying out the invention]

[0015] According to the subject matter disclosed herein, multiple industrial systems, for example, multiple machines in an oil and gas plant located in different locations, are accessed simultaneously. Data from the industrial systems is collected from the industrial systems and stored in a data database. Information about the industrial systems is stored in a system database. Using these two databases, an orchestrator, for example, an application running on a server, prepares the analysis tasks required for the evaluation of the industrial systems in a flexible manner and stores them in one or more execution queues. The preparation of the analysis tasks is continuous and repeated by scanning the system database, and is independent of the collection of data from the industrial systems. Furthermore, independent of data collection and the preparation of analysis tasks, one or more execution engines execute the analysis tasks sequentially. Each analysis task is executed with a corresponding execution environment pre-created so that the execution is effective and efficient. Typically, analysis tasks are identified in one or more execution queues so that the execution is even more effective and efficient. As already made clear herein, “simultaneously” means during the same period and within the same period, and does not necessarily mean at the same time (even if simultaneity is not excluded). In fact, as disclosed herein, the level of simultaneity depends on when the analysis task is prepared and how the analysis task is processed. Note that different assessments are designed to operate on different data. Furthermore, note that the same assessment (e.g., from different items) may be applied to different data, but this will result in separate analysis tasks.

[0016] Figure 1 shows one embodiment of system 1000, which is used to perform evaluations on multiple industrial systems and is hereafter referred to as the "innovative assessment system" or simply the "assessment system."

[0017] Figure 1 also shows several industrial systems outside of the evaluation system 1000. In particular, this figure shows four industrial systems 10, 20, 30, and 40, but any number of industrial systems may be considered, starting with a minimum of one.

[0018] Data from the industrial systems 10, 20, 30, and 40 being evaluated are repeatedly, for example, collected periodically and stored in a data database 110. The data is stored in the data database 110 in an orderly manner so that it can be selectively retrieved later. The data from the systems may be of the same type (e.g., temperature data at a specific location on the machine or pressure data at a specific location on the machine), or more typically, of different types (e.g., temperature data at several locations on the machine, or temperature and pressure data at specific locations on the machine, or temperature and pressure data at several locations on the machine, or data from several components of the machine and / or several machines). The data for evaluation may be measured data and / or calculated data, measured data derived from sensors in the industrial system being evaluated, and calculated data derived from processing circuits in the industrial system being evaluated, and processing may be performed on locally measured data by analog and / or digital circuits, including a computer.

[0019] Data from industrial systems 10, 20, 30, and 40 may be received by a data entry application 100, typically a software application running on hardware. This hardware portion may be dedicated to data reception and, optionally, data transmission (e.g., for querying purposes). Application 100 may be configured not only to receive data but also to repeatedly query industrial systems 10, 20, 30, and 40 (particularly the systems' communication devices) repeatedly, for example, periodically, and / or to repeatedly receive data when the industrial systems transmit data to the evaluation system 1000. The industrial systems may collect (similar or different) measured and / or calculated data over a period of time. Such collected data may be transmitted to the evaluation system 1000 as a data package when the evaluation system queries the industrial systems and / or when the industrial systems decide to do so.

[0020] Application 100 may also be configured to store the received data (in order) in the data database 110. The received data may also be processed by Application 100 before being stored. Generally, given that the data is received from several different (very different) industrial systems, an effective form of processing may be, for example, labeling the data in a uniform manner before storage. Temperature data at the air inlet of a gas turbine may be labeled, for example, "TAI-GT" regardless of the type and size of the gas turbine.

[0021] Information regarding the industrial systems being evaluated is stored in the system database 210. Such information particularly relates to the applicability of computational analysis computer programs to data from the industrial systems. In the embodiment of Figure 1, three analysis computer programs 311, 312, and 313 are provided as examples, and four industrial systems 10, 20, 30, and 40 are provided. For example, program 311 may be applicable to data from systems 10 and 20, program 312 may be applicable to data from systems 30 and 40, and program 313 may be applicable to only one system (e.g., system 10) or to all systems.

[0022] It should be noted that, according to some embodiments, some data in the data database 110 may be derived indirectly from industrial systems 10, 20, 30, and 40. Such data may be derived, for example, from processing performed by system 1000, or under the control of system 1000 from data received from industrial systems. For example, such data may correspond to "measurements" of "virtual sensors" calculated, for example, by the execution engine of system 1000. As will become clearer below, such data may be transferred from database 410 to database 110 under the control of application 100 and / or application 400.

[0023] A computational analysis computer program is a computer program, i.e., software, configured to be executed by a computer, i.e., hardware, and is designed to perform computational analysis on specific data from one or more industrial systems to make evaluations of one or more industrial systems, i.e., to determine some form of state or some form of prediction.

[0024] The system database 210 may be embodied, for example, as a table having rows for each industrial system considered by an "assessment system" corresponding to a computational analysis computer program, and columns for each "computational analysis" (which may also be referred to as "analysis") provided in the "assessment system". In any row, the cell is marked for the "computational analysis" applicable to the industrial system corresponding to the row. For classifying industrial systems, one or more of other columns, for example, "client" (i.e., the client name of the plant including the industrial system), "site" (i.e., the plant including the industrial system), "model" (i.e., the model of the industrial system), "name" (i.e., the name identifying the industrial system), may be advantageously provided within the table. Other columns corresponding to parameters and / or constants useful when coupling an analysis program to one or more systems and / or when executing an analysis task may be advantageously provided within the table. One or more additional component columns, for example, named "component-name" and / or "component-model", corresponding to one or more components that provide data and may be the subject of an assessment may be advantageously provided. Finally, one or more other time series, for example, named "installation date" and / or "maintenance date", may be advantageously provided so that an assessment can also take into account such information.

[0025] It should be noted that such a system database gives a great deal of flexibility to the "innovative evaluation system". At a certain point, when a further industrial system is considered by the "evaluation system", it is sufficient to simply add a row to the table and introduce the appropriate data / information. At a certain point, when further "computational analysis" is performed, it is sufficient to simply add a column to the table and introduce the appropriate data / information. At a certain point, when a new "computational analysis" is applied to data from the industrial system, it is sufficient to simply introduce the appropriate data / information into the cells of the table. If a particular "computational analysis" should be applied to data from a set of "items", the category column may be useful when selecting the "items".

[0026] Using the system database 210 and the database 110 of data, an orchestrator 200, for example, an application running on a server, prepares the analysis tasks necessary for the evaluation of industrial systems 10, 20, 30, and 40. In this description, note that the reference numeral 200 is used to identify both the application and the server on which this application runs. However, generally, the server running the orchestrator application may run one or more other applications. The orchestrator application 200 adjusts various databases to create the analysis tasks. The orchestrator application 200 runs independently of the data input application 100. Typically, they run on two separate servers or on two separate virtual machines within the same server. As will be described later, the orchestrator application 200 is associated with an orchestrator database 220 that stores the data and information to support the operation of the application.

[0027] Next, the "innovative evaluation method" dealing with the preparation of the analysis tasks will be described using the flowchart 2000 in FIG. 2.

[0028] In FIG. 2, there is an initial block 2100 corresponding to an ideal start of this method.

[0029] This method includes the following preliminary steps. - The process of providing multiple computational analysis computer programs (block 2210 in Figure 2), - The process of providing the system database (block 2220 in Figure 2).

[0030] Please note that additional computational and analytical computer programs may be added later, for example, if they are designed, developed, and tested.

[0031] It should be noted that any "computational analysis computer program" may be developed by the administrator of an evaluation system (e.g., system 1000) or by the administrator of an industrial system (e.g., systems 10, 20, 30, or 40).

[0032] It should also be noted that the system database may be updated later, for example, due to the addition of industrial systems being evaluated and / or the addition of "computational analyses" applied to the collected data.

[0033] As a preliminary step, a data database may be provided (block 2230 in Figure 2). Initially, the data database is usually empty because data has not yet been collected from the industrial system.

[0034] Essentially, two applications—a data entry application (labeled 100 in Figure 1) and an orchestrator application (labeled 200 in Figure 1)—are executed independently according to this method.

[0035] The data entry application repeatedly collects data from the industrial system (block 2310 in Figure 2) and then stores it in a data database (block 2320 in Figure 2).

[0036] The orchestrator application repeats the following: a) Scan the system database (block 2410 in Figure 2), b) For each industrial system in the system database, determine any computational analysis computer program to apply to the data (one or more "computational analyses" may be applied to the data collected from the industrial system, and only under exceptional circumstances will an industrial system registered in the system database not undergo any evaluation) (Block 2420 in Figure 2), c) For the determined computational analysis, the computer program checks whether there is corresponding data in the data database (depending on the "computational analysis" applied, there should be a certain quantity and / or quality of data to enable the calculation) (Block 2430 in Figure 2), d) For each computational analysis computer program that has been determined and confirmed positively, create the analysis tasks to be executed (block 2440 in Figure 2), e) The generated analysis tasks are progressively stored in at least one execution queue (block 2450 in Figure 2).

[0037] Any item in the execution queue, i.e., any analysis task, may contain at least the following information: - The name or identifier of the computational analysis computer program to be executed. - The name or identifier of one or more industrial systems to be evaluated, i.e., analyzed by the program - More generally, the identification of one or more industrial systems to be analyzed through the task, e.g., a set of one or more systems belonging to the same category - Time frame, i.e., the time range of the data of the industrial system being analyzed.

[0038] As will be explained later, each item in the execution queue is processed separately by the execution engine to perform the necessary "computational analysis".

[0039] Typically, an orchestrator application determines any computational analysis computer program to apply to the data based on information stored in the system database (see step b).

[0040] The orchestrator application may check whether corresponding data exists in the data database based on information stored in a configuration file associated with the computational analysis computer program (see step c).

[0041] For example, as shown in Figure 1, each computational analysis computer program 311, 312, and 313 is associated with a configuration file (see the smaller box after the larger box) that contains information about the program. Such information may be the type and amount of data from the industrial system for which the program is designed to process, and in some cases further, it may also be whether it is a 32-bit code program or a 64-bit code program and / or the operating system used to run it and / or whether it is a high-priority "computational analysis" or a low-priority "computational analysis" and / or whether it is a "computational analysis" under testing or has already been tested.

[0042] Typically, the orchestrator application verifies whether the corresponding data, in particular the appropriate and / or sufficient data, exists in the data database for the desired “computational analysis” (see step c). Such verification may be based on information stored in the data database; in other words, the orchestrator application may query the data database to verify the existence of the data. Preferably, such verification may also be based on information stored in the orchestrator database. For example, if the “computational analysis” is performed periodically, the orchestrator application may check the orchestrator database to see when it was last performed, thereby verifying whether the appropriate and / or sufficient data has existed in the data database since the last execution.

[0043] Note that there is a kind of dependency between "Analysis A" and "Analysis B" when the data required for the desired current "computational analysis," i.e., "Analysis A," comes from the processing of the previous "computational analysis," i.e., "Analysis B," for example, "Virtual Sensor."

[0044] Advantageously, the orchestrator application can check whether a "computational analysis" is already in progress. Such a check is useful, for example, to prevent an analysis on later data from running before the same analysis on earlier data has finished for one or more identical industrial systems. This check may be performed, for example, by storing "exec-state" information indicating the "current execution state" of one / any / more / all available computational analysis computer programs and / or one / more / all execution tasks currently running, for example, in an orchestrator database.

[0045] Such “execution status” information or equivalent information may be used to the advantage of the orchestrator application to determine whether a “computational analysis” is “locked” and / or “slow.” Such “execution” information may be supplemented by “start-of-execution” information, which allows the orchestrator to know when the execution of a particular “computational analysis” began. The orchestrator may check whether the execution time of one or more or all of the running tasks exceeds a predetermined maximum time length. If “yes,” execution may be stopped as appropriate, and the “computational analysis” may be considered not to be performed. The predetermined maximum time length may differ for each computational analysis computer program.

[0046] Advantageously, the orchestrator application progressively stores the generated analysis tasks in multiple execution queues (see, for example, queues 321, 322, and 323 in Figure 1). In particular, Figure 1 shows three execution queues 321, 322, and 323. However, any number of queues may be considered, starting with at least one. Multiple execution queues are useful for distributing the computational analysis work among several execution engines. The distribution may be uniform or heterogeneous.

[0047] An execution queue may be associated with one or more specific execution engines or one or more types of execution engines. For example, there may be a queue dedicated to an execution engine capable of executing a program with a specific word length, or a queue dedicated to an execution engine capable of executing a program designed for a specific operating system, or a queue dedicated to an execution engine capable of performing computations, in particular, intensive tasks, or a queue dedicated to high-priority "computational analysis." An execution queue may also be associated with a debug execution engine, which may be useful for testing and debugging new "computational analysis." Note that in this way, debugging may be performed on "real data," data originating from one or more industrial systems, so-called "fleet-level debugging." Also note that the "computational analysis" being debugged may have been previously developed by the administrator of an evaluation system (e.g., system 1000) or by the administrator of an industrial system (e.g., systems 10, 20, 30, or 40).

[0048] The orchestrator application may select an execution queue for an execution task from among multiple execution queues based on information in a configuration file associated with the computational analysis computer program.

[0049] Advantageously, the orchestrator application stores information about computational analyses already performed, particularly the results of those analyses, in the orchestrator database (see, for example, database 220 in Figure 1). Such information can be useful for future "computational analyses."

[0050] As explained, according to this "innovative evaluation method," the data entry application (100 in Figure 1) needs to query and insert data into the data database (110 in Figure 1).

[0051] As explained, according to this "innovative evaluation method," the orchestrator application (Figure 1, 200) needs to query and extract data from the data database (Figure 1, 110) and the system database (Figure 1, 210).

[0052] Such communication with these two databases, preferably both of them, may be performed via an application programming interface associated with the data database and an application programming interface associated with the system database, respectively.

[0053] Furthermore, it may be provided that each or both of these two databases may be managed by a dedicated management application. Thus, a data database management application (190 in Figure 1) and / or a system database management application (290 in Figure 1) may exist. The data entry application, the orchestrator application, and these management applications may be configured to communicate with each other to perform the operations provided by this “innovative evaluation method”.

[0054] As will be explained more clearly later, computational analysis computer programs and / or their configuration files may also be accessed through an application programming interface and / or managed through a program management application (319 in Figure 1). Note that, according to some embodiments, the orchestrator application needs to access at least the program configuration files.

[0055] The above completes the preparation for the analysis task.

[0056] Each prepared analysis task must be performed unless there is a reason not to permit or recommend its execution. In the first embodiment, if a communication error occurs in an industrial system, the computational analysis of this industrial system may not be performed (even if prepared) or may be stopped during execution. In the second embodiment, if an error is identified before or during execution, the computational analysis being tested or debugged may not be performed or may be stopped during execution.

[0057] Execution is, in principle, unrelated to preparation.

[0058] According to the innovative subject matter disclosed herein, the processing of analytical tasks relating to computational analysis of data received from an industrial system and stored in a data database for the purpose of evaluating the industrial system is performed by an execution engine.

[0059] Figure 1 shows multiple execution engines. In particular, this figure shows three execution engines 301, 302, and 303. However, any number of engines may be considered, starting with at least one. Note that an execution engine may correspond to, for example, a separate physical machine or to a separate virtual machine implemented on the same hardware. Furthermore, as will be better explained later, one or more or all of the execution engines may be local (i.e., on the same hardware on which the orchestrator application runs) or remote (i.e., on different hardware from the hardware on which the orchestrator application runs, but far away but nearby). Any combination of these two possibilities is conceivable. Typically, the creation of one or more virtual machines for one or more execution engines is implemented first. However, it should not be ruled out that this may be implemented during the operation of the “Innovative Evaluation System”.

[0060] To process the analysis task, the execution engine (e.g., engine 301) will: a) Collect execution parameters from a computational analysis computer program corresponding to the desired analysis task (see programs 311, 312, and 313 in Figure 1), wherein the execution parameters include at least information about the industrial system data processed by the computational analysis computer program. b) From the data database (database 110 in Figure 1), data from the industrial system is extracted and processed by a computational analysis computer program based on the collected execution parameters. c) Create an execution environment that includes at least the extracted data, d) Run the computational analysis computer program using the created execution environment.

[0061] The execution environment (typically including a so-called "contest") enables execution in an effective and efficient manner, with everything necessary for execution contained within the environment, so that after the environment is created, the engine does not need to access any data or information, especially any database. Furthermore, execution can be performed "wherever," i.e., remotely. For example, if the execution of an analysis task is particularly computationally intensive, it may be executed against a remote "powerful engine," and the environment (including the "contest") may be sent to the "powerful engine."

[0062] Thanks to the creation of execution environments, several analysis tasks can be performed independently of each other.

[0063] Next, we will explain the "innovative evaluation method" for managing the execution of analysis tasks, using the flowchart 3000 in Figure 3.

[0064] Figure 3 shows an initial block 3100 that corresponds to an ideal start to this method.

[0065] As explained above, the (actual or virtual) execution engine is assumed to be part of the “innovative evaluation system.”

[0066] The following description applies to any execution engine, for example, engines 301, 302, and 303 in Figure 1, and is repeated sequentially.

[0067] Preliminarily, the execution engine identifies the analysis tasks to be executed in the execution queue (see, for example, queues 321, 322, and 323 in Figure 1) – the first actual step 3200 in the method of Figure 3. Typically, when following a FIFO (First-In-First-Out) approach to manage the analysis tasks, the identified tasks are at the head of the execution queue, but other approaches are possible. The execution engine may consider one (i.e., a given) or more execution queues. If two or more queues are considered, the execution engine may select analysis tasks sequentially from the queues, or use some selection criteria.

[0068] Next, as already explained, the execution engine does the following: a) Collect execution parameters (block 3300 in Figure 3), b) Extract data from the data database (block 3400 in Figure 3), c) Create the execution environment (block 3500 in Figure 3), d) Execute the computational analysis computer program (block 3600 in Figure 3).

[0069] As already explained, any item in the execution queue, i.e., any analysis task, may contain at least the following information: - The name or identifier of the computational analysis computer program to be executed. - The name or identifier of an industrial system to be evaluated, i.e., analyzed by a program - More generally, the identification of one or more industrial systems to be analyzed through a task, e.g., a set of one or more systems belonging to the same category - Time frame, i.e., the time range of the data of the industrial system being analyzed.

[0070] Therefore, when the engine identifies tasks in the queue, a lot of data and information is also identified and can be used by the engine to perform the tasks.

[0071] During execution, that is, following step d, the execution engine may perform the following: e) Store the execution results in the results database (see, for example, database 410 in Figure 1) (block 3700 in Figure 3).

[0072] The results of the computational analysis performed in database 410 may be read, for example, by a person and / or entity responsible for evaluating multiple industrial systems and considered later.

[0073] In the "innovative evaluation system" 1000, it may be possible to provide the following data output applications 400. f) Send the results from the results database 410 to the user application (block 3800 in Figure 3).

[0074] In this case, the transmission of data to the user application is typically repeated periodically and is usually directed to a remote application. For example, a user managing one or more plants may want another entity to be responsible for evaluating their plants and be interested in receiving the evaluation results from this entity. This entity may be specialized for such evaluation activities.

[0075] It should be noted that step f may be performed taking into account, for example, information in the system database 210. In fact, the system database 210 may store “client” information for each industrial system, so that the results of each analysis task may be directed, for example, by the data output application 400, to the corresponding entity that owns or manages the industrial system.

[0076] Alternatively, the results database 410 may be configured to be accessed locally from, for example, other applications within the "Innovative Evaluation System," or remotely from, for example, applications outside the "Innovative Evaluation System."

[0077] Advantageously, after process d, and especially after process e, the execution engine, g) Information regarding the outcome of the execution may be sent to the orchestrator application (e.g., application 200 in Figure 1) (block 3900 in Figure 3).

[0078] In this way, depending on the information received, the orchestrator application may recognize the computational analyses performed, their execution timeframes, and / or whether they were completed successfully, and / or the results of the computational analyses performed in any way. This may, ultimately, be used by the orchestrator application to prepare the following analysis tasks. Note that some computational analyses may require or utilize previous results.

[0079] The orchestrator application 200 may store the execution results received in the orchestrator database 220.

[0080] The execution environment may also include references to computational analysis computer programs specified in a queue entry or as part or as part of a program (e.g., their names or links to their code), and these computational analysis computer programs may be downloaded from a computational analysis database, for example, based on the analysis task information in the queue entry.

[0081] The execution environment may generally include parameters and / or constants (for example, referencing parameters and / or constants in the system database).

[0082] The execution environment may also include, for example, execution parameters and / or constants extracted from the analysis task information within the queueing items.

[0083] The execution parameters extracted from the analysis task information may include information about computational analyses that have already been performed, in particular the results of computational analyses that have already been performed and which may be stored in the orchestrator database.

[0084] Preferably, the execution engine places data within the execution environment according to a predetermined structure adapted for execution.

[0085] As explained, according to this "innovative evaluation method," the engine (301, 302, and 303 in Figure 1) may need to query several items and / or databases (310, 320, and 410 in Figure 1), insert data, and extract data from there.

[0086] Such communication of the engine may be performed via application programming interfaces associated with items and / or databases. APIs associated with programs or program databases, and / or APIs associated with queues or queue databases, and / or APIs associated with result databases may also exist.

[0087] Furthermore, it may be provided that these databases may be managed by dedicated management applications. Thus, there may be a program database management application (319 in Figure 1), and / or a queue database management application (329 in Figure 1), and / or a results database management application (490 in Figure 1). The engine and these management applications may be configured to communicate with each other in order to perform the operations provided by this “innovative evaluation method.”

[0088] The embodiment of the system in Figure 1 includes all components used to implement both the "innovative evaluation method" responsible for preparing the analysis task and the "innovative evaluation method" responsible for executing the analysis task. According to an alternative embodiment, the "innovative system" may also include all components used to implement only the "innovative evaluation method" responsible for preparing the analysis task, or only the "innovative evaluation method" responsible for executing the analysis task.

[0089] Figure 1 shows a system 1000 comprising the following: - Orchestrator Server 200 -Data Database110 - System Database 210 - Orchestrator Database 220 - Multiple execution engines 301, 302, and 303 - Multiple computational and analytical computer programs 311, 312, and 313 (In the diagram, there is a distinction between the computer programs themselves, i.e., the executable code, shown as larger boxes, and the corresponding configuration files, shown as smaller boxes behind the larger boxes). - Multiple execution queues 321, 322, and 323, and -Results database 410.

[0090] Furthermore, Figure 1 also shows, typically, several industrial systems 10, 20, 30, and 40 that are remotely located (accessible) from the system, rather than just the system's components.

[0091] Finally, Figure 1 also shows several applications, in particular a first set of applications corresponding to the basic application, and a second set of applications corresponding to the database management application.

[0092] The first set of applications includes a data entry application 100 and a data output application 400. One or more of these applications may run on a dedicated "real machine," i.e., hardware (sometimes called a "server"), or a "virtual machine."

[0093] The second set of applications includes a data database management application 190, a system database management application 290, a program management application 319, a queue database management application 329, and a results database management application 490. All of these applications are software applications. Therefore, for each of them there exists at least one corresponding computer program, and as is well known, a software application may correspond to a set of computer programs that are executed to perform one or more functions of the application. One or more or all of these applications may run on a dedicated “real machine,” i.e., hardware (sometimes called a “server”), or a “virtual machine.”

[0094] Therefore, depending on how system 1000 is implemented, elements 100, 190, 290, 319, 329, 490, and 400 may be hardware components of system 1000 or software components of system 1000.

[0095] An embodiment of the alternative system may include more or fewer components than system 1000.

[0096] The system 1000 may be divided into a first subsystem and a second subsystem. The first subsystem includes elements 100, 110, 190, 200, 210, 220, and 290. The second subsystem includes elements 301, 302, 303, 311, 312, 313, 319, 321, 322, 323, 329, 400, 410, and 490. The division between these two subsystems may include cases where one or more hardware and / or software components are shared by the subsystems. For example, according to some embodiments, the server 200 may run one or more of applications 100, 190, and 290 in addition to the orchestrator application. For example, according to some embodiments, the execution engine and the orchestrator application may run on the same hardware. For example, according to some embodiments, the first storage device may store programs 311, 312, and 313. The first storage device may be accessed by both the orchestrator application and one or more execution engines, in which case the first storage device (which may include the application or server 319) is shared by both subsystems. For example, according to some embodiments, the second storage device may store queues 321, 322, and 323. The second storage device may be accessed by both the orchestrator application and one or more execution engines, in which case the second storage device (which may include the application or server 329) is shared by both subsystems. For example, according to some embodiments, the first and second storage devices may be part of a single storage system shared by both subsystems.

[0097] The first subsystem for evaluating industrial systems is at least, - Access to the system database 210, that is, not necessarily the entire database, but at least the means to access the database, - Access to the data database 110, that is, not necessarily the entire database, but at least the means to access the database, - An orchestrator server 200, which is appropriately configured as described above and can incorporate or have access to the orchestrator database 220 through appropriate means.

[0098] The second subsystem for processing the analysis task includes at least, - Access to the data database 110, that is, not necessarily the entire database, but at least the means to access the database, - Access to one or (more typically) several computational analysis computer programs 311, 312, and 313, that is, not necessarily programs themselves, but at least means for accessing programs. -At least one execution engine 301, 302, and 303 appropriately configured as described above, Typically, also, -Means for accessing one or (more typically) execution queues 321, 322, and 323, i.e., not necessarily queues, but at least for accessing queues.

[0099] It should be noted that the “execution environment” (typically including a “contest”) is created during the execution of an analysis task by the execution engine. Therefore, it is not a true component of the system or subsystem. However, if it is created and / or used during the execution of a computational analysis computer program, some computer memory is required to store the “execution environment.” It should be noted that, according to some embodiments, the “execution environment” may be remotely transmitted after it has been created and before it is used during the execution of a computational analysis computer program (this typically applies to the remote execution of an analysis task).

[0100] As mentioned above, an "innovative system" may include several components. Depending on how the system is implemented, the components may be local to each other or remote to each other. In this context, "local" may mean within the same "virtual machine," or within the same "physical machine," or within the same computer or server, while "remote" may mean within separate "virtual machines," or within separate "physical machines," or within separate computers or servers. Therefore, in this context, the meaning of these terms does not necessarily relate to physical distance. For example, two components may be remote to each other even if they are on the same board or in the same cabinet, i.e., they may be 1 to 100 cm apart. Naturally, the term "remote" is generally applied when the physical distance is long.

[0101] In the previous paragraphs, when describing databases, computer programs, and execution queues—that is, the accessed "entities"—we have often referred to "access means." Such "access means" may be implemented in different ways. Conveniently, their implementations imply an application programming interface (including one or more access primitives). Thus, "access" does not need to have detailed information about the accessed entity, in particular how the entity is implemented internally and / or where the entity is located (e.g., remote or local; in the case of a remote entity, access to it may require communication, for example, over the internet and / or one or more hardware systems). The accessed entity, for example, a database, may be managed by a management device associated with the entity. In this case, access to the entity implies communication with its management device. The application programming interface may implement communication with the management device if necessary.

[0102] Considering computer programs 311, 312, and 313, they may be stored somewhere and may be managed by a management application 319 associated with a program database. Their configuration files may be included in the database. Application 200 typically needs to access the information in the configuration files. Execution engines 301, 302, and 303 typically need to access the information in the configuration files and download them.

[0103] As already mentioned, Figure 1 shows three execution engines 301, 302, and 303 as an example, all of which are entirely within system 1000. As explained, the minimum number of execution engines is one.

[0104] In the simplest implementation of System 1000, each execution engine performs calculations locally, i.e., within System 1000.

[0105] However, according to alternative embodiments, one or more execution engines may perform the computation remotely, in which case, for example, the execution engine prepares all the necessary things for the computation (including, for example, creating the execution environment and downloading the computational analysis computer program) based on the data and information in the execution queue, then requests the remote “computer system” or “computer application” to perform the computation (typically sending both the created execution environment and the execution program), and waits for the results to be later stored in the results database 410. In this case, the execution engine may “branch out” from the system. Note that according to some embodiments, part of the computation may be performed locally and part of the computation may be performed remotely.

[0106] From the above description, it is clear that the systems described herein, for example, system 1000 in Figure 1000, enable the implementation of the "As A Service" model in the field of industrial systems at different levels: IAAS (Infrastructure As A Service), which is of particular interest to network designers and IT administrators; PAAS (Platform As A Service), which is of particular interest to software developers; and SAAS (Software As A Service), which is of particular interest to end users.

Claims

1. A method for processing an analysis task relating to computational analysis of data received from an industrial system (10, 20, 30) and stored in a data database (110) for the purpose of evaluating the industrial system (10, 20, 30), wherein the execution engines (301, 302, 303) a) Collect execution parameters from computational analysis computer programs (311, 312, 313) corresponding to the analysis task, wherein the execution parameters include information about industrial system data processed by the computational analysis computer programs. b) Extract data from the data database (110) from the industrial system, which is processed by the computational analysis computer program based on the collected execution parameters. c) Create an execution environment containing the extracted data, d) Using the execution environment created above, execute the computational analysis computer program: A method in which the execution queues for execution tasks in a plurality of execution queues to be executed by the execution engines (301, 302, 303) are selected based on information in a configuration file associated with the computational analysis computer program (311, 312, 313).

2. The method according to claim 1, wherein the execution engine (301, 302, 303) identifies the analysis task in a predetermined execution queue (321, 322, 323), and the identified task is at the head of the execution queue.

3. The method according to claim 1, wherein the execution engines (301, 302, 303) identify the analysis task in a plurality of execution queues (321, 322, 323), and the identified task is at the head of any execution queue.

4. The method according to claim 2 or 3, wherein the execution engine (301, 302, 303) identifies the analysis task via an application programming interface associated with one or more queues.

5. The method according to claim 1, wherein in step a), the execution engine (301, 302, 303) collects execution parameters from the computational analysis computer program via an application programming interface associated with the computational analysis computer program.

6. The method according to claim 1, wherein in step b), the execution engines (301, 302, 303) extract data from the data database (110) via an application programming interface associated with the data database.

7. The method according to claim 1, wherein in step c), the execution environment also includes references to computational analysis computer programs (311, 312, 313), or a part of a computational analysis computer program, or the entire computational analysis computer program, and the computational analysis computer program may be downloaded from a computational analysis database based on analysis task information.

8. The method according to claim 1, wherein in step c), the execution environment also includes execution parameters extracted from the analysis task information.

9. The method according to claim 8, wherein the execution parameters extracted from the analysis task information are stored in the orchestrator database (220) and include the results of a computational analysis that has already been performed.

10. The method according to claim 1, wherein in step c), the execution engine (301, 302, 303) places data in the execution environment according to a predetermined structure adapted for execution.

11. After step d), the execution engine, The method according to claim 1, wherein step e) the result of the execution is stored in a result database (410).

12. The method according to claim 11, wherein in step e), the execution engine (301, 302, 303) stores the execution result in the result database via an application programming interface associated with the result database.

13. The method according to claim 11, wherein the results database (410) is configured to be accessed locally or remotely.

14. The data output application (400) Step f) The method according to claim 11, wherein the results in the results database (410) are transmitted to a user application.

15. After step e), the execution engine (301, 302, 303) g) The method according to claim 11, wherein information relating to the outcome of the execution is transmitted to the orchestrator application (200).

16. A system (1000) for processing analysis tasks relating to computational analysis of data received from industrial systems (10, 20, 30) and stored in a data database (110) for the purpose of evaluating the industrial systems (10, 20, 30), - Access to a data database (110) that stores data collected from industrial systems, - Access to at least one computational analysis computer program (311, 312, 313), - At least one execution engine (301, 302, 303), a) Collect execution parameters from the computational analysis computer program corresponding to the analysis task, wherein the execution parameters include information about industrial system data processed by the computational analysis computer program. b) Extract data from the data database (110) from the industrial system, which is processed by the computational analysis computer program based on the collected execution parameters. c) Create an execution environment containing the extracted data, d) comprising at least one execution engine (301, 302, 303) configured to execute the computational analysis computer program using the execution environment created above, The execution queues for execution tasks in a plurality of execution queues, which are executed by the execution engines (301, 302, 303), are selected based on information in a configuration file associated with the computational analysis computer programs (311, 312, 313), in the system (1000).

17. The system (1000) according to claim 16, further comprising a data database (110), wherein the data database is local or remote.

18. The system (1000) according to claim 16, further comprising one or more computational analysis computer programs (311, 312, 313) and / or a computational analysis database, wherein the computational analysis database is local or remote.

19. The system (1000) according to claim 16, further comprising one or more queues (321, 322, 323) configured to store analysis tasks and / or queue databases, wherein the queue databases are local or remote.

20. The system (1000) according to claim 16, further comprising a results database (410), wherein the results database is local or remote.

Images