Digital application platform architecture

Abstract

A universal digital application platform architecture for implementing a class of digital applications within an industrial facility operation decision support system is described. The platform supports a set of computing modules adapted to perform model-based computations associated with the facility; bidirectional communication with one or more external data servers; validating data received from such an external data server and validating the results provided thereto; and a digital application metafile containing soft encoded data that manages scheduling of the computing modules and exchange of data between the computing modules. The set of computing modules and digital application metafiles are specific to the category of digital applications implemented.

Description

Technical Field

[0001] The present invention relates to a digital application platform architecture within an industrial facility operations decision support and / or control / automation system, and a method for generating a digital application metafile for use in the digital application platform architecture. Background Art

[0002] Software-based technologies for modeling and evaluating the performance of industrial facilities have been used for many years in many industrial sectors such as oil and gas, chemicals, petrochemicals, pharmaceuticals, food and beverages, agricultural chemicals, minerals and mining, to name a few. Such digital design and operation applications can be based on software platforms or architectures that run modeling and processing environments. These environments can then implement various applications for digital research and development activities, digital engineering and design, and digital operations. An example of such a system is the gPROMS process modeling technology available from Siemens PSE (www.psenterprise.com), in which a single platform is used as the basis for modeling and operating environments, enabling a wide range of industrial sectors to create so-called digital twins of industrial processes. This creates value through better design and more efficient operation. A digital twin is a virtual representation of a physical system that is created using sensor data from a twin physical system and CAx software that simulates the twin system and processes the sensor data to reconstruct the behavior of the twin physical system. The underlying model can be based on equations derived from physical principles and other existing knowledge, or from facility data, or from a combination of the two methods within a hybrid modeling framework. Alternatively, the model can be purely statistical in nature, based only on current and historical industrial facility data.The digital twin can then be used to explore the twin physical system, such as investigating problems, performance, and conditions.

[0003] While digital twins are used to simulate the behavior of a system, digital applications are integrated software systems that utilize mathematical models of processing systems coupled with industrial facility data to perform well-defined tasks. In other words, the purpose of a digital application is not simply to mimic the behavior of a process, but to use the model representing that behavior to perform specific tasks, such as controlling the physical system or optimizing its performance in real time.

[0004] Typically, most non-trivial digital applications involve multiple instances of one or more computations that are executed in real time, either in parallel or sequentially. These computations can also exchange information with each other and with external data servers. Such external data servers not only provide input data to the computations performed by the digital application, but also transmit the results of these computations. Figure 1 An example thereof is shown. Figure 1Figure 1 is a schematic diagram of an existing real-time optimization (RTO) digital application for a process. This is a well-established type of digital application. In its conventional form, RTO involves using a steady-state model of the process to solve a steady-state optimization calculation, the goal of which is to determine the optimal operating settings for the control system of the industrial facility implementing the process. Because the optimization depends on the current inputs of the industrial facility and the parameters of the underlying model, it is typically preceded by a steady-state data reconciliation calculation, the goal of which is to obtain reliable, up-to-date values of these quantities using available measurements from sensors and systems within the industrial facility. Furthermore, because data reconciliation is performed on a steady-state basis, it is necessary to ensure that the industrial facility is approximately in steady-state before using these measurements. Figure 1 This aspect is illustrated schematically, where a digital application 1 for steady-state real-time optimization is shown as an example sequence comprising three calculations. First, a steady-state detection calculation module 2 uses statistical analysis of industrial facility data received from an industrial facility historian 3 to determine whether the industrial facility is operating in a steady state. If the answer is no, the calculation module repeats the steady-state detection process after an appropriate time interval. If the answer is yes, a steady-state data coordination calculation module 4 uses mathematical optimization techniques applied to a mathematical model of the process to generate coordinated industrial facility inputs and updated model parameters. These are fed to a steady-state optimization calculation module 5, which also uses data such as the availability, cost, and product demand and price of raw materials and energy obtained from a business IT system 6 to optimize further mathematical models. This final optimization determines the optimal set values to be output to the facility control system 7. The three calculation steps 2, 4, and 5 are performed sequentially in a cycle that runs periodically (e.g., once per hour).

