Centralized knowledge repository and data mining system

Abstract

A system for securely and efficiently acquiring data from a process plant and processing the data for consumption by one or more external applications or systems includes receiving event data from various data sources within or associated with the plant via a variety of different data formats and data communication structures at a centralized server or gateway, stripping the communication format structures from the data, placing the data including metadata associated with the data into an event stream, and making the data in the event stream available to a processing infrastructure that processes the data in a comprehensive and robust manner for easy consumption by external data mining, data visualization, and data analysis systems or applications.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 62 / 945,667, filed December 9, 2019, entitled "Centralized Knowledge Repository and Data Mining System," each of which is expressly incorporated by reference herein in its entirety.

[0002] This disclosure is also related to commonly owned U.S. patent application Ser. No. 15 / 332,622, entitled "Publishing Data Across a Data Diode for Secured Process Control Communications," filed Oct. 24, 2016, commonly owned U.S. patent application Ser. No. 15 / 332,690, entitled "Securely Transporting Data Across a Data Diode for Secured Process Control Communications," filed Oct. 24, 2016, which issued as U.S. Patent No. 10,270,745, and commonly owned U.S. patent application Ser. No. 15 / 332,751, entitled "Secured Process Control Communications," filed Oct. 24, 2016, which issued as U.S. Patent No. 10,257,163, the disclosures of which are incorporated herein by reference in their entireties.

[0003] This disclosure is also related to commonly owned U.S. patent application Ser. No. 16 / 577,679, entitled "Edge Gateway System with Data Typing for Secured Process Plant Data Delivery," filed on Sep. 20, 2019, commonly owned U.S. patent application Ser. No. 16 / 577,664, entitled "Edge Gateway System for Secured, Exposable Process Plant Data Delivery," filed on Sep. 20, 2019, and commonly owned U.S. patent application Ser. No. 16 / 577,800, entitled "Edge Gateway System with Contextualized Process Plant Knowledge Repository," filed on Sep. 20, 2019, the disclosures of which are incorporated herein by reference in their entireties.

[0004] The present disclosure relates generally to process plants and process control systems, and more specifically to collecting, mining, visualizing and processing data from process plants / process control systems and related systems in a condensed and manageable manner. [Background technology]

[0005] Distributed process control systems, such as those used in chemical, petroleum, pharmaceutical, paper product processing, or other process plants, typically include one or more process controllers communicatively coupled to one or more field devices via an analog, digital, or integrated 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, pressure, level and flow sensors), are positioned within the process environment and generally perform physical or process control functions, such as opening and closing valves, measuring process parameters such as pressure, temperature, and the like, 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 regarding the field devices, e.g., make process control decisions, generate control signals based on the received information, and interface with control modules or blocks that execute in 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 a process plant or system.

[0006] Information from the field devices and controllers is typically made available over a data highway 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 management computing devices, typically located in a control room or other location away from the harsher 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 of 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 the 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.

[0007] As an example, the DeltaV™ control system sold by Emerson Automation Solutions includes multiple applications stored in and executed by different devices 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 over a data highway to dedicated distributed controllers. Typically, these control modules are composed of communicatively interconnected function blocks that are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs thereto and provide outputs to other function blocks in the control scheme. The configuration application may also allow the configuration designer to create or modify operator interfaces that are used by viewing applications to display data to an operator and to allow the operator to change settings, such as set points, within a process control routine. Each dedicated controller, and in some cases, one or more field devices, stores and executes a respective controller application that executes the control modules assigned to and downloaded thereto to implement the actual process control functions. A viewing application may run on one or more operator workstations (or one or more remote computing devices in communicative connection with the operator workstations and the data highway) and receive data from the controller application via the data highway and display this data to a process control system designer, operator, or user using a user interface to provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc.While a data historian application is typically stored on and executed by a data historian device that collects and stores some or all of the data provided over the data highway, a configuration database application may be run on an even further remote computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located on the same workstation as the configuration application.

[0008] Generally speaking, a process control system of a process plant includes field devices, controllers, workstations, and other devices interconnected by a set of hierarchical networks and buses. The process control system may then be connected to various business and external networks, for example, to reduce manufacturing and operational costs, increase productivity and efficiency, provide timely access to process control and / or process plant information, etc. It is becoming increasingly important to be able to acquire and visualize process plant data outside the process control network environment, to be able to perform more traditional business functions, to be able to perform data analysis and data mining on the process data, etc. Meanwhile, the interconnection of the process plant and / or process control system with enterprise and / or external networks and systems increases the risk of cyber intrusion and / or malicious cyber attacks that may result from anticipated vulnerabilities in commercial systems and applications, such as those used in enterprise and / or external networks. Cyber ​​intrusion and malicious cyber attacks of the process plant, network, and / or control system may adversely affect the confidentiality, integrity, and / or availability of information assets, which are generally similar vulnerabilities to those of general-purpose computing networks. However, unlike general-purpose computer networks, cyber intrusions of process plants, networks, and / or control systems can result in damage, destruction, and / or loss of plant equipment, products, and other physical assets, as well as loss of human life. For example, a cyber intrusion may cause a process to become uncontrollable, thereby resulting in an explosion, fire, flood, exposure to hazardous materials, etc. Therefore, protecting communications associated with process control plants and systems is of paramount importance.

[0009] Importantly, process control systems cover a broad set of industries where processes are controlled by a combination of distributed control systems (DCS) and programmable logic controllers (PLCs). These control systems are deeply integrated into the batch and continuous processes they control, and these systems both control the various processes and collect a lot of data about the operation of the processes and the equipment within the processes. As a result, the amount of data currently available from process plants, process plant control systems, and associated business and third-party systems can be overwhelming. This data can serve many different purposes, but any data mining application or data consuming service needs to get the correct data from the plant (or associated systems) and process that data separately to perform the specific type of data mining required. Furthermore, as companies look to improve their operations, they need access to this data in a format that helps them generate reports, perform analytics, and perform real-time decision support. State-of-the-art data mining techniques in use today flatten the data into its element types (e.g., float and string formats) and collect this data in historians. This approach not only suspends all of the context about the data, but also all of the time relationships across the data, which creates significant challenges for continuous monitoring and analysis of the data. Thus, there is currently no simple or coordinated infrastructure for collecting, storing, and mining a variety of different types of data coming from a variety of different data sources within and associated with a process plant in a manner that helps make the data easy to process for data analysis purposes.Instead, to the extent that data is mined in a plant environment, each data analysis application that uses or requires data from a process plant must connect individually in some way (e.g., using a server connected to the plant through a firewall or other secure data retrieval system) to one or more of the systems in the plant, specify or request the data that the application requires, then receive that data from the plant in an online or streaming manner, and then process that data individually. However, in many cases, multiple different data mining applications request and use the same data, resulting in multiple requests for the same data, consuming the bandwidth and communication infrastructure of the various systems involved. Furthermore, when there are many different data consuming or data mining applications connected to the plant, data from various sources in the plant is transmitted in an ad-hoc manner, leading to overuse of the communication and processing infrastructure in the plant, many different failure points, and complex communication networks that are not easy to understand or manage. Furthermore, in many cases, the context of the data from the plant is lost in the communication network or storage infrastructure, making this data difficult to process or use in data analysis applications. Summary of the Invention

[0010] A system and method for securely and efficiently acquiring data from a process plant and processing the data for consumption by one or more external applications or systems includes receiving data from various data sources within or associated with the plant via a variety of different data formats and data communication structures at a centralized server or gateway, stripping the communication format structure of the data packets, placing the data including metadata associated with the data into an event stream, and making the data in the event stream available to a processing infrastructure that processes the data for easy consumption by external data mining, visualization, and analysis systems or applications. The data processing infrastructure includes one or more microservices, each of which analyzes the data in the event stream to perform a specific service such as recognizing certain types of events, processing the event data, and placing the processed data into one or more time series databases (with time-based telemetry) and distributed graph databases, as well as creating new or related data and placing the new data into the event stream as new event data for processing by other microservices. The data processing infrastructure may also include various application interfaces (APIs) that allow external applications, such as data visualization applications, data mining applications, and data analysis applications, to acquire the time series data and distributed graph database and use the data for various purposes. Additionally, the data processing infrastructure may include a set of data source and security services that allow users to register and define new data sources that are used to provide data to the event stream, as well as security procedures used to protect the system and incoming data.Similarly, the data processing infrastructure may include a process graph builder service that enables a user to provide process graph context data that defines process information in a graph or other form that defines the operation and interconnections of various devices, logic, and other elements in the process for use in creating a distributed graph in the distributed graph database. The data processing infrastructure may also include a task engine that performs one or more services on the data or event streams to enable a user to manage events in the event streams that require user interaction.

[0011] The data collection and processing system described herein can be used both to monitor data in motion and to perform extensive queries on data many months after it has been collected. The system effectively and efficiently integrates existing batch and continuous process control systems along with device information and asset monitoring data. Additionally, the system described herein provides a platform for performing analytics, monitoring events, running real-time dashboards, and supporting real-time decision support where data is available in full context. This allows the event and data storage system to enable real-time monitoring of industrial operations using both data and the full context of the data. The system also provides a platform for receiving, storing, and processing data from the plant that is secure, robust (in that it can easily adapt to new types of data) and comprehensive (so that it recognizes and stores data in context with other information in the plant), while also reducing the overall communication issues associated with multiple different data mining applications that obtain data from various data sources, either individually or separately. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram of an example edge gateway system for an industrial process plant. [Diagram 2] FIG. 1 is a block diagram of an exemplary industrial process plant, particularly illustrating the interconnections between various exemplary components of the process plant or process control system, the process control system itself, and other exemplary associated systems and / or networks with a similar security level as the process plant. [Diagram 3] FIG. 1 is a block diagram of example field facing components of an edge gateway system for a process plant or process control system. [Figure 4A] 1 illustrates an example data type of an example publishable data type system generated by a field-facing component of an edge gateway system for a process plant or process control system. [Figure 4B] 1 illustrates an example data type of an example publishable data type system generated by a field-facing component of an edge gateway system for a process plant or process control system. [Figure 4C] 1 illustrates an example data type of an example publishable data type system generated by a field-facing component of an edge gateway system for a process plant or process control system. [Figure 5A] FIG. 1 is a block diagram of a first portion of edge facing components of an edge gateway system for a process plant or process control system. [Figure 5B] FIG. 5B is a block diagram of a second portion of the edge-facing component of FIG. 5A. [Figure 6] FIG. 1 is a block diagram of a data acquisition and processing system that can be used to perform and support comprehensive data analysis, data visualization, and data mining within a plant environment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Generally speaking, process plants are configured to incorporate a variety of different levels of security depending on the particular portion of the plant involved. In particular, protecting process plants and process control systems from cyber intrusions and malicious cyber attacks typically utilizes a layered or leveled security hierarchy where at least some layers or levels are protected using firewalls and other security mechanisms. Using the Purdue Model for Control Hierarchy logical framework standardized by the International Society of Automation (ISA) 95.01-International Electrotechnical Commission (IEC) 62264-1 as an exemplary framework, process control systems are typically classified as security levels 0-2 (e.g., OT (operational techniques) level where there is a high level of confidence in the safety and validity of messages, packets, and other communications), while manufacturing, corporate, and enterprise systems are typically classified as security levels 3-5 (e.g., IT (information techniques) level where there is a low level of confidence). For example, process plant systems, networks, and devices at security levels 0-3 may be protected from threats from corporate networks at security levels 4-5 and / or from any external networks higher than security level 5 that utilize the corporate network, for example, by using a demilitarized zone (DMZ) and / or one or more firewalls.However, as more services and applications that manipulate process plant data move toward running remotely, e.g., on networks and systems outside the process plant (e.g., security level 4 and / or 5 within an enterprise or business associated with, owned, and / or operated by the process plant) and / or external to the enterprise or business (e.g., above security level 5 over the Internet or other public networks), more robust techniques are needed to prevent process plant systems, networks, and devices from being compromised.

[0014] The data collection and processing systems, components, apparatus, methods, and techniques described herein have been developed with these and other security issues associated with process plants and their networks in mind, and are specifically configured to enable secure delivery of process plant related data to one or more external systems that are consumers of the process plant related data in an efficient, highly secure, comprehensive, and easy to use manner. However, before describing the data collection and processing system in more detail, Figures 1-3 will be used to describe one implementation of a plant facing system that can collect data in a highly secure and efficient manner from one or more plant systems and provide that data to the data collection and processing system, as will be described in more detail in Figures 5 and 6.

[0015] To illustrate basic plant data collection, FIG. 1 is a block diagram of an exemplary edge gateway system 1 that securely distributes process plant related data (e.g., field data) from a process plant 5 to one or more external data consuming applications and / or systems, which may include enterprise applications and / or systems (e.g., at IT levels of security, such as security levels 3-5) and / or third party applications and / or systems. The edge gateway system 1 includes a field facing component 10 (that collects data from the plant environment) communicatively connected to an edge facing component 12 (that may implement a comprehensive data collection and processing system) via a data diode 15. The field facing component 10 includes one or more processors 18 and one or more non-transitory memory or data storage devices 20 that store at least one set of data and at least one set of computer executable instructions, the at least one set of computer executable instructions being executable by the one or more processors 18. 1, the one or more memories 20 of the field facing component 10 store respective data sets, such as one or more interest lists 22, a system of exposable data types 24A, and optionally other data sets (not shown). The one or more memories 20 of the field facing component 10 further store computer executable instructions for a data typer 25, and may also store other sets of computer executable instructions (not shown). The field facing component 10 is communicatively connected to one or more process plant communication networks, data networks, and / or links 28, which may include any number of wired and / or wireless communication networks, data networks, and / or links communicatively connecting various devices, and / or other data sources 30 associated with the process plant 5 and generating data during operation of the process plant 5 to control an industrial process, for example.A more detailed description of embodiments of the field facing components 10 of the edge gateway system 1 and its subcomponents is provided elsewhere within this disclosure.

