Method and system for evaluating a plurality of industrial systems

Abstract

To simultaneously evaluate multiple industrial systems (10, 20, 30, 40), a data input application (100) repeatedly collects data from the industrial systems (10, 20, 30, 40) and stores them in a database (110) of the data. An orchestrator application (200) repeatedly and independently of the data input application (100) a) scans a system database (210), b) for each industrial system in the system database (210), determines any computational analysis computer program to be applied to the data based on information regarding the applicability relationship, c) checks whether there is corresponding data in the database (110) of the data for the determined computational analysis computer program, d) creates an analysis task to be executed for each computational analysis computer program determined and positively confirmed, and e) progressively stores the created analysis tasks in at least one execution queue (321, 322, 323).

Description

Technical Field

[0001] The subject matter disclosed herein relates to methods and systems for performing evaluations on multiple industrial systems, and more particularly, to the preparation 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 "items" specifically evaluated may be, for example, oil & gas plants or plant machinery, particularly turbomachinery, or machine parts. The evaluation may be a determination of some form of the state of the "item" (e.g., the efficiency of a machine considering its operation in the immediately preceding hour or day or week), 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 for the same evaluation to be repeated, for example, periodically (e.g., once a day or once a week or once a month).

[0004] Solutions for performing an evaluation regarding an "installed product" are described in U.S. Patent No. 10,628,145. In this document, the expression "execute analytic model" is used. This document generally refers to the possibility of evaluating multiple industrial systems, but focuses on the structure of the "execution platform" (see Figures 2 and 3) in a first aspect and on the analytic model and how to make it flexible (see Figures 5 - 9) in a second aspect. As described in its independent claims, the system and method require an "API wrapper" associated with each of the analytic model and the execution platform, and the API wrapper includes input information, output information, and "technique". According to this document, the technique can be a solution methodology, a method for generating specific values of coefficients in a kernel, or a relationship between input and output.

[0005] A company may be interested in performing different evaluations on multiple industrial systems at the same time. In this specification, "at the same time" means during the same period and within the same period, and it should be understood that it does not necessarily mean the same time period (even if simultaneity is not excluded). In fact, as disclosed in this specification, the level of simultaneity depends on when the analytic task is prepared and how the analytic task is processed.

[0006] The above-mentioned document, U.S. Patent No. 10,628,145, is titled "scalable and secure analytic model integration and deployment platform". According to its abstract, it deals with systems, devices, and methods having an analytic model for an installed product. The execution platform is configured to execute the analytic model. The API (= Application Programming Interface) wrapper is associated with each of the analytic model and the execution platform (the API wrapper includes input information, output information, and technologies). The storage device communicates with the analytic model and the execution platform and stores program instructions. The program instructions perform the function of transmitting information between the analytic API wrapper and the execution platform API wrapper and deploying the analytic model to the execution platform based on the transmitted information. According to the background art section, it is often desirable to perform an evaluation and / or prediction regarding the operation of a real-world physical system such as an electromechanical system. Conventionally, models are used to analyze data and generate results that can be used to perform an evaluation and / or prediction of a physical system. A model can be an important aspect in efficiently functioning an industrial system. A model can be built on a local computer and then sent to another computer for execution. However, executing a model on a computer different from where the model was built may involve rewriting the model program and debugging the program, which can be very time-consuming and error-prone. This rewrite / debug process may be repeated each time the model is executed on a different system. Therefore, it is desirable to provide a system and method that facilitate building a model of a physical system in a more efficient and accurate manner.As is apparent from the description, according to the invention, two or more "models" (which, according to the terminology of this specification, approximately correspond to "computational analysis") are applicable to a single "installed product" (which, according to the terminology of this specification, approximately corresponds to "industrial system"), and a single "model" can be divided into a plurality of "tasks" (which have no corresponding term in the terminology of this specification and do not correspond to the "tasks" of this specification). Only one paragraph in U.S. Patent No. 10,628,145 states that the system can receive "data from at least one of the installed product". In light of the background art, this document does not provide details regarding methods for simultaneously processing multiple models and, furthermore, methods for simultaneously processing multiple installed products.