[0005] Figure 1 It turns out that even seemingly simple and well-understood digital applications, such as the real-time optimization example, are complex software systems that combine model-based calculations with industrial facility data in real time. This complexity is exacerbated by the need to handle unusual but common situations, such as temporary interruptions in input data availability, erroneous input data, and errors in model-based calculations. These factors place stringent demands on the testing and validation required to ensure that, after successful initial development and deployment, digital applications can operate error-free, continuously, and with minimal human intervention over the long term.

[0006] There are a wide variety of existing and potential digital applications that differ significantly in their intended functionality, underlying computational aspects, and the types of external data servers with which they exchange information. In principle, the complexity of these digital applications can be, and has previously been, addressed through systematic software engineering. However, even for relatively simple applications (such as real-time optimization), this imposes significant costs in terms of the financial and time requirements for developing extensive custom computer code. This, combined with the diverse nature of potentially useful digital applications, creates significant obstacles to their large-scale development and adoption. This is reflected in the relatively small number of commercially available digital applications, which are currently limited to a small number of mature categories, such as linear model predictive control (MPC) and real-time optimization.

[0007] Therefore, there is a need to be able to conveniently and easily design, develop and implement such digital applications, and to reduce the complexity associated with the process. Summary of the Invention

[0008] The present invention aims to solve these problems by providing, in a first aspect, a general digital application platform architecture for implementing a broad class of digital applications within an industrial facility operations decision support system, the digital application platform architecture comprising: a set of computational modules adapted to perform model-based computations related to the facility; a scheduler module adapted to schedule the execution of the computational modules; a resource manager module adapted to allocate computational resources to enable the execution of the computational modules; a data manager adapted to communicate with an external data server that provides data related to the facility and facility control; a data validation module adapted to validate data received from the external data server and to validate results computed by the set of computational modules; and a digital application metafile accessible to all components of the digital application, containing soft-coded data that manages the scheduling of the execution of the computational modules and the exchange of data between the computational modules; wherein the set of computational modules and the digital application metafile are specific to a class of digital applications implemented; and wherein the soft-coded data defines information related to the class of digital applications in terms of categories of variables required in the models used by the computational modules and attributes associated with each category.

[0009] By providing soft-coded data within the digital application metafile, it is no longer necessary to develop and maintain custom computer code for any specific class of digital applications. This allows the complexity and diversity of all classes of digital applications to be managed flexibly and reliably, resulting in the construction of high-quality applications in a cost-effective manner.

[0010] Preferably, the data verification module includes: an external data verification module, which is suitable for verifying data obtained from an external data server using standards soft-coded in a digital application metafile; and a result verification module, which is suitable for verifying the results from each calculation module in the set of calculation modules using standards soft-coded in the digital application metafile.

[0011] The digital application platform architecture may further include an execution monitoring module adapted to monitor the execution of the digital application in real time and take appropriate action if the digital application deviates from expected performance or stops executing altogether.

[0012] The digital application platform architecture may further comprise an archiver module adapted to maintain a record of the performance of the digital application, the record comprising the execution of each instance of each computational module.

[0013] Preferably, one or more instances of each computation module are executed asynchronously and in parallel, with the occurrence, timing and frequency of execution of these instances being determined based on scheduling rules soft-coded in the digital application metafile.

[0014] Preferably, the data manager is adapted to communicate using a plurality of data exchange protocols.

[0015] Preferably, communication with each external data server is accomplished via a data client conforming to a standardized software interface, wherein the data manager and external data servers are configured to implement industry standard or proprietary communication protocols.

[0016] The digital application platform architecture may also include inputs to the set of computational modules from one or more mathematical models describing the behavior of the industrial facility.