[0016] The edge-facing component 12 of the edge gateway system 1 includes one or more processors 35 and one or more non-transitory memory or data storage devices 38 that store at least one set of data and at least one set of computer-executable instructions executable by the one or more processors 35. For example, as shown in FIG. 1, the one or more memories 38 of the edge-facing component 12 store at least a partial copy 24B of the system of exposable data types 24A of the field-facing component 10, with respective data sets corresponding to a data lake 40 and a context knowledge repository 42, and the one or more memories 38 of the edge-facing component 12 store respective computer-executable instructions for a context knowledge miner 45 and one or more access mechanisms 48 for the context knowledge repository 42. Although not shown in FIG. 1, it will be appreciated that the one or more memories 38 of the edge-facing component 12 may store other data sets and / or other sets of computer-executable instructions. As also shown in FIG. 1 , the edge-facing components 12 of the edge gateway system 1 are communicatively connected to one or more external data consumption systems 8 via one or more external communication networks, data networks, and / or links 50. The one or more external communication networks, data networks, and / or links 50 may include any number of wired and / or wireless communication networks, data networks, and / or links, and may include any number of private and / or public networks and / or links. The one or more external systems 8 may each be implemented using any suitable technology, such as server banks, cloud computing systems, and may include any number of public and / or private computing systems that may run various applications (third-party applications, websites, etc.). A more detailed description of embodiments of the edge-facing components 12 and their subcomponents is provided elsewhere within this disclosure.

[0017] As shown in FIG. 1, the field facing component 10 and the edge facing component 12 are interconnected via a data diode 15 (although in some implementations (not shown) of the edge gateway system 1, the data diode 15 may be omitted and the field facing component 10 and the edge facing component 12 may be directly connected or may be integral and be a single logical and / or physical component). In any case, as shown in FIG. 1, the data diode 15 includes one or more transmission media through which data (e.g., electronic data) is transmitted from the field facing component 10 to the edge facing component 12, and the data diode 15 is the only communication connection between the field facing component 10 and the edge facing component 12. In a preferred embodiment, the data diode 15 is unidirectional, such that any and all types of data (e.g., signaling data, control data, management data, payload data, etc.) flow only from the field facing component 10 to the edge facing component 12 and do not flow (and indeed, in some embodiments, cannot physically flow) from the edge facing component 12 to the field facing component 10. That is, data diode 15 may be physically and / or logically configured to prevent any and all types of data (e.g., signaling data, control data, management data, payload data, etc.) from flowing from edge facing component 12 to field facing component 10. In one example, unidirectional data diode 15 is implemented using a fiber optic link or cable or other suitable type of high bandwidth hardware and / or software transmission medium such as, for example, an Ethernet link, a wireless data diode, a software defined data diode, etc.In another example, the hardware and / or software of unidirectional data diode 15 may instead be configured to prevent the flow of any type of data (e.g., signaling data, control data, management data, payload data, etc.) from edge facing component 12 to field facing component 10 while supporting the flow of data from field facing component 10 to edge facing component 12. For example, physical ports of edge facing component 12 that would otherwise receive data from one or more external systems 8 may be blocked, disabled, and / or omitted.

[0018] For further security, data transferred from the field facing component 10 to the edge facing component 12 through the data diode 15 may be encrypted by the field facing component 10 and decrypted by the edge facing component 12. Additionally, for efficiency, the data diode 15 is configured to support high throughput data streaming, such as at a rate of 100K parameters per second or more. Indeed, in some embodiments, the data diode 15 may operate at speeds of 1 Gigabit per second or more. For example, the data diode 15 may be implemented using fiber optic links or cables, or other suitable types of high bandwidth hardware and / or software transmission media, such as, for example, Ethernet links, wireless data diodes, software-defined data diodes, and the like, to support high throughput data streaming capabilities. Such high bandwidth hardware and / or software transmission media may also be implemented with unidirectional transmit capabilities and no receive capabilities for the field facing component 10, thereby further enhancing unidirectional data transmission in only one direction, from the field facing component 10 to the edge facing component 12. Additionally, the data diode 15 is easily scalable to accommodate system growth. For example, multiple cores and / or multiple threads may be added and / or utilized to support system growth and a corresponding increase in the amount and speed of data transferred from the field facing components 10 to the edge facing components 12.

[0019] Generally speaking, the edge gateway system 1 securely connects and / or bridges the process plant 5 and associated systems at a lower numerical security level with one or more data consuming systems 8 at a higher numerical security level. For example, with reference to the Purdue model (or other similar security hierarchy), the data sources 30 and networks / links 28 through which the edge gateway system 1 obtains process plant related data may be at lower numerical security levels (e.g., security level 0 to security level 2) and may include, for example, process control systems, safety instrumented systems, configuration systems, analysis systems, communication / networking systems, asset management systems, diagnostic and / or testing tools and / or systems, commissioning tools and / or systems, user devices and / or operator interfaces, historian systems, batch systems, software defined networks, virtual networks such as virtual private networks, virtual local area networks (VLANs), virtual extensible local area networks (VXLANs), and other systems, networks, applications, and / or devices associated with the process plant 5. Thus, for ease of discussion herein, and not for purposes of limitation, the term "process plant 5" is used to collectively refer to the physical process plant and other systems associated with and communicatively connected to the physical process plant that generate and / or communicate data of lower number security levels.

[0020] In the edge gateway system 1 of FIG. 1 , the field facing components 10 that acquire and initially process process plant related data (e.g., field data) generated by the process plant 5 may be at security level 2 to security level 3, and the data diode 15 and edge facing components 12 may be at security level 3. The one or more external data consuming systems 8 may be at security level 4 or higher and may include any number of public and / or private systems and various applications running thereon, such as enterprise applications and / or systems, third party applications and / or systems, publicly available applications and / or systems, websites, etc. In this manner, the edge gateway system 1 securely distributes the field data generated by the process plant and its associated systems, networks, and / or applications 5 at lower numbered security levels to systems, networks, and / or applications 8 at higher numbered security levels.

[0021] In particular, as shown in FIG. 1, the field-facing component 10 of the edge gateway system 1 obtains or collects field data from data sources 30 according to one or more interest lists 22 stored in the field-facing component 10. The interest lists 22 indicate particular process plant-related or field data generated by the process plant 5 in association with the plant 5 operating to control an industrial process, the indicated process plant-related of the field data being exposable (e.g., exposable) to external systems, networks, and / or applications 8. In this manner, the interest lists 22 included in the edge gateway system 1 provide an initial level field-facing security such that protected field data is not inadvertently released from the process plant 5 to external data consuming systems 8. The interest lists 22 may indicate particular field interest data and / or combinations thereof, such as particular runtime data, event data, historical data, configuration data, and / or other types of process plant-related data generated by devices, components and / or systems associated with the process plant 5 of lower numerical security levels (e.g., security levels 0-2). Interest list 22 may be configured and / or defined via an interest manager (not shown in FIG. 1), which is described in more detail elsewhere in this disclosure.

[0022] Additionally, in the field facing component 10, the data typer 25 types each of the retrieved interest list data content according to a system of exposable data types 24A. Generally speaking, the system of exposable data types 24A defines or configures a system of data types (including data definitions, names, values, fields, structures, classes, objects, etc.) that are published or made available to the external data consuming system 8. Additionally, the exposable data system 24A defines names, mappings, conversions, groupings, value assignments, and / or other arrangements of process plant related or field data types into the exposable data types such that the process plant related data content may be utilized and understood by the external data consuming system 8. The terms "process plant related data types" or "field data types" used interchangeably herein generally refer to data types (e.g., data definitions, names, values, fields, structures, classes, objects, etc.) that are defined and / or configured for use with applications, devices, components, systems, and / or networks of the process plant 5 and its associated systems at a lower number security level. In one embodiment, the exposeable data type system 24A may be defined or configured via an interest manager (e.g., in a manner as described elsewhere in this disclosure). In any event, the exposeable data system 24A enables the external system 8 to interpret process plant related / field data generated by the process plant 5 and associated lower security level systems without the external system 8 having to be aware of any internal data definitions and / or configurations of the plant 5, and without the external system 8 having to query and / or initiate communication with and / or send responses to the process plant 5. In this manner, the exposeable data type system 24A and data typers 25 of the edge gateway system 1 further protect the process plant 5 from possible security breaches from the external system 8.The exposable data type system 24A and data typer 25 are described in more detail elsewhere in this disclosure.

[0023] At least through the use of the publishable data type system 24A and the data typer 25, the data diode 15 may be a truly unidirectional data diode. Currently known data diodes provide a unidirectional flow of content data, but also allow for a bidirectional flow of signaling, control, and / or management material by thus allowing acknowledgments and / or error conditions to be communicated from the data receiving end to the data sending end. However, the data diode 15 of the edge gateway system 1 may be truly unidirectional in that there is no data flow of any type from its data receiving end to its data sending end. Indeed, in an embodiment, the data diode 15 is physically configured to prevent any type of data (e.g., signaling, control, management, content, etc.) from being distributed from the edge facing component 12 to the field facing component 10, such as in an embodiment in which the data diode 15 is implemented via an optical transmission medium. Thus, at least through the truly unidirectional nature of the data diode 15, the data diode 15 of the edge gateway system 1 further protects the process plant 5 from possible security breaches from external systems 8.

[0024] In the edge-facing component 12 of the edge gateway system 1, the typed field content data received from the field-facing component 10 via the data diode 15 is stored in a data lake 40. A context knowledge miner 45 mines the data lake 40 to discover relationships and associations between the various field content data stored in the data lake 40 and creates / modifies / updates a context knowledge repository 48 such that the context knowledge repository 48 includes an indication of both the received field content data and the discovered relationships and / or associations (e.g., the context of the received field content data). In this manner, the context knowledge repository 48 stores both the process plant-related or field content data (e.g., runtime data, event data, historical data, and / or other types of data provided by the process plant 5, as well as context information indicating relationships between the provided process plant-related / field content data, conditions corresponding to the generation, delivery, and / or receipt of the process plant-related / field content data within the process plant 5, and / or the context of other types of process plant-related / field content data. The knowledge stored in the context knowledge repository 48 (e.g., the content data and associated context information, and optionally other data) can be exposed (e.g., made available) to one or more external data consuming systems 8.

[0025] Indeed, the edge facing components 12 provide one or more access mechanisms 48 through which external data consuming systems 8 may access at least a portion of the knowledge stored in the context knowledge repository 48. Each access mechanism may include yet another level of protection against possible security breaches from the external systems 8. For example, the access mechanisms 48 may be implemented using application programming interfaces (APIs), containers, etc. to help prevent unauthorized access by the external systems to the context knowledge repository 48 and / or the process plant 5. In an embodiment, at least one of the access mechanisms 48 may include a respective server or protected application running on the edge facing components 12, such as a search engine, where a server or private application (e.g., a server-specific or application-specific API, etc.) is exposed to the external systems 8 for their use. The edge facing components 12 of the edge gateway system 1 and its subcomponents are discussed in more detail elsewhere in this disclosure.

[0026] Generally speaking, the features, components, and architecture of the edge gateway system 1 provide nearly unlimited access to process plant related data from external, data consuming systems 8 in a highly secure manner and without impacting the performance of the process plant 5. Furthermore, when the edge gateway system 1 provides the process plant related data to the external systems 8 in a contextual manner, e.g., providing process plant related content data within the context of the configuration of the process plant 5, the external systems 8 may more quickly and easily find and use the process plant related data. Furthermore, the edge gateway system 1 enables a variety of different types of data consuming applications, such as mobile connectivity applications, advanced analytics applications, open systems technology applications (e.g., Node.JS, Docker, Linux, etc.), custom applications, IoT applications, IIoT applications, business and / or enterprise applications and / or enterprise applications (e.g., Excel, Power BI, etc.), and / or other types of applications, to operate securely and easily with contextual knowledge corresponding to the process plant 5. Additionally, the edge gateway system 1 is readily adaptable to aggregate process plant related data from multiple process plants to discover relevant aggregated knowledge therefrom, as well as to aggregate data from external systems at higher security levels (such as weather forecasting systems, supply chain systems, financial systems, inventory control systems, etc.) to discover relevant aggregated knowledge therefrom.

[0027] It should be noted that while FIG. 1 illustrates the edge gateway system 1 as including a single field-facing component 10 communicatively connected to the edge-facing component 12 via a unidirectional data diode 15, this is only one of many possible arrangements. For example, in some embodiments, the field-facing component 10 and the edge-facing component 12 may be implemented as integrated components within the edge gateway system 1, and the data diode 15 may be omitted. In some embodiments, the field-facing component 10 and the data diode 15 may be implemented as integrated components of the edge gateway system 1, or the data diode 15 and the edge-facing component 12 may be implemented as integrated components. In some embodiments, multiple instances of the data diode 15 may be included in the edge gateway system 1, such as when an integrated field-facing component 10 / data diode instance 15 is communicatively connected to an integrated data diode instance 15 / edge-facing component 12. In other embodiments, the edge gateway system 1 may include a single edge-facing component 12 communicatively connected to multiple field-facing components 10 via respective data diodes 15. In these embodiments, the edge gateway system 1 may serve an entire process plant site and data from the entire site may be aggregated in the edge facing components 12 and manipulated by various applications such as monitoring applications, analytical applications, reporting applications, display applications, etc. A single edge facing component 12 and multiple field facing components 10 configuration may be equally useful for serving multiple process plant sites, multiple process control systems, and / or other distributed configurations across an enterprise.

[0028] Process plants and associated data sources Figure 2 is a block diagram of an example process plant 100 configured to control an industrial process during online or runtime operation, from which process plant related information may be securely distributed via an embodiment of an edge gateway system 1. For example, the process plant 5 of Figure 1 may include at least a portion of the process plant 100 of Figure 2. As shown in Figure 2, the process plant 100 is communicatively connected to an edge gateway system 102, which may be, for example, an embodiment of the edge gateway system 1 of Figure 1.

[0029] The process plant 100 (also referred to interchangeably herein as a process control system 100 or process control environment 100) includes one or more process controllers that receive signals indicative of process and / or other types of measurements made by field devices, process this information to implement control routines, and generate control signals that are transmitted over wired or wireless process control communication links or networks to other field devices to control the operation of an industrial process within the plant 100. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering a temperature, taking measurements, sensing a condition, etc.) to control the operation of a process. Some types of field devices communicate with a controller using I / O devices and / or I / O electronic marshalling devices, hubs, services, or systems. 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 100.