[0007] Therefore, it is desirable to have a method and system for performing such evaluations simultaneously. In particular, it is desirable that they be flexible and / or efficient and / or effective. SUMMARY OF THE INVENTION

[0008] According to a first aspect, the subject matter disclosed herein relates to an evaluation method. To simultaneously evaluate a plurality of industrial systems, a data input application repeatedly collects data from the industrial systems and stores them in a database of data. An orchestrator application repeatedly and independently of the data input application, a) scans the system database, b) for each industrial system in the system database, determines any computational analysis computer program to be applied to the data based on information regarding applicability relationships, c) checks whether there is corresponding data in the database of data for the determined computational analysis computer program, d) creates analysis tasks to be executed for each determined and positively confirmed computational analysis computer program, and e) progressively stores the created analysis tasks in at least one execution queue.

[0009] According to a second aspect, the subject matter disclosed herein relates to an evaluation system. The system comprises an orchestrator server having access to a system database and a database of data, the system database storing information regarding applicability relationships of computational analysis computer programs to data from industrial systems, and the database of data storing data collected from industrial systems. The orchestrator server is configured to create analysis tasks to be executed based on information in the system database and the database of data and store them in one or more execution queues. The analysis tasks are executed by one or more execution engines.

Brief Description of the Drawings

[0010] Many of the disclosed embodiments of the invention, and the attendant advantages, will be better understood and more fully appreciated when considered in connection with the accompanying drawings. By referring to the following detailed description of the invention, a more complete understanding will be readily obtained.

Figure 1

Figure 2

Figure 3

[0011] According to the subject matter disclosed herein, multiple industrial systems, e.g., multiple machines of oil & gas plants at different locations, are accessed simultaneously. Data from the industrial systems is collected from the industrial systems and stored in a database of the data. Information regarding 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 is repeated by scanning the system database, independent of the collection of data from the industrial systems. Further, independent of the collection of data and the preparation of the analysis tasks, one or more execution engines continuously execute the analysis tasks. Each analysis task is executed after creating in advance the corresponding execution environment so that the execution is effective and efficient. Usually, the analysis tasks are identified within one or more execution queues so that the execution is more effective and efficient. As already made clear, in this specification, "simultaneously" means during the same period and within the same period, and does not necessarily mean 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 the analysis tasks are processed. Note that different evaluations are designed to operate on different data. Further, note that the same evaluation (e.g., from different items) may be applied to different data, which leads to separate analysis tasks.

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

[0013] FIG. 1 also shows a plurality of industrial systems external to the evaluation system 1000. In particular, this figure shows four industrial systems 10, 20, 30, and 40, although any number of industrial systems may be considered, at least one.

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

[0015] Data from industrial systems 10, 20, 30, and 40 may be received by a data input application 100, typically a software application running on hardware. This hardware portion may be dedicated to data reception and possibly data transmission (e.g., for query purposes). The application 100 not only receives data but also repeatedly queries, e.g., periodically, the industrial systems 10, 20, 30, and 40 (especially the communication devices of the systems), and / or is configured to repeatedly receive data, e.g., periodically, when the industrial system transmits data to the evaluation system 1000. The industrial systems may collect (similar or different) measured and / or calculated data for some time. Such a group of collected data may be transmitted as a data package to the evaluation system 1000 when the evaluation system queries the industrial system and / or when the industrial system decides.

[0016] The application 100 may also be configured to (correctly order) store the received data in a database 110 of the data. The received data may also be processed by the application 100 before being stored. Generally, considering that 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 be labeled, for example, "T - A - I - GT", regardless of the type and size of the gas turbine.