[0017] Preferably, one or more computing modules within the set of computing modules perform different types of computations, each computation using a different mathematical model.

[0018] Preferably, the metadata is stored in a digital application metafile in a structured file format.

[0019] In a second aspect, the present invention also provides a computer-implemented method for generating a digital application metafile for use in the digital application platform architecture outlined above, the method comprising the following steps: a) identifying a set of computing modules that can be executed by a digital application; b) defining conditions for executing one or more instances of a computing module based on data received from an external data server and / or data generated by the execution of other computing modules; c) defining categories of variables used by the digital application to perform computing tasks; d) defining compatibility rules between variable categories; e) defining attributes associated with each defined variable category; f) based on the defined attributes, determining criteria for external data validation, result validation, computing resource allocation and execution scheduling; and g) storing the defined variable categories and their associated attributes, as well as criteria for external data validation, result validation, computing resource allocation and execution scheduling as metadata associated with the digital application in the digital application metafile.

[0020] The method may further include defining industrial facility parameters, data validation consistency rules, rules governing communication between computing modules, and rules governing execution scheduling for a scheduler module; and storing in a digital application metafile.

[0021] Preferably, the metadata is stored in a digital application metafile in a structured file format. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The present invention will now be described by way of example and with reference to the accompanying drawings, in which:

[0023] Figure 1 It is a schematic diagram of the existing technical means;

[0024] Figure 2 is a schematic diagram of a digital application platform architecture according to an embodiment of the present invention;

[0025] Figure 3 is a flow chart illustrating a method for using a digital application platform architecture according to an embodiment of the present invention;

[0026] Figure 4 is a flowchart of a method for generating a digital application metafile according to an embodiment of the present invention;

[0027] Figure 5 is an example of a digital application metafile for real-time optimization of digital applications; and

[0028] Figure 6 is a flow chart illustrating one example of an execution cycle for a digital application of nonlinear model predictive control (NLMPC). DETAILED DESCRIPTION

[0029] Figure 1The potential complexity of digital applications presents stringent requirements for testing and validation, ensuring they can operate flawlessly, continuously, and with minimal human intervention over extended periods of time. This complexity can make it difficult to maintain digital applications over extended periods, even after successful initial development and deployment. Embodiments of the present invention address this complexity and diversity by providing a digital application platform architecture that functions within an industrial facility operations decision support system and implements a digital application metafile that facilitates the convenient and easy definition and implementation of a variety of digital applications. The platform architecture includes a set of computational modules adapted to perform model-based computations related to the facility. The platform architecture also includes a scheduler module adapted to schedule the execution of the computational modules. The platform architecture also includes a resource manager module adapted to allocate computational resources to enable the execution of the computational modules. A data manager communicates with external data servers to obtain facility-related and other data and provides key results, including facility control settings. A data validation module validates data received from the external data servers and the results received from the computational modules. These modules address the issues surrounding complexity by ensuring that the data used by the computational modules and their calculations are correct. A digital application metafile, accessible to all modules of a digital application, contains soft-coded data that manages the scheduling of computational modules and the exchange of data between them. Computational modules and digital application metafiles are specific to the class of digital application being implemented. The soft-coded data defines information related to the class of digital application in terms of different categories of variables and their associated attributes, as well as the rules governing the validity of all this data.

[0030] A digital application can be described as a well-defined task that operates under well-defined conditions, has well-defined inputs, and produces well-defined results when communicating with other IT software and hardware systems. For the real-time optimization (RTO) example, digital applications address many issues that arise during the operation of an industrial facility. These include: whether the industrial facility is currently operating in a steady state; how to handle inconsistencies in the industrial facility data; what happens if the industrial facility data is unavailable or invalid, and what should be done in this case; what should be done if the optimization calculation fails; and how to protect the industrial facility from unpredictable results produced by the optimization calculation. The methods of embodiments of the present invention answer these questions.