[0030] 2 shows a process controller 111 that is communicatively coupled to wired field devices 115-122 via input / output (I / O) cards 126 and 128, and to wireless field devices 140-146 via a wireless gateway 135 and a process control data highway or backbone 110. The process control data highway 110 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, IP or other packet protocol, etc. In some configurations (not shown), the controller 111 may be communicatively coupled to the wireless gateway 135 using one or more communications networks other than or in addition to the backbone 110, such as by using any number of other wired or wireless communications links supporting one or more communications, data, and / or industrial automation protocols, e.g., Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communications protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, HART®, WirelessHART®, HART-IP, other packet protocols, streaming protocols, Profibus, FOUNDATION® Fieldbus, etc.

[0031] The controller 111 may be, by way of example, a DeltaV controller sold by Emerson Automation Solutions and may operate to implement a batch or continuous process using at least some of the field devices 115-122 and 140-146. In one embodiment, in addition to being communicatively connected to the process control data highway 110, the controller 111 is also communicatively connected to at least some of the field devices 115-122 and 140-146 using any desired hardware and software, for example, associated with standard 4-20 mA devices, I / O cards 126, 128, and / or any smart communication protocol, such as FOUNDATION® Fieldbus protocol, HART® protocol, WirelessHART® protocol, etc. In FIG. 2, the controller 111, the field devices 115-122, and the I / O cards 126, 128 are wired devices and the field devices 140-146 are wireless field devices. Of course, the wired field devices 115-122 and the wireless field devices 140-146 may conform to any other desired standard or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0032] The process controller 111 of FIG. 2 includes a processor 130 that implements or oversees one or more process control routines 138 (e.g., stored in memory 132). To this end, the processor 130 is configured to communicate with the field devices 115-122 and 140-146, and with other nodes communicatively connected to the controller 111. It should be noted that any control routines or modules described herein may be implemented or executed in part by different controllers or other devices, if so desired. Similarly, the control routines or modules 138 described herein implemented within the process control system 100 may take any form, including software, firmware, hardware, and the like. The control routines may be implemented in any desired software format, such as using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routines 138 may be stored in any desired type of memory 132, such as random access memory (RAM) or read-only memory (ROM). Similarly, the control routines 138 may be hard-coded into, for example, one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 111 may be configured to implement the control strategies or control routines in any desired manner.

[0033] The controller 111 implements 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 which operates with other function blocks (through communications called links) to implement process control loops within the process control system 100. A control-based function block typically performs one of the following: an input function associated with a transmitter, sensor or other process parameter measurement device; a control function associated with a control routine that controls PID, fuzzy logic, etc.; or an output function that controls the operation of some device, such as a valve, to perform some physical function within the process control system 100. Of course, hybrid and other types of function blocks exist. The function blocks may be stored within and executed by the controller 111, which is typically the case when these function blocks are used for or associated with some types of 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 device itself, which may be the case for FOUNDATION® Fieldbus devices. The controller 111 may include one or more control routines 138 that may implement one or more control loops performed by executing one or more of the functional blocks.

[0034] The wired field devices 115-122 may be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O cards 126 and 128 may be any type of I / O device conforming to any desired communication or controller protocol. In Fig. 2, the field devices 115-118 are standard 4-20 mA or HART® devices that communicate to the I / O card 126 via analog lines or combined analog and digital lines, while the field devices 119-122 are smart devices, such as FOUNDATION® Fieldbus field devices, that communicate to the I / O card 128 via a digital bus using the FOUNDATION® Fieldbus communication protocol. However, in some embodiments, at least some of the wired field devices 115, 116 and 118-121 and / or at least some of the I / O cards 126, 128 may additionally or alternatively communicate with the controller 111 using the process control data highway 110 and / or by using other suitable control system protocols (e.g., ProcessBus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0035] In FIG. 2 , the wireless field devices 140-146 communicate over a wireless process control communication network 170 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 140-146 may communicate directly with one or more other devices or nodes of the wireless network 170 that are also configured to communicate wirelessly (e.g., using the wireless protocol or another wireless protocol). To communicate with other nodes not configured to communicate wirelessly, the wireless field devices 140-146 may utilize a wireless gateway 135 connected to the process control data highway 110 or to another process control communication network. The wireless gateway 135 provides access to the various wireless devices 140-158 of the wireless communication network 170. In particular, the wireless gateway 135 provides communication coupling between the wireless devices 140-158, the wired devices 115-128, and / or other nodes or devices of the process control plant 100. For example, the wireless gateway 135 provides a communicative coupling by using the process control data highway 110 and / or by using one or more other communication networks of the process plant 100 .

[0036] Similar to the wired field devices 115-122, the wireless field devices 140-146 of the wireless network 170 perform physical control functions within the process plant 100, such as opening and closing valves, taking measurements of process parameters, etc. However, the wireless field devices 140-146 are configured to communicate using the wireless protocol of the network 170. In this manner, the wireless field devices 140-146, the wireless gateway 135, and the other wireless nodes 152-158 of the wireless network 170 are producers and consumers of wireless communication packets.

[0037] In some configurations of the process plant 100, the wireless network 170 includes non-wireless devices. For example, in FIG. 2, the field device 148 of FIG. 2 is a legacy 4-20 mA device and the field device 150 is a wired HART® device. To communicate within the network 170, the field devices 148 and 150 are connected to the wireless communication network 170 via wireless adapters 152A, 152B. The wireless adapters 152A, 152B support wireless protocols such as WirelessHART, and may also support one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network 170 includes one or more network access points 155A, 155B, which may be separate physical devices in wired communication with the wireless gateway 135 or may be provided within the wireless gateway 135 as an integrated device. In addition, the wireless network 170 may also include one or more routers 158 for forwarding packets from one wireless device to another within the wireless communication network 170. In Figure 2, the wireless devices 140-146 and 152-158 communicate with each other and with the wireless gateway 135 via wireless links 160 of the wireless communication network 170 and / or through the process control data highway 110.

[0038] 2, the process control system 100 includes one or more operator workstations 171 communicatively connected to the data highway 110. Through the operator workstations 171, an operator may view and monitor the runtime operation of the process plant 100 as well as take any diagnostic, corrective, maintenance, and / or other actions that may be necessary. At least some of the operator workstations 171 may be located in various protected areas within or near the plant 100, such as, for example, the back-end environment of the plant 100, and in some cases, at least some of the operator workstations 171 may be located in remote locations, but still communicatively connected to the plant 100. The operator workstations 171 may be wired or wireless computing devices.

[0039] The example process control system 100 is further shown as including a configuration application 172A and a configuration database 172B, each of which are also communicatively connected to the data highway 110. As discussed above, various instances of the configuration application 172A may run on one or more computing devices (not shown) to enable users to create or modify process control modules and / or other types of modules and download them via the data highway 110 to the controller 111 and / or other devices of the process control system 100, as well as to enable users to create or modify operator interfaces through which an operator can view data and change data settings within a process control routine. The configuration database 172B stores the created (e.g., configured) modules and / or operator interfaces. Generally, the configuration application 172A and the configuration database 172B may be centralized and have a single logical appearance to the process control system 100, even though multiple instances of the configuration application 172A and the configuration database 172B may be implemented across multiple physical data storage devices. Thus, the configuration application 172A, the configuration database 172B, and the user interface thereto (not shown) comprise a configuration or development system 172 for a control and / or display module. Typically, but not necessarily, the user interface for the configuration system 172 is distinct from the operator workstation 171, since the user interface for the configuration system 172 is utilized by configuration and development engineers regardless of whether the plant 100 is operating in real time, whereas the operator workstation 171 is utilized by an operator during real-time operation of the process plant 100 (also referred to herein interchangeably as “run-time” operation of the process plant 100).

[0040] The example process control system 100 also includes a data historian application 173A and a data historian database 173B, each of which are also communicatively connected to the data highway 110. The data historian application 173A operates to collect some or all of the data provided across the data highway 110 and historize or store the data in the historian database 173B for long term storage. Like the configuration application 172A and the configuration database 172B, the data historian application 173A and the historian database 173B may be centralized and have a single logical appearance to the process control system 100, even though multiple instances of the data historian application 173A may be running simultaneously within the process control system 100, and the data historian 173B may be implemented across multiple physical data storage devices.

[0041] In some configurations, the process control system 100 includes one or more other wireless access points 174 that communicate with other devices using other wireless protocols, such as Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols, such as Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) or other ITU-R (International Telecommunication Union Radiocommunication Sector) compatible protocols, shortwave wireless communications, such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 174 enable communication by handheld or other portable computing devices (e.g., user interface devices 175) over a respective wireless process control communication network that is different from the wireless network 170 and that supports a different wireless protocol than the wireless network 170. For example, the wireless or portable user interface devices 175 may be mobile workstations or diagnostic test equipment utilized by an operator (e.g., one instance of the operator workstations 171) within the process plant 100. In some scenarios, in addition to the portable computing devices, one or more process control devices (e.g., the controller 111, the field devices 115-122, or the wireless devices 135, 140-158) also communicate using a wireless protocol supported by the access point 174.

[0042] In some configurations, the process control system 100 includes one or more gateways 176, 178 to systems outside the proximate process control system 100. Typically, such systems are customers or suppliers of information generated or manipulated by the process control system 100. For example, the process control plant 100 may include a gateway node 176 for communicatively connecting the instant process plant 100 with another process plant. Additionally or alternatively, the process control plant 100 may include a gateway node 178 for communicatively connecting the instant process plant 100 with external public or private systems, such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator round inventory control 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.

[0043] 2 illustrates only a single controller 111 with a finite number of field devices 115-122 and 140-146, wireless gateway 35, wireless adapter 152, access point 155, router 1158, and wireless process control communications network 170 included in the example process plant 100, it should be noted that this example is merely an illustrative and non-limiting embodiment. Any number of controllers 111 may be included within the process control plant or system 100, and any of the controllers 111 may communicate with any number of wired or wireless devices and networks 115-122, 140-146, 135, 152, 155, 158, and 170 to control processes within the plant 100.

[0044] As shown in Figure 2, and referring simultaneously to Figure 1 for clarity of explanation and not by way of limitation, a process plant 100 is communicatively connected to an edge gateway system 102, which may be an embodiment of the edge gateway system 1 of Figure 1. For example, the process plant 100 may be communicatively connected to the field facing components 10 of the edge gateway system 1 via one or more process plant communication networks, data networks, and / or links, directly and / or via respective gateways of the process plant 100. For example, the field facing components 10 of the edge gateway system 1 may be communicatively connected to the process plant 100 via networks 110, 170, via gateways 135, 176, 178, and / or other networks, links, and / or gateways associated with the process plant through which the field facing components 10 receive or obtain data generated by the various data sources 30 associated with the process plant 100.

[0045] Generally speaking, the data sources 30 and networks / links 28 through which the edge gateway system 1 obtains process plant related data may be at lower numbered levels of the Purdue model or similar security hierarchy (e.g., Level 0 to Level 2) and may include controllers, field devices, I / O cards, and other types of process control devices. It will be further understood that the set of data sources 30 associated with the process plant is not limited to only process control devices that directly generate primary process data, but may additionally or alternatively include any devices or components within and / or associated with the process plant 100 that generate process data and / or other types of data as a result of the process plant 100 controlling an online process. For example, the set of data sources 30 may include modules, alarms, event historians, batch systems and / or historians, diagnostic devices or components that generate diagnostic data, network routing devices or components that transmit information between various components and / or devices of the process plant 100, asset management systems, configuration systems, analytics systems, mobile devices, virtual networks such as software defined networks, virtual private networks, VLANs, and / or VXLANs, and the like. Indeed, any one or more of the components shown in FIG. 2 (e.g., components 111, 115-122, 126, 128, 135, 140-146, 152, 155, 158, 160, 170, 171-176, 178) and other components not shown in FIG. 2 may be data sources 30 that generate process plant-related data that may be provided for consumption by one or more external systems 8 via the edge gateway systems 1, 102.

[0046] Field Facing Components 3 is a block diagram of a field facing component 300 that may be included in an edge gateway system, such as edge gateway system 1 or edge gateway system 102. For example, field facing component 300 may be field facing component 10 shown in FIG. 1 and / or may be communicatively coupled to process plant 100 of FIG. 2. For ease of explanation, and not by way of limitation, FIG. 3 is described with simultaneous reference to FIGS. 1 and 2, however, it is understood that field facing component 300 may be included in an edge gateway system other than edge gateway system 1 or 102 and may be communicatively coupled to a process plant other than process plant 5 or process plant 100.