[0017] Information regarding the industrial system to be evaluated is stored in the system database 210. Such information relates, in particular, to the applicability relationship of computational analysis computer programs to data from the industrial system. In the embodiment of FIG. 1, as an example, three analysis 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.

[0018] Note that according to some embodiments, some data in the database 110 of data may be derived indirectly from the industrial systems 10, 20, 30, and 40. Such data may be derived, for example, from the processes executed by the system 1000 or under the control of the system 1000 with respect to data received from the industrial system. For example, such data may correspond to the "measurement" of a "virtual sensor" calculated by, for example, the execution engine of the system 1000. As will become more apparent hereinafter, such data may be transferred from the database 410 to the database 110 under the control of the application 100 and / or the application 400.

[0019] The 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 evaluate one or more industrial systems, i.e., to determine some form of state or some form of prediction.

[0020] 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 called "analytic") 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. To classify the industrial system, 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) of the category columns may be advantageously provided within the table. Other columns corresponding to parameters and / or constants useful when coupling the analysis program to one or more systems and / or when executing the analysis task may be advantageously provided within the table. One or more additional component columns, named, for example, "component-name" and / or "component-model", corresponding to one or more components that provide data and may be subject to evaluation may be advantageously provided. Finally, one or more other time series, named, for example, "installation date" and / or "maintenance date", may be advantageously provided so that the evaluation can also take into account such information.

[0021] It should be noted that such a system database gives a great deal of flexibility to the "innovative evaluation system". At a certain point, if a further industrial system is to be 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, if further "computational analysis" is to be performed, it is sufficient to simply add a column to the table and introduce the appropriate data / information. At a certain point, if a new "computational analysis" is to be 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" is to be applied to data from a set of "items", the category column may be useful when selecting the "items".

[0022] Using system database 210 and 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. It should be noted that in this description, 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.

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

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

[0025] This method includes the following preliminary steps. - Providing a plurality of computational analysis computer programs (block 2210 in FIG. 2); and - Providing a system database (block 2220 in FIG. 2).

[0026] Note that additional computational analysis computer programs may be added later, for example, when they are designed, developed, and tested.

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

[0028] Also note that the system database may be updated later, for example, due to the addition of the industrial system to be evaluated and / or the addition of "computational analysis" applied to the collected data.

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

[0030] Essentially, two applications, namely, a data input application (labeled 100 in FIG. 1) and an orchestrator application (labeled 200 in FIG. 1), are executed independently according to this method.

[0031] The data input application repeatedly collects data from the industrial system (block 2310 in FIG. 2) and then stores them in the database of data (block 2320 in FIG. 2).

[0032] 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 applied to the data (one or more "computational analyses" may be applied to the data collected from the industrial system, and only under exceptional circumstances, an industrial system registered in the system database is not subject to any evaluation) (block 2420 in Figure 2), c) For the determined computational analysis, the computer program checks whether there is corresponding data in the database of the data (depending on the "computational analysis" applied, an amount and / or quality of data should exist to enable the calculation) (block 2430 in Figure 2), d) For each computational analysis computer program determined and positively confirmed, create an analysis task to be executed (block 2440 in Figure 2), e) Gradually store the created analysis tasks in at least one execution queue (block 2450 in Figure 2).

[0033] Any item in the execution queue, i.e., any analysis task, may include 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 analyzed through the task, e.g., a set of systems belonging to one or more same categories - Time frame, i.e., the time range of the data of the industrial system to be analyzed

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

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

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

[0037] For example, as shown in FIG. 1, each computational analysis computer program 311, 312, 313 is associated with a configuration file (see the smaller box behind the larger box) containing information about the program. Such information may be the type and amount of data from the industrial system designed to be processed by the program, and in some cases, further, whether it is a 32-bit code program or a 64-bit code program, and / or the operating system used for execution, 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 test or already tested.

