Method and system for processing analytical tasks relating to computational analysis of industrial system data - Patents.com

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]

[0001] The subject matter disclosed herein relates to methods and systems for performing assessments on multiple industrial systems, and in particular, performing analytical tasks. [Background technology]

[0002] It is common to carry out an evaluation of an industrial system (installed and operating), i.e. the entire system or its subsystems or its components. The "item" specifically evaluated may be, for example, an oil & gas plant or a plant machine, in particular a turbomachinery, or a machine part. The evaluation may be a determination of some form of status of the "item" (e.g. the efficiency of the machine considering the last hour or day or week of operation) or some form of prediction regarding the item (e.g. how many hours the machine can operate before the next failure or abnormal condition).

[0003] It is also common that the same assessment may be repeated, for example, periodically (eg, once a day or week or month).

[0004] A solution for carrying out an assessment on an "installed product" is described in US Pat. No. 10,628,145. In this document, the expression "execute analytic model" is used. This document generally refers to the possibility of assessing several industrial systems, but focuses in a first aspect on the structure of the "execution platform" (see figures 2 and 3) and in a second aspect on the analytical model and how to make it flexible (see figures 5 to 9). As is clear from the above, according to the invention, more than one "model" (which according to the terminology of this specification corresponds roughly to "computational analysis") can be applied to a single "installed product" (which according to the terminology of this specification corresponds roughly to "industrial system") and a single "model" can be divided into several "tasks" (which have no corresponding terminology in this specification and do not correspond to "tasks" in this specification). Only one paragraph in this document states that the system may receive "data from at least one of the installed products." In light of the background section, this document does not provide any details on how to process multiple models simultaneously and how to process multiple installed products simultaneously.

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

[0006] More specifically, the solution of this patent document provides a storage device that stores program instructions for communicating with the analytical model and the execution platform, transmitting information between the analysis API wrapper and the execution platform API wrapper, and deploying the analytical model to the execution platform based on the transmitted information.

[0007] Furthermore, the solution of this patent document provides that a "container module" may wrap each analytical model in a "complete file system" that may contain everything necessary to run the model (e.g., code, runtime, system tools, system libraries, and anything that may be located on a server). In practice, a model may be built on a local computer and then sent to another computer for execution. However, running a model on a computer different from where the model was built may involve rewriting the model program and debugging the program, which may be very time-consuming and error-prone. This rewriting / debug process may be repeated each time the model is run on another system. It is therefore desirable to provide a system and method that facilitates model building of a physical system in a more efficient and accurate manner. The above-mentioned "complete file system" contributes greatly to meeting the needs described in U.S. Pat. No. 10,628,145.

[0008] As far as can be understood from this patent document, there is one execution platform with one execution module, and the various analytical models are configured to operate directly on input data via input information of the API wrapper and directly on output data via output information of the API wrapper. The "API wrapper" of the analytical models and the execution platform is essential to meet the needs described in US Pat. No. 10,628,145. It is further provided that each of the analytical models can 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, analytical models can be customized in flight.

[0009] An enterprise may be interested in performing several assessments simultaneously on multiple industrial systems. It should be understood that, as used herein, "at the same time" means during and within the same time period, and not necessarily contemporaneously (even if simultaneity is not excluded). Indeed, as disclosed herein, the level of simultaneity depends on when the analysis task is prepared and how the analysis task is processed.

[0010] It would therefore be desirable to have methods and systems for performing such evaluations, particularly ones that are flexible and / or efficient and / or effective. Summary of the Invention

[0011] According to a first aspect, the subject matter disclosed herein relates to an evaluation method, comprising: storing data from an industrial system in a data database in advance, and evaluating the industrial system, wherein an 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 including 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 database of data storing data collected from an industrial system. To process the analysis tasks, the execution engine is configured to create an execution environment including appropriate data extracted from the database of data, and to execute the computational analysis computer program using the created execution environment. Preferably, the execution engine is configured to identify the analysis tasks in an execution queue. Preferably, the execution engine is also configured to store results of the execution in a results database.