[0031] Figure 2 FIG2 is a schematic diagram of a digital application platform architecture according to an embodiment of the present invention. The digital application platform architecture 10 includes multiple functional modules and a digital application metafile 14. The functional modules can be considered to be divided into three groups: an application management module 11, a data verification module 12, and a calculation module 13.

[0032] The set of calculation modules 13 is specific to a class of digital applications being implemented, wherein each calculation module 13a, 13b ... 13n performs a different calculation, such as a model-based calculation. Figure 1 In the case of real-time optimization shown, there are three calculation modules: steady-state detection 13a, data coordination 13b and steady-state optimization 13c. It should be understood that the number and nature of the calculation modules 13a, 13b...13n can be flexibly adjusted according to the digital application.

[0033] The digital application metafile 14 is also specific to a class of digital applications being implemented. It contains soft-coded data that manages the scheduling of computational modules and the exchange of data between them. The soft-coded data defines information related to the class of digital applications in terms of the categories of variables required in the models used by the computational modules and the associated attributes of these variables.

[0034] and Figure 1 Unlike the example in

[15] , the scheduling of the execution of computation modules 13a, 13b, ..., 13n and the data exchange between them is not hard-coded. Instead, in an embodiment of the present invention, the scheduling of the execution of computation modules 13a, 13b, ..., 13n and the data exchange between them is soft-coded in the digital application metafile 14. Compared to hard-coding a computer application, where the behavior is determined by source code and cannot be altered by the user, soft-coding allows the behavior to be determined entirely by information provided within the digital application metafile. Soft-coding the digital application metafile 14 allows it to be automatically managed by two broad software modules: a scheduler module 15 and a resource manager module 16. The scheduler module 15 schedules the execution of computation modules 13a, 13b, ..., 13n, determining and controlling when to execute them. The resource manager module 16 allocates computation resources, such as computer cores or processors, to the execution of instances of computation modules 13a, 13b, ..., 13n. This allows for significantly greater complexity within the digital application platform architecture 10 than the conventional, strict sequence of computations executed in cycles on a single processor. For example, the occurrence or timing of execution of each computation module 13a, 13b ... 13n may depend on the results of execution of other computation modules 13a, 13b ... 13n and / or events received from an external data server. In addition, one or more instances of each computation module 13a, 13b ... 13n may be executed asynchronously in parallel, with the occurrence, timing, and frequency of execution of these instances determined based on scheduling rules soft-coded in the digital application metafile 14. This allows for optimal use of multiple computer cores or processors, as determined by the resource manager module 16.

[0035] Another aspect of digital applications is the need to communicate with various external software systems, such as industrial facility historians, commercial databases (e.g., those with real-time material pricing and availability information and product pricing information), and industrial facility control systems. To facilitate this functionality, the digital application platform architecture 10 includes a data manager 17, located within the runtime module group 11, that is adapted to communicate with various external data servers 18. Communication with each type of external data server 18 is accomplished via a data client that conforms to a standardized software interface and implements an appropriate industry standard or proprietary communication protocol. These external data servers can generally include a range of software systems and associated data exchange protocols, including but not limited to data access (DA), historian access (HDA), the Unified Architecture (UA) standard for Open Platform Communications (OPC), SQL and other databases, user interfaces, web services, and any other type of external data server that provides an application programming interface (API) for retrieving or providing data relevant to the digital application's computations.

[0036] Deploying a digital application to a specific industrial facility requires one or more mathematical models of the facility. These mathematical models are used by the computational modules of the digital application. These mathematical models are typically built and validated offline using suitable modeling tools before being deployed online in the digital application.