[0047] 3, the field data receiver 302 of the field facing component 300 may be communicatively coupled with a process plant, such as the process plant 5 or 102, and optionally with other systems, devices, and / or applications that support and / or are associated with the process plant in runtime operation, such as process control systems, safety instrumented systems, configuration systems, analysis systems, communication / networking systems, asset management systems, diagnostic and / or testing tools and / or systems, commissioning tools and / or systems, user devices and / or operator interfaces, historian systems, batch systems, software defined networks, virtual private networks, such as VLANs and / or VXLANs, other systems, networks, applications, and / or devices associated with the process plant, etc. Generally speaking, the process plant and its support systems to which the field facing component 300 is communicatively coupled operate at the Purdue model (or a similar security hierarchy) of security levels 0-2. For ease of discussion herein, and not for purposes of limitation, the term “process plant 5” is used to collectively refer to the physical process plant with which the field-facing components 300 can communicate, as well as other systems associated with and communicatively connected to the physical process plant that generate and / or communicate data at lower numerical security levels.

[0048] The field data receiver 302 is communicatively connected to the process plant 5 via one or more links, communication networks, and / or data networks 305 of the process plant 5, collectively referred to herein as the “process plant network 305.” The process plant network 305 may include any number of wired and / or wireless links and / or networks supporting one or more communications protocols, data protocols, and / or industrial automation protocols, such as Ethernet, IP or other types of packet protocols, Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communications protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, other standardized communications and / or data protocols (such as those established by the Internet Engineering Task Force (IETF), the Institute of Electrical and Electronics Engineers (IEEE), or the International Organization for Standardization (ISO)), HART®, WirelessHART®, HART-IP, Profibus, FOUNDATION® Fieldbus, Field Device Integration Technology (FDI), OPC (Object Linking and Embedded for Process Control) UA (Unified Architecture), other types of industrial automation protocols, and the like.For example, the process plant network 305 may include the process plant network 28, the wireless network 170, the backbone 110, and other wired and / or wireless networks and / or links available to the process plant 5 and its associated systems, such as, for example, an asset management network, a historian network, a data analytics network, a software defined network, a virtual network such as a virtual private network, a VLAN, and / or a VXLAN, a diagnostic and / or test network, a configuration network, and / or another type of network corresponding to the operation, maintenance and / or configuration of the process plant 5.

[0049] The field data receiver 302 retrieves one or more field configurations of the process plant 5 from the process plant 5 via the process plant network 305. For example, if the process plant 5 includes a DeltaV process control system provided by Emerson Automation Solutions, the field data receiver 302 retrieves one or more FHX files in which the process control system and its components (e.g., physical, logical, and data components) are defined, for example, via the configuration application 172A. The interest manager 308 defines, creates, generates, and updates a collection or system of exposable data types 310 based on the retrieved field configuration of the process plant 5. As described in more detail elsewhere in this disclosure, the field facing components 300 forward the system or collection of exposable data types 310 to the respective edge facing components (e.g., edge facing components 12). In an exemplary embodiment, the system or collection of exposable data types 310 is the system of exposable data types 24A of FIG. 1.

[0050] Generally speaking, to define, create, generate, and update the system of exposable data types 310, the interest manager 308 extracts information from the retrieved field data configurations, and the retrieved information is made available for exposable (e.g., exposable) to external, data consuming systems 8. Whether or not certain information contained in the retrieved field configurations is made available for exposable to external systems 8 may be predefined. For example, it may be predefined a priori by the edge gateway system, the field facing components 300, and / or by a user via one or more interest lists 315, and / or it may be indicated in-line during the extraction process, for example, by the edge gateway system, the field facing components 300, and / or by a user. In any case, the interest manager 308 names, maps, transforms, groups, assigns values ​​to, and / or otherwise arranges the extracted information into corresponding data types and configurations of the system of exposable data types 310, for example, using a syntax, such as a commonly understood standard or open source syntax. Thus, the exposable data type system 310 provides a common understanding of other types of exposable process plant related data contained in the field content data (which may include, for example, process plant related data types, parameter types, block types, module types, event types, history data types, equipment and equipment component types, display and display component types, and other process plant related data generated by the process plant) using a syntax that is naturally understood by external data consuming systems 8.

[0051] For example, the system of exposable data types 310 may include basic data types such as float, float with status, signed integer, unsigned integer, and other basic data types that are naturally understood by the external data consuming system 8. Additionally, the system of exposable data types 310 may include more complex data configuration type definitions that are defined and structured at least in part based on the basic data types shown in FIGS. 4A-4C. Some data types in the system of exposable data types 310 may include multiple fields, as shown in FIG. 4A by the exemplary mode type 312a defined to include four fields of type ENUM. Indeed, the system of exposable data types 310 may include types based on multiple enumerations, which may be user-defined or system-defined. For example, as shown in FIG. 4C, a portion 312b of the exemplary enumeration set included in the system of exposable data types 310 is named and defined to indicate distinct HART states utilized in the process plant 5. 4B illustrates a more complex example portion 312c in which a causal matrix (CEM) function block of a process plant 5 is defined within the exposeable data types system 310 through the use of block types. Of course, the exposeable data types system 310 may include many more exposeable data type definitions and / or configurations than the examples shown in FIGS. 4A-4C.

[0052] In general, the system or collection of exposable data types 310 generated or defined by the interest manager 308 need not conform to the data types, configurations, hierarchies, and architectures defined within the process plant 5 (although, if desired, some exposable data types 310 may be defined to conform at least partially to a defined process plant data architecture and configuration). Additionally, it is understood that the generation or definition of the system or collection of exposable data types 310 is not typically a one-to-one conversion or mapping of each defined process plant data type to an exposable data type. Rather, only process plant data types that allow for exposure to external data consuming systems 8 are included in the collection / system 310, and such exposable process plant data types are reorganized, rearranged, regrouped, consolidated, distributed, abstracted, defined, and / or otherwise represented in a comprehensive data type system 310 that is more useful and / or more easily utilized by the external systems 8, not only in syntax but also in the structure and arrangement of content.

[0053] In particular, as described above, in some embodiments, the interest manager 308 extracts the systems of exposable data types 310 from the captured field configuration of the process plant 5 based at least in part on one or more interest lists 315. The interest lists 315 indicate what types of process plant related data may be exposed by the field facing components 300 to external data consuming systems 8, and the interest lists 315 may be defined by a user, the field facing components 300, the edge gateway system 1, and / or some other computing system, for example, via an interest list configuration application provided by the field facing components 300. For example, the field facing components 300 may provide a web-based user interface through which a user may manually define one or more interest lists 315, for example, by using JSON (JavaScript Object Notation) or other types of scripts or notations. Additionally or alternatively, the field facing components 300, edge gateway system 1, and / or some other computing system may automatically determine or define one or more interest lists 315, for example, by using templates and best practices, by including commonly written and / or read data points (e.g., via operator interface data and / or analysis, processing historian data, mining event historian data, etc.), and / or by using other suitable automation techniques. In one embodiment, the set of interest lists 315 defines only the data of the entirety of the data acquired by the field facing components from the process plant that the field facing components 300 allow to be exposed to one or more external systems for consumption by the field facing components.Different field-facing components 300 of the process plant 5 may store different sets of interest lists 315, as desired, thus indicating the particular types of process plant-related data that the hosting field-facing components each allow to expose to the data consuming system 8.

[0054] The interest list may indicate, for example, the names and respective groupings or arrangements of related modules, nodes, diagnostics, alarms, events, and / or other field data information that are configured in multiple and possibly heterogeneous configurations within the process plant 5. Indeed, the interest list 315 need not conform to a configuration hierarchy and / or configuration content defined within the process plant 5 (although, if desired, the interest list 315 may be defined to conform at least in part to a defined process plant configuration hierarchy and / or configuration content). Generally speaking, the interest list 315 may be defined in any manner (e.g., organizationally, hierarchically, and / or content-wise) that is useful and / or easily utilized by external systems 8 that are consumers of the exposed process plant related data. For example, at least some of the interest lists 315 may be named to reflect particular plant equipment and / or devices (e.g., “Diesel Hydrotreater 1”, “Alkylation Unit 3”, etc.) and may be defined using parameters from a number of different modules, nodes, diagnostics, alarms, etc. obtained from a number of different configurations defined within the process plant 5 and associated with the particular plant equipment / devices. For example, the field data content ingestor 320 may utilize the particular interest lists 315 to extract particular field content data (e.g., control data, I / O data, diagnostic data, device data, etc.) collectively identified by the particular interest lists 315 as representing a particular named entity (e.g., “Diesel Hydrotreater 1”, “Alkylation Unit 3”, etc.) and may store the extracted data corresponding to the particular named entity in the cache 322, e.g., as is and / or in a reorganized manner, e.g., by using the exposeable data type system 310A, such that the extracted data corresponding to the particular named entity of the particular interest 315 list is exposed to the external system 8 via the edge facing component 12.

[0055] For example, a “Spray Tower 2” relationship list may be defined to reference a particular spray tower in process plant 5 and may include all parameters related to “Spray Tower 2” included in the field configuration, such as asset management systems, process control systems, safety instrumented systems, diagnostic tools, historian systems, software defined networks, virtual private networks, virtual networks such as VLANs, VXLANs, etc. For example, a “Spray Tower 2” interest list may include parameters indicative of the area in which spray tower 2 is located, parameters indicative of pipes, pumps, other vessels, lines, and other physical component devices included in spray tower 2 (which may be referenced in the field configuration, e.g., by device tags and other types of physical component tags or identifiers), logical process elements such as control loops and modules, control parameters and / or variables (e.g., set points, measurements, control signals, other signals, etc.), alarms, events, operational states or status, equipment or device states or conditions, timestamps, and other logical and / or display components included in and / or utilized by spray tower 2 (which may be referenced in the field configuration, e.g., by control tags, device signal tags, or other types of logical component tags or identifiers, etc.). Additionally, the “Spray Tower-2” interest listing may indicate other characteristics and / or aspects of the parameters, such as, for example, their respective units of measurement, their respective ranges, their respective target or set values, their respective control routines or other applications that utilize the parameters, their respective uses, their respective diagnostic parameters, and / or other respective characteristics and / or associated information.

[0056] In some embodiments, based on generation of the interest list 315, the interest manager 308 may determine one or more changes to one or more field configurations stored in the process plant 5 and communicate the determined changes to the configuration application 172A or other process plant related configuration applications via the process plant network 305, as indicated by reference numeral 318.

[0057] Returning to the field data receiver 302, in addition to the field configuration, the field data receiver 302 also receives field content data from the process plant 5 via the process plant network 305, including data generated by the process plant 5 while operating to control an industrial process, as well as other data related to the process plant 5 that performs control operations on the industrial process. Generally speaking, the field content data includes any type of data generated by the process plant 5, for example, by process control systems, configuration systems, analysis systems, communication / networking systems, asset management systems, diagnostic and / or testing tools and / or systems, commissioning tools and / or systems, user devices and / or operator interfaces, historian systems, batch systems, software defined networks, virtual networks such as virtual private networks, VLANs and / or VXLANs, and other systems, networks, applications, and / or devices associated with the process plant. For example, the field content data may include runtime process data, continuous process data, batch process data, batch history data, history data, event data, alarm data, analytical data, diagnostic data, environmental data, user interface data, performance data, and / or other types of payload data generated by the data source 30. The field data receiver 302 may receive the field content data over the process plant network 305 in any protocol utilized by the process plant network 305, e.g., Ethernet, wireless HART, HART-IP, and / or other packet protocols, streaming protocols, etc.

[0058] The field content data ingestor 320 may ingest the obtained field data content based on the interest list 315, perform processing on at least a portion of the ingested field data content, store the ingested field data content in the field facing component 300 cache or other type of memory 322, and ultimately deliver it to its respective edge facing component (e.g., edge facing component 12). The field content data ingestor 320 may cooperate with the field data receiver 302 to obtain field content data for ingestion in one or more different ways. For example, in the case of field content data published by the respective source 30 and included in the interest list 315, the field content data ingestor 320 may, for example, cause the field data receiver 302 to subscribe to the publication of such field content data on behalf of the field facing component 300. In another example, for some field content data included in the interest list 315, the field content data ingestor 320 may initiate a query of the respective data sources 30 for the field content data, e.g., via polling and / or via a request / response mechanism, e.g., according to at least some of the configured or defined interest lists 312. In yet another example, for some field content data included in the interest list 315, the field content data ingestor 320 may stop or filter any field content data obtained in the field facing component 300 via the field data receiver 302 and that is not indicated in the interest list 302. In yet another embodiment, instead of defining or indicating which field content data is exposed to external sources 8, some interest lists 315 may define or indicate which types of field content data should be excluded from being exposed to external sources 8.If such unpublished field content data is received at the field facing component 300, the field content data ingestor 320 may stop or filter such field component data so that the excluded field content data is not stored in the cache 322 and is not delivered to the edge facing components.

[0059] In some embodiments, the interest list 315 may represent publishable field content interest data that is not generated by the process plant related data sources 30, but is derived or generated from field content data generated by the process plant related data sources 30. Such secondary field content data may be determined or generated by one or more calculation engines 325 invoked by the field content data ingestor 320. Generally speaking, the calculation engines 325 operate on primary field content data obtained via the process plant network 308 to generate one or more outputs, the outputs of the calculation engines 325 being defined as publishable field content data on one or more interest lists 315. The outputs of the calculation engines 325 may be stored in the cache 322 along with other primary field content data for eventual delivery to edge-facing components. The calculation engines 325 may perform computational functions such as in-stream data aggregation and / or manipulation (e.g., average, maximum, minimum, etc.). The computation engines 325 may perform more complex calculations or algorithms, such as principal component analysis (PCA), partial least squares (PLS) prediction, and / or other types of statistical calculations or analyses. The computation engines 325 may perform process control specific calculations, such as function block, shadow block, and / or control module operations. At least some of the computation engines 325 may be defined and / or configured by scripts and / or via a web-based user interface or other type of computation engine configuration application provided by the field facing components 300, and at least some of the computation engines 325 may be defined and / or configured using containers (such as Docker containers and / or other suitable types of containers) that are accessed and / or installed from the field facing components 300.