[0013] According to such systems and methods, the "execution environment" mainly includes the data extracted from the database of data (i.e., all the data to be processed already suitably selected and arranged) and, optionally, the execution parameters. A reference to the computational analysis computer program to be executed (e.g., its name and / or a link to its code) or a part of the program or the whole program may also be included in the "execution environment". They therefore follow a completely different approach than that of US Pat. No. 10,628,145. [Brief description of the drawings]

[0014] A more complete understanding of the disclosed embodiments of the present invention, along with many of the attendant advantages thereof, will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which: [Figure 1] FIG. 1 shows a general schematic diagram of an embodiment of a system for performing an assessment on multiple industrial systems that provides both the preparation of analytical tasks and the execution of the prepared analytical tasks. [Diagram 2]FIG. 2 illustrates a flow chart of one embodiment of a method for performing an assessment on multiple industrial systems that includes preparation of an analysis task. [Diagram 3] FIG. 3 illustrates a flow chart of one embodiment of a method for performing an assessment on a plurality of industrial systems that includes performing an analysis task. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] According to the subject matter disclosed herein, multiple industrial systems, e.g., multiple machines of an oil & gas plant at different locations, are accessed simultaneously. Data from the industrial systems are collected from the industrial systems and stored in a database of data. Information about the industrial systems is stored in a system database. Using these two databases, an orchestrator, e.g., 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 the collection of data and the preparation of the analysis tasks, one or more execution engines execute the analysis tasks continuously. Each analysis task is executed by pre-creating a corresponding execution environment so that the execution is effective and efficient. Typically, the analysis tasks are identified in one or more execution queues so that the execution is more effective and efficient. As already clarified, in this specification, "concurrently" means during and within the same period of time, and not necessarily at the same time (even if simultaneity is not excluded). Indeed, as disclosed herein, the level of concurrency depends on when the analysis tasks are prepared and how they are 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 leads to separate analysis tasks.

[0016] FIG. 1 illustrates one embodiment of a system 1000 for performing an assessment on multiple industrial systems, hereinafter referred to as an "innovative assessment system" or simply as an "assessment system."

[0017] 1 also illustrates a number of industrial systems external to the evaluation system 1000. In particular, the figure illustrates four industrial systems 10, 20, 30, and 40, although any number of industrial systems may be considered, starting from as little as one.