[0038] Typically, the orchestrator application checks whether the corresponding data, particularly the appropriate data and / or sufficient data, exists in the database of the data for the desired "computational analysis" (see step c). Such a check may be based on the information stored in the database of the data. In other words, the orchestrator application may query the database of the data to confirm the existence of the data. Preferably, such a check may also be based on the information stored in the orchestrator database. For example, when the "computational analysis" is executed periodically, the orchestrator application may check in the orchestrator database when it was last executed, and thereby check whether appropriate data and / or sufficient data exists in the database of the data since the last execution.

[0039] 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 previous "computational analysis", i.e., "Analysis B", for example, the processing of a "virtual sensor".

[0040] Advantageously, the orchestrator application can check whether the "computational analysis" is already in progress. Such a check is useful, for example, to avoid the analysis of later data being executed before the same analysis of the previous data is completed for one or more of the same industrial systems. This check may be performed, for example, by storing "exec-state" information indicating the "current execution state" of the program for one / any or multiple or all available computational analysis computer programs and / or one or multiple or all execution tasks in progress in the orchestrator database, for example.

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

[0042] Advantageously, the orchestrator application progressively stores the created analysis tasks in a plurality of 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, with a minimum of one. The plurality of execution queues is useful for distributing computational analysis work among several execution engines. The distribution may be uniform or non-uniform.

[0043] The 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 calculations, especially intensive tasks, or a queue dedicated to high-priority "computational analysis". The execution queue may be associated with a debug execution engine. This can be useful for testing and debugging new "computational analysis". Note that in this way, debugging can be performed on "real data", data derived from one or more industrial systems, so-called "fleet level debug". Also note that the "computational analysis" to be 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).

[0044] The orchestrator application may select an execution queue for the execution tasks in the plurality of execution queues based on the information in the configuration file associated with the computational analysis computer program.

[0045] Advantageously, the orchestrator application stores information regarding computational analysis that has already been executed, particularly the results of computational analysis that has already been executed, in an orchestrator database (see, for example, database 220 in FIG. 1). Such information may be useful for future "computational analysis".

[0046] As described, according to this "innovative evaluation method", the data input application (100 in FIG. 1) needs to query and insert data into the database of data (110 in FIG. 1).

[0047] As described, according to this "innovative evaluation method", the orchestrator application (200 in FIG. 1) needs to query and extract data from the database of data (110 in FIG. 1) and the system database (210 in FIG. 1).

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

[0049] It may also be provided that each or both of these two databases may be managed by a dedicated management application. Accordingly, a database management application for data (190 in FIG. 1) and / or a system database management application (290 in FIG. 1) may exist. The data input 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".

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

[0051] The above is the preparation for the analysis task.

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

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

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

[0055] FIG. 1 shows a plurality of execution engines. In particular, this figure shows three execution engines 301, 302, and 303. However, any number of engines may be considered, starting from a minimum of one. It should be noted that the execution engines may correspond to, for example, separate physical machines or 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., within the same hardware on which the orchestrator application is executed) or remote (i.e., within hardware different from the hardware on which the orchestrator application is executed and far away but close to it). Any combination of these two possibilities can 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 this is realized during the operation of the "innovative evaluation system".

[0056] To process the analysis task, the execution engine (e.g., engine 301) a) Collect execution parameters from a computational analysis computer program corresponding to a desired analysis task (see programs 311, 312, and 313 in FIG. 1), where the execution parameters at least include information regarding industrial system data to be processed by the computational analysis computer program. b) Extract data from an industrial system to be processed by the computational analysis computer program from a database of data (database 110 in FIG. 1) based on the collected execution parameters. c) Create an execution environment including at least the extracted data. d) Use the created execution environment to execute the computational analysis computer program.

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

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

[0059] Next, an "innovative evaluation method" for managing the execution of analysis tasks will be described using flowchart 3000 in FIG. 3.

[0060] In FIG. 3, there is an initial block 3100 corresponding to an ideal start of this method.