[0037] Furthermore, deploying a digital application to a specific facility requires user-provided deployment configuration data 20 in the form of a structured file (e.g., XML or JSON). This configuration information includes, but is not limited to: a) identification of the variables within the mathematical model 19 associated with the digital application, b) classification of these variables according to variable categories defined in the digital application metafile 14, and c) specification of values for some or all attributes associated with each category (e.g., the valid range of values for variables measured by facility sensors, and the valid range of rates of change of these values over time). It is also necessary to identify i) the specific external data servers with which the digital application will communicate (e.g., via appropriate IP addresses for OPC-based data servers, or via Data Source Names (DSNs) for SQL databases), and ii) the precise address of each data item (e.g., variable attribute) that will need to be communicated between the digital application and these external data servers (e.g., via OPC tag names or SQL database queries).

[0038] A key determinant of the flexibility and robustness of digital applications is the quality of the data required by computation modules 13a, 13b, ..., 13n. It's often impossible to guarantee that data obtained from external data servers 18 will always be correct or even usable throughout the entire runtime of a digital application. For example, data may be temporarily unavailable due to communication issues, and even when available, the actual data values may be incorrect due to sensor failures. For a digital application to continue to operate reliably under all circumstances, it must be able to identify erroneous data values and take appropriate action when handling such errors. For example, the data value itself, the rate of change of the data value over time, or the relative values of multiple data items may indicate a problem. Replacing data values with previously obtained valid data values, adjusting them to within a specified range, or temporarily omitting computation module execution during a period may provide solutions to these problems. Within the digital application platform architecture, this is the responsibility of the external data validation module 21, located within the data validation module group 12. The criteria used to validate data items and the actions to be taken when handling invalid data items are also soft-coded within the digital application metafile 14. This eliminates the need for extensive custom code typically required in hard-coded digital applications to ensure data integrity.

[0039] The data manager 17 is also responsible for transmitting the results of the digital application to the appropriate external data server 18. For example, in the real-time optimization example described above, the optimal control setpoints determined using the calculation modules 13a, 13b, ..., 13n need to be sent to the facility control system. Ensuring the integrity of such results is particularly important in the case of digital applications operating in closed-loop mode. A separate result validation module 22, also provided within the validation module group 12, is responsible for performing a set of final validity checks on the results generated by the calculation modules 13a, 13b, ..., 13n. This serves as a final safeguard against any errors caused by unexpected flaws during the early stages of input data validation and model-based calculations. The rules and criteria for this validation are also soft-coded into the digital application metafile.

[0040] Given the complexity of most digital applications, it is also necessary to monitor their execution and take appropriate action in real time if it deviates from expected performance. This is accomplished by the execution monitoring module 23. Furthermore, an archiver module 24, located within the application management module group 11 along with the execution monitoring module 23, maintains a record of performance to enable later troubleshooting of any problems that may arise during the operation of the digital application. The archiver module is adapted to monitor the execution of the digital application in real time and take appropriate action if it deviates from expected performance or ceases execution altogether. The archiver module 24 generates and stores a separate execution archive 27 that records the execution of each instance of the computation modules 13a, 13b, ..., 13n in a level of detail that enables offline analysis and troubleshooting by qualified engineers at a later stage.