[0018] Data from the industrial systems 10, 20, 30, and 40 to be evaluated is repeatedly, e.g., periodically, collected and stored in the 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 particular location of the machine or pressure data at a particular location of the machine) or, more typically, of different types (e.g., temperature data at several locations of the machine, or temperature and pressure data at several locations of the machine, or temperature and pressure data at several locations of 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, where measured data is derived from sensors in the industrial system to be evaluated and calculated data is derived from processing circuitry in the industrial system to be evaluated, and processing may be performed on locally measured data by analog and / or digital circuitry, including a computer.

[0019] Data from the industrial systems 10, 20, 30, and 40 may be received by a data entry application 100, typically a software application running on hardware. Parts of this hardware may be dedicated to data reception and possibly data transmission (e.g., for interrogation purposes). The application 100 may be configured not only to receive data, but also to repeatedly, e.g., periodically interrogate the industrial systems 10, 20, 30, and 40 (especially the communication devices of the systems) and / or to repeatedly, e.g., periodically 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 time. Such collected data sets may be transmitted to the evaluation system 1000 as data packages when the evaluation system interrogates and / or decides to use the industrial systems.

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

[0021] Information about the industrial systems being evaluated is stored in the system database 210. Such information relates, inter alia, to applicability relationships of computational analytical computer programs to data from the industrial systems. In the embodiment of Fig. 1, by way of example, three analytical computer programs 311, 312, and 313 are provided, 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 database of data 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 on data received from the industrial systems. For example, such data may correspond to "measurements" of "virtual sensors" calculated, for example, by an execution engine of system 1000. As will become more apparent 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, that is configured to be executed by a computer, i.e., hardware, and is designed to perform computational analysis on particular data from one or more industrial systems to make an assessment, i.e., determine some form of state or some form of prediction, for the one or more industrial systems.

[0024] The system database 210 may be embodied, for example, as a table having a row for each industrial system considered by an "assessment system" corresponding to a computational analysis computer program, and a column for each "computational analysis" (sometimes also referred to as "analytic") provided in the "assessment system." In any row, a cell is marked for the "computational analysis" applicable to the industrial system corresponding to the row. Other columns may be advantageously provided in the table to categorize the industrial systems, for example, one or more of the following categorical columns: "client" (i.e., the client name of the plant containing the industrial system), "site" (i.e., the plant containing the industrial system), "model" (i.e., the model of the industrial system), "name" (i.e., the name identifying the industrial system). Other columns may be advantageously provided in the table corresponding to parameters and / or constants useful in coupling the analysis program to one or more systems and / or in performing the analysis task. One or more further component columns may advantageously be provided that provide data and correspond to one or more components that may be subject to evaluation, e.g., named "component-name" and / or "component-model." Finally, one or more other time columns may advantageously be provided, e.g., named "installation date" and / or "maintenance date," so that the evaluation can also take such information into account.

[0025] It should be noted that such a systems database gives the "innovative evaluation system" a lot of flexibility. If at some point further industrial systems are to be considered by the "evaluation system", it is sufficient to add rows to the table and introduce the appropriate data / information. If at some point further "computational analysis" is to be performed, it is sufficient to add columns to the table and introduce the appropriate data / information. If at some point a new "computational analysis" is to be applied to data from an industrial system, it is sufficient to introduce the appropriate data / information into the table cells. If a particular "computational analysis" is to be applied to data from a set of "items", the category column may help in selecting the "items".

[0026] Using the system database 210 and the data database 110, the orchestrator 200, e.g. an application running on a server, prepares the analysis tasks required for the evaluation of the industrial systems 10, 20, 30, and 40. It should be noted that in this description, the reference number 200 is used to identify both the application and the server running this application. In general, however, the server running the orchestrator application may also run one or more other applications. The orchestrator application 200 coordinates various databases to create the analysis tasks. The orchestrator application 200 runs independently of the data entry application 100. Typically, they run on two separate servers or two separate virtual machines within the same server. As will be explained later, the orchestrator application 200 is associated with an orchestrator database 220 that stores data and information to support the operation of the application.

[0027] Next, an "innovative evaluation method" dealing with the preparation of the analysis task will be described with the aid of a flow chart 2000 in FIG.

[0028] In FIG. 2, there is an initial block 2100 which corresponds to an ideal start to the method.

[0029] The method comprises the following preliminary steps. - providing a plurality of computational analysis computer programs (block 2210 of FIG. 2); - Providing a system database (block 2220 of FIG. 2).

[0030] It should be noted that additional computational analysis computer programs may be added at a later time, for example, as they are designed, developed and tested.

[0031] It should be noted that any "computational analysis computer program" may be developed by an administrator of an evaluation system (e.g., system 1000) or by an 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 over time, for example, due to the addition of additional industrial systems to be evaluated and / or the addition of "computational analysis" applied to the collected data.

[0033] As a preliminary step, a database of data may be provided (block 2230 of FIG. 2). Initially, the database of data is typically empty since no data has yet been collected from the industrial system.

[0034] Essentially, two applications run independently according to this method: a data entry application (labeled 100 in FIG. 1) and an orchestrator application (labeled 200 in FIG. 1).

[0035] The data entry application repeatedly collects data from an industrial system (block 2310 of FIG. 2) and then stores them in a database of data (block 2320 of FIG. 2).

[0036] The orchestrator application iterates: a) scanning the system database (block 2410 of FIG. 2); b) for each industrial system in the systems database, determining any computational analysis computer programs to be applied to the data (one or more “computational analyses” may be applied to the data collected from the industrial system; only under exceptional circumstances may an industrial system registered in the systems database not be subjected to any evaluation) (block 2420 of FIG. 2); c) for a determined computational analysis, the computer program checks whether there is corresponding data in the database of data (depending on the applied "computational analysis" there should be a certain amount and / or quality of data to allow the calculation) (block 2430 of FIG. 2); d) for each determined and positively identified computational analysis computer program, creating an analysis task to be executed (block 2440 of FIG. 2); e) Progressively storing the created analysis tasks in at least one execution queue (block 2450 of FIG. 2).

