Distributed Industrial Performance Monitoring and Analysis

Abstract

To provide a distributed industrial process monitoring and analysis system and a method.SOLUTION: A plurality of distributed data engines (DDEs) is embedded in a process plant to be able to collect and store data generated by a data source such as a process controller. Then, the data can be stored in a distributed mode in the DDEs embedded over the entire process plant. The DDEs are connected by a data analysis network to be able to easily transmit the data by subscription or a query. A DDE may be constituted as a plurality of clusters, and further, they can include a local cluster and a centralized cluster. The local cluster acquires streaming data from the data source, and can stream selected data to a data consumer. The centralized cluster can register the local cluster, receive data therefrom, and execute a data analysis function for the received data.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates generally to process plants and process control systems, and more particularly to real-time performance monitoring and analysis of real-time data generated by process plants and process control systems.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 32 / 239,620, entitled "DISTRIBUTED INDUSTRIAL PERFORMANCE MONITORING AND ANALYTICS," filed October 9, 2015, the entire contents of which are hereby expressly incorporated herein by reference. This application is a continuation of (i) U.S. Provisional Application No. 32 / 239,620, entitled "BIG DATA IN PROCESS CONTROL," filed March 4, 2013. (ii) U.S. application Ser. No. 13 / 784,041 entitled "COLLECTING AND DELIVERING DATA TO A BIG DATA MACHINE IN A PROCESS CONTROL SYSTEM," filed February 6, 2014; (iii) U.S. application Ser. No. 14 / 456,763 entitled "SECURING DEVICES TO PROCESS CONTROL SYSTEMS," filed August 11, 2014; (iv) U.S. application Ser. No. 14 / 216,823 entitled "DATA MODELING STUDIO," filed March 17, 2014; (v) U.S. application Ser. No. 14 / 216,823 entitled "MANAGING BIG DATA IN PROCESS CONTROL SYSTEMS," filed January 31, 2014. (vi) U.S. application Ser. No. 14 / 169,965, entitled "DETERMINING ASSOCIATIONS AND ALIGNMENTS OF PROCESS ELEMENTS AND MEASUREMENTS IN A PROCESS," filed March 14, 2014; (vii) U.S. application Ser. No. 14 / 212,411, entitled "DISTRIBUTED BIG DATA IN A PROCESS CONTROL SYSTEM," filed March 14, 2014; (viii) U.S. application Ser. No. 14 / 212,493, entitled "STREAMING DATA FOR ANALYTICS IN A PROCESS," filed October 6, 2014; (ix) U.S. application Ser. No. 14 / 506,863, entitled "REGIONAL BIG DATA IN PROCESS CONTROL SYSTEMS," filed October 6, 2014; (x) U.S. application Ser. No. 62 / 060,408, entitled "DATA PIPELINE FOR PROCESS CONTROL SYSTEM ANALYTICS," filed October 6, 2014; and (xi) U.S. application Ser. No. 14 / 507,252, entitled "AUTOMATIC SIGNAL PROCESSING-BASED LEARNING IN A PROCESS PLANT," filed October 6, 2014, the entire disclosures of which are hereby expressly incorporated herein by reference. [Background technology]

[0003] Distributed process control systems, such as those used in chemical, petroleum, industrial, or other process plants for manufacturing, refining, transforming, creating, or producing physical substances or products, typically include one or more process controllers communicatively coupled to one or more field devices via an analog bus, a digital bus, or a combined analog / digital bus, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature sensors, pressure sensors, level sensors, and flow sensors), control the process environment. Smart field devices, located within a plant environment, typically perform physical or process control functions, such as opening or closing valves and measuring process and / or environmental parameters, such as temperature or pressure, to control one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically implemented within a controller. A process controller, also typically located within a plant environment, executes a controller application that executes different control modules that receive signals indicative of process measurements made by and / or other information related to the field devices, make process control decisions, generate control signals based on the received information, and interface with control modules or blocks running on the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules within the controller send control signals over communication lines or links to the field devices, thereby controlling the operation of at least a portion of the process plant, e.g., controlling at least a portion of one or more industrial processes running or being performed within the plant. For example, the controller and field devices control at least a portion of a process being controlled by a process control system of the process plant.

[0004] Information from field devices and controllers is usually made available over a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized computing devices, which are typically located in a control room or other location away from the more austere plant environment. Each of these hardware devices is typically centralized throughout the process plant or throughout a portion of the process plant. These hardware devices execute applications that may enable operators to perform functions related to the control of the process and / or operation of the process plant, such as, for example, changing settings on process control routines, modifying the operation of control modules in controllers or field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of a process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0005] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different equipment located at various locations within a process plant. Configuration applications residing in one or more workstations or computing devices allow users to create or modify process control modules and download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs to the function blocks and provide outputs to other function blocks in the control scheme. The configuration application may also allow a configuration designer to create or modify operator interfaces that display data to an operator and allow the operator to change settings, such as setpoints, within a process control routine. Each dedicated controller, and in some cases, one or more field devices, are assigned and downloaded to implement the actual process control functions. The configuration database application may run on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway) and may receive data from the controller applications via the data highway and display this data to a process control system designer, operator, or user using a user interface to provide one of several different views, such as an operator's view, an engineer's view, or a technician's view. While the data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided over the data highway, the configuration database application may run on a more remote computer connected to the data highway to store the current process control routine configuration and its associated data. Alternatively, the configuration database may be located in the same workstation as the configuration application.

[0006] When evidence of an abnormal condition or failure is found in a process plant or process control system (e.g., when an alarm occurs or when a process measurement or actuator is found to have excessive variation), an operator, instrument technician, or process engineer, along with his or her knowledge of the system and the process controlled by the process flow path through the system, typically uses analytical tools to attempt to determine upstream measurements and process variables that may have contributed to creating the abnormal condition or evidence of failure. For example, an operator may feed historical logs of data captured over time from the outputs of process control devices (e.g., field devices, controllers, etc.) into a DeltaV™ batch analysis product or continuous data analysis tool to attempt to determine the contribution of various process variables and / or measurements to the abnormal or fault condition. Typically, a user determines which historical data logs and / or other time series data to feed into the analytical tool and, based on their knowledge of the process, identifies candidate upstream factors (e.g., measurements, process variables, etc.). These data analysis tools then utilize principal component analysis (PCA) or other analytical techniques such as partial least squares, linear regression, etc. to determine which candidate upstream factors are influencing the downstream predicted quality parameters. Therefore, the accuracy and validity of the output provided by the analysis tools is based on, or limited by, the user's knowledge and therefore may not provide complete or accurate insight into the source of the abnormal condition or failure.

[0007] Additionally, such analyses are typically performed offline from the process, and therefore, the process may change or move while the analysis is being performed. For example, a typical process plant usually performs a particular analytical cycle (e.g., a data collection and analysis cycle) once or twice a day, but the results are analyzed and any prescriptive actions are developed and implemented within the plant only some time after the analysis is performed. Thus, not only may the accuracy of the analytical results be questionable, but any prescriptive actions developed therefrom may not be optimal or may no longer apply to the currently running process.

[0008] Additionally, currently known process control plant and process control system architectures are strongly influenced by limited controller and device memory, communication bandwidth, and processor capabilities of the controllers and devices. For example, in currently known process control system architectures, the use of dynamic and static non-volatile memory in the controllers is typically minimized, or at least carefully managed. As a result, during system configuration (e.g., a priori), users typically The controller must select which data in the controller should be archived or stored, how often it should be stored, and whether compression should be used, and the controller is configured accordingly with this limited set of data rules. As a result, data that could be useful in troubleshooting and process analysis is often not archived, and when it is collected, useful information may have been lost due to data compression.

[0009] Furthermore, industrial or process control plant data sets continue to grow in size to the point where current data processing analytical applications are insufficient. Typically, known analytical techniques merely attempt to extract value from the data, but do not address the specific size of the data set from which the value is extracted, and in particular do not operate seamlessly on very large data sets (such as all the process data generated by the plant). Furthermore, known analytical techniques typically cannot handle streaming or streamed data.

[0010] The limitations of currently known process plant monitoring and analysis, and process control systems discussed above, as well as other limitations, can manifest themselves in undesirable ways in the operation and optimization of a process plant or process control system, for example, during plant operation, troubleshooting, and / or predictive modeling. Generally, real-time analysis using real-time, current industrial process performance data is not possible with known monitoring and analysis tools. Summary of the Invention

[0011] Disclosed herein are techniques, systems, devices, components, and methods for distributed industrial process performance monitoring and / or analysis. Such techniques, systems, devices, components, and methods may be applied to industrial process control systems, environments, and / or plants, which are also referred to interchangeably herein as “automation,” “industrial control,” “process control,” or “process” systems, environments, and / or plants. Typically, such systems and plants provide control of one or more processes that operate to manufacture, refine, transform, create, or produce physical substances or products in a distributed manner. Generally, the techniques, systems, devices, components, and methods involve embedding, in a distributed manner, a data monitoring and / or data analysis engine (also referred to interchangeably herein as a “distributed data engine,” “data engine,” or “DDE”) within devices that operate in concert to control an industrial process. For example, a distributed data engine may be fabricated within a device (e.g., a process control device, such as a field device, controller, I / O card, etc.) that operates with other devices to control processes running within a process plant or process control system, and / or the distributed data engine may be locally or directly coupled to such a device. Additional data engines may be embedded in or fabricated within other devices included within the process plant, such as in communication nodes, workstations, or other operator interfaces, servers, etc. In some configurations, the data engine is connected to various communication links within the process plant or otherwise connected to the process plant to have a view or window into real-time data transmitted during the execution or control of processes within the plant.

[0012] Data is streamed between the various embedded data engines, for example, using one or more data communication channels and networks that typically exist outside of the traditional communication systems found in distributed control systems (DCS), programmable logic systems (PLS), and process control health and safety monitoring systems (SHM). To avoid confusion with such conventionally known process control communication networks and links, Communication channels and networks utilized to stream communications between data engines are referred to interchangeably herein as “data analytics communication channels,” “data analytics channels,” “data analytics communication networks,” or “data analytics networks.” Streamed data may include real-time data viewed or observed by the data engines. For example, if a distributed data engine is connected to (and therefore views) traversing data over a traditional process control system communication link, the data engine may stream a copy of the data traversing the traditional communication link to one or more other data engines via the data analytics network. In another example, if a distributed data engine is manufactured within or embedded in a process control device, analytical data streamed by the data engine using the data analytics network may include a copy of data received, generated, or otherwise processed by the device. Additionally or alternatively, the streamed data may include data corresponding to one or more analyses performed locally at the device, such as analysis results, prescriptive actions, etc. This architecture allows analytical services to be locally bound and provided near or at the data source, while simultaneously enabling the provision of larger scale analytics, thereby providing timely results and optimizations while minimizing bandwidth usage and system-wide processing cycles, as described in more detail below.

[0013] In one aspect, a distributed industrial process monitoring and analysis system includes a plurality of distributed data engines (DDEs) embedded within a process plant operating to control a process. Each of the DDEs is coupled to one or more respective data sources within the process plant, each generating data as a result of the process being controlled. Additionally, each of the DDEs stores data generated by the respective one or more data sources to which the DDE is coupled. The system also includes a data analysis network that supports streaming of analytical data between the plurality of DDEs and supports sending queries regarding data stored in the plurality of DDEs.

[0014] In another aspect, a method includes advertising the presence of a cluster within a data analytics network of a process control plant operating to control a process. The method also includes registering a data source responsive to the advertising that generates continuous data resulting from the plant's control of the process. Additionally, the method includes receiving the continuous data generated by the data source and streaming at least a portion of the continuous data generated by the data source to a data consumer via the data analytics network. One or more portions of the method may be performed by the cluster, for example.

[0015] In yet another aspect, a method includes advertising the presence of a centralized cluster included in a data analytics network of a process control plant operating to control a process. The method also includes registering a local cluster responsive to the advertising and configured to store streamed continuous data generated as a result of controlling the process. The local cluster is embedded within the process plant and communicatively coupled to one or more data sources that generate at least a portion of the continuous data while operating to control the process. Additionally, the method may include receiving at least a portion of the streamed continuous data from the local cluster, performing one or more data analytics functions on the streamed continuous data received from the local cluster, and streaming output of the one or more data analytics functions to a data consumer via the data analytics network. One or more portions of the method may be performed, for example, by the centralized cluster.

[0016] In another aspect, the system includes a data analysis module bound to a continuous data stream, the continuous data stream having content generated in real time by a data source included in a process plant operating to control a process, the content of the continuous data stream being generated as a result of operations controlling the process. The system further includes a user interface that displays continuous output generated in real time from the data analysis module operating in real time on the continuous data stream. The continuous output displayed on the user interface includes continuous updates of one or more forecast values.

[0017] In yet another aspect, a performance monitoring and analysis system for industrial process control includes a platform that provides a set of user controls and a canvas that enables a user to create data diagrams that represent a data model. The platform further enables a user to evaluate or compile the data diagrams and run them against an input data set to thereby generate output data. The input data set includes time series data (and optionally other data) obtained from an online process plant that controls the process. As used herein, the term "time series data" generally refers to a series of data points, values, or sets, typically generated by one or more data sources over a time interval.

[0018] A data diagram includes a set of data blocks interconnected by a set of wires, through which data is transferred between the data blocks. Each data block in the set of data blocks corresponds to a respective data operation and includes zero, one, or more input connectors and zero, one, or more output connectors. Respective input data is received by each data block through the input connector(s), and each data block provides respective output data through the output connector(s) resulting from each data block performing its respective data operation on the respective input data. Furthermore, the input connector is included in a first data block in the set of data blocks, and each data operation of at least one data block in the set of data blocks includes a data analysis function, and different portions of the data diagram are asynchronously and independently compilable and executable. In some embodiments, for example, if no input connector is configured and no output connector is configured, the input data and output data are processed internally by the data block.

[0019] In one aspect, a method for performing real-time analysis in a process control environment includes creating a first diagram in a graphical user interface. The first diagram may represent first programming instructions operable to cause a processor to manipulate data previously generated and stored by the process control environment. The method also includes compiling the first programming instructions represented by the first diagram, executing the compiled first programming instructions to create a resulting first output, and evaluating the resulting first output to determine a predicted value of a model used to create the resulting first output. Additionally, the method includes automatically generating a second diagram from the first diagram. The second diagram may represent second programming instructions operable to cause the processor to bind to a live data source and evaluate data received from the live data source by using at least the model used to create the resulting first output. The method further includes compiling second programming instructions represented by the second diagram and executing the compiled second programming instructions to predict an aspect of operation of the process control environment.

[0020] In another aspect, a system for performing real-time analytics in a process control environment includes a plurality of process control devices operating within a process plant and a controller communicatively coupled to the plurality of process devices via a control network. The system also includes a big data storage node having a tangible, non-transitory storage medium that stores data of operation of the process control environment, a processor communicatively coupled to the big data storage node, and a program memory communicatively coupled to the processor. The program memory may include the tangible, non-transitory storage medium storing instructions that, when executed by the processor, cause the processor to display a graphical user interface including an editing canvas and receive a selection of a plurality of graphical programming elements for placement on the editing canvas to create a first diagram. The first diagram may represent first programming instructions operable to cause the processor to manipulate data stored in the big data storage node. Additionally, the instructions, when executed by the processor, cause the processor to execute the compiled first programming instructions to create a resultant first output and to create a predictive model based on the resultant first output. The instructions, when executed by a processor, may further cause the processor to automatically generate a second diagram from the first diagram. The second diagram may represent second programming instructions operable to bind to a live data source and evaluate data received from the live data source by using at least the model used to create the resulting first output. The instructions, when executed by a processor, may still further cause the processor to compile the second programming instructions represented by the second diagram and execute the compiled second programming instructions to predict aspects of operation of the process control environment.

[0021] In another aspect, an analytical service for performing data analysis in a process control environment includes a library of block definitions. The library can be stored on a tangible, non-transitory medium, and each block definition stored in the library can include (i) a target algorithm for performing an action on data in the process control environment and (ii) one or more block properties. The analytical service further includes a set of machine-readable instructions stored on the tangible, non-transitory medium, which, when executed by a processor, is operable to: (1) present a canvas to a user via a display; (2) present the library of block definitions to a user; (3) receive one or more selections of one or more corresponding block definitions; (4) place one or more blocks corresponding to the one or more block definitions on the canvas to create a module including the one or more blocks; (5) facilitate configuration of one or more properties for either (i) one or more blocks, or (ii) modules, or (iii) one or more blocks and modules; and (6) provide an evaluation of one or more of (i) the blocks, or (ii) the modules.

[0022] Additionally, the analytical service includes an execution service running on the processor, where the execution service is configured to (1) receive a request to evaluate one or more blocks or modules, (2) compile instructions corresponding to the one or more blocks or modules, (3) create one or more job processes to execute the compiled instructions and cause the one or more job processes to execute the compiled instructions, and (4) receive results of the one or more job processes. The analytical service also includes a communications network coupling the one or more processors executing the one or more job processes with one or more distributed data engines. Each distributed data engine may include a tangible, non-transitory storage medium that stores data generated within the process control environment.

[0023] In practice, data generated by or related to the operation of a process plant may be stored in multiple data stores, such as relational or non-relational databases. These data stores may utilize various data structures and query mechanisms, thereby requiring different query syntaxes to access data in different data stores. Standardized queries are described herein to facilitate data access to data stores using various formats. While the standardized queries, utilizing a standardized data query format, contain information needed to access data in the data stores, the standardized queries may not be directly executable to obtain such data. Instead, data source-specific queries are generated based on the standardized queries. This may include extracting query parameters from the standardized queries and generating one or more data source-specific queries utilizing data source-specific query formats associated with the particular data sources. The data source-specific queries can be executed to access and select data from their respective data sources, which can then be formatted to generate a data frame presenting the data indicated in the standardized queries in any desired format. This may include matching sampling rates, data properties, or other data characteristics for data obtained by data source-specific queries. In some embodiments, data from multiple data sources utilizing different data source-specific query formats can be combined into an aggregate data frame for further use in process control or analysis.

[0024] In another aspect, methods, systems, and computer-readable media storing instructions for acquiring time-series data from electronic data sources are described, including receiving an indication of an electronic data source from which data is to be acquired, receiving an indication of a time range over which the data will be acquired, receiving an indication of characteristics of the data to be acquired, determining a data-source-specific query format associated with the electronic data source, generating a data-source-specific query according to the data-source-specific format based on the indications of the time range and characteristics of the data to be acquired, executing the data-source-specific query to select data from the electronic data source, and / or receiving data from the electronic data source. The indications of the time range and characteristics of the data may be expressed in a standardized query format that is independent of the electronic data source, and the electronic data source may be a relational or non-relational database.

[0025] The method may include a standardized query utilizing a standardized query format. An indication of a time range and an indication of a characteristic may be received as the standardized query. An indication of an electronic data source may also be received as the standardized query. The standardized query may further indicate a format for the data or file to return data, such as JavaScript Object Notation (JSON). The standardized query may also be a JSON-formatted file. The standardized query format may utilize a syntax that is distinct from the native syntax utilized by the electronic data source. Such syntax utilized in the standardized query format may not be directly executable to obtain data from the electronic data source.

[0026] The indication of the time range may include at least one start time and at least one end time. The indication of the time range may also include a sample rate for the data to be acquired. The indication of the characteristics of the data to be acquired may include an indication of one or more measurements related to the operation of the process plant. The one or more measurements may include measurements from one or more field devices located within the process plant. The indication of the one or more measurements may include one or more tags, aliases, and data types associated with the data. do.

[0027] The method may further include receiving an indication of a format in which the data is to be received from the electronic data source, wherein the data may be received from the electronic data source in the indicated format. In some embodiments, an indication of a format in which the data is to be obtained may be received and the data received from the electronic data source may be converted to the indicated format.

[0028] The data source-specific query format may be determined based on the type of electronic data source. Generating the data source-specific query may include mapping the indicated time range and the indicated characteristics of the data to be acquired to the data source-specific query format. Executing the data source-specific query may include sending the data source-specific query to an interface of the electronic data source, whereby the interface queries the electronic data source with the data source-specific query.

[0029] A data frame may be generated that includes data received from an electronic data source. The data frame may include a plurality of data points. Each data point may be associated with a time within a time range. Each data point may further be associated with a time within the time range that is aligned with an integer multiple of a sample period after a start time or is the start time.

[0030] In another aspect, methods, systems, and computer-readable media storing instructions for providing data from electronic data sources are described, including receiving a standardized query using a standardized query format from a data requesting entity, extracting query parameters from the standardized query, generating a data source-specific query in a data source-specific query format based on the extracted query parameters, executing the data source-specific query to obtain data from the electronic data source, and / or providing the obtained data to a data receiving entity. The standardized query format may be different from the data source-specific query format utilized by the electronic data source. The electronic data source may be a relational or non-relational database. The data requesting entity may be a query block within an analytics program, such as Data Analytics Studio, discussed herein. The data receiving entity may be the same entity as the data requesting entity. The standardized query may utilize syntax that is not directly executable to obtain data from the electronic data source.

[0031] Extracting query parameters from the standardized query may include determining a time period of data and data parameters, where the time period may have a start time and an end time, and the data parameters may indicate a type or characteristic of data to be acquired from the electronic data source. Extracting query parameters from the standardized query may further include determining a sampling rate.

[0032] Providing the acquired data to the requesting entity may include returning a set of data points associated with the time period. Each data point may include a timestamp indicating the time for the value(s) associated with the data point. Such timestamps may be limited to times that are the start time or integer multiples of the sampling rate period after the start time. To achieve a complete time series, one or more data points may be added to the dataset with timestamps indicating integer multiples of the sampling rate period after the start time. The added data points may include values ​​of data entries in the electronic data source associated with the time most immediately preceding each timestamp of the one or more added data points. The set of data points may be formatted based on the format specified in the standardized query.

[0033] The type or characteristic of data indicated by the data parameter may be a type of measurement or a measurement value from a type of measurement device. The type or characteristic of data may further indicate a specific measurement device, which may be a field device located within a process plant. The data parameter may further indicate a tag of the data to be acquired, an alias of the data to be provided to the data requesting entity, and / or a data format type of the data to be provided to the data requesting entity.

[0034] Providing the data to the data requesting entity may include sending a data frame including the acquired data to the data requesting entity. The standardized query may include an indication of a format for the data frame. The data frame may be formatted according to the indication of the format for the data frame. The standardized query may indicate that the data frame is to be provided to the data receiving entity as a JSON file.

[0035] In another aspect, methods, systems, and computer-readable media storing instructions for accessing process plant data from multiple electronic data sources are described, including receiving a standardized query utilizing a standardized query format, generating a query specific to a first data source based on the standardized query, generating a query specific to a second data source based on the standardized query, executing the query specific to the first data source to obtain a first set of data from the first electronic data source, executing the query specific to the second data source to obtain a second set of data from the second electronic data source, and / or generating an aggregate data frame including the first and second sets of data, wherein the first and second sets of data may each include a plurality of data points including information measured by one or more field devices within the process plant.

[0036] A query specific to a first data source may utilize a first query format associated with the first electronic data source, and a query specific to a second data source may utilize a second query format associated with the second electronic data source. The standardized query may include a first index of the first electronic data source and a second index of the second electronic data source. In some embodiments, the first electronic data source may be a relational database and the second electronic data source may be a non-relational database. The first index may identify the first query format and the second index may identify the second query format. In some embodiments, the first and second indexes may be prepended to the data string index.

[0037] The standardized query format may utilize a query syntax that is distinct from both the query syntax of the first query format and the query syntax of the second query format. The query syntax of the standardized query format may not be directly executable to obtain either the first set of data from the first electronic data source or the second set of data from the second electronic data source. For example, the standardized query may be contained in one or more objects or arrays of a JSON file.

[0038] The standardized query may include a time range indicator that identifies a time period corresponding to data entries in the first and second data sets. The time range may include multiple time periods, which may be separated by exclusion periods during which data is not queried. The time range may also identify a first time period associated with the first data set and a second time period associated with the second data set. The standardized query may also include a time range indicator that identifies a time period corresponding to data entries in the aggregate data frame. It may also include an indication of the sample rate for the

[0039] The first data set may include data having a first sample rate, and the second data set may include data having a second sample rate. In such cases, generating the aggregate data frame may include matching the first and second sample rates. Matching the first and second sample rates may include adding data points corresponding to unsampled time needed to achieve the desired sample rate. Such added data points may be given values ​​of sampled data immediately preceding in time the added data point. Matching the first and second data sample rates may also include removing sampled data points.

[0040] A system for practicing such a method may further include one or more processors communicatively coupled to the one or more data sources, and one or more program memories storing computer-readable instructions that, when executed by the one or more processors, cause the computer system to perform some or all of the system functions described above. A computer-readable medium may store similar computer-readable instructions executable by one or more processors of a computer system, thereby causing the computer system to perform some or all of the system functions described above. Additional or alternative aspects of the present method, system, or computer-readable medium may be practiced as more fully described in the detailed description below.

[0041] Additionally, a novel frequency analysis analysis technique is disclosed and may be provided by any of the systems, methods, apparatus, and techniques described herein. The novel frequency analysis analysis technique can analyze streamed data to provide early warning fault detection in a process plant or process control system. More specifically, the frequency analysis analysis technique can create a new set of process variables corresponding to identified leading indicators of a fault, anomaly, performance degradation, target performance level, undesired condition, and / or desired condition, and perform a rolling FFT on the streamed process data to determine time series data for the new process variables. The rolling FFT can transform the streamed process data from the time domain to the frequency domain, where values ​​for the new set of process variables can be determined. The determined values ​​of the new process variables can be converted back to the time domain for monitoring. Detecting the presence of leading indicators within the monitored time domain data may create and / or indicate the presence of a predicted failure, anomaly, performance degradation, and / or other undesired condition, which may result in changes to the operation of the process plant to avoid, prevent, and / or mitigate the effects of the undesired upset, event, and / or condition. Similarly, detecting the presence of leading indicators within the monitored time domain data may create and / or indicate the presence of a predicted desired condition, such as a target level of performance, in some cases along with the time or time interval during which the desired condition is predicted to occur. [Brief explanation of the drawings]