[0060] In addition to the calculation engine 325, the field content data ingestor 320 may invoke a data typer 328 to convert at least a portion of the retrieved, publishable field content data into respective publishable data types according to the publishable data type system 310. That is, the data typer 328 represents the publishable field content data using names, structures, groupings, values, arrangements, etc. defined by the publishable data type system 310. The field content data ingestor 320 stores the typed field content data in a data cache 322 as published field content data associated with the process plant 5 for delivery to edge-facing components.

[0061] The published data provider 330 of the field-facing component 300 provides the publishable data configurations and published data content to the edge-facing component corresponding to the field-facing component 300, e.g., via the data diode 15 or via some other suitable data transfer mechanism. For example, the published data provider 330 may transmit the publishable data configurations of the system 310 in a publishable data type to the edge-facing component, e.g., on behalf of the field-facing component 300, so that the edge-facing component can interpret the published data content transmitted by the field-facing component 300. The published data provider 330 may then retrieve the stored published field data content stored in the cache 322 and transmit the retrieved data to the edge-facing component. The published data provider 330 may transmit the publishable data configurations and published data content using a streaming protocol and / or a public or commonly used data exchange format, such as JSON or other standardized and / or open source data format. For example, the field-facing components 300 may provide streaming services that the exposed data providers 330 utilize to stream data to corresponding edge-facing components, e.g., via respective unidirectional data diodes 15. In one embodiment, the exposed data providers 330 wrap the exposeable data configurations and exposed data content in a streaming protocol implemented using a public or commonly used data exchange format. In some embodiments, the exposed data providers 330 transmit the exposeable data configurations and exposed data content to the edge-facing components using a proprietary or private protocol, which may be a proprietary or private streaming protocol. In some embodiments, the exposed data providers 330 encrypt the exposed data configurations and exposed data content before delivering them to the edge-facing components.

[0062] In one embodiment, the published data provider 330 publishes publishable data configurations and published data content, for example, via the data diode 15. The edge facing components subscribe to information published by the published data provider 330 of the field facing components 300, thereby obtaining the publishable data configurations and published data content that may be available to external data consumption systems 8 at the edge facing components, as described in more detail elsewhere in this disclosure.

[0063] 3, the field data receiver 302, interest manager 308, field content data ingestor 320, data typer 328, and exposed data provider 330 are shown as separate and distinct components of the field facing components 300, it should be noted that this is for clarity of discussion only and not by way of limitation. Indeed, any two or more of the components 302, 308, 320, 328, and 330 may be implemented as integral components of the field facing components 300, if desired.

[0064] Edge Facing Components 5A-5B illustrate block diagrams of an edge-facing component 400 that may be included in an edge gateway system, such as edge gateway system 1 of FIG. 1 or edge gateway system 102 of FIG. 2. For example, edge-facing component 400 may be edge-facing component 12 shown in FIG. 1 and / or may be communicatively coupled to field-facing component 10 or 300, for example, via data diode 15 or another connecting link, network, or medium. Importantly, edge-facing component 400 may implement a comprehensive data collection and processing system that effectively and efficiently collects real-time data from a plant environment and processes and stores that data for use by other applications (e.g., external applications) in a unique manner that makes the data more usable and retrievable. For ease of explanation and not for purposes of limitation, FIGS. 5A and 5B are described with simultaneous reference to FIGS. 1-3, although it will be understood that edge-facing component 400 may be included in edge gateway systems other than edge gateway system 1 or 102 and may be communicatively coupled to field-facing components other than field-facing component 10 or 300.

[0065] 5A, the exposed data receiver 402 of the edge facing component 400 may likewise be communicatively coupled to field facing components that may be communicatively coupled to the process plant, such as the process plant 5 or 102, and optionally other systems, devices, and / or applications that support and / or are associated with the process plant in runtime operation, such as process control systems, safety instrumented systems, configuration systems, analysis systems, communication / networking systems, asset management systems, diagnostic and / or testing tools and / or systems, commissioning tools and / or systems, user devices and / or operator interfaces, historian systems, batch systems, virtual networks such as software defined networks, virtual private networks, VLANs, and / or VXLANs, and other systems, networks, applications, and / or devices associated with the process plant. Generally speaking, the process plant and its supporting systems to which the field facing components corresponding to the edge facing components 400 are communicatively coupled operate at security levels 0-2 of the Purdue model (or a similar security hierarchy).

[0066] The exposed data receiver 402 of the edge facing component 400 communicatively connects the edge facing component 400 and the corresponding field facing component via one or more links, communication networks, and / or data networks. In a preferred embodiment, the exposed data receiver 402 communicatively connects the edge facing component 400 to the corresponding field facing component via a data diode, such as the unidirectional data diode 15 shown in FIG. 1. For ease of discussion and not for purposes of limitation, the edge facing component 400 is described as being communicatively connected to the field facing component via the data diode 15, although it will be appreciated that other communication connections besides the data diode 15 may interconnect the edge facing component 400 and the field facing component. For example, in some embodiments, the edge facing component 400 and the field facing component may be included in an integrated system or device.

[0067] The published data receiver 402 may receive published data configurations and published data content from the field facing components. The publishable data configurations and published data content may be received via a streaming protocol and / or via a public or commonly used data exchange format, such as JSON or other standardized and / or open source data exchange format. In some embodiments, the published data configurations and published data content may be wrapped with a streaming protocol at the edge of the field facing components, and the published data receiver 402 unwraps or extracts the published data configurations and published data content from the data stream. In some embodiments, the published data configurations and published data content may be encrypted at the edge of the field facing components, and the published data receiver 402 decrypts the information received via the data stream. In some embodiments, the field facing components publish the publishable data configurations and published data content, for example, over the data diode 15. The edge facing components 400 subscribe to information published by the field facing components, thereby obtaining the publishable data configurations and published data content from the field facing components.

[0068] The releasable data configurations received at the published data receiver 402 collectively define a system of releasable data types (e.g., system of releasable data types 24A or 310) generated by the field facing components based on the process plant related configurations, such as in the manner described above. The published data receiver 402 stores the received releasable data configurations locally in one or more memories as a local copy 24B of at least a portion of the system of releasable data types 24A of the field facing components.

[0069] The published data content received at the published data receiver 402 is represented using the respective data types included in the publishable data type system 24B. The received published data content may include field content data generated by the process plant 5, such as data generated by process control systems, configuration systems, analysis systems, communication / networking systems, asset management systems, diagnostic and / or testing tools and / or systems, commissioning tools and / or systems, user devices and / or operator interfaces, historian systems, batch systems, software defined networks, virtual networks (e.g., virtual private networks, VLANs, VXLANs, etc.), and other systems, networks, applications, and / or devices associated with the process plant. For example, the field content data may include runtime process data, continuous process data, batch process data, batch history data, history data, event data, alarm data, analysis data, diagnostic data, environmental data, user interface data, performance data, and / or other types of payload data generated by the data sources 30. Additionally, the received published data content may include data derived or generated from field content data by a field facing component corresponding to the edge facing component 400, such as by one or more computational engines 325 of the field facing component. The published data receiver 402 provides the received published data content to a published data ingestor 405 of the edge facing component 400 for interpretation, possible further processing, and storage to make the published data content (and possible additional content) available for consumption by data consuming applications and / or systems, represented in FIG. 5B by block 422.

[0070] In particular, the published data ingestor 405 utilizes a local copy of the publishable data type system 24B to interpret published data content received from the field facing components. In this manner, the published data ingestor 405 and the edge facing components 400 need not be aware of (and in fact are not aware of) the internal or native data definitions and / or configurations of the process plant 5. That is, the edge facing components 400 interpret the received published data content based on the received publishable data configurations stored in the publishable data type system 24A corresponding to the field facing components, and the edge facing components 400 do not need to send communications to the field facing components to obtain and / or adjust the data configurations. This technique protects the process plant 5 from possible security breaches since it is not necessary to send management and / or control messages from the edge facing components to the field facing components communicatively connected to the process plant 5, thereby eliminating a likely point of entry for malicious actors. Additionally, this technique allows configuration changes at the process plant 5 to be communicated in-line, in real-time, and incrementally to the edge facing components 400 as needed. Furthermore, this technique allows a single edge facing component 400 to provide services to many different field facing components that utilize different exposable data type systems.

[0071] In some embodiments, the published data ingestor 405 of the edge-facing component 400 may further derive and / or generate additional data from the received published data content. For example, the published data receiver 402 may invoke one or more computation engines 408 to manipulate at least a portion of the received published data content, thereby generating additional data content available to the data consuming application and / or system 422. The computation engines 408 may be stored in the edge-facing component 400 and may perform computational functions such as in-stream data aggregation and / or manipulation (e.g., average, maximum, minimum, etc.) on payload values ​​of the data. Some computation engines 408 may be configured to perform more complex calculations or algorithms, such as principal component analysis (PCA), partial least squares (PLS) prediction, and / or other types of statistical calculations or analyses, calculation of key performance indicators (KPIs), and some computation engines 408 may be configured to drive events. At least some of the computation engines 408 may be defined and / or configured by scripts and / or via a web-based user interface or other type of computation engine configuration application provided by the edge-facing components 400, and at least some of the computation engines 400 may be defined and / or configured by using containers accessible and / or installed in the edge-facing components 400. Indeed, some of the computation engines 408 may be made available for use by data consuming applications and / or systems 422, such as in a manner as described elsewhere in this disclosure.

[0072] The published data ingestor 405 stores the received published data content and output generated by the computation engine 408 in a data lake 410, which may be, for example, the data lake 40 of FIG. 1. Because the data lake 40 stores field content data received from field-facing components, the data lake 40 mirrors at least a portion of the overall data related to the process plant 5 (e.g., runtime data, configuration data, event data, historical data, and other types of data generated by and associated with the process plant 5), and the process plant related data stored in the data lake 40 is exposable to (e.g., made available for use by) external data consuming systems 8. In some process plants, all data generated by the process plant 5 is mirrored in the edge-facing components 400 and exposed to external systems 8, while in other process plants, only a subset of all data generated by the process plant 5 is mirrored in the edge-facing components 400 and exposed to data consuming applications and / or systems 8, the subset being defined by a collection of a set of interest lists 22, 315 present across the set of field-facing components of the process plant 5.

[0073] As previously discussed, in some implementations, in addition to the mirrored process plant-related data, the data lake 40 stores associated computational data generated by the computational engine 408 of the edge-facing components 400 based on public content data received from the process plant 5. Additionally, in some embodiments, the data lake 410 also stores content data received via one or more external data ingestors 412 from other external data providing systems (e.g., systems that are external to the process plant 5 and generate data that can be interpreted and / or analyzed in conjunction with the process plant-related data not shown in FIG. 5A ), typically at a numerically higher security level than the process plant 5. Such external data providing systems may include, for example, enterprise level systems such as email systems, intranet systems, site business planning and logistics systems, scheduling systems, supply chain management systems, financial systems, accounting systems, inventory management systems, other enterprise systems, other IT systems, etc., and / or systems provided by third parties, such as weather forecast systems, stock market feeds, third party provided OPC servers, etc. The external data ingestor 412 may convert, modify, translate, and / or otherwise transform the external data received from the external data providing system to conform to the publishable data types system 24B. Additionally, in some embodiments, the external data ingestor 412 may invoke one or more calculation engines 408 to manipulate the retrieved external data, thereby generating additional data that is stored in the data lake 410. In some embodiments, the external data ingestor 412 may communicate with enterprise and / or third party systems to thereby retrieve and / or reconcile their respective data configurations, and in some embodiments, the external data ingestor 412 may update the publishable data types system 24B to include their corresponding data types utilized by the enterprise and / or third party systems.However, even though the edge-facing components 400 may participate in bidirectional communications with external data-providing systems, the edge-facing components 400 still do not transmit communications to field-facing components that are communicatively connected to the process plant 5 (and in fact may be physically prevented from transmitting), thereby protecting the process plant 5 from security breaches that may occur via external systems.

[0074] In any event, the data lake 410 stores content data generated and received by the process plant 5 via the field-facing components, and in some implementations stores content data generated and received by one or more external data providing systems. In some embodiments, the data lake 410 may store additional data (whether process plant related and / or externally generated) that is calculated and / or derived from the received content data by one or more calculation engines 408. Data stored in the data lake 410 may be stored according to publishable data type system 24B, making the data content more readily available for consumption by applications and / or systems 422.

[0075] The edge-facing components 400 include a context knowledge miner 415 that operates on the content of the data lake 410 to discover relationships and associations between various different data points of the data lake 410. That is, the context knowledge miner 415 discovers the context of each of the data points of the data lake 410. For example, the context knowledge miner 415 may discover that a certain type of alarm was generated for a similar set of operating conditions across various different vendors' field devices in the same area of ​​the process plant at a certain time, or the context knowledge miner 415 may discover that the key performance indicators of a particular line in the plant correspond to the rate of change of a particular valve relative to the rate of change of another particular valve. In either case, the context knowledge miner 415 stores the discovered contexts and relationships along with the content of the data lake 415 (collectively referred to herein as "knowledge") in the contextualized process plant knowledge repository 420, e.g., connected domains. For example, the contextualized process plant knowledge repository 420 may be implemented using a graph database or other suitable model in which the content data and their respective interconnections are stored. For example, the graph database nodes may correspond to names or labels contained in the data lake 410, the properties stored in the nodes may include respective parameters, values, states, etc., and the connectors between the nodes and other nodes may indicate interrelationships discovered by the context knowledge miner 415. Generally speaking, the information stored in the contextual process plant knowledge repository 420 is exposable (e.g., available for consumption) to data consumer applications and / or systems 422.