[0037] Any item in the execution queue, ie any analysis task, may contain at least the following information: - the name or identifier of the computational analysis computer program being executed - name or identifier of one or more industrial systems to be evaluated, i.e. analysed by the program - more generally, the identification of one or more industrial systems to be analysed 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 industrial system data to be analyzed

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

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

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

[0041] 1, each computational analysis computer program 311, 312, 313 is associated with a configuration file (see the smaller boxes after the larger boxes) that contains information about the program. Such information may be the type and amount of data from the industrial system the program is designed to process, and possibly even whether it is a 32-bit or 64-bit code program, and / or the operating system it runs on, and / or whether it is a high priority or low priority "computational analysis", and / or whether it is a "computational analysis" being tested or has already been tested.

[0042] Typically, the orchestrator application checks whether corresponding data, in particular suitable and / or sufficient data, exists in the database of data for the desired "computational analysis" (see step c). Such a check may be based on information stored in the database of data, in other words the orchestrator application may query the database of data to check the existence of data. Preferably, such a check 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 in the orchestrator database when it was last performed, thereby checking whether suitable and / or sufficient data exists in the database of data from the last execution.

[0043] It should be noted 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 a previous "computational analysis", i.e. "analysis B", e.g. a "virtual sensor".

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

[0045] Such "execution state" information or equivalent information may be advantageously used by the orchestrator application to ascertain whether a "computational analysis" is "locked" and / or "slow". Such "exec" information may be supplemented by "start-of-exec" information that allows knowing when an execution of a particular "computational analysis" started executing. The orchestrator may ascertain, for one or more or all running tasks, whether the execution time is longer than a predetermined maximum length of time. If yes, execution may be stopped as appropriate, and the "computational analysis" may be considered not to be executed. The predetermined maximum length of time may vary for each computational analysis computer program.

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

[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 execution engines that may execute programs with a particular word length, or a queue dedicated to execution engines that may execute programs designed for a particular operating system, or a queue dedicated to execution engines that may execute computation, particularly intensive tasks, or a queue dedicated to high priority "computational analysis". An execution queue may be associated with a debug execution engine. This may be useful for testing and debugging new "computational analysis". It is noted that in this way, debugging may be performed on "real data", data originating from one or more industrial systems, so-called "fleet level debug". It is also noted that the "computational analysis" to be debugged may have been previously developed by an administrator of the evaluation system (e.g., system 1000) or by an administrator of the industrial system (e.g., systems 10, 20, 30, or 40).

[0048] The orchestrator application may select an execution queue for an execution task within a plurality of 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 that have already been performed, in particular the results of computational analyses that have already been performed, in an orchestrator database (see, for example, database 220 in FIG. 1). Such information may be useful for future "computational analyses."

[0050] As described, this "innovative evaluation method" requires a data entry application (100 in FIG. 1) to query and insert data into a database of data (110 in FIG. 1).

[0051] As described, this “innovative evaluation method” requires the orchestrator application (200 in FIG. 1) to query and extract data from the data database (110 in FIG. 1) and the system database (210 in FIG. 1).

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

[0053] It may also be provided that each or both of these two databases may be managed by a dedicated management application. Thus, there may be a data database management application (190 in FIG. 1) and / or a system database management application (290 in FIG. 1). 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 better explained later, the 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 FIG. 1). Note that according to some embodiments, the orchestrator application needs to have access to at least the program configuration files.

[0055] This completes the preparation for the analysis task.

[0056] Each prepared analysis task must be executed unless there is a reason not to permit or recommend its execution. As a first example, if a communication error occurs in an industrial system, a computational analysis on this industrial system may not be executed (even if prepared) or may be stopped during execution. As a second example, a computational analysis during testing or debugging may not be executed or may be stopped during execution if an error is identified before or during execution.

[0057] Execution, in principle, is independent of preparation.

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