[0042] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary system process plant or process control system including a distributed, embedded industrial process performance monitoring and / or analysis engine. [Figure 2A] FIG. 1 is a block diagram of an exemplary system for distributed industrial process performance monitoring and analysis. [Figure 2B]1 is an embodiment of an exemplary distributed industrial process performance monitoring and analysis system arrangement in association with an exemplary process control system. [Figure 3] FIG. 1 is a block diagram of an example industrial process performance monitoring and / or analysis engine. [Figure 4A] 1 is an exemplary data diagram illustrating the characteristics and interconnections of various data blocks. [Figure 4B] 1 is an exemplary Data Analytics Studio user interface. [Figure 4C] 1 illustrates exemplary relationships between data block definition libraries, data block definitions, data modules, data blocks, data block instances, and wires. [Figure 4D] An example of a draft or creation of a data module. [Figure 4E] The zoomed-in area of ​​the Data Studio canvas where data modules are created. [Figure 4F] 1 is an exemplary data block definition template for different types of data blocks. [Figure 4G] 1 is an exemplary data block definition template for different types of data blocks. [Figure 4H] 1 is an exemplary data block definition template for different types of data blocks. [Figure 4I] 1 is an exemplary flow for evaluating, editing, or expanding a data diagram. [Figure 4J] 1 is an exemplary architecture that supports the presentation of standard and custom visualizations. [Figure 4K] 1 is an exemplary scenario in which a composite data block is created. [Figure 4L] 1 is an exemplary offline data diagram; [Figure 4M] 4B is an online data diagram generated from a transformation of the example offline data diagram of FIG. 4L. [Figure 4N-1]1 is an exemplary Data Analytics Dashboard user interface. [Figure 4N-2] 1 is an exemplary Data Analytics Dashboard user interface. [Figure 4O] 1 is a high-level block diagram of a control loop for controlling and optimizing the performance of a process plant. [Figure 4P] 1 is an exemplary method for providing localized data analysis services. [Figure 4Q] 1 is an exemplary method for providing localized data analysis services. [Figure 5A] FIG. 2 is a block diagram of an exemplary architecture for an Analytics Service in accordance with the present invention. [Figure 5B] 5B is a block diagram illustrating in more detail an example data service entity of the architecture depicted in FIG. 5A. [Figure 5C] 1 is a flowchart illustrating a method for presenting a properties dialog for a block placed on a programming canvas, according to the presently described embodiment. [Figure 5D] 1 is an exemplary programming canvas in which an exemplary offline diagram is configured on the programming canvas. [Figure 5E] FIG. 5E is an exemplary online diagram corresponding to the offline diagram of FIG. 5D. [Figure 5F] 1 is an example properties dialog for a module. [Figure 5G] 10 is an example properties dialog for a block of an offline module, where the properties pertain to both offline and online operation. [Figure 6A] FIG. 1 is a block diagram of an example analytical query system. [Figure 6B] FIG. 1 is a block diagram of an exemplary analytical configuration using standardized queries. [Figure 6C] 1 is an exemplary standardized query. [Figure 6D]1 is a flow diagram of an exemplary standardized query method. [Figure 6E] 1 is a flow diagram of an exemplary standardized query method. [Figure 7A] 1 is a graph of exemplary process flow measurements for a flare system of a refinery over a time interval. [Figure 7B] 7B is a graph of the example process flow measurements of FIG. 7A during different time intervals. [Figure 7C] 1 is a graph of exemplary process flow data for a refinery, including a flare event in the data. [Figure 7D] 7D is a graph of time series data determined by applying a rolling FFT to the process flow data of FIG. 7C. [Figure 7E] FIG. 7D is a graph of the results of using PCA to analyze the frequency domain data of FIG. 7D around a flare event. [Figure 7F] FIG. 7D is a graph of the results of using PCA to analyze the frequency domain data of FIG. 7D around another flare event. [Figure 7G] 1 is a flow diagram of an exemplary method for providing early fault detection in a process plant. DETAILED DESCRIPTION OF THE INVENTION

[0043] Disclosed herein are techniques, systems, devices, components, and methods for distributed industrial performance monitoring and analysis. Generally, the novel performance monitoring and analysis techniques provide knowledge discovery and actionable knowledge about industrial process plants, process control environments, and / or process control systems that operate to control one or more industrial processes in real time. Typically, the industrial processes performed by such process plants or control systems are controlled in order to manufacture, refine, transform, create, or produce a physical substance or product. Examples of such process plants or control systems include oil refineries, paper mills, chemical manufacturing, pharmaceutical manufacturing, food processing, and distribution, among others.

[0044] The primary concerns of any process control system, plant, or environment are its safety, reliability, and economic viability. Operational safety is particularly important for any process control system or plant because uncontrolled processes, failures, breakdowns, and / or preventable human error can lead to explosions, fires, releases of hazardous chemicals, environmental damage, loss of equipment, and / or loss of life. Reliability of equipment and process operations is important to maintain and / or improve the economics and profitability of the plant. Furthermore, plant economics and profitability can be improved by adjusting plant operations to enhance performance.

[0045] Failures occurring in a process control system can affect its safety, reliability, and / or economic viability. Failures typically occur when multiple events combine to create a situation that the process control system was not designed to handle, such as unknown changes in feedstock composition, equipment degradation, equipment damage, and abnormal (or erroneous) user operational actions. Other examples of failures include unplanned equipment shutdowns, chemical releases to the atmosphere, pressure relief valve lifting, equipment temperature runaways, and performance degradation. Of course, failures are not limited to total or large-scale events; failures can be any abnormal event or combination of events that have or can lead to economic, safety, and / or environmental impacts.

[0046] Typically, when a fault is detected (e.g., automatically by a process control system), an alarm is generated at the operator interface. The operator then attempts to diagnose the root cause of the fault and take corrective action. Therefore, some of the key factors in managing faults are early fault detection and reduction of false alarms. This may include, for example, timely and reliable detection of a fault, diagnosing the root cause of the fault, and taking corrective action to return the instrument, controller, process, and / or equipment that is the source of the fault to normal operation.

[0047] Known data monitoring and analysis tools attempt to keep process plants within their normal operating range and provide a first line of defense against faults. However, such tools typically focus only on a single loop or a very limited scope within the process plant. These tools cannot handle the entirety (or even most of) a typical modern process control plant, where hundreds of thousands of process variables are observed at very high rates. Furthermore, known data monitoring and analysis tools cannot handle special events, such as degraded equipment performance, removed field equipment, or major changes in operating conditions, caused by conditions outside each tool's immediate, limited scope.

[0048] On the other hand, the novel distributed industrial process performance monitoring and analysis techniques, systems, apparatus, components, and methods disclosed herein can handle (e.g., monitor and / or analyze) industrial process monitoring and analysis ranging in size from an entire process plant to a single loop or even a single device. Indeed, in some configurations, the novel techniques disclosed herein can simultaneously address multiple process plants (e.g., multiple refineries owned and operated by a single company or by different companies, if data is available). Generally, the novel performance monitoring and analysis techniques disclosed herein discover and provide knowledge indicative of early detection and / or advance warning of potential failures that may occur within process plants and control systems, thereby allowing sufficient time to take prescriptive or corrective action to prevent the failure from occurring. In some situations, the novel techniques disclosed herein also discover and provide prescriptive, actionable knowledge to prevent potential failures from occurring and / or limit the impact of their occurrence. Additionally, the novel techniques disclosed herein discover or provide knowledge that indicates potential improvements to plant efficiency, as well as actionable knowledge to realize those efficiency improvements.

[0049] Exemplary Process Control System with Distributed Industrial Process Monitoring and Analysis As discussed above, a process plant, process control system, or process control environment that includes or supports at least a portion of the novel distributed industrial process monitoring and analysis techniques described herein operates to control one or more industrial processes in real time. Thus, the process plant or control system may include one or more wired or wireless process control devices, components, or elements therein that perform physical functions (such as opening or closing valves, measuring temperature, pressure, and / or other process and / or environmental parameters) to control processes running within the process plant or system. The process plant or process control system may include, for example, one or more wired communication networks and / or one or more wireless communication networks. The process plant or control system may include centralized databases, such as continuous databases, batch databases, and other types of historian databases.

[0050] 1 is a detailed block diagram of an exemplary process plant or process control environment 5 that includes or supports any or all of the distributed industrial process monitoring and analysis techniques described herein. The process control system 5 includes a plurality of distributed data engines of a distributed industrial process monitoring and analysis system that are included in, integrated with, or supported by the process control plant or environment 5. (A more complete description of distributed industrial process monitoring and analysis systems is provided in a later section.) Each of the distributed data engines of the industrial process monitoring and analysis system The distributed data engine may be directly or indirectly connected (e.g., physically connected or wirelessly connected) to certain components or portions of the plant 5. For example, the distributed data engine may be embedded in or fabricated within a particular device or node of the process plant 5 to form a centralized entity, the data engine may be connected or coupled to a particular device or node of the plant 5, or the data engine may be connected or coupled to a conventional communication link of the plant 5. In FIG. 1, a circled "DDE" represents each exemplary distributed data engine.

[0051] As discussed above, the distributed data engines may be embedded within process control devices whose primary function is to automatically generate and / or receive process control data to perform functions for controlling processes in real time in the process plant environment 5. For example, each data engine may be embedded within or fabricated within a process controller, field device, and I / O device. In the process plant environment 5, the process controller receives signals indicative of process measurements produced by the field devices, processes this information to execute control routines, and generates control signals that are transmitted over conventional wired or wireless process control communication links or networks to other field devices to control the operation of processes within the plant 5. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, increasing or decreasing a temperature, etc.) to control the operation of a process, and some types of field devices communicate with a controller using I / O devices. The process controllers, field devices, and I / O devices may be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices may be included within the process plant environment or system 5, each of which may include a respective distributed data engine.

[0052] 1 illustrates a process controller 11 that is communicatively coupled to wired field devices 15-22 via input / output (I / O) cards 26 and 28, and to wireless field devices 40-46 via a wireless gateway 35 and a process control data highway or backbone 10 (which may include one or more wired and / or wireless communication links and may be implemented using any desired or suitable communication protocol, such as, for example, an Ethernet protocol). In one embodiment, the controller 11 is communicatively coupled to the wireless gateway 35 using one or more communication networks other than the backbone 10, such as by using any number of other wired or wireless communication links supporting one or more communication protocols, such as, for example, Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, cellular communication protocols (e.g., WiMAX, LTE, or other ITU-R compliant protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc. As referred to herein, backbone 10 and these other communication networks are examples of "traditional" process control communication networks.

[0053] The controller 11 may be, by way of example, a DeltaV™ controller sold by Emerson Process Management, but may also be operated to perform a batch or continuous process using at least some of the field devices 15-22 and 40-46. In some embodiments, in addition to being communicatively connected to the process control data highway 10, the controller 11 may also be connected to other devices, such as standard 4-20 mA devices, I / O cards 26, 28, and / or FOUNDATION® Fieldbus protocols, HART (registered trademark), and / or other communication protocols. The controller 11 may also be communicatively coupled to at least some of the field devices 15-22 and 40-46 using any desired hardware and software associated with any smart communication protocol, such as the I / O cards 26 and 28, the I / O cards 26, ...

[0054] The process controller 11 of FIG. 1 includes a processor 30 that executes or oversees one or more process control routines 38 (e.g., stored in memory 32). The processor 30 is configured to communicate with field devices 15-22 and 40-46, as well as other nodes communicatively connected to the controller 11. Note that any control routines or modules (quality prediction and fault detection modules or function blocks) described herein may be implemented or executed in part by different controllers or other devices, if so desired. Similarly, the control routines or modules 38 described herein implemented within the process control system 5 may take any form, including software, firmware, hardware, etc. The control routines may be implemented in any desired software format, such as by using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design methodology. The control routines 38 may be stored in any desired type of memory 32, such as random access memory (RAM) or read-only memory (ROM). Similarly, the control routines 38 may be hard-coded, for example, in one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 11 can be configured to implement control strategies or control routines in any desired manner.

[0055] In some embodiments, the controller 11 executes control strategies using what are generally referred to as function blocks, each of which is an object or other portion (e.g., a subroutine) of an overall control routine and operates in conjunction with other function blocks (through communications called links) to execute process control loops within the process control system 5. Control-based function blocks typically perform one of the following functions: an input function, such as one associated with a transmitter, sensor, or other process parameter measurement device; a control function, such as one associated with a control routine that performs control such as PID, fuzzy logic, or the like; or an output function that controls the operation of some device, such as a valve, to execute a physical function within the process control system 5. Of course, hybrid and other types of function blocks exist. The function blocks may be stored within and executed by the controller 11, which is typically the case when these function blocks are used for or associated with certain smart field devices, such as standard 4-20 mA devices and HART® devices, or the function blocks may be stored within and implemented by the field devices themselves, which may be the case for FOUNDATION® Fieldbus devices. The controller 11 may include one or more control routines 38 that may implement one or more control loops and may be executed by executing one or more of the function blocks.

[0056] The wired field devices 15-22 can be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O cards 26 and 28 can be any desired communication or can be any type of I / O device that conforms to the controller protocol. In Figure 1, field devices 15-18 are standard 4-20 mA or HART® devices that communicate with I / O card 26 over analog or combined analog-digital lines, while field devices 19-22 are smart devices, such as FOUNDATION® Fieldbus field devices, that communicate with I / O card 28 over a digital bus using the FOUNDATION® Fieldbus communication protocol. However, in some embodiments, at least some of wired field devices 15, 16, and 18-21 and / or at least some of big data I / O cards 26, 28 additionally or alternatively communicate with controller 11 (and / or other big data nodes) using process control data highway 10 and / or other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0057] As shown in FIG. 1, the controller 11, the I / O cards 26 and 28, and the wired field devices 15-16, 18-21 each include a respective embedded distributed data engine, indicated by a circled "DDE," which communicates with other distributed data engines via one or more data analysis communication channels and / or networks (not shown in FIG. 1).

[0058] 1 , the wireless field devices 40-46 communicate over a conventional wireless process control communication network 70 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the process control data analysis communication network 112 that are also configured to communicate wirelessly (e.g., using this or another wireless protocol). To communicate with one or more other nodes not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to the process control data highway 10 or another conventional process control communication network.

[0059] The wireless gateway 35 may provide access to the various wireless devices 40-58 of the wireless communication network 70. Specifically, the wireless gateway 35 provides communication coupling between the wireless devices 40-58, the wired devices 11-28, and / or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 may provide communication coupling using the process control data highway 10 and / or using one or more other conventional communication networks of the process plant 5.

[0060] Like the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 can perform physical control functions within the process plant 5, such as opening or closing a valve or taking measurements of a process parameter. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. Thus, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0061] In some scenarios, wireless network 70 may include non-wireless devices. For example, field device 48 of FIG. 1 may be a legacy 4-20 mA device, and field device 50 may be a conventional wired HART® device. To communicate within network 70, field devices 48 and 50 The wireless devices 40-46 and 52-58 may be connected to the wireless communication network 70 via a wireless adapter or may be integrated with the wireless adapter 52a or 52b. The wireless adapters 52a and 52b may support other communication protocols, such as Foundation® Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, the wireless network 70 may include one or more network access points 55a and 55b, which may be separate physical devices that communicate with the wireless gateway 35 via a wired connection or may be provided as an integrated device together with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 for forwarding packets from one wireless device to another within the wireless communication network 70. The wireless devices 40-46 and 52-58 may communicate with each other and with the wireless gateway 35 through a wireless link 60 of the wireless communication network 70 and / or via the process control data highway 10.

[0062] As shown in FIG. 1, adapter 52a, access point 55a, and router 58 each include a respective embedded distributed data engine, indicated by a circled "DDE," which communicates with other distributed data engines via one or more data analysis communication channels and / or networks (not shown in FIG. 1).