[0076] 5A, it should be noted that while exposed data receiver 402, exposed data ingestor 405, and context knowledge miner 415 are depicted as separate and distinct components of edge-facing component 400, this is for purposes of clarity of discussion only and not by way of limitation. Indeed, any two or more of components 402, 405, and 415 may be implemented as integrated components of edge-facing component 400, if desired.

[0077] 5B , the edge facing components 400 provide a set of one or more access mechanisms 425 through which various types of data consuming applications and / or systems 422 access, directly or via other applications and access mechanisms, the information stored in the context knowledge repository 420. The data consuming applications and / or systems 422 that may utilize the access mechanisms 425 provided by the edge facing components 400 may include external applications and / or systems 8, such as, for example, enterprise applications and / or systems 422a (email, internet, site business planning and logistics, scheduling, supply chain management, finance, accounting, inventory control, corporate and / or other IT applications and / or systems) that own, operate, and / or are otherwise associated with the process plant 5 and that are at a higher numerical security level than the process plant 5, and third party applications and / or systems 422b (e.g., cloud computing applications / systems, external OPC servers, IoT applications / systems, IIoT applications / systems, etc.) that consume process plant related knowledge. In some configurations, the data consuming applications and / or systems 422 may include plant-related applications and / or systems 422c, which may be at a similar numerical security level as the process plant 5, or may be systems within the process plant 5, such as process control systems, analytical systems, etc.For example, at least some of the one or more access mechanisms 425 may be utilized by one or more applications specific to the process plant 5, such as a monitoring application, an analytics application, an optimization application, a virtualized device application, a process control application, an alarm management application, a device management application, a dispatching application, a low-cost sensor application, a simulation application, an operator training application, a redundancy or backup application, a recovery application, a safety instrumented system application, a vibration monitoring application, an engineering application, an asset management application, a user interface application, or an application running on a personal electronic device. As shown in FIG. 5B , the data consuming applications and / or systems 422 may be communicatively connected to the edge-facing component 400 via one or more networks 423, which may be public, private, wired, and / or wireless networks. Additionally or alternatively, at least some of the data consuming applications 422 may be installed on the edge-facing component 400, whether installed by a plant, an enterprise, or a third party, as described in more detail below.

[0078] As shown in FIG. 5B, the access mechanisms 425 provided by the edge-facing components 400 include one or more APIs 428 that serve as direct access mechanisms to the information stored in the contextual knowledge repository 420. The one or more direct access APIs 428 may be implemented according to, for example, a REST (REpresentational State Transfer) architecture, GraphQL or other suitable query language, and / or other standardized open-source interoperable data syntax, format, and / or architecture utilized for APIs. For example, the APIs 428 may interface with C, C++, and / or C# applications, Python applications, Node.JS applications, and / or other types of applications whose languages, protocols, platforms, frameworks are supported by or provided by the edge-facing components 400, and thus the APIs 428 may be accessed using respective bindings. Other higher level or more removed access mechanisms may utilize the one or more direct access APIs 428 to access the knowledge and information stored in the contextual knowledge repository 420.

[0079] Other access mechanisms 425 provided by the edge facing components 400 include, for example, utilities 430, servers 432, services 435, and applications 438, to name a few. In general, the access mechanisms 425 collectively support various types of access to the process plant related knowledge stored in the context knowledge repository 420, such as request / response, publish / subscribe, event-driven access, etc. Each of the access mechanisms 425 may utilize one or more direct access APIs 422 to access the information stored in the context knowledge repository 420. Some of the access mechanisms 425 may be exposed to external applications and / or servers 422, some of the access mechanisms may be exposed only to the process plant 5 and other associated systems of a lower numbered security level (e.g., OT level), and / or some of the access mechanisms may be exposed to the edge facing components 400 itself. For example, at least one access mechanism 425 may include one or more replication mechanisms through which the data lake 410 and / or the context knowledge repository 420 are replicated, e.g., for purposes of fault tolerance, backup, and / or redundancy.

[0080] Utilities 430 that may be provided by edge-facing components 400 include, for example, a query and / or search engine, a natural language processor, and / or other types of contextual utilities. Additionally or alternatively, utilities 430 may include computational utilities, such as calculations, analyses, analytics, scripts, etc. Utilities 430 may be implemented in edge-facing components 400 using, for example, functions, algorithms, applications, etc.

[0081] The servers 432 that may be provided by the edge facing components 400 include, for example, OPC UA servers that expose process plant related knowledge through an OPC UA data model to data consuming applications / systems 422, for example via respective subscriptions, web servers that host one or more websites and / or web applications through which the data consuming applications and / or systems 422 interface with the edge facing components 400 to access the process plant related knowledge stored in the context knowledge repository 420, and other types of servers. In some embodiments, one or more of the servers 432 are not exposed to external applications and systems 422, but instead are provided for use by the process plant 5 and / or systems associated with the process plant 5 with a lower numbered security level. For example, the edge facing components 400 may provide I / O servers that route data between various components of the process plant 5.

[0082] Services 435 that may be provided by edge-facing components 400 include, for example, Advanced Message Queueing Protocol (AMQP) queuing services (e.g., publishing knowledge in JSON format), Message Queuing Telemetry Transport (MQTT) publication and subscription services, and / or other similar purpose services, systems, and / or protocols that support the transfer of process plant related information to cloud computing applications and / or systems, IoT and / or IIoT applications and / or systems, event hubs, and / or other data consuming applications and / or systems (e.g., via publication / subscription mechanisms and / or point-to-point mechanisms) 422. For example, services 435 may include an OPC runtime service that may provide a respective data source to each external OPC server (which may be a plant, enterprise, or third-party OPC server) that is a consumer of process plant related knowledge. Additionally, services 435 may include other types of services, such as authentication and / or authorization services to data consuming applications and / or systems 422 (e.g., by using OAuth2 or other suitable standards), services that interact with mobile devices, web services, knowledge or information subscription managers, and / or any other types of services that may be exposed by and / or utilized by at least some of the data consuming applications and / or systems 422.

[0083] Additionally, edge facing components 400 may provide one or more applications 438 that access information stored in context knowledge repository 420 and manipulate the accessed information. For example, some of utilities 430 may be implemented using applications 438, some web services may be implemented using applications 438, etc. At least some of applications 438 may be provided by companies, such as query engines and search engines. Some of applications 438 may be provided by third parties and may be published and / or utilized by at least some of data consuming applications and / or systems 422.

[0084] Indeed, edge facing components 400 may support or provide a number of architecture configurations, platforms, and frameworks that allow edge facing components 400 to support or provide enterprise and third party generated utilities 430, servers 432, services 435, and / or applications 438 associated with process plant 5. In some configurations, both enterprise and third party provided utilities 430, services 432, and / or applications 438 may be installed on edge facing components 400. For example, edge facing components may support Docker, Linux, or other types of containers through which OPC UA servers, AMQP gateways, and various enterprise provided access mechanisms 425 may be implemented in edge facing components 400 and third party provided applications may be implemented in edge facing components 400. Docker and / or other types of containers may utilize direct access APIs 428, for example, to access information stored in context knowledge repository 420.

[0085] Additionally or alternatively, edge facing components 400 may provide a Node.JS framework to support web applications and services provided by the enterprise and / or by third parties and installed on edge facing components 400. The Node.JS framework may utilize a direct access API 428 to access information stored in context knowledge repository 420, and / or the Node.JS framework may invoke various utilities 430 (e.g., query, search, language processing, etc.) to access, retrieve, and / or manipulate information stored in context knowledge repository 420.

[0086] Thus, in view of the above considerations, embodiments of the edge gateway system 1 securely connect the process plant 5 and associated networks to applications running on the plant premises as well as remotely running applications, such as those hosted on clouds and / or remote networks. Applications and / or systems consuming data generated by the process plant 5 and discovered relationships and / or knowledge contained therein can securely and efficiently access and obtain the exposed contextual process plant knowledge with minimal to no risk to the process plant 5 itself. Additionally, the edge gateway system 1 may operate continuously in environments with permanent intranet connectivity (e.g., security levels 3 and 4), as well as in environments with public internet connectivity. Various security mechanisms and capabilities of the edge gateway system 5 (e.g., physical separation of OT and IT networks, physical prevention of data flow to the process plant 5, secure start-up and updates, signed firmware and packet execution, encryption, system of customizable exposable data types, etc.) secure the process plant 5 and its data and provide protection against data theft and security breaches. Additionally, in embodiments, the edge gateway system 1 and / or components thereof utilize or incorporate one or more of the security techniques described in commonly owned U.S. patent application Ser. No. 15 / 332,622, commonly owned U.S. patent application Ser. No. 15 / 332,690, and commonly owned U.S. patent application Ser. No. 15 / 332,751, the entire disclosures of which are incorporated herein by reference, thereby further securing the process plant 5 and its data and providing further protection against data theft and security breaches.

[0087] Figure 6 illustrates another embodiment of a data collection, storage and processing system that may use many of the same elements or infrastructure described with respect to Figures 5A and 5B to provide a single or centralized platform for performing data analysis, data mining and data visualization on plant data. In particular, Figure 6 illustrates a real-time industrial data event and storage system 600 for condition monitoring and decision support that can collect data from many different data sources or platforms, store that data for processing in real time and / or at future times, and store the processed data in a format or manner that facilitates use and understanding of the data in a number of different data analysis, visualization and mining applications.

[0088] More specifically, the system 600 is connected to various data sources 602 and interacts with various applications (which may be web applications, for example), including a data source registration application 604, a real-time data visualization application 606 (which may include data mining applications, data analysis applications, etc.), and a process graph builder application 608 (which may include other applications that allow a user to provide process context information to the system 600 for use in processing plant data, as described in more detail herein). Generally speaking, the data processing system 600 may be outside of a plant firewall (or process control system firewall) and thus may be configured to receive data from various different data sources 602 in any desired manner, including the manner described with respect to the field-facing components of FIGS. 1-3. More specifically, the data used or collected by the system 600 may be generated in many different locations throughout the continuous and / or batch operations of one or more process plants. Each of the data sources 602 may be associated with a different system within one or more plants, such as a control system, a maintenance system, a support system, a business system, a logging system, etc. Thus, for example, the data sources 602 may include one or more DeltaV edge systems providing continuous process data provided by an edge gateway system as described herein with respect to Figures 1-3. However, the data sources 602 are not limited to continuous process control system data and / or may instead include batch process data from one or more batch systems (such as a DeltaV batch system), a Syncade workflow system (which is a business support system), an AMS system (which is an asset management or maintenance system), any OPC data source such as an OPC UA data source, and the like.Thus, data sources 602 may include productized data sources, including Bio-G Scheduling, DeltaV Batch, Edge Gateways, OPCUA and Syncade (which are equipment, inventory, recipe, workflow system environments and support platforms), or any other data source. Additionally, system 600 also allows end users to define new (previously unknown) data sources and data source types to be connected to system 600 in a manner described in more detail below.

[0089] Data sources 602 can send or stream data to system 600 using any desired or common format and data structure, and using any desired communication format or protocol. Thus, for example, data sources 602 can stream telemetry to the platform using a variety of protocols, including gRPC, HTTPS, WebSocket, MQTT, or Akka stream. Thus, advantageously, each of data sources 602 can send data in a format in which the data is stored or used in the corresponding system, and can send the data using any communication format available to data sources 602. In other words, each of data sources 602 can send or forward data to system 600 using its own interface semantics, and can send data in, by way of example only, Akka stream, REST API, MQTT, WebSocket, gRPC, or any other data format. As a result, data sources 602 do not need to pre-process data sent to system 600, which makes the data easily searchable and reduces processing and communication activity at data sources 602.

[0090] As shown in FIG. 6, the system 600 includes a gateway device 610 that receives data from various different data sources 602 via one or more communication networks, lines, portals, etc. The gateway device 610 may be any desired type of computer or server system that operates as an electronic communication gateway to receive data and information from the data sources 602 in various different data formats and, if necessary, different communication protocols. The gateway 610 may receive the data in any manner, such as in one or more data streams, in bulk packets, etc. Generally speaking, the gateway 610 receives the data, verifies and authenticates that the source of the data is authorized, and, if verified, places each data message received from the data source, in chronological order, as a separate event in the event stream 612. More specifically, the gateway 610 receives data messages in various different communication protocols, authenticates the data packets or messages as acceptable or permitted by the system 600, strips out the communication protocol information, retrieves the underlying data (which may be process data, control data, maintenance data, user data, or any other type of data), and then places the data in the event stream 612 as a separate event. Importantly, the gateway 610 maintains metadata associated with the underlying data, including timestamps, origin or source of the data, the data source 602 that sent the data, sender and recipient of the underlying data, timing information, etc., and places this metadata in the event stream 612 as part of each event. So, essentially, the gateway device 610 ingests data related to different events in the plant into the system 600, removes the communication format information, and then creates separate events in the event stream 612, with each event containing all of the data sent by the data source 602 for the captured event.An individual event may be, for example, a measurement of an individual process variable, a user logon, a user initiated action, a generated alarm or alert, a maintenance action taken by maintenance personnel, a fault detection or failure, a control action, etc. As noted above, each event not only includes the data underlying the event, but also includes metadata for that event including, for example, an indication of the device making the measurement or communication associated with the event, a timestamp associated with the capture of the data associated with the event, a device or user identification associated with the captured data, etc. Additionally, the gateway 610 places the event data in the event stream 612 in chronological order, thereby preserving the time data of different events within the event stream 612.