[0059] FIG. 1 shows multiple execution engines. In particular, the figure shows three execution engines 301, 302, and 303. However, any number of engines may be considered, starting from as low as one. It is noted that the execution engines may correspond, for example, to separate physical machines or to separate virtual machines realized by the same hardware. Furthermore, as will be better explained later, one or more or all of the execution engines may be local (i.e., in the same hardware where the orchestrator application runs) or remote (i.e., in a different hardware than the hardware where the orchestrator application runs, but in the vicinity of it, although it is far away). Any combination of these two possibilities may be considered. Typically, the creation of one or more virtual machines for one or more execution engines is realized first. However, it should not be excluded that it is realized during the operation of the "innovative evaluation system".

[0060] To process an analysis task, an execution engine (e.g., engine 301) a) collecting execution parameters from a computational analysis computer program (see programs 311, 312, and 313 in FIG. 1 ) corresponding to a desired analysis task, the execution parameters including at least information regarding the industrial system data to be processed by the computational analysis computer program; b) extracting from a database of data (database 110 of FIG. 1 ) data from the industrial system based on the collected execution parameters to be processed by a computational analysis computer program; c) creating an execution environment that contains at least the extracted data; d) Using the created execution environment, a computational analysis computer program is executed.

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

[0062] Thanks to the creation of an execution environment, the execution of several analysis tasks can be carried out independently of each other.

[0063] Next, an “innovative evaluation method” for managing the execution of analysis tasks will be described with reference to a flow chart 3000 in FIG.

[0064] In FIG. 3, there is an initial block 3100 which corresponds to an ideal start to the method.

[0065] As explained above, the execution engine (real or virtual) is assumed to be part of an "innovative rating system."

[0066] The following description applies to any execution engine, for example any of engines 301, 302, and 303 of FIG. 1, and is repeated consecutively.

[0067] Preliminarily, the execution engine identifies an analysis task to be executed in an execution queue (see, e.g., queues 321, 322, and 323 in FIG. 1) - the first actual step 3200 in the method of FIG. 3. Typically, the identified task is at the head of the execution queue if a First-In-First-Out (FIFO) approach to managing analysis tasks is followed, although other approaches are possible. The execution engine may consider one (i.e., predetermined) or multiple execution queues. If more than one queue is considered, the execution engine may select an analysis task from the queue in order or may use some selection criteria.

[0068] Then, as previously described, the execution engine: a) collecting run parameters (block 3300 of FIG. 3); b) extracting data from a database of data (block 3400 of FIG. 3); c) creating an execution environment (block 3500 of FIG. 3); d) Running the computational analysis computer program (block 3600 of FIG. 3).

[0069] As previously 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 being executed - name or identifier of the industrial system 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 industrial system data to be analyzed

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

[0071] Following execution, ie, step d, the execution engine may: e) storing the results of the execution in a results database (see, for example, database 410 in FIG. 1) (block 3700 in FIG. 3);

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

[0073] In the "Innovative Rating System" 1000, it may be possible to provide the following data output applications 400: f) Send the results in the results database 410 to the user application (block 3800 of FIG. 3).

[0074] In this case, the transmission of data to the user application is typically repeated, for example periodically, and is typically directed to a remote application. For example, a user managing one or more plants may request another entity to take charge of the evaluation of his or her plants and may be interested in receiving the results of the evaluation from this entity. This entity may be specialized in 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. Indeed, in the system database 210, for each industrial system, "client" information may be stored, 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, for example by other applications within the Innovative Rating System, or remotely, for example by applications outside the Innovative Rating System.

[0077] Advantageously, after step d, and in particular after step e, the execution engine comprises: g) Information regarding the outcome of the execution may be sent to an orchestrator application (eg, application 200 of FIG. 1) (block 3900 of FIG. 3).

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

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

[0080] The execution environment may also include a reference (e.g., its name or a link to its code) to a computational analysis computer program specified in the queue item or part or entire program, and the computational analysis computer program may be downloaded from a computational analysis database, for example, based on the analysis task information in the queue item.

[0081] The execution environment may generally include parameters and / or constants (eg, references to parameters and / or constants in a system database).

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

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

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

[0085] As explained, this “innovative evaluation method” may require the engine (301, 302, and 303 in FIG. 1) to query, insert data into, and extract data from several items and / or databases (310, 320, and 410 in FIG. 1).

[0086] Such communication of the engines may be performed through application programming interfaces associated with the items and / or databases. There may be APIs associated with the programs or program databases, and / or APIs associated with the queues or queue databases, and / or APIs associated with the results database.