[0063] In some embodiments, the process control system 5 may be implemented using Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, WiMAX (Worldwide Interoperability for Microwave The process plant 5 may include one or more other wireless access points 72 that communicate using other wireless protocols, such as mobile communication protocols such as LTE (Long Term Evolution), LTE (Long Term Evolution), or other ITU-R (International Telecommunication Union Radio communication Sector)-compliant protocols, short-wavelength wireless communication such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 72 enable communication by handheld or other portable computing devices (e.g., user interface devices 73) over a respective conventional wireless process control communication network that is different from the wireless network 70 and that supports a different wireless protocol than the wireless network 70. For example, the wireless or portable user interface devices 73 may be mobile workstations or diagnostic test equipment utilized by operators within the process plant 5. In some scenarios, in addition to the portable computing devices, one or more process control devices (e.g., controller 11, field devices 15-22, or wireless devices 35, 40-58) also communicate using the wireless protocol supported by the access points 72.

[0064] In some embodiments, a process control system 5 includes one or more gateways 75, 78 to systems outside of the immediate process control system 5. Typically, such systems are consumers or sources of information generated by the process control system 5 or upon which the operation of the process control system 5 is based. For example, a process control plant 5 may include a gateway node 75 to communicatively connect the immediate process plant 5 with another process plant. Additionally or alternatively, the process control plant 5 may include a gateway node 78 to communicatively connect the immediate process plant 5 with external public or private systems, such as a laboratory system (e.g., a Laboratory Information Management System or LIMS), an operator round database, a material handling system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, another provider's process control system, or other external systems. That's fine.

[0065] As shown in FIG. 1, access point 72, user interface device 73, and gateway 75 each include a respective embedded distributed data engine, indicated by a circled "DDE," which communicates with other distributed data engines via one or more data analysis communication channels and / or networks (not shown in FIG. 1).

[0066] 1 only illustrates a single controller 11 along with a finite number of field devices 15-22 and 40-46, wireless gateway 35, wireless adapter 52, access point 55, router 58, and process control communications network 70 included within process plant 5, it is noted that this is an illustrative and non-limiting embodiment only. Any number of controllers 11 may be included within process control plant or system 5, and any of the controllers 11 may communicate with any number of wired or wireless devices and networks 15-22, 40-46, 35, 52, 55, 58, and 70 to control processes within plant 5.

[0067] Exemplary Distributed Industrial Process Performance Monitoring and Analysis System Architecture 2A includes a block diagram of an exemplary system 100 for distributed industrial process performance monitoring and analysis, also referred to interchangeably herein as a Data Analytics System (DAS). The DAS 100 may operate in conjunction with, for example, the process plant 5 of FIG. 1 and will be so discussed herein for ease of illustration. However, it is understood that at least a portion of the DAS 100 may operate in conjunction with other process plants and / or process control systems other than the process plant 5.

[0068] Generally, DAS 100 supports localized performance monitoring and / or analysis while simultaneously supporting large-scale (e.g., system-wide and / or across multiple devices or nodes of process plant 5) performance monitoring, data mining, and data analysis for the process plant environment. To this end, system 100 includes multiple distributed data engines (DDEs), examples of which are indicated in FIG. 2A by reference numerals 102a-102e and in FIG. 2B by reference numerals 102f-102h. As used herein, reference numeral "102x" refers to any one or more of DDEs 102a-102h. At least some of the distributed data engines illustrated in FIG. 2A correspond to the distributed data engines illustrated in FIG. 1. For example, data engine 102a in FIG. 2A is a data engine included within wireless gateway 35 in FIG. 1, and data engine 102b in FIG. 2A is a data engine embedded in controller 11 in FIG. 1. 1. For example, distributed data engine 102c is connected to data highway 10, distributed data engine 102d is embedded in a centralized big data appliance 108 of process plant 5, and distributed data engine 102e is embedded in a big data cloud node 110, where big data cloud node 110 can handle the data analysis needs of process control plant 5 (and in some configurations, other process control plants). Of course, system 100 is not limited to five data engines 102a-102e or eight data engines 102a-102h, but can include any number of distributed data engines, at least some of which are embedded or fabricated within their respective data sources (e.g., in respective process control devices of process plant 5) and / or at least some of which are otherwise connected to some other data source (e.g., component, part, etc.) of process plant 5.

[0069] In some configurations, some distributed data engines 102x may communicate at least some information with other data engines using a conventional process control communication network, but as noted above, typically, distributed data engines do not communicate with other distributed data engines using any of the conventional process control plant communication networks (e.g., backbone 10, wireless network 70, wired connections between I / O cards 28 and devices 19-22 of FIG. 1, etc.). However, generally, data engines 102x communicate with other data engines 102x using one or more data analysis communication networks 112 that are separate and distinct from the conventional process control network. The analytical data is streamed between the distributed data engines or nodes of the network 112, for example, by using an analytical streaming service, a streaming and / or queuing protocol, and / or a messaging broker or system 115 that supports streaming, such as a custom streaming source, Flume, HDFS, ZeroMQ, Kafka, Microsoft Message Bus, MQTT, AMQP, RabbitMQ, or the like, a custom specialized history object communications protocol, such as that described in the aforementioned U.S. application Ser. No. 14 / 506,863, entitled "STREAMING DATA FOR ANALYTICS IN PROCESS CONTROL SYSTEMS," or another suitable communications protocol. In FIG. 2A , the network 112 is not fully depicted for clarity, although several branches of the data analytics communications network 112 are depicted in FIG. 2A . Thus, in some embodiments, at least a portion of the data analytics communications network 112 may, in some sense, be an overlay network on top of a conventional process control communications network within the plant 5.For example, the physical equipment comprising the DDE 102x and at least a portion of the data analysis network 112 may be located on the premises of the process plant 5, and in some cases may be located within the equipment of the process plant 5.

[0070] In another embodiment, at least a portion of the data analytics communication network 112 may be implemented alongside or substantially in parallel with a conventional process control communication network, as shown in FIG. 2B. In FIG. 2B, a process plant 5 includes various process control devices or components that are communicatively connected to a conventional process control communication network, for example, to assist in the control of one or more processes within the plant 5. Three of such process control devices / components each have a respective DDE 102f, 102g, and 102h embedded therein and associated therewith, and each of the DDEs 102f-102h is communicatively connected to the data analytics network 112. However, the majority of the equipment supporting and / or comprising the data analytics network 112 is not located within the facilities of the process plant 5, but instead may be located remotely in an enterprise data center.

[0071] In another embodiment, at least a portion of the data analytics communication network 112 may be implemented as a logical network within the process plant 5. In this embodiment, for example, both process control data and analytical data may be transmitted over the same physical communication link, which has the appearance of logically separate links, such as one conventional process communication link and one data analytics communication link.

[0072] However, regardless of the implementation of the data analysis network 112, the data analysis network 112 intersects with a traditional process control communication network at devices or nodes within the process control system 5, and these devices or nodes include distributed data engines (e.g., data engines 102a, 102b, 102f, 102g, 102h). embedded therein and communicates information with other devices or nodes within the process control system 5 via the conventional process control communication network and / or by means of a distributed data engine (e.g., data engine 102c) connected thereto for the purpose of having a window into the data being transmitted to the conventional process control communication network.

[0073] The data analysis network 112 may utilize any desired communication technology and / or communication protocol. At least a portion of the data analysis network 112 may utilize wired technology, and at least a portion of the data analysis network 112 may utilize wireless technology. In general, however, the data analysis network 112 may support data packet transmission protocols and / or technologies such as IP or other asynchronous data packet protocols rather than Ethernet.

[0074] At a higher or upper layer, the data analytics network 112 may utilize streaming-enabled protocols, message brokers handling real-time data feeds, and / or messaging systems, such as Apache Kafka, that handle real-time data feeds 115. As shown in FIG. 2A , the streaming capabilities 115 provided by the data analytics network 112 enable the distributed performance monitoring and analysis system, or DAS 100, to bind locally to data sources and provide various analytical services near the data sources (e.g., near or at devices or nodes of the process plant 5, such as 11, 18, 26, 28, 72, 35, 52a, 55a, and 72 in FIG. 1 , where the distributed data engines 102x are embedded). At the same time, the streaming capabilities 115 of the system 100 also enable larger-scale prediction and optimization by the system 100, because only the specific source-generated data required to support broader or higher-level data analysis needs to be communicated to the receiving data engines. For example, if data engine 102d performs a particular data analysis only on data generated by each of the controllers of process plant 5 and captured within one hour after a particular configuration change was instantiated in each controller, data engine 102b embedded in controller 11 will stream only the required data to engine 102d (e.g., only stream output data generated by controller 11 within one hour after a particular configuration change was instantiated to data engine 102d, but not other output data generated by controller 11).

[0075] As shown in Figure 2A, portions of the distributed performance monitoring and analysis system, or DAS 100, are located locally within the process control environment or plant 5. For example, distributed data engines 102a, 102b, 102c, and 102d are located on the premises of the process plant 5. Also shown in Figure 2A, other portions of the system 100 are located remotely. For example, data engine 102e is located in the cloud 110. Other data engines 102x may be located at one or more remote locations (not shown), such as a server bank serving multiple process plants or process control systems. Of course, in some configurations, the system 100 may omit a locally located data engine or may omit a remotely located data engine. That is, the system 100 may provide performance monitoring and analysis (e.g., via one or more distributed data engines) entirely on-premise (e.g., locally) in the subject process control environment 5, entirely off-premise (e.g., remotely) in the subject process control environment 5, or using a combination of on-premise and off-premise distributed data engines (e.g., locally and remotely).

[0076] Exemplary Types of Performance Monitoring and Analysis for Industrial Control Systems Generally, industrial control system performance monitoring and analysis is a subject of interest. Analyzing data in industrial process control systems involves collecting data generated by the system (e.g., in real time while the system is operating to control a system or processes) and performing one or more analytical functions or operations on at least a portion of the collected data to determine knowledge about how well the control system is performing, or in some cases, to determine actions that can be taken to improve the performance of the system. Data analytics in industrial process control systems can be considered in three general categories: descriptive analytics, predictive analytics, and prescriptive analytics. A general discussion of these categories of analytics follows.

[0077] Descriptive analysis allows a user to discover what happened in a process control system or plant, when it happened, how often it happened, and what problem(s) resulted from what happened. Typically, descriptive analysis is performed on data collected (e.g., inductively) by monitoring the process system or plant and may utilize techniques such as basic calculations, scaling, and standard statistics.

[0078] Prescriptive analytics allows users to optimize operations within a process control system or plant. For example, prescriptive analytics allows users to answer questions such as: What is the best answer? What is the best outcome given uncertainty? What are significantly different or better options? Predictive analytics can identify, monitor, and control key quality variables or key indicators of process operations in industrial process control plants and systems. Additionally, predictive analytics can identify what will happen to key quality variables or key indicators of process operations given a set of future inputs or causal conditions. The predicted values ​​can then be leveraged by prescriptive analytics to generate prescriptive actions. Typically, prescriptive analytics utilizes techniques such as constraint-based optimization and multi-objective optimization, but known data monitoring and analysis tools are rudimentary and significantly limited in scope.

[0079] For example, known data monitoring and analysis tools allow a user or operator to optimize the performance of a single piece of equipment or unit in a plant by using constraint-based optimization tools that operate based on data collected by monitoring (e.g., inductively) that single piece of equipment or unit. However, because a process control system or plant includes multiple pieces of equipment and process units, the overall process may still be far from optimal due to process interactions between multiple units. While multi-objective optimization techniques for interacting units or collaborative optimization across portions of a process control system are available in known data monitoring and analysis tools (e.g., first-principles modeling), due to the increasing complexity of processes, such collaborative optimization techniques are difficult and often take too long to execute to be useful (if feasible at all). For example, known multi-objective optimization tools operate based on data collected by monitoring (e.g., inductively) multiple pieces of equipment or units to identify an optimal operating point and determine a trajectory that moves the current operating point toward the optimal operating point. However, each cycle of data collection and calculation based thereon can be very time-consuming, such that by the time a prescriptive action is identified, the process has moved far into its operation, and as a result, the identified prescriptive action may no longer be optimal or may even be ineffective, counterproductive, and / or dangerous. Furthermore, when a user attempts to reduce or limit the size and scope of a calculation (and therefore the time required for the calculation) by limiting the amount of variables input to a multi-objective optimization tool, the user is making human judgments about which variables to select as inputs, which are not only limiting in scope but may also be imprecise, and therefore may result in erroneous or inaccurate results.

[0080] Furthermore, known data monitoring and analysis tools often cannot provide the identity and values ​​of critical quality variables on demand (e.g., due to limitations in available measurement techniques) and therefore cannot provide timely and relevant results. For example, currently used techniques for predictive analysis of process control systems include either offline (e.g., laboratory) or online (e.g., analyzer) techniques, both of which have their respective drawbacks. Offline determination of critical quality variables is undesirable because significant delays incurred by laboratory testing make any output suboptimal or even invalid for the current process state (e.g., the measured signal cannot be used as a feedback signal). The use of online analyzers to determine critical quality variables is also undesirable because known online analyzers are problematic, inefficient, and require frequent and costly maintenance. These limitations can have serious impacts on product quality, waste generation, and operational safety.

[0081] Furthermore, in large-scale monitoring situations, traditional centralized performance monitoring schemes have serious limitations. A suitable performance monitoring system should have fault-tolerance capabilities, operational reliability, and economy, all of which are compromised when a centralized performance monitoring scheme is applied to large-scale monitoring situations. Specifically, the centralized monitor simultaneously monitors failures in all units of a process. Because the centralized monitor uses all measurement variables in its calculations, if one variable is unavailable or one communication channel is interrupted, the entire monitoring system may cease to function. Therefore, when a failure is found in one unit, the centralized monitor is limited in its ability to detect additional failures from other units occurring during the same period. In addition, the real-time capability of the centralized monitor is limited by the lowest sampling rate of the variables, which reduces the efficiency of the monitoring system. Furthermore, different variables in a plant have very different dynamic scales (even within the same unit), and a single monitoring scheme is usually not applicable to all variables of an entire process or unit, making it suboptimal, especially in situations where variables influence each other, such as across interacting process units. Still further, when there is geographic distribution within a process control system (e.g., long distances between various process units, such as an oil pipeline), each unit is typically equipped with separate performance monitoring equipment, which introduces problems of local (but not global) performance monitoring, as well as transmission delays, data loss, and battery limitations.

[0082] Unlike currently used rudimentary, univariate, and / or centralized predictive monitoring and analysis techniques, and unlike the inductive nature of descriptive and prescriptive analytics, the novel distributed performance monitoring and analysis systems, methods, apparatus, components, and techniques for industrial control systems and plants described herein enable users to monitor what is currently happening within a process control system or plant at any point in time and to make real-time predictions of what is likely to happen next or later based on current data. The novel techniques disclosed herein enable users to answer questions such as "What's happening now?", "What's going to happen next?", and "What will happen if this trend continues?" with little or no user or human bias regarding the characteristics of the process data.

[0083] The novel techniques for distributed performance monitoring and analysis for industrial control systems described herein generally include a platform (e.g., the system architecture 100 shown in FIG. 2A) and applications that operate on or in conjunction with the platform. For example, it supports evaluation, monitoring, and data mining of a process control system or plant (e.g., process control system 5) by leveraging a data-driven methodology that is augmented with equipment and process knowledge before, during, and after the system or plant operates to control one or more processes. In some implementations, the platform may support multiple control systems or plants.

[0084] Performance monitoring and analytical applications that rely on or operate in conjunction with this platform may include, for example, inferred measurements, equipment monitoring, fault detection, process prediction, causality, other monitoring applications, and / or other analytical applications. Techniques that may be utilized by these applications include data mining, optimization, predictive modeling, machine learning, simulation, distributed state estimation, etc. Thus, the monitoring and analytical applications may be used to monitor, predict, and diagnose performance degradation and failures of any number of any parts of the process control system 5, including in areas such as instrumentation, equipment, controls, user interactions, and processes.

[0085] Thus, the distributed industrial performance monitoring and analysis techniques described herein may include inference mechanisms that provide continuous, online assessment of key process variables from readily available process measurements. To maintain the data model over time, the system may further support the ability to monitor, adjust, and enhance the data model. Methods that may be used include, in the simplest case, detuning the model (e.g., increasing the normal operating range to ±3 seconds of prediction). More complex examples include model switching and model adaptation.

[0086] Indeed, as part of a research and prototype testing program, the inventors have used the techniques described herein to establish a prototype industrial process performance data monitoring and data analysis framework to address the challenges of soft sensor development in the presence of nonlinearities, non-Gaussian distributions, data sample irregularities, process constraints, and / or other factors. In these prototypes and studies, data generated by several soft sensors was monitored and analyzed for specialty chemical, batch, and hydrocarbon processes, and the resulting knowledge was utilized to improve the processes achieved. Significant economic and environmental benefits were reported by our industrial partners. Examples of our research and prototypes are described in later sections.

[0087] Returning now to FIG. 2A, the present distributed industrial performance monitoring and analysis system, or DAS 100, provides the tools, configurations, and interfaces needed to support localized performance monitoring, while simultaneously supporting large-scale data mining and data analysis for a process plant environment, such as process plant 5 of FIG. 1. For example, system 100 may include a user interface application (e.g., Data Analytics The system 100 may include a data analysis engine (e.g., a Run-time Studio), a runtime engine for executing the models (which may operate in whole or in part based on real-time data generated by the process control system), and the same or another user interface application (e.g., a Run-time Dashboard) for displaying the analytical results. The system 100 may operate on or support multiple types of data sources, such as real-time values ​​(e.g., real-time continuous values) as previously described, external data such as event collection, batch data collection, operator round data, LIMS data, supply chain data, and / or weather data, and any other type of data associated with the process control system, including both structured and unstructured data. The system 100 may also generate "outside the box" statistics, such as descriptive statistics, histogram plots, correlation plots, etc. The system 100 may provide a set of standard analyses that are not part of the process control system. Additionally, the system 100 may provide a structured environment for a user to create desired analyses and view both the source data and the n-th order data generated by applying multiple different data analyses to identify potential relationships within various data sets of a process control system and / or predict product performance, quality, and other characteristics. Generally, the system 100 may provide knowledge discovery about a process control system as well as actionable knowledge (e.g., to improve or optimize process control system performance, correct and / or predict failures, improve reliability, improve safety, improve economics, etc.), which may be represented as a data model.

[0088] As shown in FIG. 2A , the system 100 can be highly distributed and may include, for example, a large number of distributed data engines 102x. The network 112 of embedded data engines 102x may interconnect a large number (e.g., hundreds, thousands, or millions) of sensors and sources of information for the process control system. As previously described, the data engines 102x are clustered near, at, or within process control system devices and nodes (e.g., manufacturing equipment, process control devices, communication nodes, material handling systems, laboratory systems, plant users, and the process itself). Thus, the embedded nature of the distributed industrial performance monitoring and analysis system 100 is tightly coupled to the physical process control plant. However, the embedding and integration of the data engines 102x into the manufacturing infrastructure of process control system devices and nodes may make the data engines 102x nearly invisible to end users. Typically, the data engine 102x is small, wirelessly connected to the network 112, has limited bandwidth, and operates under physical constraints such as limited energy and the need for sufficient heat dissipation because the data engine 102x may be embedded within a process control device such as a temperature sensor or other type of sensor.

[0089] As previously described, distributed data engines 102x interconnect with other data engines 102x over network 112 using streaming and / or queuing protocols. Each distributed data engine 102x may support one or more data monitoring and / or data analysis applications. Large numbers of connected clusters of applications may require the use of statistically accurate (as opposed to deterministic) algorithms for resource accounting, fault detection and correction, system management, etc., with each cluster providing targeted functionality for localized needs.

[0090] Thus, the distributed industrial performance monitoring and analysis system 100 may improve the safety, efficiency, and productivity of a process control plant. For example, the system 100 may precisely control process parameters, thereby reducing the overall cost of process manufacturing. Additionally, integration of the system 100 into the process control environment 5 may result in better product quality and less waste due to precise process control and real-time quality assurance; more flexible, rapidly configured production lines as a result of programmable subsystems; system health monitoring that leads to more effective, preventative, and lower-cost maintenance; a safer work environment due to better monitoring and control; and better part assembly techniques, such as through the use of smart RFID tags, to name just a few of the myriad benefits.

[0091] The distributed industrial performance monitoring and analysis system 100 may also improve human-machine interaction between users and the process control system 5 to the point of creating a real-time human-plus-machine control loop within the process plant 5. For example, the improved human-machine interaction may increase quality and productivity by ensuring the absence of operator / maintenance / reliability errors and by reducing accidents. Availability, reliability, and continuous quality of service of the process control plant 5 may be achieved through advanced control, redundancy, intelligent alarms, self-diagnosis, and repair by the system 100 .

[0092] Exemplary Industrial Performance Data Monitoring / Data Analysis Engine Turning now to the distributed, industrial performance distributed data monitoring and / or analytics engine 102x, generally, the distributed data engine 102x may be a node of the data analytics communication network 112 that collects, observes, retrieves, receives, processes, stores, caches, and / or analyzes all or most of the process control related data (e.g., big data) generated or otherwise observed by one or more data sources, such as by the device or component in which the data engine 102x is embedded or by the component(s) to which the data engine 102x is coupled or connected. In some circumstances, the distributed engine 102x may generate additional data (e.g., results of the analyses it performs) and / or transmit or forward selected data to other nodes of the data analytics network 112. As used interchangeably herein, the terms “process control big data,” “process big data,” and “big data” generally refer to all (or substantially all) data generated, received, and / or observed by devices and / or components (e.g., both process control devices / components and analytical devices / components) contained within and associated with a process control system or plant (e.g., process control system or plant 5), and in particular, all (or substantially all) data generated, received, and / or observed while the process control system or plant is running to control one or more processes in real time. In one embodiment, all data (including all process data and all analytical data) generated by, created by, received at, or otherwise observed by all devices contained within and associated with the process plant 5 is collected and stored as big data in the data analytics communication network 112. In process plant and process control environments, the collection and analysis of this big data is important to improving safety, reliability, and economics because time spans and the presence or absence of specific data points can be critical.For example, if a particular data value is not delivered to a receiving component of a process plant within a certain time interval, the process may become uncontrollable, which may lead to fire, explosion, loss of equipment, and / or loss of life. Furthermore, multiple and / or complex time-based relationships between different components, entities, and / or processes operating within the process plant and / or external to the process plant may affect operational efficiency, product quality, and / or plant safety.

[0093] The process control big data generated, collected, observed, retrieved, received, stored, cached, processed, analyzed, and / or forwarded by the distributed data engine 102x may include data directly utilized in or generated from controlling a process within the plant 5, and may include, for example, first-order real-time and configuration data generated or used by process control devices such as controllers, input / output (I / O) devices, and field devices. Additionally or alternatively, the data engine 102x may generate, collect, observe, process, analyze, store, receive, retrieve, cache, and / or forward such first-order process control data as well as other data within the process plant 5, for example, data related to the delivery and dispatch of network control of the data analytics communication network 112 and / or other communication networks within the plant 5, data indicative of bandwidth, network access attempts, diagnostic data, etc. Additionally, some of the data engines 102x may generate, collect, observe, store, cache, or otherwise process data indicative of results, learnings, and / or information learned therein by processing and / or analyzing the process control big data collected by the process control data analytics communication network 112. Typically, such analysis results, learning, and / or learned information are generated from analysis performed by one or more data engines 102x.

[0094] Accordingly, a distributed data engine (e.g., DDE 102x) is referred to interchangeably herein as a “big data appliance,” “big data appliance node,” or “appliance node.” In most cases, the distributed data engine of a big data appliance node 102x includes multi-core hardware (e.g., a multi-core processor) for sending and receiving big data in real time (e.g., via streaming) and, in some embodiments, for caching and / or storing the real-time big data for later streaming or other delivery over the process control data analytics communication network 112. Accordingly, the distributed data engine 102x also includes memory (e.g., high-density memory) for caching and / or storing the big data. Examples of real-time data that may be sent, received, streamed, cached, collected, stored, received, retrieved, cached, and / or otherwise observed by the data engine 102x may include process control data, such as measurement data, configuration data, batch data, event data, and / or continuous data. For example, real-time data corresponding to configurations, batch recipes, set points, outputs, rates, control actions, diagnostics, alarms, events, and / or changes thereto may be collected. Other examples of real-time data may include process models, statistics, status data, network and plant management data, and analytical results. Descriptions of various types of exemplary big data appliances and their components that may be utilized with any or all of the techniques described herein may be found in the aforementioned U.S. patent applications Ser. Nos. 13 / 784,041, 14 / 174,413, and 14 / 212,493, although it will be understood that any or all of the techniques described herein may be utilized with other suitable big data appliances.

[0095] Typically, the distributed data engine 102x generally operates based on big data generated or provided by one or more data sources within the process control plant or system 5 and / or otherwise associated with the real-time operation of the process control plant or system 5. For example, the DDE 102x may collect and timestamp data received at and / or generated by the device in which it is embedded or data received at and / or generated at its corresponding data source(s). The collected data may be stored (at least temporarily) in local memory of the data engine 102x. In some situations, at least some of the data may be transported or streamed to one or more other data engines 102x using a specialized historical object communication protocol, such as that described in the aforementioned U.S. application Ser. No. 14 / 506,863, entitled "STREAMING DATA FOR ANALYTICS IN PROCESS CONTROL SYSTEMS," or another suitable communication protocol or messaging system, such as Kafka.

[0096] In some embodiments, one or more data engines 102x support large-scale data mining and data analysis based on multi-dimensional data, including real-time continuous values, event collections, batch data collections, operator round data, and / or other data. A distributed data engine 102x can be configured to perform one or more data analyses based on its locally collected data and / or data collected by other DDEs 102x. For example, a DDE 102x can analyze structured data (e.g., time series and tabular data stored in memory, relational databases, and / or non-relational databases, or streamed) as well as unstructured data (e.g., data stored in memory, relational databases, and / or non-relational databases, or streamed). The DDE 102x may include various tools that operate based on a set of data engines (e.g., PDFs). Additionally, the DDE 102x may support any one or more desired target environments and execute the respective target code therein (e.g., Java, C#, R script, Python script, Matlab® script, Statgraphics, etc.). The DDE 102x may implement learning algorithms (e.g., partial least squares regression, principal component analysis, etc.), classification techniques (e.g., random forests, pattern recognition, etc.), and / or other data analyses to generate results and / or useful information, such as predicting product capabilities, quality, and / or other desired characteristics. Results of the local analyses may be stored in the local memory of the data engine 102x and may themselves be processed as additional big data. Furthermore, some data engines 102x may include interfaces for configuring and developing models, runtime engines for executing the models, and dashboards for displaying results in a user interface. For example, a distributed data engine 102x may implement the aforementioned "DATA PIPELINE FOR PROCESS CONTROL" (DPC) framework. The results may be organized with runtime analytics in a manner such as that discussed in U.S. application Ser. No. 62 / 060,408, entitled "SYSTEM ANALYTICS," and / or as discussed in later sections of this disclosure. The displayed results may include standardized descriptive statistics, histograms, correlation plots, and / or other data representations that can identify potential relationships within various data sets.

[0097] In some cases, the distributed data engine 102x is embedded within, manufactured within, directly coupled to, or otherwise co-resident with a host data source (e.g., data engines 102a, 102b, and 102c shown in FIG. 2A). In some cases, the distributed data engine 102x may be a standalone big data node of the process control data analytics communication network 112 (e.g., data engines 102d and 102e shown in FIG. 2A). That is, in these cases, the data engine 102x is not embedded within or co-resident with the data source of the process control system or plant 5, but may otherwise observe data generated by one or more data sources (e.g., data engine 102c, etc., when the distributed data engine is coupled with a traditional process control communication link). Whether embedded or standalone, the data engine 102x analyzes big data locally generated and / or provided by one or more data sources to discover or learn knowledge. This learned knowledge may be stored in the data engine 102x, acted upon locally by the data engine 102x, and / or provided or transmitted as big data to other data engines 102x, e.g., receiving big data nodes. Additionally, the distributed data engine 102x may provide portions of its known or stored big data to other data engines 102x and / or other nodes in the analytic network 112 (e.g., local or remote user interface nodes).

[0098] 3 includes a simplified block diagram of an example distributed industrial process performance data monitoring and / or data analysis engine 150, an instance of which may be included in the process control data analysis communication network 112 of FIG. 2A (e.g., distributed data engine 102x). Referring to FIG. 3, the example distributed data engine 150 includes a big data storage area 155 for caching, storing, and / or historizing big data, one or more big data appliance receivers 160, and one or more big data appliance request servicers 165. Each of the big data appliance receivers 160 is configured to receive and / or observe data from one or more data sources 168. In one embodiment, the big data appliance receivers 160 are configured to receive and / or observe data from one or more data sources 168 via a network interface to a conventional process control communication network, such as a data highway 10, a Fieldbus network, a WirelessHART network, or the like. The big data appliance receiver 160 receives and / or observes data traveling through a conventional process control communication network via a local interface. Additionally or alternatively, the big data appliance receiver 160 may receive data via a local interface from its corresponding data source(s) 168, such as a process control device or other type of device, in which the DDE 150 is embedded, manufactured therein, or to which the DDE 150 is locally, directly, and / or otherwise closely coupled. Still additionally or alternatively, the big data appliance receiver 160 may receive big data packets, for example, via a data analysis network interface 175. The received big data packets may have been streamed from another DDE 150 and / or generated by a big data source with which the data engine 150 resides. Regardless of the source(s) 168 of the received / observed data, big data appliance receiver 160 processes the received / observed data packets and / or messages to retrieve the substantive data and timestamps carried therein and stores the substantive data and timestamps, e.g., as time-series data, and optionally as metadata, in big data storage 155 of data engine 150. As used herein, the term “metadata” generally refers to data about the data, such as statistical information about the data, categorical information about the data, summary information, descriptive information, definitions, etc. Big data storage 155 may comprise multiple local and / or remote physical data drives or storage entities, such as RAID (Redundant Array of Independent Disks) storage, solid-state storage, cloud storage, high-density data storage, and / or any other suitable data storage technology suitable for databank or datacenter storage, having the appearance of a single or centralized logical data storage area or entity to other nodes, and configured to store and / or historize big data locally.

[0099] Each big data appliance request servicer 165 is configured to access time-series data and / or metadata stored in big data appliance storage 155, for example, per request of a requesting entity or an application, such as a local or remote data analysis application, user interface application, or another application. For example, big data appliance request servicer 165 may publish selected data stored in big data appliance storage 155 to subscribers of the selected data at a given time interval. In another example, big data appliance request servicer 165 may retrieve data stored in local big data appliance storage 155 per request of a remotely executing data analysis application. Additional examples of accessing data stored in DDE 150 are discussed in later sections. Such data may be stored in various data formats, including relational or non-relational databases, or other data structures. In some embodiments, a standardized query format may be used to access data in any of these data sources.

[0100] In some embodiments, distributed data engine 150 includes one or more big data analyzers 170 for performing respective data analysis and / or learning on at least a portion of the big data stored in memory 155. The execution of local analysis and / or learning may be performed in response to a command or instruction generated by a user or another node. Additionally or alternatively, the execution of local analysis and / or learning may be performed in an automatic and / or autonomous manner without the use of any input from a user or another node to initiate and / or perform the learning analysis. For example, data analysis and / or learning may be performed in a manner such as that discussed above, as described in the aforementioned "DATA No. 62 / 060,408, entitled "PIPELINE FOR PROCESS CONTROL SYSTEM ANALYTICS," or in any other suitable manner. In one embodiment, big data analyzer 170 performs large-scale data analysis (e.g., data mining, data discovery, etc.) on the stored data, individually or collectively, to discover, detect, or learn new information or knowledge. Data mining generally involves the process of examining large amounts of data to extract new or previously unknown interesting data or patterns, such as unusual records or groups of data records. Big data analyzer 170 may also perform large-scale data analysis (e.g., machine learning analysis, data modeling, pattern recognition, predictive analysis, correlation analysis, etc.) on the stored data to predict, calculate, or identify potential relationships or inferences within the stored data.

[0101] In some embodiments, multiple big data analyzers 170 (and / or multiple instances of at least one big data analyzer 170) may operate in parallel and / or collaboratively to analyze data stored in big data storage 155 of distributed data engine 150 and / or to analyze data stored in one or more other big data storage areas of other distributed data engines 102x. Furthermore, multiple big data analyzers 170 may share, exchange, or transfer calculated parameters and model information among each other as a type of collaborative data analysis and learning. Multiple big data analyzers 170 may be co-located on the same big data node or may reside on different big data nodes. An example of collaborative data analysis that may be utilized with any or all of the techniques described herein is found in the aforementioned U.S. Application No. 62 / 060,408, entitled "DATA PIPELINE FOR PROCESS CONTROL SYSTEM ANALYTICS," although any suitable collaborative data analysis technique(s) may be utilized with any or all aspects of the present disclosure. The results of the analysis performed by big data analyzer 170 may be stored in big data appliance storage area 155 and / or returned to a requesting entity or application.

[0102] In one embodiment, at least a portion of big data receiver 160, big data appliance request servicer 165, and / or big data analyzer 170 are included in or implemented by one or more integrated circuits, semiconductors, chips, or other suitable hardware. For example, big data analyzer 170, which performs spectral analysis, may be implemented by an integrated circuit chip included in a big data node, such as that described in the aforementioned U.S. application Ser. No. 14 / 507,252, entitled "AUTOMATIC SIGNAL PROCESSING-BASED LEARNING IN A PROCESS PLANT." In one embodiment, at least a portion of big data receiver 160, big data appliance request servicer 165, and / or big data analyzer 170 include computer-executable instructions stored in memory and executable by processes operating in distributed data engine 150. For example, at least a portion of big data appliance receiver 160, big data appliance request servicer 165, and / or big data appliance analyzer 170 may include respective computer-executable instructions stored in one or more non-transitory, tangible memory or data storage devices and executable by one or more processors to perform one or more of the respective big data functions.

[0103] In some embodiments, at least some big data analyzers 170 are not included in the distributed data engine 150, but instead are co-located with the distributed data engine 150 in the same host data source device or component and are integrated into the data engine 150. The big data analyzer 170 is communicatively connected to the data engine 150. For example, the data engine 150, including the storage area 155, the receiver 160, and the servicer 165, may be implemented by a first set of computer-executable instructions, and the big data analyzer 170 may be implemented by a semiconductor chip or a second set of computer-executable instructions, which may or may not be stored in the same non-transitory, tangible memory or data storage device as the first set of computer-executable instructions. In some embodiments, the big data analyzer 170 is not included in the data engine 150 and is not co-located with the data engine 150 in the same host data source device or component, but is still communicatively connected to the data engine 150. For example, the big data analyzer 170 may be located at another node of the data analysis network 112 other than the DDE 150, such as a user interface node or an analysis server.

[0104] 3 further includes one or more network interfaces 175 configured to enable data engine 150 to send and receive payload big data through data analytics network 112 and to communicate (e.g., signaling and other types of communication) with other data engines and nodes of data analytics network 112. For example, data engine 150 may use network interface 175 to subscribe to one type of data published by another node, and the type of data produced by the publishing node and the type of data to which data engine 150 subscribes may be received via network interface 175.

[0105] As previously discussed, various types of real-time data may be generated, collected, observed, retrieved, received, stored, cached, processed, analyzed, and / or streamed by the distributed data engine 102x, such as process-related data, plant-related data, and other types of data. Examples of process-related data include continuous, batch, measurement, and event data that is generated while a process is being controlled in the process plant 5 (and, in some cases, indicative of the effects of real-time execution of the process). Additionally, process-related data may include process definitions, sequence data or setup data such as configuration data and / or batch recipe data, data corresponding to configurations, process diagnostic runs and results, etc.

[0106] Plant-related data, such as data related to the process plant 5 but that may not be generated by applications that directly configure, control, or diagnose processes in the process plant 5, may be generated, collected, observed, retrieved, received, stored, cached, processed, analyzed, and / or streamed as big data by the distributed data engine 102x. Examples of plant-related data include vibration data, steam trap data, data indicative of values ​​of parameters corresponding to plant safety (e.g., corrosion data, gas detection data, etc.), data indicative of events corresponding to plant safety, data corresponding to machinery health, data corresponding to plant assets such as plant equipment and / or devices, data corresponding to configurations, performance and results of equipment, machine, and / or device diagnostics, and data useful for diagnostics and prognosis.

[0107] Additionally, other types of data, including data highway traffic data and network management data associated with the process control big data network backbone and of various communication networks of the process plant 5, user-related data such as user traffic, login attempts, queries, and commands, text data (e.g., logs, operating procedures, manuals, etc.), spatial data (e.g., location data), and multimedia data (e.g., closed-circuit TV, video clips, etc.), may be generated, collected, observed, retrieved, received, stored, cached, processed, analyzed, and analyzed as big data by the data engine 102x. and / or may be streamed.

[0108] In some embodiments, dynamic measurement and control data may be automatically generated, collected, observed, retrieved, received, stored, cached, processed, analyzed, and / or streamed as big data by the distributed data engine 102x. Examples of dynamic measurement and control data include data identifying changes in process operation, data identifying changes in operating parameters such as set points, and records of process and hardware alarms, events such as downloads or communication failures. In addition, static data such as controller configurations, batch recipes, alarms, and events may be automatically collected by default when changes are detected or when a controller or other entity is first added to the data analytics communication network 112.

[0109] Also, in some scenarios, at least some static metadata describing or identifying dynamic control and measurement data is captured in the distributed data engine 102x when a change in the metadata is detected. For example, if a change is made in the controller configuration that affects a module's or unit's measurement and control data and must be transmitted by the controller, an associated metadata update is automatically captured by the data engine 102x. Additionally or alternatively, parameters, survey data, and / or other types of monitoring data associated with special modules used to buffer data from external systems or sources (e.g., weather forecasts, public events, corporate decisions, etc.) may be automatically captured by the data engine 102x.

[0110] In some situations, additional parameters created by the end user are automatically included in the distributed data engine 102x. For example, the end user may create special operations on a module or add parameters to a unit to be collected, or the end user may want to collect standard controller diagnostic parameters that are not communicated by default. Parameters that the end user optionally configures may be communicated in the same manner as the default parameters.

[0111] User interface applications for industrial performance monitoring and analysis As previously mentioned, the data analysis system, or DAS 100, may include one or more user interface applications through which human-machine interactions related to data occur. Exemplary instances of these user applications are depicted in FIG. 2A by references 120a-120d. This section of the disclosure and FIGS. 4A-4Q describe in more detail an industrial performance monitoring / analysis user interface application. This user interface application may be provided by or operate in conjunction with, for example, the process plant or system 5 of FIG. 1, the industrial performance monitoring / analysis system 100 of FIG. 2A, and / or the monitoring and analysis engine 150 of FIG. 3. However, the industrial performance monitoring / analysis user interface application described herein may also be provided by or operate in conjunction with other industrial performance monitoring and analysis systems for process control systems. However, for ease of discussion, the industrial performance monitoring / analysis user interface application will be discussed below with simultaneous reference to FIGS. 1, 2, and 3. Additionally, for ease of reading, the Industrial Performance Monitoring / Analytics User Interface Application is referred to herein using capital letters to distinguish it from general purpose and / or other user interface applications, and may also be referred to herein interchangeably as a "Data Analytics User Application," "Data Analytics User Interface," or "Data Analytics User Interface." e Application," "Data Analytics Application," "DDE User Interface Application," or "User Interface Application."

[0112] The DDE User Interface Application provides an interface for users to interact with the Distributed Industrial Process Performance Monitoring and Analysis System, or DAS 100, to define structure, query data, and build and evaluate draft data models. Once the draft data model is complete, the DDE User Interface Application enables the download of the data model to a runtime engine and the deployment of the data model to operate with the online process control system. The deployed data model (also called the running or online data module) can be accessed and monitored through the DDE User Interface Application's runtime dashboard. The DDE User Interface Application can also generate alarms and notifications corresponding to the running data model.

[0113] Specifically, the DDE User Interface Application allows users to create, view, and modify data models, each of which defines one or more data analyses (e.g., descriptive, predictive, and / or prescriptive analyses) to be performed or implemented on input data sets. Data models are drafted or created in offline mode (e.g., while the data model is disconnected from the live data sources of an online or running process control system); in this mode, the data model is referred to herein as an "offline data module." Generally, offline data modules are defined by offline data diagrams, which a user creates through the DDE User Interface Application by selecting a set of "blocks" or "data blocks" and interconnecting those blocks on the diagram in a desired manner using a set of "wires." Each data block includes inputs, through which data is received into the block. Each data block also represents or defines specific functions, actions, algorithms, and / or operations, which are performed by each data block based on its input data, thereby generating output data that can be provided to other blocks via one or more outputs. Each data block can be evaluated separately to compile and execute the offline diagram representation of the block and its interconnecting wires into executable code, and the results of each data block's execution are presented in the offline data diagram. As discussed in later sections, the compilation of data blocks into code, and their subsequent execution, can be performed in a distributed manner across different target environments and locations.

[0114] Similarly, offline data diagrams can be evaluated as a whole. Evaluation of an offline data diagram involves compiling the data blocks and wires and executing the compiled code to transport input and output data across the wires and perform the functions, actions, algorithms, and / or operations defined by the particular configuration of the blocks and wires of the offline data diagram. Also, like individual data blocks, compilation of offline data diagrams and execution of the compiled offline data diagrams can be performed in a distributed manner across different target environments and locations.

[0115] Additionally, the DDE User Interface Application allows the user to convert an offline data module into an "online data module." This conversion allows the online data module of the data model to be used in the online process. A data model may bind to a live data source of a process plant or otherwise receive live (e.g., streaming) data being generated by the process plant, perform one or more data analyses defined therein on the live data, and provide output to a user interface, a historian, or other application. For example, the output data generated by the data model may include descriptive, predictive, and / or prescriptive information or data corresponding to the process plant and / or the processes being controlled therein.

[0116] Specifically, a user can convert an online data diagram for a particular data model into an online data diagram for that particular data model. Like an offline data diagram, an online data diagram includes a set of data blocks interconnected by a set of wires, and because the offline and online data diagrams generally correspond to the same data model, the functions, actions, algorithms, and / or operations defined by the online data diagram correspond to those of the offline data diagram. However, at least some of the blocks and interconnections differ between the offline and online data diagrams, primarily (but not necessarily solely) to accommodate the connection of online data modules to an online process plant.

[0117] Also like offline data diagrams, online data diagrams can be compiled as a whole into executable code that corresponds to the online data modules of the data model. Compilation of a particular block of the online data diagram results in the definition of the particular block's bindings with respective data sources and data consumers in the online process plant. Deployment of the online data modules instantiates these bindings and causes the executable to run or execute, thereby integrating the online data modules with the online process plant so that the online data modules execute in conjunction with the operation of the online process plant. The compilation of the online data diagram and the resulting binding and execution of the online data modules can be performed in a distributed manner across different target environments and locations.

[0118] In particularly useful embodiments, the online data module of the data model receives and operates, at least in part, on continuous, real-time data generated by devices or components of the process plant as a result of ongoing control of online processes running in the plant. For example, the online data module operates on continuous, real-time time-series data generated by the online process plant and / or a process control system included in the plant while the process plant and process control system operate to control the process. The data model continuously operates on the continuous, real-time data stream (e.g., by performing its one or more data analysis functions and, if present, other functions defined by the data model) and continuously generates a real-time stream of result or output data, which may be displayed in a user interface (e.g., as a rolling line graph or other depiction) that continuously reflects the current, real-time value of the data model's output. In one example, the data output generated by the data model and displayed in the user interface includes at least one predicted value and its variation over time. In general, however, the data model may operate on large amounts of data generated by various data sources within the process control plant or environment 5 for purposes of fault detection, prediction, and provisioning related to the process control plant or environment 5.

[0119] In one embodiment, the DDE User Interface Application is web-based and accessed through a web browser so that different instances of the Application can be used on different platforms (e.g., Apple Macintosh, Linux, Windows, etc.) and by different users on different computing devices, sometimes simultaneously. However, the DDE User Interface Application is not limited to a web-based implementation and may utilize any other suitable implementation that is platform independent and can be scaled to multiple users and / or instances simultaneously.

[0120] Additionally, although the DDE User Interface Application is described herein as being applied to a single process control plant or environment 5, with multiple instances of the DDE User Interface Application running simultaneously, this configuration is illustrative only and is not intended to be limiting. For example, in some configurations, the DDE User Interface Application may be applied to multiple process control plants or environments operating independently at different locations and with different processes. For example, a single DDE User Interface Application provided by a server or bank of computers may be utilized at multiple refineries of an oil company, with some instances of the DDE User Interface Application running at Refinery A and some instances running at Refinery B.

[0121] In any event, as previously discussed, the DDE User Interface Application abstracts as blocks or data blocks the functions, actions, algorithms, and / or operations that may be performed by the data blocks on respective input data. Examples of blocks or data blocks are designated by their respective functions, actions, algorithms, and / or operations, e.g., load, clean, manipulate, analyze, visualize, etc. Each data block may load or acquire respective input data, perform one or more of its respective functions, actions, algorithms, and / or operations on the acquired input data, and generate one or more respective results or respective output data. Multiple data blocks may be interconnected as desired (e.g., serially, in parallel, many-to-one, one-to-many, etc.) to form an offline data diagram that represents or defines a draft data model or offline data module that can be executed or evaluated by applying or operating on the offline data module (or portions thereof) to one or more sets of data sets or offline data sources. For example, during execution or evaluation of an offline data module, the offline data diagram is compiled into executable code, the identified data set(s) are acquired and loaded into or for use by the offline module, and the interconnected blocks of the compiled offline module are executed to perform their respective operations on their respective inputs and provide their respective results on their respective outputs, resulting in one or more analytical outputs or results produced by the overall offline data module that corresponds to the data model being developed or created. In some embodiments, during offline evaluation, rather than loading data sets from files into the draft data model, input data may be received from streaming offline data sources such as a test tool, environment, or plant.Additionally, as described in more detail below, offline data modules or draft data models may be incrementally evaluated as they are developed. In the DDE User Interface Application, the platform or infrastructure for evaluating offline data blocks and offline data modules is provided by Data Analytics Services. This is described in a later section.

[0122] After the offline data module (or portion thereof) has been evaluated, the user can review and scrutinize the results of the evaluation, and the draft model (or portion thereof) can be modified as appropriate and re-evaluated until satisfactory results are achieved. The user can complete the draft data model / offline data module, convert it into an online data module, and execute or deploy the online data module to operate based on real-time, online, or streaming live data being generated due to real-time operation of the process control environment or plant 5. For example, the executing or deployed online data module or data model can continuously operate based on real-time data being continuously generated due to online operation of the process plant, and the online data module or model can itself continuously generate real-time output data or results of its execution, which can be displayed and continuously updated in the user interface. The online execution or operation of the deployed online data module and corresponding results can be monitored in the Dashboard of the DDE User Interface Application, which is also described in more detail in a later section.

[0123] As previously discussed, within the DDE User Interface Application, data blocks, data modules (whether online or offline), and portions thereof, may be visually and / or graphically represented to the user as diagrams or data diagrams on a workspace or canvas provided by the DDE User Interface Application. Generally, each data diagram includes a set of data blocks (e.g., which may be represented as two-dimensional shapes) interconnected by a set of wires (e.g., which may be represented as lines). The DDE User Interface Application typically includes two modes of operation (although in some embodiments, more or fewer modes may be included), both of which utilize data diagrams to represent data modules and the data blocks contained in the data modules.

[0124] One of the modes of operation is referred to interchangeably herein as "Data The offline data module diagram may contain more data blocks and / or connections than the resulting online data module, because some of the blocks and connections in the offline module may be used to analyze and view data in different parts of the module, e.g., to verify whether a particular part of the data model is performing as desired and / or providing sufficiently useful and / or predictive data. Generally, offline diagrams of data models are used to (1) explore and clean raw datasets, and (2) perform classification, regression, clustering, and dimensionality reduction. Data Studio is a representation of a workflow that can be constructed, adjusted, and evaluated for a desired analytical operation, such as a workflow. Data modules that are offline may be evaluated incrementally or continuously while they are being developed. The results of the evaluation process for offline data modules or data models are communicated to the user via Data Studio.

[0125] In some cases, the execution or evaluation of offline data modules may take an extended period of time to complete. In these situations, the status and progress of the offline data module evaluation process may be communicated to the user via another mode of operation of the DDE User Interface Application, which is referred to interchangeably herein as the “Data Analytics Dashboard,” “Analytics Dashboard,” or simply “Dashboard.” The Dashboard is typically utilized by the user to view and / or manage modules that are (i) offline data modules (e.g., draft data models) being evaluated and / or (ii) online data modules (e.g., completed data models being deployed as data modules). The Dashboard also represents the draft data models being evaluated and the deployed online data modules using respective diagrams or visual graphical representations. The deployed data modules are referred to as “online” because the deployed modules are executing based on real-time data being generated due to the online or runtime operation of the process control system or plant 5. Generally, an online diagram of a data module is a representation of a workflow that binds to one or more data sources (e.g., streaming data sources) within a process control system or plant 5 to create real-time descriptions, predictions, and / or prescriptions, and / or continuously adjust data models during or at runtime. Data modules that are deployed or online may run continuously until they are explicitly terminated from the Dashboard.

[0126] A. Data Module Diagram An exemplary diagram of a data module (whether offline or online) generally includes multiple data blocks and wires that interconnect the various blocks together to form one or more data flow pipelines. As previously mentioned, a data block is generally an abstraction of a function or operation that a user wants to apply to a dataset. For example, one particular block may load a dataset from data storage or a file on disk, another particular block may remove all missing values ​​in the dataset (e.g., values ​​that have no measurements at times corresponding to times when another parameter / variable has a measurement), and yet another particular data block may perform a random forest analysis. Typically, different data blocks correspond to different functions or operations that can be performed on a dataset, and thus, the various data blocks may each have a corresponding type or name, such as “Load,” “Query,” “Fill,” “Columns,” “PCA (Principal Component Analysis),” “PLS (Partial Least Squares),” “Explore,” “Write,” etc.

[0127] Each block may have zero or more respective properties. A block's set of properties (which may be an empty set for some blocks) corresponds to its block type, so that all instances of the same block type have the same set of properties. For some blocks, the default values ​​of the properties are specified in the DDE A User Interface Application may be provided, and for some blocks, a user may enter and / or modify one or more of the property values. A data block definition defines each property and any default property values ​​for a data block type (as well as other information for some blocks). Data block definitions are stored in a data block definition library provided by the DDE User Interface Application. Generally, the data block definition library is available to all open instances of the DDE User Interface Application so that multiple data analysis users or engineers can simultaneously develop and / or explore data using the resources provided by the library.

[0128] Each block has zero, one, or more input connectors that specify the data (if any) flowing into the block from one or more other blocks or data sources. In addition, each block has zero, one, or more output connectors that specify the data (if any) flowing out of the block (and potentially into one or more receiving blocks via their respective input connectors). The interconnections between the inputs and outputs of various blocks are represented in the data module diagram by wires. Any kind of data can flow or be transported through any wire, from the value of a simple counting device to data frames each containing millions of values ​​for the target code.

[0129] Additionally, each block has a state. For example, when a block is first created, it is in a "configuring" or "configuring" or "not configured" state. After a block is configured, it moves to a "configured" state. While an offline block is being evaluated, it is in an "evaluating" state. After an offline block is evaluated, it moves to either an evaluation "success" state or an evaluation "failure" state. When an online block is configured or bound to a data source and / or data consumer, its state is "configuring" or "binding." After an online block is deployed to a process control system and begins operating based on live data, its state is "deployed" or "running." Of course, other states are also possible. Typically, each block includes a visual indicator that indicates its current state. Additionally, each data module as a whole may have an indicator that indicates its current state.

[0130] An example data diagram 200 illustrating various possible data block characteristics and interconnections is shown in Figure 4A. This example data diagram 200 includes a LoadData block 202a connected to a FillNaN block 202b via a wire 205. The representation of LoadData block 202a includes an indicator 208a of its current block state, an indicator 210a of its block type or name, an indicator 212a of the result of the block's evaluation, and an output connector 215a, through which at least a portion of the data generated as a result of the LoadData block's evaluation is delivered over wire 205 to a recipient (in this scenario, FillNaN block 202b).

[0131] FillNaN block 202b includes an input connector 218b that receives data flowing from LoadData block 202a over wire 205. Like LoadData block 202a, FillNaN block 202b includes an indicator 208b of its current block state, an indicator 210b of its block type or name, an indicator 212b of the result of its evaluation, and an output connector 215b through which at least a portion of the data generated as a result of the FillNaN block's evaluation is delivered over wire 220 to a recipient or consumer (not shown).

[0132] 4A, LoadData block 202a has no input connectors because LoadData block 202a does not receive data output from any other data block in data diagram 200. Instead, LoadData block 202a may be configured to load or acquire one or more input data sets from one or more data sources. These data sources may include offline data sources such as data files, data sources (e.g., the Seeq system), relational databases, or non-relational databases, and / or the data sources may include online or streaming data sources such as data streams generated by distributed data engine 202x.

[0133] B. Data Analytics Studio As previously mentioned, one of the modes of operation of the DDE User Interface Application is the Data Analytics Studio. The Data Analytics Studio can be utilized by a user to design, develop, view, and explore data models. FIG. 4B depicts an exemplary user interface presented by the Data Analytics Studio 240, which includes a navigation bar 242 and a workspace or drawing canvas 245. The navigation bar 242 provides controls and indicators through which a user can manage offline and online data modules. This is because the user can now perform actions such as, for example, creating a new offline data module, identifying an offline or online data module that is currently open and shown on the canvas 245, easily viewing the status (e.g., offline or online) of a data module that is currently open and shown on the canvas 245, saving / storing an offline data module that is currently open and shown on the canvas 245, converting an offline module to an online data module, switching between viewing an offline data diagram and an online data diagram of a data module, evaluating an offline data module, expanding an online data module, browsing to other data modules, and other such module management functions. Accordingly, the Data Analytics Studio 240 includes a number of user controls and indicators 248a-248n thereon, including, but not limited to: · Module navigation controls 248a that allow the user to search and browse other data modules; · Identifier 248b of the data module currently open on the canvas 245; one or more indicators 248c, 248d that indicate whether the view of the data module currently open on the canvas 245 is an offline view or an online view; one or more controls 248e, 248f that allow the user to switch between an online view and an offline view of the data modules currently open on the canvas 245; User controls 248g that allow the user to view and / or define properties of the data module currently open on the canvas 245; A user control 248h that allows the user to save the currently open data module; User controls 248i that allow a user to evaluate at least a portion of the currently open data modules User control 248j, which allows the user to expand the currently open data module -Indicators showing the operation status of the currently opened module Ta248k; and / or one or more other user controls and / or indicators (not shown), etc.

[0134] 4B also illustrates user control 248m, through which a user can view, select, and / or add block definitions from a data block definition library (not shown in FIG. 4B). In the embodiment shown in FIG. 4B, library user control 248m is shown located on canvas 245, although in other embodiments, control 248m can be positioned on navigation bar 242 or any desired location.

[0135] Indeed, the number, type, location / positioning, form factor, arrangement, etc. of user controls and indicators shown in the exemplary Data Analytics Studio 240 is merely one of many possible embodiments. A greater or fewer number and / or type of user controls and / or indicators may be included. Different locations / positioning, as well as different form factors, arrangements, etc. of such user controls and / or indicators may be utilized. In some embodiments, the navigation bar 242 may be omitted, and another mechanism for the user to access the controls may be provided (e.g., a pop-up window, a drop-down menu, etc.).

[0136] 1. Data Analytics Studio - Offline Data Module In Data Analytics Studio 240, drawing canvas or workspace 245 is an area where offline data modules can be developed, defined, and evaluated. For example, in drawing canvas or workspace 245, a user can access the DDE User Interface Application's block definition library (e.g., via user control 248m) to select various data block definitions stored therein and interconnect (e.g., wire) the selected block definitions to form a data diagram for the data model. Additionally, in drawing canvas or workspace 245, a user can edit the properties of specific data block instances; evaluate portions of a draft data model, including viewing the evaluation progress and results; and / or perform other actions related to the offline data modules.

[0137] As discussed above, each data block that may be utilized in a data diagram is based on a block definition for that data block's type. That is, a particular instance of a block of a given type has a set of properties that conform to the block definition for that given type, but the particular instance may differ from other instances of the same given type of block, for example, in a manner similar to an object class and instances of an object class. As also discussed above, block definitions are stored in a block definition library, which is accessed (e.g., shown or hidden) via user controls 248m that may be placed on the canvas 245.

[0138] An illustration of an example relationship 250 between a data block definition library, data block definitions, data modules, data blocks, data block instances, and wires is shown in Figure 4C. As shown in Figure 4C, block definitions are made available through a block definition library 252 provided by the DDE User Interface Application. In some embodiments, different users and / or groups of users may have different access rights (e.g., read-only, read / write) to particular block definitions and / or other data analysis library resources (and / or portions thereof). (e.g., ki) may be given.

[0139] Block definitions 255 stored in library 252 may be utilized to create instances 258 of blocks 255 for use within data module 260. One or more properties 262 of block definition 255 may be specifically defined for block instances 258. Block instances 258 may be configured or designed to include one or more input connectors 265 through which data to the block instance 258 is received, and block instances 258 may be configured or designed to include one or more output connectors 270 through which output data (e.g., data resulting from evaluation of block instance 258 operating on input data received via input connectors 265) is provided, for example, to another block instance 258 (for writing or storage), a user interface, etc. Each input connector 265 of a block instance 258 may receive data over one or more wires 272 of data module 260, and each output connector 270 of a block instance 258 may provide data over one or more wires 272 of data module 260. Each wire 272 of a data module 260 provides an interconnection between a particular output connector 270 of a particular block instance 258 and a particular input connector 265 of another particular block instance 258, thereby enabling the transfer of data between the two data block instances.

[0140] In one embodiment, block definitions are organized in library 252 by categories of function or action. Categories may contain subcategories, which may contain sub-subcategories, and so on. In an illustrative but non-limiting example, block definition library 252 includes at least five categories of block definitions: Data Sources, Filters, Transformers, Visualizations, and Data Consumers.

[0141] Block definitions in the Data Sources category typically define various actions related to data sources that provide input data on which a data module operates. For example, block definitions in the Data Sources category may include "CreateDataSet," which creates an input dataset; "LoadDataSet," which loads or acquires an existing dataset from an offline or online data source; "LoadDB," which loads or acquires data from a database (e.g., a process control database or an analytical database); and "SaveDataSet," which histories an input dataset for longer-term data storage (e.g., for testing the input dataset after its creation). Furthermore, some Data Sources categories may include one or more subcategories. For example, the CreateDataSet and LoadDataSet categories may each include respective subcategories for the specific dataset format and / or environment in which the dataset was created, such as CSV (comma-separated values), Raspberry Pi, Seeq, etc. Generally, offline Data Sources blocks are configured to acquire or access static data sources, such as data files, process control databases, analytical databases, etc. On the other hand, Online Data Sources blocks are typically configured with a binding definition that associates a particular instance of the Online Data Source block with one or more online data sources within the process plant. Compilation of the configured Online Data Source instantiates this binding so that the Online Data Source block receives streaming data generated by the one or more online data sources to which it is bound.

[0142] The Data Source category may have block definitions, such as "QueryDataSource" or "Query," that relate to searching for or obtaining selected data from one or more data sources. Query blocks may operate based on offline and / or online data sources. Generally, Query block definitions allow a data module to query, obtain, or request the identity of a particular type of data (e.g., as indicated by a column, tag, or other suitable identifier) ​​and / or to query, obtain, or request only data generated during a particular time interval (which may be multiple discrete time intervals). Still further, Query blocks can query any type of data, regardless of the format and / or environment in which the data is captured or stored. Further details of Query blocks are provided in later sections of this application.

[0143] Block definitions in the Filters category typically define various filtering techniques that can be performed on a dataset. For example, block definitions in the Filters category may include "Clip," "HighPass," "LowPass," "SGF (e.g., for Savitzky-Golay filtering)," "Exponential," "Averaging," "Wavelet," etc.

[0144] Block definitions included in the "Transformers" category of data block definition library 252 typically define various techniques for manipulating, analyzing, and / or otherwise transforming the contents of a dataset or a filtered dataset. For example, the Transformers category may include data block definitions in subcategories corresponding to cleaning an input dataset, such as "FillNaN" (e.g., filling dataset entries that are not numbers), "RmvOutlier" (e.g., removing outlier data), "CorrectBad" (e.g., correcting bad data detected in the input dataset), and "ExcludeBad" (e.g., excluding bad data detected). In addition, the Transformers category may include data block definitions in subcategories corresponding to manipulating the contents of an input dataset, such as "Scale," "Shift," "Split," "Merge," "CenterNormal," "DownSample," "TimeOffset," and "Columns." Furthermore, in some embodiments, the Transformers category may include block definitions in subcategories corresponding to aligning data in the input dataset, such as "TimeDelay," "LagCorrect," and the like.

[0145] The Transformers category may include data block definitions in subcategories corresponding to analyzing input datasets to gain knowledge and learn about their contents, such as "Sensitivity," "Clusters," "Random Forest," "CBP (e.g., Conditional Bayesian Probability Analysis)," "KMeans," "FourierTransform," "FastFourierTransform," "PLS," and "PCA." Some subcategories in the Transformers category may include one or more sub-subcategories. For example, the "PCA" subcategory of the Transformers category may include data block definitions in sub-subcategories corresponding to various principal component analysis techniques, such as "PCA_NIPALS" (PCA and nonlinear iterative partial least squares), "PCA_SVD" (PCA and singular value decomposition), and "PCA_Test."

[0146] Block definitions in the Visualizations category typically define various techniques for presenting the output generated by a data module. For example, the Visualizations category may include graphical and / or graphical visualizations such as "LineGraph", "Chart", "BarGraph", "ScatterChart", "Histogram", "DataGrid", "DataCloud", "Animation", etc. or may include subcategories corresponding to different visual representations. The Visualizations category may include subcategories corresponding to preparing output data for a particular graphical representation, such as "RoundSigFig."

[0147] Block definitions in the Data Consumers category typically define actions for various consumers or recipients of output data generated by a data module. For example, the Data Consumers category may include a subcategory, “Write,” which causes the output data to be written or saved to a file, database, or other static storage. This “Write” subcategory may then have respective subcategories corresponding to various types of locations, databases, database formats, file formats, etc., indicating where and how the output data is written or saved. The Data Consumers category may include a subcategory, “Publish,” which causes the output data to be streamed (e.g., over the analytical data network 112) or otherwise published or delivered to a subscriber or recipient of the data (e.g., a distributed data engine 102x, an online data module, an application running on a process control system, a user interface, etc.). In some embodiments, to convert an offline Publish block into its online version, the Publish data block is configured and bound to a live data consumer (e.g., an online data module, a running application, a process control device, element, or component, etc., that has a subscription to the output of the data model). In one embodiment, the Data Consumers category may include a subcategory, "Convert2Control," which converts the output data into a signal in a format understood by a conventional process control communication network and delivers the signal via the conventional process control communication network to a process control entity, element, device, or component to effect or cause a change in the process plant 5.The subcategory "Convert2Control" may include sub-subcategories corresponding to, for example, various conventional process protocol formats (e.g., HART, PROFIBUS, WirelessHART, etc.) and / or various targets within the process plant 5 that are potential recipients of change signals (e.g., control loop inputs, control loop configurations, message priorities, parameter values, etc.). For example, the Convert2Control block may be configured to bind to a particular process control entity, element, device, or component within the process plant 5 that receives the output of the Convert2Control block and modifies its operation accordingly.

[0148] The data block definition library 252 may contain other data block definitions therein, each of which may or may not belong to a category. For example, the "Explore" block allows a user to explore the output data generated by these other data blocks in offline mode. For example, the Explore data block may accept multiple different data wires at its input connectors and generate a visual representation that includes both sets of input data in a comparative manner, for example, by aligning two input data sets over time and creating a histogram, overlaying one line graph on top of another, thereby displaying information from each respective data set next to information from the other data set. The Explore block allows a user to manipulate its output visualization, for example, by increasing / decreasing the scale of the x-axis and / or y-axis, arranging and / or filtering statistical data displayed in a chart. Note that the Explore block may not have an online counterpart, as its function is primarily to allow a user to explore and understand the output data generated by the draft data model.

[0149] When a user develops a new data model, the user can invoke data block definition library 252 (e.g., by toggling via user control 248m). The user can add a desired data block to canvas 245 by dragging and dropping the desired data block definition from library 252 to the desired location on canvas 245 (thereby adding the data block to the data module under development depicted on canvas 245). (Of course, drag-and-drop is only one way of indicating the selection, positioning, and incorporation of a particular data block into a data module; many other suitable ways of doing so are possible.) After the drag-and-drop operation, the selected block definition is associated with the draft data module, and a respective instance of that data block for the draft data model is created and named. In the exemplary scenario illustrated in FIG. 4D , draft Module A1 is in the middle of the development process, and its corresponding draft offline data diagram is shown on Data Studio canvas 245. As indicated by indicator 248c, Module A1 has an “offline” status. The user has already added blocks A1-B1, A1-B2, and A1-B3 to draft Module A1 and connected them with wires A1-W1 and A1-W2. The user invokes library 252 via control 248m, selects block B4 from the library, and drags and drops block B4 onto canvas 245 (as indicated by the dashed line), in the process of naming an instance of block B4 "A1-B4." After naming the instance of block B4, the user may interconnect A1-B4 with one or more other data blocks in draft Module A1 with wires. For example, the user may hover the cursor over an input connector of A1-B4 and click to create a new wire connection to the selected input connector.The user may then click on a desired output connector of another block instance on the canvas 245 to create a new wire interconnecting the selected input connector to the desired output connector, thereby interconnecting the two block instances. In another example, the user may hover the cursor over an output connector of another block instance and click to create a new wire connection to the selected output connector, and then click on a desired input connector of A1-B4 to create the interconnecting wire. Of course, any suitable user control mechanism may be utilized to create wire interconnections between block instances.

[0150] In the Data Studio canvas 245, a user can modify the value of a given property of a block for a particular block instance. For illustrative purposes, FIG. 4E depicts a portion of the Data Studio canvas 245, in which data module B1 is being developed. Two block instances contained in draft Module B1, namely B1-FillNaN and B1-PCA, are positioned and interconnected on the canvas 245. B1-FillNaN receives its input data set from a data source not shown in FIG. 4E, and B1-PCA provides two outputs, “Model” 280a and “Scores” 280b, to respective consumer or receiving blocks (also not shown). The user indicates that he or she wants to modify the value of a block-defined property corresponding to the B1-PCA block instance (e.g., by hovering over the B1-PCA block instance, by double-clicking on the B1-PCA block, or by using any other suitable user control mechanism). In response to activation of the user control, a window 282 appears (e.g., as a floating dialog box, a pop-up window, or some other suitable representation) containing a list of defined properties corresponding to the PCA block definition. The user can then modify the values ​​of the various block properties of the B1-PCA as desired via window 282. It is possible.

[0151] As previously discussed, the properties of each data block, if any, are defined by its respective block definition, which is stored in block definition library 252. Illustrative (but non-limiting) examples of block definitions and their respective properties are shown in Figures 4F-4H. It is understood that block definition library 252 may include one or more, none, and / or other block definitions of the example block definitions shown in Figures 4F-4H. Furthermore, the number, types, and default values ​​of the properties of each example block definition shown in Figures 4F-4H may also differ from the examples described herein.

[0152] 4F , a data block definition template for a “LoadDB” data block 285a is presented by the DDE User Interface Application, for example, as a result of a user dragging a LoadDB block definition from library 252 onto canvas 245 and subsequently indicating that they wish to view and / or modify block property values ​​of the LoadDB data block 285a to create a particular instance of the block 285a. Actions or functions performed by the LoadDB block 285a within the offline diagram of the data model include loading a particular data set (or otherwise obtaining the contents of that data set) on which the operation of the data model is based. For example, a particular input data set may be loaded or obtained from a database or file. A user can indicate a particular input data set to be loaded into the data model by entering a desired name, indicator, or value in the DatabaseName property field 285b and the DataSet property field 285c, for example, via drop-down menus, search and selection (e.g., of a process control database or other database associated with a process control system), free-form text entry, etc. For example, a user can select a desired DatabaseName 285b from a drop-down menu, and that selection of the desired database 285b results in the provision of a corresponding drop-down menu in the DataSet field 285c that includes only the datasets 285c of the selected / identified database 285b. The LoadDB block 285a also includes a Plot property field 285d, which in this implementation is a Boolean flag whose value indicates whether a plot of the dataset 285c from the database 285b is generated / presented when the LoadDB block instance is evaluated.If Plot 285d is set to "Yes," after block evaluation, a plot of the loaded data set 285c is displayed in the graphical representation of the LoadDB block instance shown on the canvas 245, for example, in the View Block Results area 212 of the LoadDB block instance. For the LoadDB block 285a, the Plot property 285d is optional, and its value is "None" by default (e.g., no plot of the loaded input data set is generated / presented when the block is evaluated). After the user enters all desired values ​​into the property fields 285b, 285c, and 285d of the LoadDB data block 285a, the user can save the modified property values, thereby configuring the LoadDB data block template 285a to create specific instances of the LoadDB data block 285a for use in the data model the user is creating / developing. The user can name the specific instance, for example, by entering a desired name (e.g., "LoadDB-1") in the block name field 210 of the block instance shown on the canvas 245.

[0153] Figure 4G shows the DDE User Interface Application 4G illustrates a data block definition template for a "Columns" data block 286a. A particular instance of the Columns data block 286a extracts or acquires a selected group of data (referred to herein as the data's "columns" or "tags") from a loaded / acquired dataset, as specified by its property value in the SelectedColumns property field 286b. For example, the Columns data block 286a receives a dataset (or some indication thereof, such as a pointer, indicator, or other reference to the dataset) via its input connector, for example, from an instance of the LoadDB data block 285a. The SelectedColumns property 286b of the Columns data block 286a allows the user to select one or more columns, tags, or other portions of the input dataset upon which the user wants other blocks in the data model to act. For example, as shown in FIG. 4G, the user is in the process of scrolling through a list of tags for DatasetA and highlighting a desired tag. Typically (but not necessarily), the selected columns or tags are a subset of all columns or tags contained in the input data set. A user can save the column or tag selections 286b (and other block properties, if present) to configure the Columns data block 286a to create a specific instance, e.g., for use in a data model the user is creating / developing. A user can name a specific instance of Columns 286a, for example, by entering a desired name in its block name field 210.

[0154] FIG. 4H illustrates a data block definition template for the “PCA_NIPALS” data block 287a presented by the DDE User Interface Application. The PCA_NIPALS data block 287a performs principal component analysis (PCA) and nonlinear iterative partial least squares on a set of data. For example, the PCA_NIPALS data block 287a may receive via its input connector columns or tags of data (or indicators or references thereto) determined by an instance of the Columns data block 286a. In another example, the PCA_NIPALS data block 287a may receive via its input connector an entire data set (or indicators or references thereto) loaded for use by a data model by the LoadDB 285a data block. The template for the PCA_NIPALS block 287a allows the user to select the number of PCA components 287b and confidence level 287c, if desired. Both property fields 287b, 287c are optional for the PCA_NIPALS block 287a and may be set to default values ​​(e.g., defined in the block definition of PCA_NIPALS) or zero. In the example scenario shown in Figure 4H, the user indicates that the current instance of PCA_NIPALS is configured to generate two components 287b and a confidence level 287c of at least 95%. The PCA_NIPALS data block 287a template can be configured (with or without modifying property values) to create a specific instance to be used in the data model the user is creating / developing, and the user can name the specific instance, for example, by entering a desired name in its block name field 210.

[0155] Some types of data blocks are consumer or receiving data blocks that operate on output data generated by previous blocks. These types of consumer data blocks may require previous blocks to be evaluated in order to construct these consumer data blocks. For example, an instance of LoadDB block 485a provides data to an instance of Columns block 486a. As wired to do so, evaluation of the LoadDB block instance 485a provides a data set from which the user may select specific columns or tags to configure the Columns block instance 486a.

[0156] Turning now to the evaluation of offline data blocks and data modules, an offline data module can be evaluated repeatedly as it is being developed and need not be fully completed in order to be evaluated. Thus, evaluation of an offline data module can be performed asynchronously, allowing a user to evaluate portions of a draft data module, modify the draft data module based on the evaluation, re-evaluate, re-modify, re-evaluate, and so on. For example, a user may create a starting data block for a data module, evaluate that single data block, then connect a second data block to the first and evaluate only the second data block (or evaluate both the first and second data blocks as a whole), add four more data blocks, and evaluate only the newly added data blocks (or evaluate all six data blocks as a whole), etc. That is, when a desired number of data block instances and / or associated wires have been added to a working data diagram of an offline or draft data module, the module (or portion thereof) represented in canvas 245 can be evaluated, for example, by activating evaluation user control 248 i in navigation bar 242. For example, if a user desires to evaluate the entirety of the blocks and wires presented on canvas 245, the user may simply evaluate user controls 248i. On the other hand, if a user desires to evaluate only a subset of the blocks and wires presented on canvas 245, the user may select the desired blocks and / or wires (e.g., with a click, a lasso tool, or other suitable mechanism) and then activate controls 248i to cause the selected set of blocks and wires to be evaluated.

[0157] FIG. 4I illustrates an example of how the offline data diagram 288 may be evaluated. While the offline data diagram 288 is being created or developed, the Data The representation of the blocks and interconnections shown on the Studio canvas 245 is stored in a transmission file or document 290 (also referred to herein as a “configuration file”), which may be in a lightweight data exchange format such as JSON (Java Script Object Notation) or any other desired format. Thus, the graphical offline data diagram 288 is bound to the transmission storage file or document 290. When a user indicates that he or she wants the offline data diagram 288, or a portion thereof, evaluated (e.g., by activating a user control 248i), the transmission file or document 290 is compiled into the language of the target execution environment, thereby generating executable code 292 for the data diagram 288. In some embodiments, the transmission file or document 290 may be split into multiple parts, each of which is compiled into a different target language that is executable in a different target environment (e.g., multiple chunks or segments of executable code 292 in different target languages ​​may be generated from the transmission storage file or document 290). After executable code 292 for offline data diagram 288 is generated, a process is created to manage and coordinate the execution of code 292, which may or may not span different target environments and / or may or may not be executed by different processors.

[0158] As various blocks of the offline data diagram 285 are executed or evaluated, the process may send feedback to Data Studio. For example, Based on feedback from the process, Data Studio updates the respective status indicator 208 of each data block in the offline diagram 285 to indicate whether the block is compiling, evaluating, successfully, or unsuccessfully (e.g., failed). Indeed, generally throughout the compilation and execution process illustrated in FIG. 4I, feedback may be returned to Data Studio and displayed in the user interface. For example, based on feedback from the process, Data Studio updates module status indicator 248k and / or offline status indicator 248c to indicate whether the module as a whole is being compiled, evaluated, successfully, or unsuccessfully evaluated.

[0159] In the DDE User Interface Application, the infrastructure and actions used to evaluate offline data blocks, diagrams, and modules are provided by Data Analytics Services. For example, activation of evaluation user control 248i invokes Data Analytics Services to perform an evaluation of the offline data block, diagram, or module (or portions thereof) currently being developed on canvas 245, which may, for example, utilize multiple different backend platforms (e.g., multiple different target languages, compilers, processors, and / or target environments). Thus, the DDE User Interface Application shields users from having to interact with (or have knowledge of) the backend platform utilized to implement the data block, diagram, or module. That is, users can utilize Data Studio and Dashboard features (e.g., data block definition library 252, canvas 245, and associated user controls) not only to design or manipulate data modules using data diagrams, but also to deploy those designs in real time and independently of the backend platform, which is managed "behind the scenes" by Data Analytics Services. The DDE User Interface Application architecture also advantageously allows additional back-end platforms and / or components to be added or removed without affecting user-facing data module design, evaluation, testing, and deployment functionality.

[0160] A more detailed description of Data Analytics Services and its evaluation support is provided in a later section.

[0161] Referring to FIG. 4A , as previously discussed, evaluation of data modules in offline mode can be an iterative process. As a user adds and configures blocks for a draft data module, the user can evaluate the added blocks, with each block's status reflected by its respective status icon (e.g., indicator 208 shown in FIG. 4A ). In situations where a block's evaluation is unsuccessful or fails, the user can obtain details about the failure (e.g., by selecting or clicking the “Failed” status indicator 208) so that the user can address any issues that led to the failure. In situations where a block's evaluation is successful, the user can view the results of the block evaluation, for example, by selecting or clicking the block's respective view block results icon 212. In some embodiments, when a user selects “View Block Results” 212, a modal dialog or visualization dialog may appear (e.g., as a pop-up window, floating dialog box, or other suitable format) allowing the user to view and explore various visualizations to view the data block results. It is possible.

[0162] Indeed, when a data block is executed or evaluated, it may store any kind of result(s) that may be useful to assist a user in determining the effect(s) of the data block acting on data transported to it (e.g., via wires and input connectors). The type(s) of result(s) stored are typically specific to the block (and, in some cases, specific to a particular instance of the block) and may be defined or determined by the block developer. These results may be presented to the user via modal or visualization dialog windows.

[0163] In addition to block- and / or block-instance-specific results, the DDE User Interface Application may provide standard visualizations that may be applicable to more than one (and, in some cases, most or all) of the data blocks. For example, when a block is executed, a standard set of various statistics about the state of the data may be collected at the end of the block's execution, such that the mean, standard deviation, and other such statistics may be calculated for each column, tag, or portion of the data set and stored with the resulting data set. When the visualization dialog for a particular block instance is presented (e.g., via activation of the respective user control 212), the calculated set of standard statistics for each column, tag, or portion is retrieved from the data store and presented to the user. The user can then select the columns / tags / portions of interest and request Data Studio to generate respective charts or other visual formats (e.g., line plots, scatter plots, histograms, data grids, data summary grids, calculated statistics and histograms showing the distribution of the data, etc.) that represent the statistics for that column / tag / portion. In some embodiments, the statistics and the data set are stored independently, as storing the statistics independently from the resulting data set is advantageously easier than using the DDE User Interface. This allows the application to load only the amount of data required into the browser.

[0164] An exemplary architecture 300 for presenting standard and custom visualizations is shown in FIG. 4J. In the exemplary architecture 300, the data block code for “Block1” 302 is executed, generating a resulting data set 305, calculated standard statistics / other visualizations 308, and Block1-specific results 310, which are stored in a local or remote storage area 312 managed by a DDE User Interface Application. In a Data Studio instance 315 (e.g., a browser window), when a user selects the “View Block Results” user control 212 displayed in the Block1 graphic, the calculated statistics 308 (e.g., the standard set and / or any custom visualizations) for Block1 are loaded 318 into the Data Studio instance 315, and the user can select the desired columns, tags, or portions of interest. Once the user selects the desired columns / tags / portions of Block1, the corresponding data is loaded 320 into the Data Studio instance 315 for viewing and exploration by the user.

[0165] Over time, as multiple data modules are configured, for example, within the same process control system 5 and / or across an enterprise having multiple process control systems, common patterns of block configuration and usage may emerge. When such commonality is identified, it may be desirable to group a set of individual data blocks to form a new block, e.g., a composite block, that encapsulates their common behavior. In some scenarios, it may be desirable to define a custom unified data block, for example, when a particular set of property values ​​is found to be repeated over time, or when the user desires to define a custom data operation or function. Custom and / or composite data blocks may be created and stored within the library 252 so that they are available for use in other data modules. An exemplary scenario 330 illustrating the creation of a composite data block is shown in FIG. 4K. In a data diagram 332, a user selects two unified data blocks with a particular relationship (e.g., "Fill NaN" and "Scale") 335 to form a new composite block. Using a modal dialog box, pop-up window, or other suitable interface provided by Data Studio, the user configures or defines a new composite block with the desired name "Fill & Scale" and saves this new "Fill & Scale" composite block to the data block definition library 252 (reference 338). After "Fill & Scale" has been defined and saved for some time, this new composite block can be incorporated into another data diagram 339 instead of using the separate "Fill NaN" and "Scale" data blocks.

[0166] FIG. 4L depicts an example offline data diagram 340 illustrating some of the above-described features and principles, which will be described herein with simultaneous reference to FIGS. 4A, 4B, and 4F-4H. In FIG. 4L, the example offline data diagram 340 was created by a user on a user canvas 245 of Data Studio. Specifically, the user invoked the block definition library 252, e.g., by activating control 248m on the canvas 245, and dragged and dropped a LoadDB block template 285a onto the canvas 245. Furthermore, the user named this particular instance of the LoadDB block 285a "LoadDB4M" (reference 342a) and configured the LoadDB4M block instance 342a to load Dataset4 from Database M, e.g., by setting property values ​​in fields 285c and 285b of the LoadDB4M block 342a. Additionally, although not explicitly depicted in FIG. 4L, the user set the Plot property value 285d of LoadDB4M342a to “True” when evaluating block LoadDB4M342a so that a plot of the loaded Dataset4 is generated and presented in the View Block Results field 212a of LoadDB4M block 342a.

[0167] After the user configured the LoadDB4M block instance 342a, the user connected two receiving Columns block instances 342b and 342c to the output of the LoadDB4M block instance 342a. For example, the user dragged and dropped two different instances of the Columns data block template 286a onto the canvas 245 and named these instances "Columns X" (reference 342b) and "Columns Y" (reference 342c), respectively. Furthermore, the user connected each of the inputs of the Columns X block 342b and the Columns Y block 342c to the output of the LoadDB4M block 342a using interconnect wires.

[0168] The user also configured Columns X block 342b and Columns Y block 342c to be based on the evaluation of LoadDB4M block 342a. Specifically, the user first evaluated LoadDB4M block 342a (e.g., by selecting the image of block 342a on canvas 245 and activating "Evaluate" user control 248i), thereby causing LoadDB4M block 342a to be compiled and executed to load or acquire Dataset4 from Database M. Because the Plot property of LoadDB4M block 342a is set to “True,” this evaluation of LoadDB4M block 342a also causes a Plot of the loaded Dataset4 to be displayed, for example, in the View Block Results field 202a of LoadDB4M block 342a (not shown in FIG. 4L). Using this plot, the user can view and explore various columns, tags, or subgroupings of data in Dataset4, and then configure Columns X block 342b to receive subgroups or columns of data labeled or tagged with “X” in Dataset4 and configure Columns Y block 342c to receive subgroups or columns of data labeled or tagged with “Y” in Dataset4 (e.g., by selecting the appropriate subgroup, column, or tag indicator in the property field 286b of the Columns block template 286a for each of Columns blocks 342b, 342c, respectively). Thus, evaluation of Columns X block 342b results in only data from Dataset4 that is characterized, labeled, or tagged as "X" being loaded or accessed in block 342b, and evaluation of Columns Y block 342c results in only data from Dataset4 that is characterized, labeled, or tagged as "Y" being loaded or accessed in block 342c.

[0169] The user also dragged, dropped, and configured a Partial Least Squares (PLS) block in the offline data diagram 340. Specifically, the user named a PLS block instance 342d "PLS4M_X_Y" and configured the PLS4M_X_Y block 342d to receive the output of the Columns X block 342b and the output of the Columns Y block 342c at its respective inputs. The PLS4M_X_Y block 342c runs or performs a partial least squares function, action, algorithm, or operation on the data provided by the Columns X block 342b and the Columns Y block 342c, and the results (e.g., respective PLS models generated based on the relationship between the Columns X and Columns Y data) are provided to the Explore4M_X_Y block 342e via the output of the PLS4M_X_Y block 342d. Like the other blocks 342a-342d, the Explore4M_X_Y block 342e is an instance of a respective Explore block definition that the user drags and drops onto the canvas 245, names, and configures.

[0170] In offline diagram 340, Explore4M_X_Y block 342e is configured to receive the output generated by PLS4M_X_Y block 342d, but in addition to 342d, a user has also configured Explore4M_X_Y block 342e to receive as input the direct output of Columns Y block 342c, e.g., via wire 342f. This configuration allows a user to explore the relationship between the output of PLS4M_X_Y block 342c and the output of Columns Y block 342c through Explore4M_X_Y block 342e, e.g., by presenting one or more visualizations and / or statistics. For example, the output of PLS4M_X_Y block 342c typically includes one or more predicted values. The Explore4M_X_Y block 342e allows a user to compare one or more predicted values ​​included in the output of the PLS4M_X_Y block 342c with the actual values ​​of the Columns Y block 342c to determine, for example, whether the use of the Columns X data 342b in the PLS4M_X_Y model 342d adequately predicts the Columns Y data 342c.

[0171] In this offline data diagram, neither the PLS4M_X_Y block 342d nor the Explore4M_X_Y block 342e has completed its own configuration. It is noted that the configuration of each of the PLS4M_X_Y blocks 342d and the Explore4M_X_Y blocks 342e does not require that its immediately preceding block(s) be evaluated before it can be evaluated. That is, the configuration of each of the PLS4M_X_Y blocks 342d and the Explore4M_X_Y blocks 342e can be performed independently of the evaluation of the other blocks and at any time. However, because the offline data diagram 340 represents one or more data pipelines or data flows, the evaluation of each downstream data block typically requires that its upstream data block(s) be evaluated before that downstream data block can be evaluated (unless, of course, the receiving or downstream data block merely receives a test or dummy input data set for the individual block evaluation process). In fact, in some scenarios, a user may configure and / or evaluate the entire offline data diagram 340 altogether, rather than evaluating it block by block or portion by portion.

[0172] 2. Data Analytics Studio - Online Data Module Returning now to FIG. 4B , after the offline data diagram of a data model has been completed and evaluated to the user's satisfaction in Data Studio, the offline data diagram can be translated or converted into its corresponding online form. To convert the offline data diagram to its online form, the user selects or activates the online toggle or user control 248f of the navigation bar 242, thereby causing the DDE User Interface Application to convert the offline data diagram into its online equivalent and display the online data diagram of the data model on the canvas 245. Certain offline data blocks may have online equivalent definitions (e.g., offline and online versions of the “Load” data block), while other offline data blocks may not require different online equivalents but are still included in the online data module (e.g., a “FillNaN” block or a “PCA_NIPALS” block), while still other offline data blocks are omitted in the online data module (e.g., an “Explore” block). The infrastructure and actions performed during the conversion of an offline diagram to its online equivalent are provided by Data Analytics Services. For example, activation of user control 248f invokes Data Analytics Services to perform a transformation of the offline data diagram into its corresponding online data diagram. A more detailed description of how Data Analytics Services performs this transformation is provided below in the description of Data Analytics Services.

[0173] When the online data diagram for a data module is presented on the Data Studio canvas 245, a user can configure the online data module. Configuring an online data module typically involves indicating live process control data related to the control of a process that is acquired as input data for the online data module, for example, by defining bindings that associate the online data module with data sources of corresponding input data. In addition, configuring an online data module may include indicating (e.g., by defining bindings) the location(s) and / or consumer (e.g., one or more consumer DDEs and / or applications, data stores, files, historians, process control devices, routines, elements, components, etc.) to which output data generated by the online data module is provided. Configuring and / or modifying the data blocks of an online data module, their respective properties, and interconnections is, in some embodiments, performed in a manner similar to that discussed above with respect to offline data modules. will be done.

[0174] If the user identifies a problem or issue with the online data module or otherwise desires to modify the online data module, the user can flip or switch the online data module to its offline representation, for example, by utilizing offline switch or user control 248d, and the user can further modify and evaluate the offline data diagram of the data model as described above. Later, when the user flips or switches the offline data diagram to its online representation, the modified offline data diagram is transformed into the online data diagram of the corresponding data model.

[0175] Figure 4M illustrates an online data diagram 345 that corresponds to the example offline data diagram 340 of Figure 4L, and Figure 4M will be discussed below with simultaneous reference to Figures 4A, 4B, 4F-4H, and 4L. In the example scenario depicted in Figure 4M, a user has determined that the offline diagram 340 of Figure 4L defines the data model as intended or desired, and that this data model is ready for deployment to an online process control system. Thus, while the Studio is viewing the offline data diagram 340 (e.g., the one shown in Figure 4L), the user activates the online toggle 248f of Data Studio, thereby converting the offline data diagram 340 into a corresponding online data diagram 345, which is presented on the Data Studio canvas 245, as shown in Figure 4M. This transformation is performed by the Data Analytics Services of the DDE User Interface Application, and the specific actions, mechanisms, and architecture utilized by Data Analytics Services to perform this and other transformations are described in more detail in later sections.

[0176] Note that while the online data diagram 345 and the offline data diagram 340 represent the same data model, the sets of blocks and wires in the two data diagrams 345, 340 are different. For example, the data pipeline in the offline data diagram 340, which starts at the output of the LoadDB4M block 342a, traverses the Columns Y block 342e, and terminates at the input of the Explore4M_X_Y block 342e, is omitted from the online data diagram 345. This is because this data pipeline was utilized in the offline data diagram 340 to test and verify the offline PLS4M_X_Y block 342d, and is not necessary in the online environment, now that the validity of the PLS4M_X_Y block 342d has been proven to the user's satisfaction. However, in some embodiments, a user may choose to include this verification data pipeline in the online data diagram 345, for example, if the user desires to perform continuous testing and verification of the online data model in the online environment.

[0177] Another difference between offline data diagram 340 and online data diagram 345 is the LoadDB4M block. In offline data diagram 340, LoadDB4M block 342a is configured to load data from offline data source Dataset4 of Database M. However, in online data diagram 345, LoadDB4M block 347a has been transformed into a block that can connect to online data sources, such as online streaming data sources in process plant 5. A user can configure LoadDB4M block 347a to bind to a desired online data source, and the configured The compilation of the LoadDB4M block 347a instantiates the binding.

[0178] In the online data diagram 345, the Columns X block 347b is generally similar to or equivalent to its offline counterpart 342b. However, as previously discussed, the online counterpart of the PLS4M_X_Y block 347c receives only the inputs necessary for the PLS4M_X_Y block 347c to operate in an online environment, namely the outputs of the Columns X block 347b.

[0179] Additionally, the online data diagram 345 has no equivalent to the offline Explore4M_X_Y block 342e, because the purpose of the Explore4M_X_Y block 342e in the offline environment was to provide the user with insight into how well the draft data diagram 340 achieved the user's goals. In the online data diagram 345, the output of the PLS4M_X_Y block 347c is provided to a "Write" data block 347d, which is a type of Data Consumers data block. The Write data block 347d causes the real-time output of the PLS4M_X_Y block 347c in the online environment to be written to a file or database, as specified in the configuration of the Write block 347d. Of course, if the user so desires, the output of the PLS4M_X_Y block 347c can additionally or alternatively be provided to one or more other data consumers of the data model by interconnecting the output of the PLS4M_X_Y block 347c with the input of another Data Consumer block. For example, the PLS4M_X_Y block 347c can be connected to a Publish block such that the output of the PLS4M_X_Y block 347c is published to the data analysis network 112 and available for use by other data analysis applications. In another example, the PLS4M_X_Y block 347c can be connected to a Convert2Control block such that the output of the PLS4M_X_Y block 347c causes a change in an online process control system. For example, the Convert2Control block may be configured to convert the output of the PLS4M_X_Y block 347c into an input signal for a process control function, loop, or application within the process plant 5 and deliver the input signal to a corresponding process control industry, element, device, or component.

[0180] 3. Deploying Data Modules Typically, online data modules are not evaluated asynchronously, as was possible with offline data modules. Rather, online data modules are first configured (e.g., bound to live data sources and / or one or more data consumers / receivers) and then deployed as a whole to run continuously and interact with the online process control system. A user deploys a data module to the online process control system, for example, by clicking or activating the “Deploy” user control 248j in the navigation bar 242, thereby notifying Data Analytics Services to handle the deployment of the online data module. The infrastructure and actions used to deploy data modules are described in more detail in the description of Data Analytics Services. However, in general, when an online data module is deployed, it follows a compilation and execution process similar to that of an offline data module being evaluated, as illustrated, for example, in FIG. 4I. However, the target environment(s) of an online data module may differ from the target environment(s) of its corresponding offline data module, and the online data module may be bound to other sources live within the process control system or plant. will be done.

[0181] In one embodiment, the DDE User Interface Application supports "one-click" deployment. That is, when an offline data module is configured the way the user wants it, the user does not need to convert this data module to its online representation and configure bindings for the data blocks of the online representation that are responsible for reading and writing data from live data sources. Instead, during "one-click" deployment, as the user initiates it, any bindings required for the subject data module are automatically determined and configured by the DDE User Interface Application. In an exemplary scenario, a user may assign data modules to run against a specific DCS controller, for example, by using a dialog box or window provided by Data Studio that retrieves information about the DCS system hierarchy. The user may browse the hierarchy and assign data modules accordingly. The DDE User Interface Application (e.g., Data Studio and / or Data Analytics Services) then leverages the assigned process control system element (in this scenario, the specific DCS controller) to automatically determine the required bindings. An exemplary infrastructure and actions used to implement one-click deployment are described in more detail in the description of Data Analytics Services.

[0182] After the online data analytics module is successfully deployed, any resulting values ​​(e.g., descriptive, predictive, and / or prescriptive) generated by its execution can be presented to a user, for example, via the Data Dashboard of the DDE User Interface Application. In one embodiment, the resulting values ​​include at least one predicted value, and the corresponding real-time live data value(s) generated by the process control system 5 for the tag(s) or process control element to which the predicted value applies can also be presented along with the predicted value.

[0183] C. Data Analytics Dashboard As previously discussed, the DDE User Interface Application includes a second mode of operation, the Data Analytics Dashboard. The Dashboard is typically utilized by a user to view and / or manage modules, which are (i) offline data modules (e.g., draft data models) being evaluated and / or (ii) online data modules being deployed to an online process control system or plant. Using visual and other representations, the Dashboard provides the user with insight into the status and other information corresponding to the evaluation of offline data models, as well as insight into deployed online data modules and real-time or live information being generated by the online data modules. Generally, the Data Analytics Dashboard mode provides the user with an interface through which the user can monitor and manage online and offline data modules. The user can also terminate the evaluation of any offline data modules and the execution of any online data modules from the Dashboard. Generally, although not necessarily, at least a portion of the information displayed on the Data Analytics Dashboard is provided to the Dashboard 350 by the Data Analytics Services of the DDE User Interface Application.

[0184] Figure 4N-1 shows the DDE User Interface Application 3 depicts an exemplary user interface 350 presented by the Data Analytics Dashboard. A first portion 352 of the exemplary Dashboard user interface 350 provides current data analysis summary information, such as an indication of the number of online data modules 355 currently being monitored by the DDE User Interface Application and an indication of the number of live data streams 358 upon which the online data modules 355 are acting. As previously discussed, the live data streams 358 are received from one or more data sources continuously generating real-time data resulting from an online process control plant or environment 5 controlling one or more industrial processes, and the running online data modules 355 are configured to receive the live data streams 358. The data analysis summary information also includes an indication of the number of offline data modules 360 whose evaluation is currently being monitored by the DDE User Interface Application. In some embodiments, the Dashboard user interface 350 includes one or more other notifications or other information 362 related to the monitored data analysis modules, whether online or offline.

[0185] When the user clicks or otherwise activates one of the summary controls 355, 358, 360, 362, additional summary information corresponding to that selection is presented in a second portion 365 of the Dashboard 350. In FIG. 4N-1, the user has selected to view summary information for the currently running online data modules 355, of which there are currently two: Diagram 2, indicated by reference 368, and Diagram 3, indicated by reference 370. For each running online data module 360, 370, the second portion 365 of the Dashboard 350 shows its respective summary information, including the module's name 372, the start time 375 when the module was deployed, a trend indicator 378 of the module's output over the most recent time interval (which may be graphical, as shown in FIG. 4N-1), the most recent latest forecast or forecast value(s) 380, and / or other information (not shown). Of particular note, in Dashboard 350, the trend indicators 378 for each online data module 368, 370 are continuously updated to reflect the continuously generated output of the respective data module 368, 370, thereby allowing a user to monitor the execution of the online data modules and their continuously generated results in real time.

[0186] Additionally, the Data Analytics Dashboard 350 allows a user to click on any summary information associated with any data module 360, 378 to view further details, for example, in a pop-up window, dialog box, or other suitable display mechanism (not shown). For example, if a user clicks on the Name of Diagram2 368, the Dashboard 250 may present an online data module diagram for Diagram2 368 and an indication of one or more specific data streams 358 to which Diagram2 368 is bound. If a user clicks on the Start information for Diagram2 368, an indication of the creator of Diagram2 368, the user who deployed Diagram2 368, and / or the owner of Diagram2 368 may be presented. Clicking on the Trend 378 information in Diagram2 368 allows the user to manipulate and explore the output data trends in Diagram2 368, for example, by lengthening or shortening the time interval viewed, converting the trend information into a different type of visualization (e.g., bar chart, pie chart, scatter plot, etc.), applying and / or obtaining statistics about the trend data over a given interval (e.g., average, rolling average, maximum, minimum, etc.), etc. Similarly, clicking on the Last Prediction 380 information in Diagram2 368 allows the user to, for example, view the time of the latest prediction and how often the prediction is made, and compare the latest prediction with the current The latest forecast value(s) can be manipulated and explored, such as by comparison with live data values.

[0187] When a user selects user control 360 to view a currently executing offline data module (which is not present in the example scenario of FIG. 4N-1 ), additional summary information corresponding to the offline data module is presented in a second portion 365 of Dashboard 350. Generally, the summary information for an offline data module is similar to that for an online data module, except that instead of showing the associated live data stream, the summary information for the offline data module may show the test data file(s) or data streams generated by the offline data source(s) (e.g., test tool, device, and / or environment) on which the offline data is being executed. Additionally, the summary information for an offline data module may show the current status, state, and / or progress of its execution.

[0188] In some scenarios, a user can configure and / or deploy an offline data module from the Dashboard (rather than from Data Studio). For example, a user may be monitoring the evaluation of an offline data module from the Dashboard, and the offline data module successfully completes its evaluation. The user may activate a user control (not shown) in the Dashboard. Through this user control, the user can configure the data module to reference live data source(s) and the data generated by the live data source(s) on which the online data module runs. This configuration of binding the online data module to data source(s) is similar to the configuration described above, except that it is initiated from the Dashboard rather than from Data Studio. Alternatively, the user may take advantage of one-click deployment for offline data modules from the Dashboard.

[0189] When a user selects user control 358 to view information associated with the online data streams currently bound to the running online data modules (there are three in the example scenario of FIG. 4N-1 ), additional summary information corresponding to the online data streams is presented (not shown) in a second portion 365 of Dashboard 350. The summary information for each live data stream may include an identifier for the data stream, an indication of the data source from which the data stream is received, a corresponding process control system tag or other conventional process control system identifier for the live data source, information about the subscription(s) and / or publication of the data stream, an indication of one or more online data modules currently running based on the live data stream, a continuously updated visualization of the live data stream (e.g., a line graph, bar chart, scatter plot, etc., and / or basic statistics thereof), and / or other information.

[0190] Of particular note in the exemplary scenario depicted in FIG. 4N-1 is that while the data stream overview 358 indicates that there are currently three live data streams on which online data modules are acting, the online data module overview 355 indicates that there are only two running online modules. Thus, one of the two running online modules 368, 370 is acting on two of the live data streams. The user can see this relationship by navigating to view the details of each online data module 368, 370, which provides an indication of the data stream to which each module 368, 370 is bound, or by navigating to view the details of each data stream 358, which provides an indication of the running online data modules acting on each data stream 358. This can be found by navigating to view the details.

[0191] 4N-2 depicts an exemplary user interface 382 that may be presented by the Data Analytics Dashboard of the DDE User Interface Application. In one embodiment, the user interface 382 is included in the second portion 365 of the user interface 350 shown in FIG. 4N-1. In one embodiment, the user interface 382 is a full-screen view.

[0192] The user interface 382 includes one or more tiles or cards 385a-385j, each corresponding to a respective running online data module, which may collectively be referred to as a palette or deck of cards 385x. Each of the cards 385x in the palette may include information similar to that displayed for the running online data modules 360, 370 in FIG. 4N-1 , such as the module's name, the start time the module is deployed, a trend indicator of the module's output over the most recent time interval, the most recent updated forecast or forecast value(s), and / or other information. Also similar to the display for the running online data modules 360, 370, the trend indicator for each of the cards 385x is continuously updated to reflect the continuously generated output of its respective online data module, thereby allowing a user to monitor its execution and continuously generated results in real time.

[0193] Each of the cards 385x is resizable and movable as desired by the user. In some embodiments, the size of a particular card 385x increases when that particular card is focused. A card 385x may be manually focused when the user clicks on that particular card 385x, hovers over that particular card 385x, etc. Additionally or alternatively, a card 385x may be automatically focused when a particular data module requires urgent attention (e.g., when a predictive value exceeds a threshold, when the data module itself requires user input or intervention, ranking the importance of conditions within the card 385x, etc.). Other automatically generated indicators of needing attention may be indicated in the user interface 382 by, for example, highlighting or providing some other action for a particular card 385x, adjusting the size of a set of cards 385x according to their respective urgency, moving a particular card 385x to the foreground or front of a palette, or arranging cards 385x in order of attention priority. In some embodiments, a user may define specific actions that are automatically applied to card 385x in certain situations.

[0194] Returning now to the data block definitions 255 stored in the DDE User Interface Application's data block definition library 252 (e.g., as shown in FIG. 4C ), the data block definitions stored in library 252 may be dynamically discovered by the DDE User Interface Application during its startup or initialization. In one embodiment, the data block definitions are defined using a lightweight data exchange format, such as a JSON file or document, or other suitable format. A particular data block definition file or document includes the name of the block definition and details the block properties and connectors that define that particular data block. In some cases, a particular block definition may provide a definition for an offline representation and a definition for an online representation.

[0195] The DDE User Interface Application can continuously and dynamically discover block definitions, allowing additional block definitions (e.g., custom data blocks) to be created. Additional block definitions (related to blocks, composite data blocks, and / or other data blocks) may be added to library 252 at any time while the DDE User Interface Application is running. In one embodiment, additional block definitions are generated by a utility application referred to herein as a "data block definition wrapper." For example, the data block definition wrapper may be invoked when a user saves a custom or composite data block, as described above with respect to FIG. 4K. When the block definition wrapper executes, it creates an instance of the additional block definition and creates and stores a corresponding JSON document or similar that defines the additional block definition. For example, the created instance of the additional block definition generates a JSON document and stores it in library 252. Referring to FIG. 4K as an example scenario, when a user saves composite block definition 338, the block definition wrapper executes and generates and stores a JSON document or similar for composite block definition 338.

[0196] During the configuration of a data block (whether offline or online), the DDE User Interface Application may need to implement some functionality (e.g., business logic) to achieve the necessary configuration experience to assist the user in successfully configuring and using the data block. Because block definitions are dynamically discovered by the DDE User Interface Application, this functionality is not embedded in the DDE User Interface Application itself. Thus, in some embodiments, any associated functionality that is specific to a particular data block may also be dynamically loaded when the DDE User Interface Application is initialized. A reference to the dynamically loaded functionality that corresponds to a particular data block is then maintained in the block definition of the particular data block and is used by the DDE User Interface Application when the block definition of that particular block is configured. Additional details regarding block definitions and associated functionality are provided in later sections of this application.

[0197] Industrial process monitoring and analysis systems integrated with process control systems 1-3 and 4A-4N-2, a distributed industrial process performance monitoring and / or analysis system, or DAS 100, provides a platform that supports data analysis configuration, data modeling, data model execution, data visualization, and streaming services for an industrial process platform. As previously discussed, while various nodes of the monitoring and analysis system 100 are embedded within the process control system or plant 5, typically the data communication network 112 of the analysis platform 100 exists outside of (and independent of) the existing DCS, PLS, sanitary monitoring, and other systems of the process plant 5. In one exemplary configuration, the data analysis network 112 is overlaid on top of the process plant 5, thereby separating the network 112 from most or all of the process plant 5's conventional process control communication networks 10, 70, etc. The traditional process control communication network continues to transmit process control data to control, manage, and / or supervise the processes and operational controls of the plant 5, while the data analytics network 112 transmits analytical data (which may include copies of the data transmitted over the traditional process control communication network) to discover knowledge, e.g., descriptive, predictive, and / or prescriptive, about the operation of the process plant 5. The architecture of the data analytics system 100 allows the data analytics system 100 to be easily added to or integrated into an existing legacy process plant 5.

[0198] The knowledge about the process plant 5 discovered by the data analysis system 100 is , may be utilized to modify parameters, equipment, operations, and other parts of the process plant 5 to increase performance of the plant 5 and to reduce the occurrence of failures, damage, and other undesirable conditions. Advantageously, the data analytics system 100 discovers knowledge about the process plant 5 in real time corresponding to the current online operation of the process plant 5, such that the discovered knowledge describes, predicts, and / or prescribes the current operation of the process plant 5. Thus, the data analytics system 100 and the process plant 5 form a control loop to control and optimize the performance of the process plant 5.

[0199] An exemplary high-level block diagram 400 of a control loop for controlling and optimizing the performance of a process plant 5 is illustrated in FIG. 4O. As shown in FIG. 4O, the online process plant 5 generates and acts upon various types of control data 402 and communicates the control data over a conventional process control communication network (e.g., networks 10, 70, etc.) to control one or more industrial processes and generate a process plant output 405. The distributed industrial process performance monitoring and analysis system 100 is connected to and integrated with the process plant 5 via an embedded distributed data engine 102x that ingests analytical data 408 generated as a result of the process plant 5 controlling one or more processes to generate the output 405. As previously discussed, the ingested analytical data 408 may include primary and higher-level process control data 402, as well as results / outputs of analytical functions performed locally by the DDE 102x and / or results / outputs of analytical functions performed by offline and online data analysis modules developed via Data Studio of the data analysis system 100. In some cases, the captured analytical data 408 includes new analytical functions generated via Data Studio and / or new analytical functions generated autonomously by the DDE 102x.

[0200] The data analytics system or platform 100 receives, generates, communicates, and acts upon the analytical data 408 to generate analytical output 410. The analytical output 410 may include discovered knowledge about the process plant 5, such as knowledge describing the current operation of the process plant 5, knowledge predicting the occurrence of a failure, breakdown, time interval, performance, event, etc. given the current operation of the process plant 5, and / or knowledge specifying one or more prescriptive actions that may be taken to mitigate an undesirable characteristic of the current plant operation and / or to mitigate the likelihood of the occurrence of an undesirable, predicted failure, breakdown, time interval, performance, event, etc. given the current operation of the process plant 5. In some embodiments, the discovered knowledge 410 includes knowledge about the state of the analytical data 408. For example, the discovered analytical knowledge 410 may include an optimal offline data set that can be utilized to evaluate different offline data modules, a series of steps that have been used repeatedly by data engineers and defined as a new data analysis user procedure, a new configuration of data blocks defined as a new data analysis technique, etc. In fact, during testing of a prototype data analysis system 100 integrated into a refinery process plant, new data analysis techniques for industrial process plants were discovered by control loop 400, as described in a later section below.

[0201] At least a portion of the discovered knowledge included in the analysis output 410 may be provided to a Human-Machine Interface (HMI) 412, such as a Data Analytics User Interface Application. Through the HMI 412, a user may explore the discovered knowledge 410 generated about the process plant 5 by the data analysis system 100. In some cases, exploration of the discovered knowledge 410 may involve a user utilizing Data Studio to access additional data analysis modules. The process includes creating and executing rules for additional exploration to generate additional discovered knowledge 410. At some point, based on the discovered knowledge 410, the user may make one or more changes 418 to one or more values, parameters, equipment, components, control loops, and / or other current operations of the online process plant 5, thereby optimizing the performance and output 405 of the process plant 5 and / or preventing or arresting the occurrence of failures, damages, and other undesirable conditions.

[0202] In some situations, at least a portion of the discovered knowledge included in the analytical output 410 is provided directly to the process plant 5 to effect or make one or more prescriptive changes, as represented by arrow 420 in FIG. 4O. For example, the discovered knowledge 410 may include a prescriptive action, including a change to a set point, a change to a controller configuration, a change to a process control message priority, or a change to some other value, parameter, configuration, etc. The data analysis system 100 can automatically and directly download or otherwise make the change at the process plant 5 without requiring any user intervention 418, thereby automatically optimizing the performance and output 405 of the process plant 5 and / or preventing or arresting the occurrence of failures, damages, and other undesirable conditions based on the discovered knowledge 410. It is noted that as the analysis system 100 processes the current analytical data 408 and generates the discovered knowledge 410 based on the current operation of the process plant 5, this leg of the control loop 400 automatically updates the online process plant 5 to improve its current operation in real time. Thus, in contrast to existing analytical techniques that require hours or even days to calculate, determine, and implement prescriptive actions, the prescriptive actions generated by analytical system 100 are optimized for the current operating conditions of plant 5 and are applied to process plant 5 immediately, in some cases before any user is aware of an impending, undesirable, or desired condition.

[0203] Of course, for optimal overall implementation of prescriptive actions within the process plant 5, the control loop 400 requires both the autonomous leg 420 and the HMI-controlled leg 418. For example, some prescriptive actions require human intervention, such as the installation of a replacement valve, sensor, or other component.

[0204] As discussed above, the data analytics platform 100 enables analytical data to be streamed among multiple embedded distributed data engines (DDEs) 102x. Any type of primary data generated by the process plant 5 as a result of controlling a process may be streamed. For example, process control data contained in signals generated by process control devices (e.g., controllers, I / O cards, field devices, etc.) that are typically transmitted over a conventional process control communication network for process control purposes may also be streamed over the data analytics network 112 for data analysis purposes. Thus, content or data contained in process control signals, sensor signals, etc. may be copied and / or replicated and streamed over the data analytics network 112. Additionally, secondary (or higher-order) process control data generated and transmitted over a conventional process control communication network (e.g., data histogrammed in a process control database or historian, process control configuration, process control user interface commands, process control network management signals, and any other signals traditionally transmitted and received over a conventional process control communication network as a result of controlling a process) may be streamed over the data analytics network 112 for data analysis purposes. Additionally, the data analysis network 112 may analyze calculated or traditional process control data and The analytical data may be streamed and / or the results of analytical functions or techniques performed on the analytical data may be calculated.

[0205] As a result, data analytics platform 100 partially integrates with process plant 5 by binding locally to data sources of process plant 5 and / or by providing data analytics services or functionality near data sources within process plant 5, while simultaneously providing larger scale prediction and optimization. Only data required to support outer-loop prediction and optimization needs to be communicated to higher / more capable analytics servers and cloud platforms of analytics system 100.

[0206] As discussed above, some of the DDEs 102x of the data analysis system 100 are embedded in physical devices within the process plant 5. For example, some of the DDEs 102x are each integral with a respective process control device (e.g., controller 11, I / O cards 26, 28, field devices 15-16, 18-21, 42A, 42B, 44, etc.) and / or a respective network routing and management device (e.g., gateways 35, 75, 78, adapter 52a, router 58, access points 55a, 72, etc.). In one embodiment, rather than being integrated into a centralized device or component of the process plant 5, the DDE may be a standalone device that is connected as a scope, monitor, or voyeur to a conventional process communication link or network (e.g., networks 10, 70, PLS networks, health and safety monitoring systems, etc.) and may copy / replicate selected process control data being transmitted over the conventional process communication link or network for streaming over the data analysis network 112 for data analysis purposes.

[0207] In some scenarios, two or more DDEs may form a local data analysis cluster to which data sources register and connect, and through which analytical data generated by the registered data sources may be received as analytical data by the data analysis network 112. In some examples, a set of DDEs forms a local cluster and advertises its existence. The local cluster appears as a centralized node or single DDE instance 150 on the data analysis network 112, even if the local cluster includes multiple DDEs interconnected via the data analysis network 112. When a new data source is activated or started on the premises of the process plant 5, the data source scans or looks for the advertisement of the local cluster. The data source may detect the advertisement of the local cluster and register with the local cluster, thereby connecting to the data analysis network 112. The registered data sources may then request bandwidth from the analysis system 100 (e.g., through their local cluster) and publish data to their local cluster, to another node on the data analysis network 112, or directly to the analysis system 100. As local clusters appear as instances of distributed data engine 150, the local clusters receive locally generated analytical data (e.g., analytical data from registered sources and / or other sources) via their respective big data receivers 160 and store the locally generated analytical data in their respective local persistent storage 155. Additionally, the local clusters may provide at least a portion of the stored analytical data to a requesting application (e.g., another data analysis application, a data module, a user interface, a Data Studio, another application, etc.), e.g., via their respective big data request servicers 165. In some cases, the local clusters may perform their respective local data analysis functions on stored data received from registered data sources and / or other data streamed within data analysis network 112, e.g., via their respective big data request analyzers 170. The results or output of the local data analysis functions may be stored locally in respective big data storage 155 and / or streamed, e.g., via one or more data analysis network interfaces 175 of each of the local clusters, to one or more other DDEs outside the local cluster, e.g., another local DDE or local cluster, a centralized data cluster, or a subscribing application.

[0208] In some embodiments, local clusters register themselves with more centralized clusters that receive and store higher-level analytical data and perform respective higher-level data analysis functions. For example, a particular centralized cluster (e.g., a regional cluster) may receive and perform data analysis on streamed data from all local clusters in a particular region of plant 5. In another example, a particular centralized cluster may receive and perform data analysis on streamed data from all control loops of a particular type of configuration in plant 5. Like local clusters, the centralized cluster has the appearance of a single node or instance of DDE 150 within data analysis network 112.

[0209] Consequently, the ability of distributed industrial process performance monitoring and analysis system 100 to provide DDEs and / or clusters of DDEs at various layers or dimensions of localization enables fault detection and prediction to be performed near the data sources of the process plant 5, thereby providing real-time fault detection and prediction responsive to real-time data generated by online data sources. Such a multi-tiered or clustered architecture also enables storage of analytical data throughout system 100, and indeed, since analysis system 100 includes portions embedded within process plant 5, it enables storage of analytical data throughout process plant 5. Furthermore, data analysis system 100 provides the ability to access data stored at any DDE, providing a centralized system for analytical configuration, diagnostics, and performance, fault, and damage monitoring.

[0210] In some embodiments, one or more centralized clusters provide a centralized location for a user or system administrator to establish rules for backing up or historizing analytical data from multiple DDEs 102x. In one example, one or more centralized clusters are located on the premises of the process plant 5 and serve the process plant 5 as a whole. In another example, one or more centralized clusters are located or hosted in the cloud and serve the process plant 5 as a whole. In some configurations, the centralized cluster(s) providing backup or historizing for the process plant 5 also service other process plants. Generally, as discussed above, analytical data is persistently stored in each DDE or cluster in its respective big data storage area 155. In some cases, some analytical data received at or generated by a DDE or cluster may be cached at that DDE or cluster for faster access (e.g., based on one or more criteria such as number of subscribers, frequency of publication or transmission, etc.), but generally all local analytical data is moved to persistent storage 155 at the DDE or cluster. Periodically, or at predefined times, the analytical data persistently stored in each DDE may be backed up, archived, or historized to long-term data analysis storage, for example, in a centralized analytical data historian accessible via the data analysis network 112. For example, the data analysis historian may be a plant-wide data analysis historian and / or may be hosted in the cloud. However, typically, the data analysis historian is independent and separate from any process control data historians. User interfaces accessing one or more centralized clusters may be configured to store, archive, or historize the data for long-term data analysis storage. Through the interface, a user or system administrator can define a set of rules that indicate how often each particular DDE storage area 155 is backed up, when the backup occurs, where the analysis data is histories, etc.

[0211] In one embodiment, one or more centralized clusters provide a centralized location for a user or system administrator to establish rules regarding the replication of analytical data within clusters, nodes, and / or DDEs 102x of data analysis system 100. For example, a set of replication rules can define which specific analytical data is replicated within which specific nodes of data analysis network 112 and how frequently the specific analytical data is updated within the specific nodes. For example, a set of replication rules can define how frequently the results of analytical function A performed by node A are replicated (e.g., by streaming) at nodes B-D so that the replicated results are available to nodes B-D as they perform their respective data analysis functions. Similar to histogram and backup rules, a set of replication rules can be defined by a user or system administrator via a user interface that accesses one or more centralized clusters. For example, a system administrator can utilize the user interface to manage the set of replication rules, and the set of replication rules can be stored in one or more centralized clusters. The one or more centralized clusters that provide management of replication of analytical data may be the same set of clusters that provide management of backup / historization of analytical data, or may be a different set of clusters.

[0212] In one embodiment, one or more centralized clusters provide location services, streaming services (e.g., streaming service 115 of FIG. 1 ), data dictionaries, and / or other functionality that can be utilized by local clusters, other centralized clusters, and / or individual DDEs 102x to establish the exchange of analytical data therebetween. The one or more centralized clusters providing location services, streaming services, data dictionaries, and / or other functionality may be the same as or a different set of clusters than the set of clusters providing analytical data replication management and / or analytical data backup / historization management. A system administrator or user may utilize a user interface to access one or more centralized clusters to manage the services, dictionaries, and other functionality used to establish and provide the exchange of analytical data between clusters and between nodes of the data analysis network 112.

[0213] 4P depicts an example method 450 for providing localized data analysis services. In one embodiment, a cluster of distributed data engines 102x or DDEs performs at least a portion of method 450. In general, at least a portion of method 450 may be performed by any portion of a distributed industrial performance monitoring and / or analysis system, such as system 100. Indeed, method 450 may be performed using any portion of any of the systems, apparatus, devices, and / or techniques described herein. However, for ease of discussion, method 450 is described below with respect to a cluster of one or more DDEs 102x of analysis system 100 appearing as a centralized DDE instance 150. However, this is merely one of many embodiments and is not intended to be limiting.

[0214] The example method 450 includes announcing the existence of a cluster by a cluster (block 452). The cluster is included in the data analysis network 112 of the process control plant 5 that is online and operating to control a process, and the cluster announcement is made by the data analysis network 112. It may be transmitted over network 112, over one or more other networks, via a short-range wireless protocol such as Bluetooth, NFC, or via any other suitable means of announcement.

[0215] The method 450 further includes receiving, at the cluster, a response from the data source to the cluster's announcement. For example, the response from the data source may be a request from the data source to register with the cluster, and the method 450 may include registering the data source with the cluster and / or the data analytics network 112 (block 455), thereby connecting the data source with the data analytics network 112. The data source may be a device or component included in the process plant 5 and generating data as a result of process control by the online process plant 5. In one example, the data source generates continuous time series data resulting from the process being controlled.

[0216] Additionally, the method 450 includes receiving, by the cluster, data generated by the data source (block 458). For example, the data source may stream its generated data to the cluster via the data analysis network 112. Additionally or alternatively, the cluster may subscribe to particular data generated and published by the data source. In some embodiments, the cluster may query the data source for particular data, for example, by using a query mechanism described in a later section of this application. If the data source is a device or component that typically communicates process control data over one or more conventional process control communication networks (e.g., networks 10, 70), the data source may continue to communicate process control data normally over the one or more conventional process control communication networks while also streaming a copy or replica of the content of the communicated process control data over the data analysis network 112.

[0217] Upon receiving data generated by a data source, the cluster may cache at least a portion of the received data, for example, if the received data meets one or more caching conditions. However, regardless of whether any of the received data is cached, the entire received data is stored locally in the cluster's persistent storage 155.

[0218] The method 450 includes streaming at least a portion of the data generated by the data source by the cluster over the data analysis network 112 to a data consumer (block 460). The data consumer may be, for example, another analysis node or cluster, a data analysis application, a user interface and / or user interface application, an online data analysis module, another application, and / or a database or data historian. The data consumer may be bound to a data source and / or a particular data stream that includes at least a portion of the data generated by the data source. The particular data desired to be received by the data consumer is typically time-series data and may be continuous data.

[0219] A data consumer may have queried the cluster for specific data generated by a data source, for example by utilizing a query mechanism described in a later section of this application, and the streaming (block 460) may be a response to this query generated by the data consumer. In some embodiments, a data consumer may subscribe to specific data generated by a data source and published by the data source or the cluster. In any event, the cluster may store the desired data generated by the data source in its cache or its local persistent storage. The data is received from the data storage 155 and streamed to the data consumers over the data analysis network 112 (block 460).

[0220] In some embodiments, method 450 includes performing, by the cluster, one or more data analysis functions or techniques on at least a portion of the data generated by the data sources (not shown in FIG. 4P). The one or more analysis functions or techniques may include descriptive analysis, predictive analysis, and / or prescriptive analysis. The one or more analysis functions or techniques may be performed by the cluster, for example, by an online data analysis module, another data analysis application, or per user request. In another example, the one or more analysis functions or techniques may be automatically initiated and performed by the cluster. Results of the execution of the one or more analysis functions or techniques may be returned to a requesting party and / or stored locally at the cluster in persistent data storage 155. In some embodiments, the one or more analysis functions or techniques are performed on data generated by multiple data sources registered with the cluster and stored (and optionally cached) in the cluster.

[0221] The cluster is referred to herein as a “local” cluster because the cluster receives primary data generated by data sources within the process plant 5 and is located near these data sources within the process plant 5. In some embodiments, the method 450 includes the local cluster detecting announcements generated by a centralized cluster, such as a regional cluster, a wide-area cluster, or a plant-wide cluster. The local cluster may register itself with the centralized cluster and may stream at least a portion of the local analytical data stored in its cache and / or its persistent data storage 155 to the centralized cluster. For example, the analytical data streamed to the centralized cluster may include data generated by the data sources and / or results of one or more analytical functions performed by the local cluster. The local cluster may stream data to the centralized cluster per query initiated by the centralized cluster and / or the local cluster may publish data to which the centralized cluster subscribes.

[0222] In some embodiments, method 450 includes historizing or backing up data stored in persistent storage 155 local to the cluster (not shown in FIG. 4P). The data backup may be initiated by the cluster, or the data backup may be initiated by the centralized analytic data historian. In some embodiments, the cluster and the centralized analytic data historian may have a publisher / subscriber relationship. The timing and / or amount of data to be backed up from the cluster may be defined by a system administrator of system 100 in some embodiments. The backed-up data may be transmitted and / or streamed from the cluster to the analytic data historian for long-term storage and backup.

[0223] FIG. 4Q depicts an example method 470 for providing localized data analysis services. In one embodiment, a cluster of distributed data engines 102x or DDEs 102x performs at least a portion of method 470. In general, at least a portion of method 470 may be performed by any portion of a distributed industrial performance monitoring and / or analysis system, such as system 100. Indeed, method 470 may be performed using any portion of any of the systems, apparatus, devices, and / or techniques described herein. However, for ease of discussion, method 470 is described below with respect to a cluster of one or more DDEs 102x of system 100 appearing as a centralized DDE instance 150. However, this is merely one of many embodiments and is intended to be limiting. It is not intended to

[0224] The exemplary method 470 includes announcing the existence of the centralized cluster by the centralized cluster (block 472). The centralized cluster differs from the local clusters of FIG. 4P because data sources typically do not register directly with the centralized cluster. Rather, local clusters or other types of clusters often register with the centralized cluster, and the centralized cluster performs data analysis functions on data received from such other clusters. However, like local clusters, the centralized cluster is included in the data analytics network 112 of the process control plant 5 that is online as it operates to control the process, and announcements of the centralized cluster may be transmitted, streamed, and / or broadcast through the data analytics network 112. As used herein, a "centralized" cluster refers to a cluster to which other clusters subscribe. A centralized cluster may handle a control loop (e.g., a "control loop" cluster), an area of ​​a process plant (e.g., a "wide-area" cluster), a region of a process plant (e.g., a "regional" cluster), an entire process plant (e.g., a "plant-wide" cluster), multiple process plants (an "enterprise" cluster), etc. Typically, a centralized cluster includes multiple DDEs interconnected via a data analysis network 112 that appear as a single, centralized DDE instance 150 .

[0225] The method 470 further includes receiving, at the centralized cluster, a response from the other cluster to the centralized cluster's announcement. For example, the response from the other cluster may be a request from the other cluster to register with the centralized cluster, and the method 470 may include registering the other cluster with the centralized cluster (block 475). The registering cluster may be a local cluster, such as the local cluster of FIG. 4P, or the registering cluster may be another centralized cluster.

[0226] Additionally, method 470 includes receiving at the centralized cluster streamed data from the registered clusters (block 478). For example, the registered clusters may stream a portion of their stored and / or cached data to the centralized cluster via the data analysis network 112. Thus, the streamed data typically includes time series data, which may be, for example, continuous data. Additionally or alternatively, the centralized cluster may subscribe to specific data published by the registered clusters. In some embodiments, the centralized cluster queries the registered clusters for specific data, for example, by using a query mechanism described in a later section of this application. The streamed data may include data generated by the registered clusters and / or data streamed to the registered clusters from data sources and / or other clusters.

[0227] In some embodiments, the centralized cluster caches at least a portion of the streamed data it receives, for example, if the received data meets one or more caching conditions. Regardless of whether any of the data received at the centralized cluster is cached, the entirety of the received data is stored locally in persistent storage 155 of the centralized cluster.

[0228] At block 480, the method 470 includes performing one or more data analysis functions or techniques on at least a portion of the received, streamed data (e.g., data stored in the cache and / or in the persistent storage 155). The one or more analysis functions or techniques may include descriptive analysis, predictive analysis, and / or prescriptive analysis. For example, the one or more analysis functions or techniques may include an online data analysis module. The one or more analytical functions or techniques may be performed by the centralized cluster per request of a module, another data analysis application, or a user. In another example, one or more analytical functions or techniques may be performed automatically and / or periodically by the centralized cluster. The results or output of the execution of the one or more analytical functions or techniques may be returned to the requesting party and / or may be stored locally at the centralized cluster in persistent data storage 155. In some embodiments, one or more analytical functions or techniques are performed on data generated by multiple registered clusters and stored (and optionally cached) in the centralized cluster.

[0229] The method 470 includes streaming at least a portion of the results or output of the one or more analytical functions or techniques by the centralized cluster to one or more data consumers via the data analytics network 112 (block 482). The one or more data consumers may include, for example, another analytical node or cluster, a data analytics application, a user interface and / or user interface application, an online data analytics module, another application, and / or a database or data historian. The one or more data consumers may be bound to the centralized cluster, a particular analytical result / output, and / or a particular data stream that includes the particular analytical result / output.

[0230] One or more data consumers may have queried the centralized cluster for specific analytical results / outputs, for example, by utilizing the query mechanisms described in later sections of this application, and the streaming (block 482) may be a response to this query generated by one or more data consumers. Additionally or alternatively, the data consumers may subscribe to specific analytical results / outputs published by the centralized cluster. In any event, the centralized cluster receives the desired data from its cache or its local persistent data storage 155 and streams the desired data to one or more data consumers via the data analysis network 112. In some cases, the desired analytical results / output data is streamed as it is generated by one or more data analysis functions or techniques.

[0231] In some embodiments, method 470 includes registering one or more additional local clusters with the centralized cluster and receiving respective analytical data from the one or more additional local clusters (not shown in FIG. 4Q). In such embodiments, performing one or more data analytical functions or techniques (block 480) may include performing the data analytical functions or techniques on the analytical data received from the multiple local clusters at the centralized cluster.

[0232] In some embodiments, method 470 includes historizing or backing up data stored in persistent storage local to the centralized cluster (e.g., data stored in big data storage 155) (not shown in FIG. 4Q). The data backup may be initiated by the centralized cluster, or the data backup may be initiated by the centralized analytic data historian. In some examples, the centralized cluster in the centralized analytic data historian may have a publisher / subscriber relationship. The timing and / or amount of data to back up from the centralized cluster may be defined by a system administrator of system 100 at the centralized cluster or at another centralized cluster. For example, the system administrator may utilize a user interface to manage a set of rules regarding backups within system 100, which may be stored in the centralized cluster. The backed-up data may be transmitted and / or streamed from centralized cluster 152 and the analytic data historian for long-term storage and backup. It can be done.

[0233] Additionally or alternatively, in some embodiments, method 470 includes providing a set of rules for replication of analytical data within clusters, nodes, and / or DDEs 102x of data analysis system 100. For example, the set of replication rules can define which particular analytical data is replicated within which particular nodes of data analysis network 112 and how frequently the particular analytical data is updated within the particular nodes. For example, the set of replication rules can define how frequently the results of analytical function A performed by node A are replicated (e.g., by streaming) at nodes B-D so that the replicated results are available to nodes B-D as they perform their respective data analysis functions. Similar to the histogram and backup rules, the set of replication rules can be defined by managed systems in one or more centralized clusters of system 100. For example, a system administrator can manage the set of replication rules utilizing a user interface, and the set of replication rules can be stored in the one or more centralized clusters.

[0234] In some embodiments, method 470 includes a centralized cluster detecting an announcement generated by another centralized cluster. For example, the announcing cluster may be a regional, wide-area, or plant-wide cluster located on the premises of the process plant 5. In some cases, the announcing cluster may be hosted in the cloud and may provide analytical services for a portion of the plant 5, the entire plant 5, or multiple plants. A centralized cluster may register itself with the announcing cluster and stream analytical data stored in its cache and / or its persistent data storage 155 to the announcing cluster. For example, a centralized cluster may stream at least some of the results of analytical functions performed by the centralized cluster. A centralized cluster may stream data to an announcing cluster to which it is registered and / or the centralized cluster may publish data subscribed to by the announcing cluster.

[0235] In some embodiments, method 470 includes providing location services, streaming services (e.g., streaming service 115 of FIG. 1), and / or data dictionaries that can be used by other local and centralized clusters and individual DDEs 102x to establish the exchange of analytical data therebetween (not shown in FIG. 4Q).

[0236] Industrial Performance Monitoring / Analysis Services The functionality of Data Studio's transformation of offline data diagrams into online data diagrams, the execution of both offline and online blocks and modules, and the analyses represented by the diagrams is enabled by an Analytics Service provided by an industrial performance monitoring and analysis system, such as Data Analytics System (DAS) 100. The Analytics Service is referred to interchangeably herein as the "Service," "Services," or "Analytics Services." Any or all of the Analytics Services described herein may operate in conjunction with any or all of Figures 1, 2, 3, and / or 4A-4Q, and / or in conjunction with any number of the features and / or techniques described in the sections of this disclosure corresponding to Figures 1, 2, 3, and / or 4A-4Q, respectively.

[0237] Generally, the Analytics Service (e.g., Data Studio) The Analytics Service can compile, execute, and / or transform offline diagrams (e.g., in Data Studio and / or Dashboard) and can compile, execute, and / or create online diagrams (e.g., in Data Studio and / or Dashboard). The Analytics Service facilitates exploration of large sets of data, i.e., Big Data, without necessarily requiring knowledge of the particular type(s) of data and without requiring users of the Analytics Service to engage in low-level programming to perform the analysis. An exemplary block diagram architecture of the Analytics Service 500 is shown in FIG. 5A in the context of a portion of system 100. More specifically, the Analytics Service 500 is one of multiple computer-implemented processes, each of which is associated with various software entities (e.g., computer-executable instructions and data stored on one or more tangible, non-transitory computer media). As described in detail below, the Analytics Service 500 interacts with the larger system 100 in large part through data generated and / or stored by various entities of system 100.

[0238] As noted above, the DDE User Interface Application, in embodiments, is a web-based application. FIG. 5A depicts an embodiment of the Analytics Service 500 implemented in such an embodiment, i.e., with a web-based DDE User Interface Application. In its broadest sense, the Analytics Service 500 implemented in this manner includes client-side, server-side, and back-end computer-implemented processes. For example, as depicted in FIG. 5A, the Analytics Service 500 includes a web client process 502, a web server process 504, an execution service process 506, and one or more job processes 508. The various processes 502, 504, 506, 508 may run on one or more processors, on one or more workstations or servers, and in one or more physical and / or geographic locations. That is, one instance of the web client process 502 may run on a workstation remote from the server on which the web server process 504 runs, while another instance of the web client process 502 may run on the same server, and indeed may run on the same processor, as the server on which the web server process 504 runs. As another example, the execution service process 506 may run on a workstation within the realm of the process control environment, while one or more job processes 508 may run on one or more processors in a distributed process environment (e.g., a server farm) located remotely from the process control environment. In short, the Analytics Service 500 is designed to be flexible such that the various processes 502, 504, 506, 508 do or do not need to run on the same processor, workstation, bank of processors, one or more virtual machines, and / or the same physical or geographic location.Advantageously, this architecture not only facilitates remote access to the data analysis provided by Analytics Service 500 and the ability to leverage massive processor and computational resources to perform the analysis, but also enables Analytics Service 500 to consume and / or analyze data across multiple process plants, regardless of how different their geographic locations may be.

[0239] The web client process 502 operates according to principles not very different from commonly understood principles, but consistent with the above description of the DDE User Interface Application. For example, the web client process 502 may be implemented as a DDE User Interface Application (e.g., Data The DDE User Interface Application includes various software entities, including a View entity 510, which presents the user with the canvas 245 and user controls 248a-n of the Analytics Studio 240 (e.g., Data Analytics Dashboard), the application model entity 512, which manages the transport and translation of application data, such as block states, into a form that the user interface can utilize, and which provides feedback from and / or otherwise generates views that indicate the operation of the online data modules; an Application entity 514, which is a software entity (i.e., a web-based application) that is downloaded to the web client process 502 and resides on the client workstation or device through which the user interacts with the DDE User Interface Application; and a Data Services entity 516, which passes data to and from the DDE User Interface Application.

[0240] The data services entity 516 receives data returned from various executed jobs, for example, in response to user inputs and requests. As described above and in further detail below, the DDE User Interface Application may request the execution of various analyses based on data from (and, in some cases, data currently being generated by) the process control environment, either in an exploratory mode (e.g., in Data Analysis Studio) used to discover relationships between disparate data (or data of known relationships), or in a predictive mode (e.g., in Dashboard) used to perform real-time (or near-real-time) continuous analysis to predict at least one value in the process control environment. As used herein, the phrase "real time" or "real-time" means "sufficiently contemporaneous so as to remain useful for adjusting or otherwise affecting the current operation of the process plant." For example, when one or more blocks are placed on the canvas 245 and one or more of those blocks are executed, the results of that execution may be returned to the application entity 514 via the data service entity 516 (e.g., using a Web Socket protocol connection from the web server process 504) and displayed to the user via the display entity 510.

[0241] At the same time, the data services entity 516 may communicate with the web server process 504 via other protocols (e.g., HTTP) to request and receive various types of information necessary for the operation of the application entity 514. As an example, when the application entity 514 is first executed, it may request and receive the latest block definitions 255 from the block definition library 252 via the data services entity 516 using the HTTP protocol. Alternatively, the application entity 514 may initially receive only the categories and list of available block definitions 255, and upon selection by the user, the application entity 514 may request and receive the specific block definition 255 selected by the user via the data services entity 516 using the HTTP protocol.

[0242] Turning now to the web server process 504, one or more server communication entities 518 communicate with the web client process 502. As noted above, communication between the server communication entity(ies) may implement protocols such as HTTP, HTTPS, and the Web Sockets protocol, however, the particular protocols described should not be considered limiting as any other protocol suitable for the present application may be implemented. In addition to communicating with the web client process 502, the server communication entities 518 communicate with one or more blocks placed on the canvas 245 (i.e., the The data may be received from one or more processes that perform required instructions (e.g., data analysis, data loading, data filtering, etc.) according to the server communication entity 518. The data may be received from the processes, for example, via a web socket (not shown) of the server communication entity 518, which may also be communicated to the web client process 502 via the web socket protocol.

[0243] The data services entity 520 provides data to the web client process 502 other than data received from processes executing instructions associated with various blocks. For example, the data services entity 520 may retrieve block definitions 255 from the block definition library 252 and communicate them to the application entity 514, and / or communicate status information about the execution of blocks from the execution services process 506 to the application entity 514 so that the status can be displayed by the display entity 510.

[0244] 5B, the data service entity 520 is depicted in more detail. Specifically, the data service entity 520 includes a copy of (or a pointer to) the block definitions 255 in the block definition library 252 and a set of data plug-ins 523. Each of the data plug-ins 523 is a set of computer-executable instructions that conforms to an interface that can be invoked by the application entity 514 to perform a specific task. Each of the plug-ins 523 is independent of the application entity 514 and is loaded by the application entity 514 when the application entity 514 encounters metadata that identifies the plug-in 523 to be loaded. The plug-ins 523 may contain logic that is specific to the application and / or the operating environment in which the Analytics Service 500 is running. That is, the set of plugins 523 for a process control environment that implements Analytics Service 500 may be different from the set of plugins for a financial service that implements Analytics Service 500 (note that Analytics Service 500 facilitates exploration of large sets of data, i.e., Big Data, without necessarily requiring knowledge of the particular type(s) of data and without requiring the user of Analytics Service 500 to perform low-level programming to perform the analysis), and indeed may also be different from the set of plugins for a different process control environment that implements Analytics Service 500.

[0245] The separation of block definitions 255 from application entities 514 allows application entities 514 to use and deploy different block definitions based on customer requirements. Because logic specific to an application and / or operating environment is not hard-coded into application entities 514, block definitions can be created, added, modified, and / or removed without affecting the underlying operation of application entities 514. By providing plug-ins 523 and block definitions 255 separately from application entities 514, application entities 514 can operate with similar functionality regardless of the particular block definitions 255 and plug-ins 523 required for a particular application.

[0246] 5A, as described above, application entity 514 operates to facilitate the creation of offline diagrams, such as offline diagram 340 of FIG. 4L, on canvas 245. To create an offline diagram, a user selects one or more blocks, places them on canvas 245 (e.g., by dragging and dropping), and "wires" the blocks together so that data is communicated between them. Each of the blocks is defined in a block definition library 252。 When the user activates user control 248m, the application entity 514 causes the display entity 510 to display available categories of block definitions 255 and / or available block definitions 255 from which the user can select and place a block on the canvas 245. In one embodiment, the block definition library 252 is stored in a memory device shared by one or both of the execution service process 506 and the web server process 504, and metadata for the block definition library 252 (e.g., block definition name, block definition category, etc.) is sent to the application entity 514, but the block definition is sent to the application entity 514 only when a block is selected for placement on the canvas 245. Alternatively, the block definition library 252 is sent in its entirety to the application entity 514 if the application entity 514 is instantiated in the web client and remains present in the web client throughout the execution of the web client process 502. The master copy of the block definition library 252 may reside in a database (not shown) within the process control environment, a cloud storage device accessible over a network, a workstation, or the like.

[0247] The block definitions 255 may be categorized according to the functionality of each block. While FIG. 5A depicts block definitions 255 sorted within each of several depicted categories 521, FIG. 5A is not intended to suggest that block definitions 255 categorized in any particular category 521 necessarily be stored together or necessarily stored separately from other block definitions 255. While this may be true in some embodiments, in other embodiments, the block definitions 255 are not stored in any particular order, but instead may each be tagged with metadata that may indicate the category to which the block definition belongs. The metadata for any given block definition 255 may also indicate, by way of example and not limitation, the number of inputs and outputs, properties required for execution of the block, UI control types for each property, when (i.e., under what conditions) the controls for each property are enabled / disabled, plugin information for the properties, default values ​​for the properties, etc.

[0248] In many, but not all, embodiments, blocks include properties that can be or must be specified before the block can be compiled and executed. Because block definitions 255 are not built into the application entity 514, values ​​from which a user can select properties for a particular block cannot be predetermined and / or provided to the application entity 514 when the application entity 514 is instantiated. FIG. 5C is a flowchart depicting a method 551 for presenting a properties dialog for a block placed on the canvas 245. When a block is placed on the canvas 245, the application entity 514 retrieves the corresponding block definition 255 from the data services entity 520 or, in embodiments, from the database 529 (block 553). The application entity 514 then receives a command to display a properties dialog for the block placed on the canvas 245 (block 555), for example, when a user double-clicks the block.

[0249] When application entity 514 receives a command to indicate properties for a block (block 555), application entity 514 parses the block definition property by property. For each property, application entity 514 retrieves metadata for that property (block 557) and parses the metadata for the property to find plug-in information (block 559). If the application entity 514 finds plug-in information for the property (block 561), the application entity 514 discovers and loads the identified plug-in (e.g., from plug-ins 523 of the data service entity 520) (block 563). The application entity 514 invokes the plug-in identified by the metadata for the property to obtain the needed property value (block 565). On the other hand, if the application entity 514 does not find plug-in information for the property (block 561), the application entity 514 finds the default value(s) for the property in the metadata for the property (block 567).

[0250] In either case, by calling a plug-in identified by the metadata for the property to get the property value (block 565) or by finding the default value(s) for the property (block 567), the application entity 514 finds the UI control type (text box, drop-down selection, radio button, checkbox, etc.) in the metadata for the property (block 569) and adds the value(s) and control to the property dialog (block 571). If additional properties exist in the block definition (block 573), the application entity 514 retrieves metadata for this next property (block 557), and the method continues until no additional properties exist (block 573). If additional properties are not found in the block definition, the application entity 514 displays the property dialog for the user to set the property (block 575).

[0251] In some embodiments, and / or for some block definitions 255, one or more first properties of the block may be displayed in an inactive or disabled state until one or more second properties of the block are configured. Upon configuring one or more second properties, application entity 514 may re-execute one or more steps of method 551 and / or re-execute one or more of plug-ins 523 associated with the first property.

[0252] As an example, assume that a user places a "load" block on the canvas 245. The application entity 514 retrieves the block definition 255. In one embodiment, the block definition 255 for the load block provides the application entity 514 with metadata about the block, specifically indicating that the load block has three properties: the block's name, a selected database (the database's name), and a selected dataset (the dataset's name) that pulls from the selected database. When the property configuration dialog is triggered (e.g., by double-clicking the load block), the application entity 514 must determine what to display. The application entity 514 may determine that no plug-in information is present in the metadata for the block's name property and instead finds a default value, e.g., "load<##>". The application entity 514 may also find that the control type for the block's name, as indicated in the metadata for the block's name property, specifies a text box. The application entity interprets the default value (e.g., "load01") and places it in the dialog as a text box.

[0253] The application entity 514 parsing the block definition finds metadata about the database name property. By examining the metadata about the database name property, the application entity 514 finds plug-in information about that property and, as appropriate, discovers, loads, and executes the identified plug-in. The identified plugin, written for a particular application and / or operating environment (e.g., for a particular process control environment), is programmed to discover a list of database names (and associated locations) into which datasets can be loaded. Upon receiving the list of database names, the application entity 514 parses metadata about the properties of the database names and determines which should be displayed in a drop-down selection control. The application entity 514 adds a drop-down selection control to the properties dialog with the list of database names returned by the plugin.

[0254] Parsing the block definition, the application entity 514 finds metadata about the dataset name property. The metadata about the dataset name property identifies a plug-in and indicates that the dataset name property is a drop-down selection control, but also indicates that this control should be disabled until a database name is selected by the user. When no further properties are found in the block definition for the load block, the application entity 514 displays a dialog. When the user selects one of the database names from the database name drop-down selection control, the application entity 514 invokes the plug-in identified in the metadata about the dataset name property (from the data block definition), passing the name of the selected database as an argument to the invoked plug-in. The plug-in returns the names of the datasets available within the selected database name, fills the drop-down selection control for the dataset name property with the names of the available datasets, and displays the dialog again, this time with the control enabled instead of disabled. The user can then select a dataset name to complete the configuration of the data block.

[0255] Of course, once a block is placed on the canvas 245 and configured to specify any required properties, the block can be executed (i.e., the programming instructions specified in the block definition can be executed) so that any downstream blocks (i.e., any blocks that have inputs "wired" to the output of this block) receive valid inputs from this block and produce valid outputs. For example, with respect to the offline data diagram 340 shown in FIG. 4L, the LoadDB4M block 342a must be evaluated or executed before the blocks Columns X 342b and Columns Y 342c can be configured. This is because the configuration of the blocks Columns X 342b and Columns Y 342c is based on user selections from the output of the LoadDB4M block 342a. On the other hand, and still referring to FIG. 4L, the PLS4M_X_Y block 342d can be configured independently of the evaluation of the blocks Columns X 342b and Columns Y 342c, while the block Columns Columns X 342b and Y 342c must be evaluated before the PLS4M_X_Y block 342d can be evaluated based on the input data set loaded into the offline data diagram 340.

[0256] The execution and evaluation of blocks and / or modules is asynchronous, allowing a user to continue modifying blocks or modules while they are being evaluated. For example, a user may begin execution of one block while continuing to edit and / or configure one or more other blocks. Advantageously, each separately compilable and executable block can be evaluated, and its results explored, before selecting, configuring, and / or executing downstream blocks. As a result, a priori knowledge of the expected output of a particular block is not required, nor is it necessary to know what the next block in the data flow will be before seeing the results of any particular block.

[0257] Any execution of an offline or online diagram involves the functionality of an execution service process 506 and a job process 508. Generally, as described above, a job process 508 may execute on one or more processors on which the execution service process 506 and / or web server process 506 are executing (which may or may not be the same processor(s)), on one or more processors on which the web client process 502 is executing, and / or on one or more separate processors, such as processors in a cloud computing platform, and may execute on one or more virtual machines configured based on one or more processors. Also, each job process 508 may execute in a different target environment, for example, by executing each job process 508 on a dedicated virtual machine configured for the target environment. Each job process 508 generally represents a portion of the code to be executed. In some cases, a particular job process 508 executes the target script / code associated with a particular block, while in other cases, instructions associated with a single block are divided into smaller segments of script / code for execution in multiple job processes 508.

[0258] Specifically, when instructions associated with a single block are divided into smaller script / code segments for execution by different job processes, these different job processes may cooperate to achieve some form of parallelism. As used herein, "parallel computing" is used to refer to the general practice of dividing a task into smaller units and performing them in parallel, "multithreaded processing" refers to the ability of a software program to execute multiple threads (if resources are available), and "distributed computing" refers to the ability to spread processing across multiple physical or virtual machines. In principle, distributed computing can be scaled out without limit. In light of these concepts, it should be understood that executing instructions on a distributed platform is not the same as executing instructions in a distributed mode. In the absence of explicit instructions supporting distributed processing, the instructions will be executed locally.

[0259] The ability to parallelize a task is a property inherent in the definition of the task itself. Some tasks are easy to parallelize because the computations performed by each job process are independent of all other job processes and the desired set of results is a simple combination of the results from each job process. These tasks are said to be "embarrassingly parallel."

[0260] Some tasks require more effort to parallelize. Specifically, such "linearly parallel" tasks are those in which the computations performed by one job process are independent of the computations performed by another job process, but the desired set of results is a linear combination of the results from each job process. For example, a "calculate average" block may be defined by an instruction to calculate the average of a set of values ​​in a distributed database in which a single set of data is stored across multiple physical memory devices. As a more specific example, assume that the average calculation block calculates the average temperature across a set of 300 bioreactors, each of which stores temperature data in the memory of an associated controller. Execution of the average calculation block may be parallelized by assigning the set of temperature values ​​for the 300 bioreactors to each of multiple job processes and then calculating the "total" average as a weighted average of the averages determined by each of the multiple job processes.

[0261] Tasks where data must be organized in a meaningful way are more difficult to parallelize. A "data-parallel" task is one where the computation performed by each job process can be performed independently from all other job processes, as long as each job process has the "right" chunk of data. This is a task that stands alone. This could involve, for example, calculating an independent temperature average for each of the same 300 bioreactors (rather than an average across all 300 of them), assuming there are no cross-effects within those same 300 bioreactors. This task can be parallelized if each job process has temperature data for a single one of those bioreactors.

[0262] However, for such a task to be data parallel, the data must be organized into chunks that are consistent with the task. This may be true if each of the 300 bioreactors in the above scenario stored its temperature data in a single corresponding database or location. However, if the data for all 300 bioreactors were stored in a single database and not organized in any way within the database, this data would require reorganization before any kind of analysis could occur. In the systems described herein, data reorganization may be handled by other blocks in the diagram (e.g., data filtering blocks, query blocks, etc.) that are constructed to perform the analysis.

[0263] The creation and management of job processes 508, as well as the parallelization and distribution of job processes among various processors, is the responsibility of the execution service process 506. When a module or block is executed, whether the module or block is executed as part of an online or offline diagram, the configuration of the module or block is sent from the web server process 504 to the execution service process 506. In an embodiment, this configuration is sent as a JSON (JavaScript Object Notation) file, but this configuration file may utilize any data format that is language-independent and suitable for asynchronous browser-server communication. The configuration file contains the specific source code of the environment in which the analysis represented by the diagram 602 (or part thereof) will be executed, as well as the values ​​of environmental properties and variables required for its execution.

[0264] Because a block definition does not require that block to run in any particular environment, and the target environment is selected during configuration of the block (or the module that contains the block), new target environments can be added to those available in the Analytics Service without having to rewrite the Application, the block definition, or any stored or running blocks and / or modules.

[0265] Similarly, new block definitions 255 can be added to the block definition library 252 at any time without affecting any of the pre-built modules or changing the operation of the Analytics Service 500 as a whole or the application entities 514 specifically. Referring again to FIG. 5B , the creation and addition of new block definitions is accomplished, in an embodiment, by an algorithm definition wrapper 525. In the algorithm definition wrapper 525, a user or developer can create a definition by developing an algorithm using a definition generator 527. The definition generator 527 generates a definition 255′ and stores the definition 255′ in the block definition library 252, for example, in a database 529. As will become more clear in later sections of this description, each block definition 255 can have a corresponding data plugin 523, which can be stored in a location known to the Analytics Service 500 (e.g., a database 531). The data service entity 520 may retrieve the block definitions 255 and data plugins 523 and provide them to the application entity 514 when the application entity 514 is initialized / instantiated.

[0266] Alternatively, rather than creating a new block definition, in some embodiments, a user-defined block definition may not have an associated algorithm, but instead may include properties into which the user can place their own code. That is, one of the block definitions 255 may allow the user to enter their own algorithm as a property into the block.

[0267] As used herein, the terms “parameter” and “parameters” refer to the properties or properties of a block(s) and / or module(s), respectively, that are included in a configuration file and passed as parameters to the execution service via the configuration file. Properties passed as parameters in a configuration file may include, for example, a file path, the name of a dataset, selected columns, the confidence level and number of components desired in the results of a PCA analysis, and any other information required by the compiler entity 526 to compile executable code and the job process 508 to execute the compiled instructions. That is, not all properties of a block or module are required for execution. For example, some properties of a block or module may specify or otherwise relate to how the block or module is displayed in Data Analytics Studio, but do not affect how its data is collected, manipulated, or processed / analyzed.

[0268] In some embodiments, the configuration file contains block and / or module definitions, as well as any properties needed to compile and execute the blocks / modules. In an alternative embodiment, the configuration file contains only the block's identification code and required configuration parameters, and the block definition is retrieved from memory (e.g., from block definition library 252). Regardless, the configuration parameters may vary according to the block definition. Some blocks may have no configuration parameters, while other blocks may have one, two, or many configuration parameters. In addition, configuration parameters may be required or optional. For example, a data load block (a block that loads a set of data) or a query block (a block that searches for specific data within a dataset) may require a data path that specifies where the data is to be loaded or queried. However, a column selection block may have "all columns" as a default selection and therefore may not require specific subjective configuration of the selection of a subset of columns.

[0269] Other parameters in the configuration file may include environmental parameters, such as, by way of example and not limitation, an execution mode specifying whether the workflow or a portion thereof is executed offline or online; a target execution environment (e.g., Python, PySpark, Native Spark, etc.); whether the execution is local or distributed; a configuration for the distributed environment; an indication of a streaming data source to which the workflow or a portion of the workflow is bound; an option to create a new job or bind to a persistent job and continue its execution; an option to cache data across persistent jobs; an option to include validation variables in online diagram executions for the purpose of evaluating the accuracy of the running model; or other environment variables.

[0270] Configuration of blocks, modules, and / or environment parameters can occur in any of a variety of ways. As noted above, for example, many parameters are passed in a configuration file according to properties set in the respective block or module. When building a diagram, it is often (but not always) necessary for a user to configure and execute a particular block before downstream blocks can be configured and / or executed. This is the case when a user uses a first block to load data and a second downstream block to select columns from the data. The load block must be configured (e.g., with the path to load the data, the selection of the data to load, etc.) before it can be executed, and must be executed before the columns available in the data are known to the second block so that the user can select columns.

[0271] Alternatively or additionally, one or more parameters may be added to the configuration file when a block or module is requested for execution. This may be true, for example, if the user does not specify one of the block or module's properties. This may also be true if one or more properties are programmed to be specified only when requested for execution. In embodiments, for example, Data Analytics Studio allows the user to specify when a block or module is selected for execution, the target environment for execution, and / or the target processor or bank of processors on which the block or module will execute. Furthermore, in some embodiments, one or more parameters in the configuration file may be passed from the Data Analytics Studio environment itself. Parameters such as a preferred execution environment, restrictions on the physical location where processing can / must occur (e.g., preventing or requiring cloud execution), and so forth, may be specified by the application for all blocks / modules executed within the application. These parameters may be passed to the configuration file when any particular block or module is requested for execution.

[0272] In any event, still referring to FIG. 5A , the job listener entity 522 receives an execution request via a configuration file to execute a block(s) or module(s) and creates one or more job manager entities 524 corresponding to the block(s) and / or module(s) requested to be executed. The job manager entity 524 receives the configuration file and, according to the identified target execution environment, sends the configuration file to one or more of the diagram compiler entities 526 for compilation into instructions executable by a processor in the identified target environment. The diagram compiler entities 526 may be designed such that each diagram compiler entity 526 is operable to compile the configuration file for any of several identified target environments, or each diagram compiler entity 526 may be designed such that each diagram compiler entity 526 is operable to compile a configuration file specifying only one specific target environment. In any event, the output of the job compiler entity 526 is computer-readable instructions executable by a processor in the identified target environment.

[0273] The job manager entity 524, which sends the configuration file to the diagram compiler entity 526, sends the compiled output from the diagram compiler entity 526 to a job executor entity 528. The job executor entity 528 determines what resource(s) (e.g., processor resources) are available to execute the compiled output according to specified configuration parameters for the job's target environment, whether the job should be distributed, whether the job should be local or remote, and any / other variables, including but not limited to the source(s) of input data and the destination(s) of output data, and then creates job processes 508 with the specified resources. Each job process 508 executes the compiled output in a particular target environment to execute the compiled output for a particular target environment. In an embodiment, some or all of the job process 508 may be performed by a big data analyzer 170 embedded in the distributed data engine 150.

[0274] Thus, in this flexible architecture, at least each of the following scenarios is possible: a single block or module is executed as multiple job processes 508 across multiple processors in a distributed manner, a single block or module is executed as multiple job processes 508 serially on a single processor, a single block or module is executed as a single job process 508 on a single processor, multiple blocks are executed as multiple corresponding job processes 508 across multiple processors in a distributed manner, etc. Also, while it is generally contemplated that job processes 508 corresponding to a single block or module will run in the same target environment (e.g., Python, PySpark, etc.), there is no requirement that all processes for different blocks within a module or different modules within a project run in a single target environment. In some cases, for example, a particular target environment may be better suited to implementing a target algorithm associated with one block in a module, while other blocks in the module may execute more efficiently in a different target environment, so the blocks may be configured to specify different target environments in their respective properties, with the end result being that job processes 508 associated with different blocks execute in different environments.

[0275] Still further, it is expected that in many instances, the blocks associated with a particular module or project will be executed in a job process 508 that is either all distributed or all local. However, in light of the above description, it will be apparent that efficiencies can be gained by executing one or more blocks of a module or project locally while executing other blocks of the module or project on one or more remote processors (e.g., in a cloud computing environment). For example, consider a diagram in which a first block performs a query to retrieve specified data from a database (or other data storage) located remotely from the Analytics Service 500, and a second block performs analysis on the data returned by the query. Rather than performing this query on a processor remote from the database, it may be more efficient to create a job process 508 on a processor local to the database (e.g., in an embedded DDE in the database) and perform the query on the data local to the embedded DDE. This may be particularly true when the database is in another geographic location, such as when a user queries data related to a process control environment other than the process control environment in which the user is currently located. The results of the query may then be analyzed according to the second block, either in the same job process (and processor), in a different job process within the same processor, or in a different job process within a different processor (e.g., a local processor).

[0276] The job executor entity 528 also keeps track of job processes 508 and keeps track of data dependencies, particularly in distributed processing applications. Thus, as each job process 508 completes, output data is returned to the job executor entity 528, which determines whether some or all of that data is passed on to another job process 508 and / or returned to the web server process 504 for display in the application entity 514 by the web client process 502. During the execution of a job process 508, the job executor entity 528: The job process 508 may receive status information, which may be returned to the web server process 504 for display in the application entity 514. The job process 508 may also return predictive data to the job executor entity 528, particularly when the job process 508 is executing an online diagram (or a portion of an online diagram), which runs continuously until explicitly stopped. Note that predictive data may be returned to the job executor entity 528 each time it is generated and passed to the web server process 504 for display in the application entity 514, while the predictive data may simultaneously be returned to a location within the process control environment (e.g., a DDE storage location, a controller implementing a control function, etc.) and written as a function of one of the blocks in the online diagram. In an embodiment, status, state, and / or predictive data is passed between the job process 508 and the job executor entity 528 via a backchannel streaming communication channel established during job creation, allowing the job processes 508 to communicate with each other and / or the job executor entity 528.

[0277] Through the examples below, it will become apparent that the flow of data through the Analytics Service 500 depends, to some extent, on the blocks and / or modules that are configured, the properties that are configured for each of the blocks or modules, and whether the diagram being executed is an offline diagram or an online diagram.

[0278] Example 1 - Creating an offline diagram 5D is a diagram depicting an example canvas 600 having a composed offline diagram 602 thereon, including blocks 604a-604g and wires 606a-606h. Referring again to FIG. 5A, canvas 600 is displayed by web client process 502, and in particular by display entity 510 in cooperation with application entity 514. Application entity 514 receives data (including block definition library 252) via data services entity 516, which in turn communicates with web server process 540 via server communication entity 518.

[0279] Generally, there are two ways to construct an offline diagram 602 as depicted in Figure 5D. First, a user can toggle the block definition toggle 248m to open the block definition library 252 (see Figure 4D). From the block definition library 252, a user can select blocks 604a-604g one by one and place the blocks 604a-604g on the canvas 600. Next, a user can place wires 606a-606h to connect the various blocks. A wire 606a is placed between the output 608a of block 604a and the input 610b of block 604b, a wire 606b is placed between the output 608b of block 604b and the input 610c of block 604c, a wire 606c is placed between the output 608b of block 604b and the input 610d of block 604d, a wire 606d is placed between the output 608b of block 604b and the input 610e of block 604e, a wire 606e is placed between the output 608c of block 604c and the input 610f2 of block 604f, a wire 606f is placed between the output 608d of block 604d and the input 610g of block 604g, a wire 606g is placed between the output 608d of block 604d and the input 610f1 of block 604f, and a wire 606h is placed between the output 608f1 of block 604f and the input 610g of block 604g. After placing the blocks 604a-604g and wires 606a-606h in this manner, the offline diagram 602 remains unconstructed.

[0280] Alternatively, the user can select and place blocks 604a-604g one at a time, configure properties for each block 604a-604g as they are placed on canvas 600, and optionally (and in most cases) execute each of blocks 604a-604g after configuring properties for the block.

[0281] A user can configure each of blocks 604a-604g one at a time by clicking on the block and specifying properties associated with the block in a block properties window 612 for the block (whether placing and wiring blocks 604a-604g before configuring properties, or placing each one at a time and configuring properties for each before placing the next block). In FIG. 5D, block 604a, a query block, is selected, displaying the block properties window 612 for query block 604a. In the example canvas 600 depicted in FIG. 5D, the block properties window 612 for query block 604a includes a query properties entry area 614 where a user can enter a query. While a detailed description of the query language is reserved for discussion in a later section of the specification, for present purposes, it is sufficient to assume that a query entered in the query properties entry area 614 may specify the location of data to be queried upon execution of query block 604a. Block properties are stored as parameters in a configuration file associated with the block. The configuration file may reside on the web client running the web client process 502 or may be located on the web server running the web server process 504 .

[0282] After configuring the properties of query block 604a, a user typically executes block 604a before placing the next downstream block and / or before beginning to configure the properties of the next downstream block (in this case, block 604b). To execute block 604a, the user activates evaluation user control 248i. Doing so causes a configuration file associated with block 604a to be sent to the execution server process 506 via the data services entity 520 of the web server process 504. The configuration file is received by the execution server process 506, for example, as a JSON file, and a job listener entity 522 creates a job manager entity 524 to handle the execution request. The job manager entity 524 then causes an appropriate diagram compiler entity 526 to compile the configuration file into executable instructions (i.e., compiled query code) suitable for the target environment specified by the parameters in the configuration file. The diagram compiler entity 526 returns an output file containing the compiled code and may also return metadata indicating the target environment for which the compiled code is suitable. (Alternatively, the job manager entity 524 may maintain knowledge of the target environment during the compilation process.) The job manager entity 524 passes the output file to a job executor entity 528, which determines, according to parameters in a configuration file for the target environment, whether the code should be executed locally or remotely, whether the code should be executed on a distributed system, etc., and selects and reserves processor and memory resources to execute the instructions contained in the output file. The job executor entity 528 then creates job process(es) 508 to execute the output file.

[0283] When the execution of the output file is complete (in the case of an offline block or module) or when the results are available (in the case of an online module), these results are returned to the job executor entity 528. In this case, since there were no further executions pending (the diagram is an offline diagram and the block that just executed, i.e., query block 604a, is the only block configured), ), and the results are returned to the web server process 504 via the server communication entity 508 and ultimately to the application entity 514 in the web client process 502. The output data may include all of the data returned by the query, but may also include various statistical information (metadata) about the query data, such as (but not limited to) the mean, standard deviation, and median for each column of the data returned by the query. In embodiments, the metadata and result data are stored independently of each other. This advantageously allows a user to review information about the result data without necessarily loading all of the result data, which may be time- and / or resource-, i.e., computer-memory-, intensive. A user can view the returned data and / or metadata about the returned data by clicking on the block results view control 212a (see FIG. 4A) on the block. The default view may include metadata about the results for each of the variables included in the results, and may allow the user to select one or more selected portions of the resulting data to load and, if desired, view (e.g., in the form of a graph, chart, table, etc.) without having to load all of the data. Additionally, the return of the results to application entity 514 allows configuration of the properties of the next downstream block (in this case, block 604b) to which the data and / or metadata is made available over wire 606a.

[0284] Note that execution of a block (e.g., block 604a) may not be required in all cases to configure the next downstream block (e.g., block 604b). Whether a block must be configured and / or executed before a downstream block can be configured and / or executed will depend on data dependencies, as understood in view of the present disclosure as a whole.

[0285] It should also be noted that during execution, job process 508 may communicate with various distributed data engines 150 to receive or access data stored in big data storage 155. In cases where job process 508 is executing in an embedded big data analyzer 170, big data analyzer 170 may be communicatively coupled to big data storage 155, either directly or through one or more big data request servicers 165. Alternatively, in cases where job process 508 is executing in a processor that is not part of the embedded big data analyzer 170, job process 508 may be communicatively coupled to a DDE over a network and request data via big data request servicer 165.

[0286] The construction and implementation of each property of blocks 604b-604g of offline diagram 602 continues in the same manner and need not be described in great detail.

[0287] A. Using Offline Diagrams for Exploration and Modeling Users of a DDE User Interface Application working with Offline Diagrams typically expect to do one or both of two things: (1) explore various sets of data to explore and discover relationships between various data sets and / or events, and (2) create models of those relationships with the goal of implementing real-time, continuous predictive capabilities. Achieving the latter requires some measure of time spent working on the former. That is, in many (but not all) cases, users explore data sets to find relationships between the data using various analytical tools (principal component analysis, Fourier analysis, regression analysis, etc.), and when relationships are found that appear to have predictive value, the user implements that analysis as a model and employs it in real-time, continuous analysis of processes.

[0288] In embodiments, the Analytics Service 500 may include tools that automatically perform analysis of data, whether real-time data or historized data, or both, to discover anomalies, abnormal conditions, relationships between data, and / or characteristics of a particular data set within a process environment. In one embodiment, the block definition library 252 includes a block 255 that observes data and discovers anomalies in the context of the data set being reviewed, such as irregular spikes or dips in the data. Such anomaly-finding blocks in offline diagrams may receive historized data as input and further employ some of the techniques described above, including, for example, PLS, PCA, and other types of analysis, to look for characteristics in the historized data that may be interesting to explore. Alternatively or additionally, anomaly-finding blocks in online diagrams may receive both historized and real-time data and compare the historized data to the real-time data to look for anomalies in the real-time data relative to the historized data. In either case, the output of the anomaly discovery block may include one or more of the time the anomalous event occurred, the source(s) of the anomalous data (e.g., which measurements and / or devices are associated with the anomaly), etc.

[0289] In one embodiment, the block definition library 252 includes a block 255 that autonomously discovers relationships between various data. The relationship discovery block can select random or quasi-random sets of data (aligned in time) and run several different analyses on these sets of data to look for relationships that may be of interest to the user, particularly causal or predictive relationships. Of course, a truly random selection of a set of data is unlikely to produce many useful results. However, the selection of a data set may be influenced by, for example, physical location, plant hierarchical structure, or other evidence that may suggest that relationships between data may exist.

[0290] In some embodiments, the relationship discovery block may work in conjunction with the anomaly discovery block to discover relationships between data. As an example, the anomaly discovery block may output the times at which various anomalies occur in various datasets. The anomaly discovery block, in some embodiments, stores the times of ano...

Claims

1. 1. A distributed industrial process monitoring and analysis system comprising: a plurality of distributed data engines (DDEs) embedded within a process plant operative to control a process, each DDE coupled to a respective one or more data sources corresponding to each DDE generating data as a result of the process being controlled by the process plant, each DDE storing the data generated by the respective one or more data sources; a data analytics network that supports streaming of analytics data between the plurality of distributed data engines and sending queries regarding data stored in the plurality of DDEs; 11. A system comprising: (i) at least one of the DDEs publishes to the data analysis network at least a portion of the data being generated by the respective one or more data sources corresponding to the one of the DDEs; and (ii) another of the DDEs subscribes to at least a portion of the data being generated by the respective one or more data sources corresponding to the one of the DDEs and published by the one of the DDEs, the other of the DDEs being configured to receive from the one of the DDEs the at least a portion of the data to which the other of the DDEs subscribes when the one of the DDEs publishes at least a portion of the data.

2. The system of claim 1 , wherein at least one DDE of the plurality of DDEs is integral with a process control device operative to control the process.

3. The system of claim 2 , wherein the process control device transmits a signal over a process control communications network to another process control device to control the process.

4. The system of claim 1 , wherein queries regarding data stored in the plurality of DDEs are generated by one or more of the DDEs, a user interface, or an application.

5. The system of claim 4 , wherein the queries regarding the data stored in the multiple DDEs include queries regarding data stored across two or more DDEs.

6. 6. The system of claim 1, wherein the data stored in the plurality of DDEs is periodically transported via the data analysis network to an analytical data historian, the analytical data historian being independent of a process control data historian accessible via a process control communications network of the process plant.

7. The system of claim 1 , wherein each of the DDEs includes a cache in addition to a data storage area for storing the data generated by the respective one or more data sources.

8. 8. The system of claim 1, wherein a first DDE of the plurality of DDEs advertises a cluster in which the respective one or more data sources coupled to the first DDE register.

9. 9. The system of claim 8, wherein each of the one or more data sources coupled to the first DDE exposes to the cluster announced by the first DDE the data being generated by the each of the one or more data sources as a result of the process being controlled.

10. The system of claim 8 or 9, wherein the data exposed by the first DDE includes the results of a data analysis performed by the first DDE using at least a portion of the data generated by each of the one or more data sources coupled to the first DDE.

11. 11. The system of claim 8, wherein the cluster advertised by the first DDE is a local cluster, and a second DDE advertises a regional cluster to which the first DDE registers and to which the first DDE publishes data.

12. 12. The system of claim 11, wherein the second DDE corresponding to the regional cluster provides at least one of a location service or a data dictionary used to establish a data exchange with another regional cluster.

13. The system of claim 11 or 12, wherein one or more additional DDEs corresponding to one or more additional local clusters are registered with the regional cluster and publish data to the regional cluster.

14. 14. The system of claim 11, wherein a third DDE advertises a centralized cluster to which the second DDE registers and to which the second DDE publishes data.

15. The system of claim 14 , wherein the second DDE exposes at least a portion of the data stored at the second DDE to the centralized cluster via the data analysis network.

16. The system of claim 14 or 15, wherein the data published by the second DDE to the centralized cluster includes results of a data analysis performed by the second DDE using data received at the second DDE from another DDE.

17. 17. The system of claim 14, wherein one or more additional DDEs corresponding to one or more additional regional clusters are registered with the centralized cluster and publish data to the centralized cluster.

18. The system of claim 14 , wherein the centralized cluster is hosted in a cloud computing environment.

19. 19. The system of claim 14, wherein the process plant is a first process plant and other clusters corresponding to other process plants are registered with the centralized cluster and publish data to the centralized cluster.

20. 20. The system of claim 14, wherein the centralized cluster stores a set of rules for the data analysis network, the set of rules including a rule corresponding to at least one of replication or backup.

21. 21. The system of claim 1, further comprising a user interface for managing a set of rules for the data analysis network, the set of rules including a rule corresponding to at least one of replication or backup.

22. The system of claim 1 , wherein the other one of the DDEs performs one or more data analysis functions on the subscribed data.

23. 23. The system of claim 22, wherein results of the one or more data analysis functions performed by the other one of the DDEs are published to the data analysis network.

24. 24. The system of any one of claims 1 to 23, further comprising a data analytics user interface application through which a user acquires data stored in one or more DDEs and develops a data analytics model that predicts one or more values ​​of the process plant based on the data acquired from the one or more DDEs.

25. the data acquired by the data analysis model from the one or more DDEs includes continuously updated data generated by the process plant while controlling the process; and 25. The system of claim 24, wherein the data analytics model is continuously executed on the continuously updated data obtained from the one or more DDEs, thereby generating a continuous output, the continuous output including continuous updates to the one or more forecast values ​​of the process plant.

26. 26. The system of claim 25, wherein the continuously updated data obtained by the data analysis model from the one or more DDEs comprises data streamed from the one or more DDEs to the data analysis model via the data analysis network.

27. 27. The system of claim 25 or 26, wherein the data analysis model sends queries to the one or more DDEs to obtain the continuously updated data via the data analysis network.

28. 28. The system of claim 25, wherein the continuous output generated by the data analysis model is displayed in a user interface using a continuously updated graphical visualization.

29. 30. The system of claim 28, wherein the continuously updated graphical visualization of the one or more forecast values ​​is displayed on the user interface in conjunction with a continuously updated graphical visualization of one or more actual values ​​generated by the process plant and corresponding to the one or more forecast values.

30. 30. The system of claim 29, further comprising presenting an indication of accuracy of the data analytics model, the accuracy being based on a comparison of the one or more predicted values ​​and the one or more actual values.

31. 31. The system of claim 25, wherein the continuous output generated by the data analytics model is streamed to at least one of the plurality of DDEs.

32. 32. The system of claim 1, further comprising a user interface for obtaining data stored in any of the plurality of DDEs.

33. 33. The system of claim 1, wherein the analytical data streamed over the data analysis network includes results of data analysis functions performed by the plurality of DDEs and at least one of data generated by process control devices while controlling the process in the process plant, historized data, and other data.

34. 34. The system of claim 33, wherein the results of the data analysis functions performed by the plurality of DDEs include new analysis functions generated by another data analysis function.

35. the data generated by a process control device while controlling the process in the process plant is (i) transmitted over one or more process control communication networks to control the process; and (ii) transmitted over the data analysis network; and 35. The system of claim 33 or 34, wherein the historized data is (iii) transmitted over one or more process control communication networks to a process control data historian for storage, and (iv) transmitted over the data analysis network to an analysis data historian for storage.

36. 36. The system of claim 1, wherein at least some of the DDEs respectively store the data being generated by the respective one or more data sources using different formats.

Images