[0091] As will be appreciated, the event stream 612 is a memory device that stores a never-ending sequence of individual events ordered by time, and the event stream 612 may be similar to the data lake 410 of FIG. 5A and may be constructed in a similar manner using similar hardware. The event stream 612 may be configured using any type of computer memory, or any desired type of electronic database, including a distributed database, and the event stream 612 operates to store event data and make the event data available to a number of different services, which will be described in more detail below. Generally speaking, any of the event data in the event stream 612 may be accessed at any time, in any order, by one or more of the services. Additionally, the event stream 612 may allow one or more of the services to insert new events or event data into the event stream memory at any time, and may store the event data for any desired period of time. For example, the duration of the event stream may be 30 days, although other time frames or periods may be used instead.

[0092] The system 600 also includes components that facilitate managing data sources and event data received by the system 600 that is placed in the event stream 612. In particular, the system 600 includes a data source registration component 614 and a security enforcement component 616. In particular, the data source registration component 614 stores a list and information about data sources that are authorized to send data to the gateway 610 for processing and placement in the event stream 612. The data source registration component 614 can store or specify the names or identities of the authorized data sources, the type of data sent by the data source, the data format of the data sent by the data source, the communication format or protocol and network information for the communication connection with the data source, the security level of the data sent by the data source or other security information, and security registration procedures and information (such as security certificates, encryption methods used by the data source, etc.). In addition, the security component 616 registers the data sources 602 with the platform 600, authenticates the data sources 602, issues and verifies security certificates, TLS operations, etc. to ensure secure communication between each of the data sources 602 and the gateway 610. For example, each data source instance 602 may be registered with the security component 614 of the platform 600, where the data source is assigned a type (i.e., batch), an X.509 certificate for identity and authentication (for example), and a set of permissions for streaming data of a particular type. Of course, the security component 616 can implement any desired type of security authentication and encryption techniques.Additionally, a user may use one or more of the data source registration applications 604 to add or connect new data sources 602 to the system 600 and specify or modify information about the data sources 602 required by the gateway 610 to receive, decode, and process incoming data, such as data format, data protocol, communication protocol, security level, user authentication, etc. In this manner, the data source registration component 614, in conjunction with the data source registration applications 604, may enable a user to add new data sources, remove data sources that provide data to the system 600, modify the type, format, security level, etc. associated with each data source 602, and / or provide other data source information to the system 600, thereby enabling the system 600 to incorporate new and different data or data types from the same or different data sources 602.

[0093] Additionally, as shown in FIG. 6, the system 600 includes one or more microservices 620 that operate on the event stream 612 to process the event data in the event stream 612. Each microservice 620 transforms the data in the event stream 612 into a different type of data that can be more easily consumed or used by data mining, data visualization, and data analysis applications, and / or transforms the event data to create new events and places those new events in the event stream 612 for processing or use by other microservices 620. In particular, each microservice 620 performs one specific processing activity or action using the event data in the event stream 612 to generate new data that is stored in one or both of the time series database 622 or the distributed graph database 624, or to generate new data that is placed in the event stream 612. The microservices 620 are at the heart of the system 600, as these microservices 620 generally operate or execute independently of one another to process the data in the event stream 612 to generate new and more easily understood or usable data. Each microservice 620 can process the event data for each event stored in event stream 612 in chronological order (e.g., first-in to last-in, or in any other chronological order) to determine higher level information about the event, such as the presence of a particular occurrence in the plant (e.g., an alarm, an event, a change in state, a user interaction, etc.). Furthermore, the microservice 620 then stores that new higher level data as a timed event in time series database 624 and / or as a node in one or more process graphs in distributed graph database 624. Additionally, one or more of the microservices 620 can create new events and place or store those events in event stream 612 in the appropriate chronological location (either when a new event occurs or when a new event is recognized or detected by the microservice 620).These new events can then be made available for use by other microservices 620, which can perform, by way of example only, any of the processing described with respect to context knowledge miner 415 in FIG. 5A. In any case, each of the microservices 620 is a stream processing service that consumes the events in the event stream 612, transforms the events into higher level data that is stored in databases 622 and / or 624 or generates additional events, and places those events in the event stream 612.

[0094] The microservices 620 can be pre-configured and can run on any processing hardware using any software to perform the particular service that each microservice 620 was created to perform. Each of the microservices 620 can cycle through the event data in the event stream 612 at any desired rate (e.g., can operate in real-time or faster than real-time) to access, review and process the event data in the event stream 612, and different microservices 620 can operate at different rates or in different places within the event stream 612. Furthermore, any number of microservices 620 may be up and running at any particular time, accessing and processing different portions of the event stream 612. In this manner, any number of different microservices 620 can be created to perform the event data processing required by any number of different data consumers (e.g., data visualization, mining, and analytics applications 606) that connect to the system 600. However, the microservices 620 are generally a stable or relatively fixed set of services that operate continuously on the data in the event streams 612, and thus can effectively and efficiently manage the processing power and memory requirements of the system 600. Nevertheless, as new data analysis, data mining, and data visualization applications 606 are designed to connect to or be supported by the system 600, new microservices 620 can be created, stored in, and executed on the system 600. Generally speaking, the microservices can be similar or the same as the applications or services that run as part of the context knowledge miner 415 of FIG. 5A. Similarly, as described above, the microservices 620 can store the transformed event data in one or both of the time series database 622 and the distributed graph database 624.

[0095] As will be appreciated, both databases 622 and 624 store contextual knowledge about events (or other data) that allows different events to be related to one another in some way, such as in time, by plant area, unit, device, controller scheme, logic element or other plant equipment or logic designation, by process variable, by one or more parameters, values, states, etc., by user, by manufacturer, by property, by value, by alarm or alarm category, by process hierarchy, by control hierarchy, or by any other context category that may be identified within or associated with the plant data. Generally speaking, time series database 622 stores data primarily using time correlation (e.g., time associated with events), while graph series database 624 stores data as graph data using process or other graphs that define interrelationships between various elements within a process or process plant.

[0096] More specifically, the time series database 622 is a database that stores and includes time-based telemetry data determined and detected by the microservices 620, while the distributed graph database 624 is a database that stores graph data (graphs with interconnected nodes) that reflect relationships between data (in nodes) stored in the process graph component 626 and defined by one or more graph models provided by the process graph component 626. Generally speaking, a graph database is a database in which data is organized or connected by various predefined relationships, and thus each node in the graph database is contained in, contains, or is related to one or more other nodes in the database by various predefined relationships. These predefined relationships may be stored or defined in one or more process graphs provided by or in the process graph component 626. In other words, each graph created in the database 624 is a knowledge graph that is constructed by encoding complex entities and relationships into a set of nodes and edges. This knowledge graph provides flexibility so that system 600 can connect data as the domain dictates, provides performance because queries that traverse facts and highly connected data are orders of magnitude better when implemented in a graph, provides agility because it becomes easier to deliver high quality software updates, and provides scalability because a distributed graph solution can scale horizontally.

[0097] As described above, one or more process graph model builder applications 608 may be used or provided to enable a user to define a variety of different process graphs or process models that can be used to 1) define relationships between components and data in a process and 2) define process graph models that are used to build graphs in the graph database 624. More specifically, the process graph builder service 608 enables a user to create models that connect and contextualize data stored in the graph database 624. Thus, the process graph builder 608 is a service that enables an end user to create comprehensive models that connect and contextualize raw data streaming through the platform 600. By way of example, process models that can be used may include one or more process hardware hierarchies, process plant layouts, process control software hierarchies, etc. These concepts can be extended beyond adding context to process data by integrating with PLM solutions to facilitate, for example, easy recipe creation, enterprise recipe management, technology transfer, and migration to other MES solutions. In one example, the process graph builder service 608 can be used to create high level process flow charts that connect or provide relationships between events streaming through the system, such as, for example, material transactions, electronic signatures, equipment cleaning, batches, process data, alarms and events, scheduling changes, etc., to define various relationships between events occurring in the plant and control environment.

[0098] Additionally, system 600 includes one or more application interfaces (APIs) 630 that allow external users to access the data in time series database 622 and distributed graph database 624 for use in any desired data visualization, data mining, or data analysis application. Of course, APIs 630 may be designed or configured to provide any level of access, as well as access to any or all of the data in databases 622 and 624, and may enforce security and access rights to the data in databases 622 and 624. APIs 630 support any desired type and number of data visualization applications 606. In particular, data visualization applications 606 may use APIs 630 to query data from databases 622 and 624 and use that data for any number of purposes. For example, data visualization applications 606 may present real-time data in the form of dashboards, which may be customizable by users. As a further example, a report builder such as Power BI may be provided to connect to system 600 using REST APIs and then access the data used to generate reports. Users can customize dashboards using components provided through system 600 or using tools such as Power BI and Tableau. Of course, data visualization application 606 can perform any desired type of data processing, mining, analysis or data visualization services, such as any of those discussed above with respect to the data consuming applications and / or systems of FIG.

[0099] Additionally, system 600 includes a task engine 640 that can be used to manage events that require some user interaction. That is, some events stored or placed in event stream 612 may request or require user interaction for some reason, for example, to complete or change data in the event due to incomplete or erroneous data or for some other reason. Generally, task engine 640 provides a user, such as a data manager, with direct access to the data in event stream 612 and to change / add / delete data.

[0100] Additionally, in one implementation, device 600 can be used to enable external data processing applications (such as advanced data analytics applications) to perform distributed data processing and data mining on data from the plant. More specifically, one or more distributed data analytics applications 650 can use the event stream 612 to perform various types of data processing, such as analytical data processing, on various different data in the event stream 612 and place the processed data (or events and actions associated with the processed data) back into the event stream 612 for use by other data analytics applications 650. By way of example, various different data pipeline applications such as those described in U.S. Patent No. 9,823,626, entitled "Regional Big Data in Process Control Systems," and U.S. Patent No. 10,168,691, entitled "Data Pipeline for Process Control System Analytics," both of which are expressly incorporated herein by reference, may place data into the event stream 612 in some pre-determined order and access the data from the event stream 612 to perform distributed data analytics in the manner described in U.S. Patent Nos. 9,823,626 and 10,168,691. In this case, however, the event stream 612 in the system 600 is or provides the inter-application data communication functionality described in U.S. Patent Nos. 9,823,626 and 10,168,691 to coordinate data arriving at various different processing states or stages implemented by appropriate data analytics applications. As shown in FIG. 6, one or more data analysis applications 650 can provide processed data to an event stream 612 and use the data from the event stream 612 to perform distributed data analysis in any of the manners described in U.S. Pat. Nos. 9,823,626 and 10,168,691.

[0101] In particular, one or more external data analysis applications 650A may operate on data obtained directly from one or more external data sources of any kind and provide processed data to the event stream 612, for example in the form of intermediate data (analytically processed data in some intermediate form) on which calculations and actions need to be performed by the next function (analytic application) in the data processing pipeline. The actions may include methods or functions to be performed on the data by the next or downstream analytical application, metadata of the data, descriptions of the intermediate or processed data or calculations, etc. Additionally, the intermediate data may include models or other descriptions of the data being placed in the event stream 612 to enable understanding or interpretation of the data by other users of the event stream 612. Data source 650A (which is a specific example of data source 602 above) is a registered data source 602 that provides processed data, functions, and actions (as well as accompanying metadata) to the gateway 610, which then places this data or information into the event stream 612 as separate events. Of course, microservice 520 can operate on this data (event data) in any desired manner. However, in addition, one or more other external data analysis applications 650B-650N can connect to system 600, and more specifically to event stream 612, to retrieve event data from event stream 612, perform additional processing on this event data, and place new or more fully processed data, again in the form of intermediate data, in the form in which calculations and actions need to be performed on that data, as new events in event stream 612. In this manner, event stream 612 serves as a communication path between various different data analysis applications 650, enabling applications 650 to perform distributed data analysis in a pre-determined order and / or manner.

[0102] Importantly, data analysis applications 650 may be granted access to event stream 612 via one or more separate external communication ports or paths or connections, so that these applications 650 can place new events into event stream 612 at any appropriate location (to chronologically order the event data of the next data analysis application 650 that may use the new event data). If desired, each of data analysis applications 650A-650N may be verified and registered in the manner described above with data source registration and security components 614 and 616 using one or more data source registration applications 604. Furthermore, data analysis applications 650A-650N may be stored and executed in any external device or system, including any in-plant or off-plant computer system. Similarly, task engine 640 may be used to orchestrate the ordering of events placed into event stream 612 by data analysis applications 650 to create an efficient event communication pipeline in which data (intermediate data, calculations and actions) from one analysis application 650 is provided to another analysis application 650 in the appropriate order. Similarly, the output of each of the data analysis applications 650 may be placed into the event stream 612 as a separate event, such that these events (and their underlying data) are available for analysis or use by the microservices 620, and ultimately available for use as event data created and stored in databases 622 and 624, which support other data mining, analysis, and data visualization applications 606 via API 630.

[0103] In any event, as will be appreciated, system 600, and specifically its event stream 612, can be used to perform data processing to facilitate the use of data visualization, data mining, and data analytics, as well as to provide a data storage and communication structure for use in a distributed data pipeline-based data analytics platform.