[0087] It may also be provided that these databases may be managed by dedicated management applications. Thus, there may be a program database management application (319 in FIG. 1), and / or a queue database management application (329 in FIG. 1), and / or a results database management application (490 in FIG. 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 of Fig. 1 includes all components used to implement both the "innovative evaluation method" responsible for preparing the analytical task and the "innovative evaluation method" responsible for executing the analytical task. According to alternative embodiments, the "innovative system" may include all components used to implement only the "innovative evaluation method" responsible for preparing the analytical task or only the "innovative evaluation method" responsible for executing the analytical task.

[0089] FIG. 1 shows a system 1000 comprising: -Orchestrator Server 200 -Database of 110 - System Database 210 -Orchestrator Database 220 A plurality of execution engines 301, 302, and 303 - a plurality of computational analysis computer programs 311, 312, and 313 (in the figure, a distinction is made 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); a plurality of execution queues 321, 322, and 323; and -Results database 410.

[0090] Additionally, FIG. 1 also illustrates a number of industrial systems 10, 20, 30, and 40 which are not components of the system and which are typically remotely and widely separated (accessed) from the system.

[0091] Finally, FIG. 1 also shows several applications, in particular a first plurality of applications corresponding to base applications, and a second plurality of applications corresponding to database management applications.

[0092] The first plurality of applications includes a data entry application 100 and a data output application 400. One or more or all of these applications may run on dedicated "real machines" or hardware (sometimes called "servers"), or on "virtual machines."

[0093] The second plurality 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. These applications are all software applications. Thus, for each of them there is 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 be executed on dedicated "real machines" i.e. hardware (sometimes called "servers"), or "virtual machines."

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

[0095] Alternate system embodiments may include more or fewer components than system 1000.

[0096] 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, server 200 may execute 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 execute on the same hardware. For example, according to some embodiments, a first storage device may store programs 311, 312, and 313. A 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 application or server 319) is shared by both subsystems. For example, according to some embodiments, a second storage device may store queues 321, 322, and 323. A 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 application or server 329) is shared by both subsystems. For example, according to some embodiments, the first storage device and the second storage device may be part of a single storage system shared by both subsystems.

[0097] The first subsystem for evaluating the industrial system includes at least: - access to the system database 210, i.e. at least the means to access the database, not necessarily the entire database; access to a database 110 of data, i.e. not necessarily the entire database, but at least the means for accessing the database; - an orchestrator server 200 suitably configured as described above and which may incorporate an orchestrator database 220 or have access to the orchestrator database 220 through suitable means;

[0098] The second subsystem for processing analysis tasks includes at least: access to a database 110 of data, i.e. not necessarily the entire database, but at least the means for accessing the database; - access to one or (more typically) several computational analysis computer programs 311, 312 and 313, i.e. not necessarily the programs, but at least a means for accessing the programs; at least one execution engine 301, 302 and 303 suitably configured as described above; Typically also - having access to one or (more typically) the execution queues 321, 322 and 323, ie not necessarily the queues, but at least means for accessing the queues;

[0099] Note that the "execution environment" (which typically includes the "contest") is created during the execution of the analysis task by the execution engine. It is therefore not a true component of a system or subsystem. However, some computer memory is required to store the "execution environment" as it is created and / or used during the execution of the computational analysis computer program. Note that according to some embodiments, the "execution environment" may be remotely transmitted after it is created and before it is used during the execution of the computational analysis computer program (this typically applies to remote execution of analysis tasks).