[0061] As described above, it is assumed that the (actual or virtual) execution engine is part of an "innovative evaluation system".

[0062] The content described below is applicable to any execution engine, for example, any of the engines 301, 302, and 303 in FIG. 1, and is continuously repeated.

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

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

[0065] As already explained, any entry within the execution queue, i.e., any analysis task, may include at least the following information. - The name or identifier of the computational analysis computer program to be executed - The 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 analyzed through the task, for example, a set of systems belonging to one or more of the same categories - The time frame, i.e., the time range of the data of the industrial system to be analyzed

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

[0067] After execution, that is, following step d, the execution engine may perform the following. e) Store the results of the execution in a result database (see, for example, database 410 in FIG. 1) (block 3700 in FIG. 3).

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

[0069] In the “innovative evaluation system” 1000, it may be possible to provide the following data output application 400. f) Transmit the results in result database 410 to a user application (block 3800 in FIG. 3).

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

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

[0072] Alternatively, the result database 410 may be configured to be accessed locally from other applications within, for example, the "innovative evaluation system" or remotely from applications outside, for example, the "innovative evaluation system".

[0073] Advantageously, after step d, and in particular after step e, the execution engine g) may send information regarding the outcome of the execution to an orchestrator application (e.g., application 200 of FIG. 1) (block 3900 of FIG. 3).

[0074] In this way, depending on the information received, the orchestrator application may recognize the computational analyses that were executed and their execution time frames, and / or whether they were successfully completed, and / or the results of the computational analyses executed in some form. This may, that is to say, be used by the orchestrator application to prepare for the following analysis tasks. Note that some computational analyses may require or utilize previous results.

[0075] The orchestrator application 200 may store the outcome of the execution received in the orchestrator database 220.

[0076] The execution environment may also include a computational analysis computer program specified in a queue entry, and the computational analysis computer program may be downloaded from the computational analysis database, for example, based on the analysis task information within the queue entry.

[0077] The execution environment may generally include parameters and / or constants (e.g., referring to parameters and / or constants within the system database).

[0078] The execution environment may also include execution parameters and / or constants extracted, for example, from the analysis task information within a queue entry.

[0079] The execution parameters extracted from the parsing task information may include information regarding previously executed computational analyses, particularly the results of previously executed computational analyses that may be stored in the orchestrator database.

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

[0081] As described, according to this "innovative evaluation method", the engines (301, 302, and 303 in FIG. 1) may need to query several items and / or databases (310, 320, and 410 in FIG. 1), insert data, and extract data therefrom.

[0082] Such communication of the engines may be performed via an application programming interface associated with the item and / or database. There may be an API associated with the program or program database, and / or an API associated with the queue or queue database, and / or an API associated with the result database.

[0083] Also, it may be provided that these databases may be managed by dedicated management applications. Accordingly, 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 result database management application (490 in FIG. 1). The engine and these management applications may be configured to communicate with each other to perform the operations provided by this "innovative evaluation method".

[0084] The embodiment of the system of FIG. 1 includes all components used to implement both an "innovative evaluation method" responsible for preparing the analysis task and an "innovative evaluation method" responsible for executing the analysis task. According to an alternative embodiment, the "innovative system" may 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.

[0085] FIG. 1 shows a system 1000 comprising the following. - An orchestrator server 200 - A database 110 of data - A system database 210 - An 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, there is a distinction between the computer program itself shown as a larger box, i.e., the executable code, and the corresponding configuration file shown as a smaller box behind the larger box) - A plurality of execution queues 321, 322, and 323, and - A result database 410.

[0086] Furthermore, FIG. 1 also shows a plurality of industrial systems 10, 20, 30, and 40 that are typically remote (accessed) from the system and not components of the system.

[0087] Finally, FIG. 1 also shows a plurality of first applications corresponding to some applications, particularly basic applications, and a plurality of second applications corresponding to database management applications.