[0104] As will be appreciated, the system 600 described with respect to Figure 6, in particular, is a unique and useful platform for performing comprehensive data visualization, data mining, and data analysis. In particular, the platform or system 600 provides a cloud-enabled architecture, where the term "cloud" refers to an environment that provides on-demand network access to a shared pool of configurable computing resources (i.e., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal administrative effort. Furthermore, the system may be deployable on-premise, on a supported cloud provider, or as a hybrid solution.

[0105] Additionally, system 600 implements a responsive, adaptable, and elastic solution for data collection, mining, visualization, and analysis. System 600 is generally responsive, a cornerstone of usability, since system 600 provides fast and consistent response times that give a consistent quality of service. Additionally, system 600 is an adaptable solution that maintains responsiveness under fluctuating workloads by scaling resources up and down in response to changing inputs, and system 600 is an elastic solution because system 600 maintains responsiveness in the event of failures.

[0106] Furthermore, the system 600 provides easy real-time integration with adjacent applications. In particular, the system 600 implements native low-latency mechanisms to integrate MES functions with other existing plant applications and systems, such as control systems (continuous and batch control), ERP systems, LIMS systems, and other adjacent applications, while being easy to configure, modify, and maintain over time, and while allowing new data sources to be introduced in context without requiring new versions of the solution.

[0107] Similarly, system 600 is a general-purpose workflow engine that includes a workflow execution engine that can model manufacturing processes, assets, and / or individual tasks for various users, so that the end user experience is flexible yet feels native while providing native integration with MES capabilities. Additionally, system 600 provides fresher or more recent insight into the process environment by capturing a continuous stream of events that represent the "pulse" of the process, by providing a single version of truth (i.e., by maintaining a rolling window of events that represents the single source of truth) that is used by all of the data visualization, mining, and analytics applications, provides faster response by incorporating a simpler architecture that allows for automatic near real-time processing of the continuous stream, thereby allowing response times in milliseconds, and by eliminating the bespoke point-to-point connections between the various transactional systems that exist today, thus solving the complex architectures used today.

[0108] Additionally, system 600 provides a state-of-the-art development (DevOps) pipeline for CI / CD. In particular, system 600 provides an architecture, process, and culture around DevOps principles to implement or support small batches, automated testing (unit, integration, load, and security), continuous integration of data, and continuous deployment to a production-like environment, and the system provides infrastructure as code. Additionally, system 600 includes features that simplify installation, securing, configuring, maintaining, scaling, troubleshooting, and upgrading the entire solution, so that security best practices can be adopted or easily implemented for selected cloud-enabled architectures and web-based applications, making them secure and easy to manage at runtime.

[0109] While any programming paradigm can be used to implement system 600, it will be appreciated that it is preferable to configure all software components that make up platform 600 to run or execute within or as containers. These containers can then be managed by an orchestration engine that allows system 600 to be run in a stable, efficient manner, and to be highly (e.g., horizontally) scalable.

[0110] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, such as in the RAM or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed to include, among other components, software and / or firmware running on hardware, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embedded solely in hardware, solely in software, or in any combination of hardware and software. Thus, while the exemplary systems described herein are described as being implemented in software running on a processor of one or more computing devices, one skilled in the art will readily recognize that the examples provided are not the only way to implement such systems.

[0111] Thus, while the invention has been described with reference to specific examples, these are illustrative only and are not intended to be limitations of the invention, and it will be apparent to those skilled in the art that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

Claims

1. 1. A data acquisition and analysis system for use in a process environment having a plurality of different data sources coupled to different process equipment, comprising: a data source registration device that stores data source information for each of the plurality of different data sources, the data source information defining information regarding data communicated from each of the plurality of different data sources; a gateway device coupled to a data registration device and adapted to be connected to each of the plurality of different data sources via one or more communication networks to receive different streams of process data from each of the plurality of different data sources, wherein the gateway device uses the data source information to process the streams of process data from the plurality of different data sources, and the gateway device processes the data streams from each of the plurality of different data sources by removing communication information from the data streams and creating a plurality of events, each of the plurality of events including underlying process data and metadata in the data stream; an event stream storage device coupled to the gateway device that receives each of the events from the gateway device and stores the events as an event stream; various services coupled to the event stream storage device, each of the various services operating on one or more types of events in the event stream to process the underlying process data and metadata in the events to create processed event data associated with the events, and each of the various services placing the processed event data in a further database; an interface coupled to the further database that allows a user to retrieve or view the processed event data.

2. The data collection and analysis system of claim 1 , wherein the event stream storage device stores the events as a time-ordered event stream.

3. 3. The data collection and analysis system of claim 1 or claim 2, wherein the gateway device creates an event from each of the plurality of different data sources to include the underlying process data of the data streams from the different data sources in the same data format as provided in the data streams from the different data sources.

4. 4. The data collection and analysis system of claim 1, wherein the gateway device creates one or more of the events to include underlying process data provided in the data stream from a data source and metadata associated with the underlying process data.

5. 5. The data collection and analysis system of claim 4, wherein the metadata includes one or more of a timestamp, an indication of an origin or source of the underlying process data, an indication of the data source that sent the underlying process data, an indication of other senders or recipients of the underlying process data, and an indication of a device that performed a measurement or communication associated with the underlying process data.

6. 6. The data collection and analysis system of claim 1, wherein the gateway device validates and authenticates the data source of the underlying process data as authorized before creating an event in the event stream.

7. The data collection and analysis system of claim 1 , wherein the gateway device receives data messages in the data stream from the plurality of different data sources via a plurality of different communication protocols.

8. 8. The data collection and analysis system of claim 1, wherein the underlying process data for each event is one or more of continuous process data, batch process data, control data, maintenance data, and process user data.

9. 9. The data collection and analysis system of claim 1, wherein the underlying process data for each event is associated with one of an individual process variable measurement, a user logon, a user initiated action, an alarm or alert generated, a maintenance action taken via a maintenance system, a fault detection, a failure or control action.

10. The data collection and analysis system of claim 1 , wherein the data source registration device includes a communications security enforcement component.

11. 11. The data collection and analysis system of claim 1, wherein the data source registration device stores a list of the plurality of different data sources authorized to send data streams to the gateway device and information about each of the plurality of different data sources.

12. 12. The data collection and analysis system of claim 11, wherein the data source registration device stores an identity of each authorized data source, a type of data transmitted by each authorized data source, a data format of the data transmitted by each authorized data source, and a communication format or communication protocol and network information for a communication connection with each authorized data source.

13. The data collection and analysis system of claim 11 or 12, wherein the data source registration device stores security information of the data transmitted by each authorized data source.

14. 14. The data collection and analysis system of claim 13, wherein the security information includes one or more of a security registration procedure, a security certificate, and an encryption method used with each authorized data source.

15. 15. The data collection and analysis system of claim 13 or claim 14, wherein the data source registration device includes a security component that registers each of the plurality of different data sources with the gateway device and authenticates each of the plurality of different data sources by issuing or verifying a security certificate or by establishing TLS operations with each of the plurality of different data sources.

16. 16. The data collection and analysis system of claim 15, wherein the security component assigns to each of the plurality of different data sources a type, identity and credentials for authentication, and a set of permissions for streaming particular types of data.

17. 17. The data collection and analysis system of claim 1, further comprising a data source registration application executing on a processor to enable a user to create and store data source information in the data source registration device.

18. 20. The data collection and analysis system of claim 17, wherein the data source registration application allows a user to add new data sources, delete data sources, or change the data type, data format, or security level associated with existing data sources.

19. 19. The data collection and analysis system of claim 1, wherein two or more of the plurality of different data sources communicate data to the gateway device using different types of communication streams.

20. 20. The data collection and analysis system of claim 1, wherein the data source information includes security information identifying one or more security measures used by the gateway device when communicating with each of the plurality of different data sources.

21. 21. The data collection and analysis system of claim 20, wherein two or more of the plurality of different data sources each communicate with the gateway device using different security measures.

22. 22. A data collection and analysis system according to any preceding claim, wherein the further database is a time series database which stores processed event data in a time series manner.

23. 23. The data collection and analysis system of claim 1, wherein the further database is a distributed graph database that stores processed event data in one or more distributed graphs.

24. 24. The data collection and analysis system of claim 23, further comprising a process graph database coupled to the distributed graph database, the process graph database storing connectivity information defining a configuration of one or more of the distributed graphs stored in the distributed graph database.

25. 25. The data collection and analysis system of claim 24, wherein the connection information is based on process plant information defined according to a configuration of a process for which the plurality of different data sources collect data.

26. 26. The data collection and analysis system of claim 25, further comprising a user interface application executing on a processor and coupled to the process graph database to enable a user to provide the process plant information used to create the connectivity information of one or more distributed graphs stored in the distributed graph database.

27. 27. The data collection and analysis system of claim 1, wherein the interface comprises one or more application programming interfaces (APIs).

28. 30. The data collection and analysis system of claim 27, wherein the interface includes a plurality of APIs, each of the plurality of APIs coupled to a different external application for obtaining processed event data from the further database and providing the processed event data to the different external application.

29. 29. The data collection and analysis system of claim 1, wherein the further database includes both a time series database and a distributed graph database, and at least one of the services places processed event data in the time series database and another of the services places processed event data in the distributed graph database.

30. 30. The data collection and analysis system of claim 29, wherein at least one of the services places processed event data into the time series database and the distributed graph database.

31. 31. The data collection and analysis system of claim 29 or claim 30, further comprising a process graph builder application executing on a processor to enable a user to specify process information to define one or more process graphs used to create the distributed graph in the distributed graph database.

32. 32. The data collection and analysis system of claim 31, wherein each of the process graphs defines relationships between components and data within the process environment.

33. 33. The data collection and analysis system of claim 32, wherein one of the process graphs defines one or more process hardware hierarchies, one or more process plant layouts, or one or more process control software hierarchies.

34. 34. The data collection and analysis system of claim 1, further comprising a task engine executing on a processor to enable a user to access event data in the event stream.

35. 35. The data collection and analysis system of claim 34, wherein the task engine enables a user to modify event data in the event stream.

36. 36. The data collection and analysis system of claim 34 or claim 35, wherein the task engine enables a user to add process data or metadata to events in the event stream.

37. 37. The data collection and analysis system of claim 1, further comprising one or more data analysis applications coupled to the event stream storage device that process event data in the event stream.

38. 40. The data collection and analysis system of claim 37, wherein one of the one or more data analysis applications creates and places new events in the event stream.

39. 39. The data collection and analysis system of claim 1, wherein one of the services creates a new event with processed event data and places the new event with processed event data into the event stream.

40. 40. The data collection and analysis system of claim 39, wherein another of the services accesses the new event, processes the event data in the new event to create further processed event data, and places the further processed event data in the further database.

41. 41. The data collection and analysis system of claim 1, wherein the underlying process data from a first of the plurality of different data sources is in a first data format and the underlying process data from a second of the plurality of different data sources is in a second data format, and the first data format and the second data format are different data formats.

42. 42. The data collection and analysis system of claim 41 , wherein a gateway creates events from the first of the plurality of disparate data sources using data in the first data format and creates events from the second of the plurality of disparate data sources using data in the second data format.

43. 43. The data collection and analysis system of claim 1 , wherein the services are microservices.

44. 44. The data collection and analysis system of claim 1, wherein each of the services is independently performed on the event data in the event stream.

45. 45. The data collection and analysis system of claim 1, wherein one of the services operates in real time on the event data in the event stream.

46. 46. ​​The data collection and analysis system of claim 1, wherein one of the services is performed faster than real time on the event data in the event stream.

47. 47. The data collection and analysis system of claim 1, wherein multiple ones of the plurality of different data sources are associated with different systems within the process environment.

48. 48. The data collection and analysis system of claim 1, wherein one of the plurality of different data sources is associated with a process control system and another of the plurality of different data sources is associated with one of a process maintenance system, a process support system, a process business system, and a process data logging system.

49. 49. The data collection and analysis system of claim 1, wherein one of the plurality of different data sources is an OPC data source.

50. 50. The data collection and analysis system of claim 1, wherein two or more of the plurality of different data sources stream data to the gateway device using different streaming formats or communication protocols.

51. 51. The data collection and analysis system of claim 1, wherein each service transforms the event data in the event stream into a different type of data that can be more easily consumed by further applications.

52. 52. The data collection and analysis system of claim 1 , wherein at least one of the services processes the event data in the event stream to create one or more new events and place the one or more new events in the event stream.

53. 53. The data collection and analysis system of any of claims 1 to 52, wherein each service is an independently running microservice to process one or more types of events in an event steam to generate new, more usable event data.

54. 54. The data collection and analysis system of claim 1, wherein each service is a microservice that transforms the event data in the event stream in a time series manner to determine higher level information about the events in the event stream.

55. 55. The data collection and analysis system of claim 54, wherein each microservice stores the new higher level data as timed events in the time series database and / or as nodes in one or more process graphs in a distributed graph database, and / or creates new events and places those new events in the event stream at a particular chronological location in the event stream.

56. 56. The data collection and analysis system of claim 54 or claim 55, wherein different ones of the microservices operate at different speeds.

57. 57. The data collection and analysis system of claim 54, wherein different ones of the microservices operate to obtain event data from different locations within the event stream.

58. 58. A data collection and analysis system as claimed in any of claims 54 to 57, wherein the further database stores contextual knowledge about the processed events that enables different processed events to be related to each other in some way.

59. 59. The data collection and analysis system of claim 58, wherein the contextual knowledge enables different processed events to be associated with each other in one or more of time, plant area, unit, device, controller scheme, logic element, plant equipment, logic designation, process variable, parameter, value, process state, user, manufacturer, property, alarm, alarm category, process hierarchy, or control hierarchy.

60. 60. A data collection and analysis system as claimed in any of claims 54 to 59, wherein the further database is a graph sequence database which stores data as graph data using a process graph which defines the interrelationships between various elements within a process.

Images