[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, the term "local" may mean in the same "virtual machine", or in the same "real machine", or in the same computer or server, and the term "remote" may mean in a separate "virtual machine", or in a separate "real machine", or in a separate computer or server. Thus, in this context, the meaning of these terms does not necessarily relate to physical distance. For example, two components may be in the same board or in the same cabinet, or remote, i.e. at a distance of 1-100 cm. Of course, the term "remote" is generally applied when the physical distance is large.

[0101] In the previous paragraphs, we have often referred to "access means" when describing databases, computer programs, and execution queues, i.e., the "entities" to be accessed. Such "access means" may be implemented in different ways. Advantageously, their implementation means application programming interfaces (including one or more access primitives). In this way, "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, e.g., via the Internet and / or one or more hardware systems). The accessed entity, e.g., a database, may be managed by a management device associated with the entity. In this case, access to the entity means communication with that 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 managed by a management application 319 associated with a program database. Their configuration files may be included in the database. Applications 200 typically need to access information in the configuration files. Execution engines 301, 302, and 303 typically need to access information in the configuration files and need to download them.

[0103] 1 shows, by way of example, three execution engines 301, 302, and 303, all of which are entirely internal to the system 1000. As explained, the minimum number of execution engines is one.

[0104] According to the simplest implementation of the system 1000, each of the execution engines performs computations locally, ie, within the system 1000.

[0105] However, according to alternative embodiments, one or more of the execution engines may execute the computation remotely, in which case, for example, the execution engine prepares everything necessary for the computation (including, for example, the creation of the execution environment and the downloading of the computational analysis computer program) based on the data and information in the execution queue, and then requests a remote "computer system" or "computer application" to execute the computation (typically sending both the created execution environment and the execution program), and waits for the results to be stored later in the results database 410. In this case, the execution engine may "branch out" from the system. It should be noted that according to some embodiments, some of the computation may be executed locally and some of the computation may be executed remotely.

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

Claims

1. A method for processing analytical tasks relating to computational analysis on data received from an industrial system (10, 20, 30) and stored in a database of data (110) for evaluation on said industrial system (10, 20, 30), comprising: a) collecting execution parameters from a computational analysis computer program (311, 312, 313) corresponding to said analysis task, said execution parameters including information regarding industrial system data processed by said computational analysis computer program; b) extracting from said database of data (110) data from said industrial system to be processed by said computational analysis computer program based on said collected performance parameters; c) creating an execution environment that includes the extracted data; d) executing the computational analysis computer program using the created execution environment.

2. 2. The method of claim 1, wherein the execution engine (301, 302, 303) identifies the analysis task in an execution queue (321, 322, 323), in particular in a predefined execution queue, the identified task being at the head of the execution queue.

3. 2. The method of claim 1, wherein the execution engine (301, 302, 303) identifies the analysis task in a plurality of execution queues (321, 322, 323), the identified task being at the head of any execution queue.

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

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

6. 2. The method of claim 1, wherein in step b) the execution engine (301, 302, 303) extracts data from the database of data (110) via an application programming interface associated with the database of data.

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

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

9. 9. The method of claim 8, wherein the execution parameters extracted from the analysis task information include information about already performed computational analyses, in particular results of already performed computational analyses, which may be stored in the orchestrator database (220).

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

11. After step d), the execution engine: The method of claim 1, further comprising: e) storing results of the execution in a results database (410).

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

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

14. A data output application (400), The method of claim 11, further comprising: f) transmitting the results in the results database (410) to a user application.

15. After step d), in particular after step e), said execution engine (301, 302, 303) The method of claim 1 , further comprising: g) sending information regarding the outcome of the execution to an orchestrator application (200).

16. A system (1000) for processing analytical tasks relating to computational analysis on data received from an industrial system (10, 20, 30) and stored in a database (110) of data for performing an evaluation on said industrial system (10, 20, 30), comprising: - access to a database (110) of data storing data collected from the industrial system; - access to at least one computational analysis computer program (311, 312, 313); at least one execution engine (301, 302, 303), a) collecting execution parameters from the computational analysis computer program corresponding to the analysis task, the execution parameters including information regarding industrial system data processed by the computational analysis computer program; b) extracting from said database of data (110) data from said industrial system to be processed by said computational analysis computer program based on said collected performance parameters; c) creating an execution environment that includes the extracted data; d) at least one execution engine (301, 302, 303) configured to execute the computational analysis computer program using the created execution environment.

17. 17. The system (1000) of claim 16, further comprising a database (110) of said data, said database of data being local or remote.

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

19. The system (1000) of claim 16, further comprising one or more queues (321, 322, 323) configured to store analysis tasks and / or a queue database, the queue database being local or remote.

20. 17. The system (1000) of claim 16, further comprising the results database (410), the results database being local or remote.

Images