[0088] The first plurality of applications includes a data input application 100 and a data output application 400. One or more or all of these applications may be executed on a dedicated "real machine", i.e., hardware (which may be referred to as a "server"), or a "virtual machine".

[0089] The second plurality of applications includes a database management application 190 for data, a system database management application 290, a program management application 319, a queue database management application 329, and a result database management application 490. These applications are all software applications. Thus, 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 be executed on a dedicated "real machine", i.e., hardware (which may be referred to as a "server"), or a "virtual machine".

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

[0091] Embodiments of the alternative system may include more or fewer components than the system 1000.

[0092] 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 be executed 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 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 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.

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

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

[0095] It should be noted that the "execution environment" (typically including a "contest") is created during the execution of the analysis task by the execution engine. Therefore, it is not a true component of the system or subsystem. However, some computer memory is required to store the "execution environment" when it is created during 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 being created and before being used during the execution of the computational analysis computer program (this typically applies to the remote execution of analysis tasks).

[0096] As described 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 from each other. In this context, the term "local" may mean within the same "virtual machine", or within the same "physical machine", or within the same computer or server, and the term "remote" may mean within a separate "virtual machine", or within a separate "physical machine", or within a separate computer or server. Thus, in this context, the meanings of these terms are not necessarily related to physical distance. For example, two components may be remote even if they are within the same board or the same cabinet, i.e., at a distance of 1 to 100 cm. Of course, the term "remote" is generally applied when the physical distance is long.

[0097] In the previous paragraph, when explaining a database, a computer program, and an execution queue, i.e., an "entity" to be accessed, the "access means" has often been mentioned. Such "access means" may be implemented in different ways. Advantageously, their implementation means an application programming interface (including one or more access primitives). Thus, "access" does not need to have detailed information about the entity being accessed, especially how the entity is implemented internally and / or where the entity is located (for example, in the case of a remote entity, access to it may require communication via the Internet and / or one or more hardware systems). The entity being accessed, such as a database, may be managed by a management device associated with the entity. In this case, access to the entity means communication with its management device. The application programming interface may implement communication with the management device if necessary.

[0098] 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 need to download them.

[0099] As already described, FIG. 1 shows, as an example, three execution engines 301, 302, and 303, all of which are completely inside system 1000. As explained, the minimum number of execution engines is 1.

[0100] According to the simplest implementation form of system 1000, each of the execution engines executes calculations locally, that is, inside system 1000.

[0101] However, according to an alternative embodiment, one or more of the execution engines may execute calculations remotely. In this case, for example, the execution engine prepares all the matters necessary for the calculation (including, for example, creating an execution environment and downloading a 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 calculation (typically sending both the created execution environment and the execution program), and waits for the result to be stored in result database 410 later. In this case, the execution engine may "branch out" from the system. It should be noted that according to some embodiments, part of the calculation may be executed locally and part of the calculation may be executed remotely.

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

Claims

1. A method for simultaneously evaluating a plurality of industrial systems (10, 20, 30, 40), the method comprising: - A preliminary step of providing a plurality of computational analysis computer programs (311, 312, 313); - A preliminary step of providing a system database (210) for storing information regarding the applicability relationship of the computational analysis computer programs (311, 312, 313) to data from the industrial systems (10, 20, 30, 40). A data input application (100) is configured to: - Repeatedly collect data from the industrial systems (10, 20, 30, 40) and store them in a database (110) of the data; An orchestrator application (200) repeatedly and independently from the data input application (100) is configured to: a) Scan the system database (210); b) For each industrial system in the system database (210), determine any computational analysis computer program to be applied to the data; c) Check whether there is corresponding data in the database (110) of the data for the determined computational analysis computer program; d) Create an analysis task to be executed for each determined and positively confirmed computational analysis computer program; e) Gradually store the created analysis tasks in at least one execution queue (321, 322, 323).

2. The method according to claim 1, wherein in step b), the orchestrator application (200) determines any computational analysis computer program to be applied to the data based on the information stored in the system database (210).