[0041] Figure 3 is a flowchart illustrating a method for using a digital application platform architecture according to an embodiment of the present invention. Method 300 begins at step 302, where data manager 17 retrieves data required to determine the next scheduled calculation (e.g., a flag set manually by an operator of the industrial facility or automatically by other parts of the facility's IT / automation system to request that certain actions occur) from an external data server 18, and external data validation module 21 validates this data. By combining this data with information in the digital application metafile 14, scheduler module 15 determines, in step 304, the subset of calculation modules 13a, 13b, ..., 13n that need to be executed next ("scheduled calculation modules"). In some cases, these scheduled calculation modules may actually include multiple instances of the same calculation module. This is the case, for example, when the same calculation needs to be applied to multiple identical facility items or chains within the industrial facility.

[0042] The execution of the scheduled computation modules begins at step 306, where the resource manager 16 allocates appropriate computational resources to each of them. Steps 308-322, described below, are performed for each of the scheduled computation modules determined by the scheduler 15. These steps can be performed sequentially or in parallel, and their outputs can be used to determine further scheduling decisions. This information is part of the soft-coded instructions in the metafile 14.

[0043] Step 308 obtains all data required by the scheduled computation modules by transferring data already obtained from the external data server 18 in step 302 and / or by reading additional such data from the external data server. All such raw input data is passed by the data manager 17 to the external data validation module 21, which validates the raw data using the rules and standards soft-coded in the digital application metafile 14 in step 310. In step 312, the validated data is passed to the scheduled computation modules to enable their execution in step 314. In step 316, the raw results from the scheduled computation modules are passed to the result validation module 22, which validates the results based on the rules and standards soft-coded in the digital application metafile 14 in step 318. In step 320, the validated results are transmitted back to the data manager 17, which sends them to the external data server 18 in step 322. In step 324, the archiver module 24 creates an execution archive 27 containing a complete record of the execution of each scheduled computation module. The application then waits for the scheduler 15 to determine the next set of computation modules 13a, 13b...13n to be executed; this may be done at a fixed scheduling frequency, as a result of an event (eg a flag being written), or preferably as a combination of both.

[0044] Figure 3 The method outlined in relies on information defined in a digital application metafile 14. In this example, the digital application metafile 14 is in XML format and includes metadata generated from the attributes of the variables associated with the facility model 19 used as the basis for the calculation modules 13a, 13b...13n. The digital application metafile 14 stores data in a structured file format. This can be XML, JSON or other suitable structured file format. This is in Figure 4 As further described in FIG, which is a flow chart of a method for generating a digital application metafile according to an embodiment of the present invention. The method 400 begins at step 402, wherein a set of computational modules executable by the digital application is identified. Figure 1In the real-time optimization example of , this would include a steady-state detection module, a steady-state data coordination module, and a steady-state optimization module. In step 404, conditions for executing one or more instances of the computational module are defined in terms of data received from an external data server and / or data to be generated by the execution of other computational modules. Next, in step 406, variable categories are defined that the digital application uses to perform computational tasks. In step 408, attributes associated with each defined variable category are defined. In step 410, based on the defined attributes, criteria for external data validation, result validation, computational resource allocation, and execution scheduling are determined. Finally, in step 412, the defined variable categories and their associated attributes, as well as the criteria for external data validation, result validation, computational resource allocation, and execution scheduling associated with the digital application, are stored as metadata within the digital application metafile.

[0045] Figure 5 A high-level view of an example digital application metafile for a nonlinear model predictive controller (NLMPC) digital application is provided and is created in XML format. Lines 51 to 351 list the parameters (" <globalparameters>”), and then lists the data consistency rules from lines 352 to 396 (" <consistencyrules>”).

[0046] Figure 5 Lines 397 to 1505 of the digital application metafile example in specify the five variable categories considered by the digital application:

[0047] Measured variables (MEA);

[0048] Manipulated variables (MVs);

[0049] Control variables (CVs);

[0050] Disturbance variable (DV);

[0051] Reporting variables (RV).

[0052] The digital application metafile also defines a set of related information items ("attributes") associated with each variable category. Table 1 shows a list of possible attributes for the five variable categories listed above:

[0053] Table 1: Variable categories and associated attributes defined in the example numerical application metafile for nonlinear model predictive control

[0054] It should be noted that a variable can belong to more than one category simultaneously, subject to compatibility rules, so membership in one category may require or exclude membership in another. For example, in the NLMPC example considered here, membership in category MV also requires membership in category MEA, but excludes membership in categories CV or DV. This is further illustrated in Table 2 below, which shows the category compatibility matrix specified in the digital application metafile 14:

[0055]

[0056] Table 2: Compatibility legend for variable categories used for nonlinear model predictive control: Essential, Allowed, ×: Not allowed

[0057] During the runtime of a digital application, values for certain variable attributes may be received from an external data server. The external data validation module 21 automatically performs a set of basic validity tests on these data values. For example, in the NLMPC application example considered here, a measurement value for a variable in the "Measured Variables" category will typically be requested from the distributed control system (DCS) of an industrial facility. The external data validation module 21 will then check whether the value is indeed already available and is of the expected type (e.g., real number, integer, logical class, or enumerated string); and if so, further check whether the value and the rate of change of the value relative to the previously acquired value are within certain lower and upper limits. These limits are specified for each individual variable within the deployment configuration data 20, either explicitly or indirectly through reference to other data also obtained from the external data server. The deployment configuration data 20 also specifies the action to be taken if an external data item is deemed unavailable or invalid. For example, an invalid value can be replaced with a valid value of the same data item if it is sufficiently recent, or an invalid value can be made valid by clamping it to the nearest lower or upper limit.

[0058] The basic validity tests described above are automatically performed in all cases. In addition, the digital application metafile can specify more complex validation criteria for external data, including rules that can be used to check the mutual consistency of multiple data items. This corresponds to Figure 5 These rules can refer to the value, specification status, or validity status of any variable attribute. Table 3 below shows an example of a rule used by the external data validation module to determine whether the values of the three quantities mentioned in the lower right cell are consistent with each other:

[0059]

[0060] Table 3: Example of consistency rules defined in a digital application metafile for external data validation

[0061] Figure 5 Lines 1532 to 1938 of the example numerical application metafile specify the computational modules for the numerical application, which in the case of NLMPC are Cold Start Initialization (CSI), Warm Start Estimation (WSE), and Optimization and Prediction (OP).

[0062] Finally, lines 1869 to 1928 specify the rules used by the scheduler module 15 to determine the scheduling that the above-mentioned computing modules should perform. Figure 6 One such schedule is shown in FIG. This is a flow chart illustrating an example execution cycle for a digital application of NLMPC. The precise schedule to be executed is determined by the execution cycle mode, an externally acquired flag typically set manually by the facility operator via the facility's distributed control system (DCS). Two possible modes are available: a "cold start" mode and a "hot start" mode. An execution cycle 600 begins at step 602, where the execution cycle mode is obtained from an external data server 18 (typically a DCS). At step 604, the schedule for the next execution cycle is determined based on the selected mode. For the "cold start" mode, a cold start initialization involving steady-state coordination of the facility data is performed at step 606; this is followed by the main optimization and prediction calculations at step 608. For the "hot start" mode, a dynamic state estimation calculation is used at step 610 to determine the current state of the facility and estimate any unmeasured disturbances; this is followed by optimization and prediction at step 612. For both modes, a wait for the next scheduled action occurs at step 614 until the scheduled execution cycle length is reached, at which point the process returns to step 604, where the execution cycle schedule is determined.

[0063] The digital application platform architecture 10 described herein will have the same application management 11 and data validation 12 elements for each category of digital application 13 implemented. However, the digital application metafile 14 and the set 13 of computational modules 13a, 13b…13n are specific to each category of digital application implemented. For example, the digital application metafile 14 and the set 13 of computational modules 13a, 13b…13n used for real-time optimization will differ from those used for nonlinear model predictive control, etc. The overall behavior of the digital application is completely defined by the soft-coded data in the digital application metafile 14. Therefore, the digital application platform architecture 10 allows for a "plug-and-play" approach, whereby a unique, specific digital application metafile 14 and the set 13 of computational modules 13a, 13b…13n can be developed offline for each category of digital application to be implemented and then used in conjunction with the application management 11 and data validation 12 elements. Furthermore, most computational modules 13a, 13b...13n required for typical classes of numerical applications can themselves be standardized, since they correspond to a small number of standard forms of model-based computations, such as steady-state or dynamic simulation or optimization, and state estimation or parameter estimation.

[0064] In short, this significantly reduces or eliminates the need for custom computer code, which facilitates the development of new types of digital applications and the maintenance of existing categories of digital applications. Therefore, any improvement in the functionality of the digital application platform architecture 10 will be immediately reflected in all categories of digital applications built on and implemented by it.< / consistencyrules> < / globalparameters>

Claims

1. A digital application platform architecture for implementing a class of digital applications within an industrial facility operations decision support system, the digital application platform architecture comprising: a set of computational modules adapted to perform model-based computations related to the facility; a scheduler module, the scheduler module being adapted to schedule the execution of the computation module; a resource manager module adapted to allocate computing resources to enable execution of the computing module; a data manager adapted to communicate with an external data server providing facility-related data and facility control; a data verification module adapted to verify data received from the external data server and to verify results calculated by the set of calculation modules; as well as a digital application metafile accessible to all components of the digital application, the digital application metafile comprising soft-coded data that manages the scheduling of the execution and the exchange of data between the computational modules; wherein the set of computing modules and the digital application metafile are specific to the class of digital applications implemented; and wherein the soft-coded data defines information related to the class of digital applications in terms of categories of variables required in a model used by the computing modules and attributes associated with each category.

2. The digital application platform architecture according to claim 1, wherein: The data verification module includes: an external data validation module adapted to validate data obtained from the external data server using criteria soft-coded in the digital application metafile; and A result verification module is adapted to verify a result from each of the set of calculation modules using criteria soft-coded in the digital application metafile.

3. The digital application platform architecture according to claim 1 or 2 further comprises an execution monitoring module, which is adapted to monitor the execution of the digital application in real time and take appropriate action if the digital application deviates from expected performance or stops executing altogether.

4. The digital application platform architecture according to any one of claims 1 to 3 further comprises an archiver module adapted to maintain a record of the performance of the digital application, the record comprising the execution of each instance of each computing module.

5. The digital application platform architecture according to any one of the preceding claims, wherein: One or more instances of each computation module are asynchronously executed in parallel, with the occurrence, timing, and frequency of execution of these instances determined based on scheduling rules soft-coded in the digital application metafile.

6. A digital application platform architecture according to any one of the preceding claims, wherein: The data manager is adapted to communicate using a plurality of data exchange protocols.

7. A digital application platform architecture according to any one of the preceding claims, wherein: Communication with each external data server is accomplished via a data client conforming to a standardized software interface, wherein the data manager and the external data servers are configured to implement industry standard or proprietary communication protocols.

8. The digital application platform architecture of any preceding claim, further comprising input to the set of computational modules from one or more system models describing the behavior of the industrial facility.

9. The digital application platform architecture according to claim 7, wherein: One or more computation modules within a group of computation modules perform different types of computations, each using a different system model.

10. The digital application platform architecture according to any one of the preceding claims, wherein: The metadata is stored in the digital application metafile in a structured file format.

11. A computer-implemented method for generating a digital application metafile for use in a digital application platform architecture according to any one of claims 1 to 9, the method comprising the following steps: a) identifying a set of computational modules that can be executed by the digital application; b) defining conditions for executing one or more instances of a computing module based on data received from an external data server and / or data generated by the execution of other computing modules; c) defining a class of variables used by the digital application to perform computing tasks; d) define compatibility rules between variable categories; e) determining the attributes associated with each variable category defined; f) determining criteria for external data validation, result validation, computing resource allocation, and execution scheduling based on the determined attributes; as well as g) Storing the defined variable categories and their associated attributes, as well as standards for external data validation, result validation, computing resource allocation, and execution scheduling as metadata associated with the digital application in the digital application metafile.

12. The computer-implemented method of claim 11 , further comprising: defining industrial facility parameters, data validation consistency rules, rules governing communication between computing modules, and rules governing execution scheduling for a scheduler module; as well as Stored in the digital application metafile.

13. The computer-implemented method of claim 11 or 12, wherein: The metadata is stored in the digital application metafile in a structured file format.

Images