3. The method according to claim 1, wherein in step b), the orchestrator application (200) determines any computational analysis computer program to be applied to the data via an application programming interface associated with the system database (210).

4. The method according to claim 1, wherein in step c), the orchestrator application (200) checks whether there is corresponding data in the database (110) of the data based on information stored in a configuration file associated with the computational analysis computer program (311, 312, 313).

5. The method according to claim 1, wherein in step c), the orchestrator application (200) checks whether there is corresponding data, in particular suitable and / or sufficient data, in the database (110) of the data based on information stored in the database (110) of the data and preferably also based on information stored in the orchestrator database (220).

6. The method according to claim 1, wherein in step c), the orchestrator application (200) checks whether there is corresponding data in the database (110) of the data via an application programming interface associated with the database (210) of the data.

7. The method according to claim 1, wherein the data collected by the data input application (100) is measurement data and / or calculation data.

8. The method according to claim 1, wherein the orchestrator application (200) progressively stores the created analysis tasks in a plurality of execution queues (321, 322, 323).

9. The method according to claim 8, wherein the execution queues (321, 322, 323) are associated with one or more specific execution engines (301, 302, 303) or one or more types of execution engines.

10. The method according to claim 8, wherein the execution queue (323) is associated with a debug execution engine (303).

11. The method according to claim 8, wherein the orchestrator application (200) selects an execution queue among a plurality of execution queues (321, 322, 323) based on information in a configuration file associated with the computational analysis computer program (311, 312, 313).

12. The method according to claim 1, wherein the orchestrator application (200) stores information on the calculation analysis already executed, in particular the results of the calculation analysis already executed, in the orchestrator database (220).

13. A system (1000) for simultaneously evaluating a plurality of industrial systems (10, 20, 30, 40), - Access to a system database (210) storing information on the applicability relationship of calculation analysis computer programs (311, 312, 313) to data from industrial systems (10, 20, 30, 40), - Access to a database (110) of data storing data collected from industrial systems (10, 20, 30, 40), - An orchestrator server (200), a) Scanning the system database (220), b) For each industrial system in the system database (220), determining any calculation analysis computer program to be applied to the data, c) Checking whether there is corresponding data in the database (210) of the data for the determined calculation analysis computer program, d) Creating an analysis task to be executed for each determined and positively confirmed calculation analysis computer program, e) An orchestrator server (200) configured to progressively store the created analysis tasks in at least one execution queue (321, 322, 323). A system comprising:

14. The system (1000) according to claim 13, further comprising the system database (210) and / or the database (110) of the data.

15. The system (1000) according to claim 13, further comprising an orchestrator database (220), and the orchestrator server (200) is configured to store information on the calculation analysis already executed, in particular the results of the calculation analysis already executed, in the orchestrator database (220).

16. The system (1000) according to claim 13, storing a computational analysis computer program (311, 312, 313) to be applied to data from an industrial system and / or a configuration file related to the computational analysis computer program.

17. The system (1000) according to claim 13, further comprising a data server (190) for managing a database (110) of the data, wherein the data server (190) is local or remote from the orchestrator server (200).

18. The system (1000) according to claim 13, further comprising a system server (290) for managing the system database (220), wherein the system server (290) is local or remote from the orchestrator server (200).

19. The system (1000) according to claim 13, further comprising a queue server (329) for managing one or more execution queues (321, 322, 323), wherein the queue server (329) is local or remote from the orchestrator server (200).

20. The system (1000) according to claim 13, further comprising a data server (190) for managing data from an industrial system (10, 20, 30, 40), wherein the data server (190) is local or remote from the orchestrator server (200).

21. The system (1000) according to claim 13, further comprising a computational analysis server (319) for managing one or more computational analysis computer programs (311, 312, 313), wherein the computational analysis server (319) is local or remote from the orchestrator server (200).

Images