AI extensions and intelligent model validation for industrial digital twins

Abstract

The present disclosure relates to AI augmentation and smart model validation for industrial digital twins. Industrial smart data tags conforming to structured data types are used as a basis for creating digital twins of industrial assets. The digital twins can include automation models and mechanical models or other types of non-automation models, both of which reference the smart tags in relation to digitally modeling the industrial assets. The structured data topology provided by the smart tags allows the digital twins to easily interface with artificial intelligence (AI) systems. AI analysis can utilize the smart tags to discover new relationships between key performance indicators and other variables of the assets, and encode these relationships in the smart tags themselves. These augmented smart tags can also be used to perform AI-based digital twin validation. The additional contextualization provided by the augmented smart tags can simplify the AI analysis and help to quickly converge on desired analysis results.

Description

[0001] This application is a divisional application of the invention patent application filed on February 14, 2020, with application number "202010092995.4" and invention title "AI Extension and Intelligent Model Verification for Industrial Digital Twins". Technical Field

[0002] The topics discussed in this article generally relate to industrial automation systems, as well as model-based analysis and visualization of industrial data, for example. Background Technology

[0003] Collecting and delivering information to users in a meaningful presentation format can provide valuable insights into the past, present, and future operation of industrial assets. However, the highly distributed nature of data available across numerous industrial units associated with the various industrial machines or systems that constitute an industrial enterprise presents challenges regarding the collection and formatting of data for common presentation on client devices that can be delivered to users. Furthermore, much of the information available on a given set of industrial units includes uncontextualized, unstructured data (e.g., integers, real numbers, or discrete values ​​stored in data tables on industrial controllers), the meaning of which must be defined by the application used to present the data. This burdens developers of such applications, who must specify the meaning of each item of unstructured data received and presented by these applications so that the data will be meaningful to the viewer (e.g., product counts, productivity, system temperature or pressure, historical trends, etc.). Summary of the Invention

[0004] The following is a simplified overview to provide a basic understanding of some of the aspects described in this article. This overview is not an extensive review, nor is it intended to identify key / important elements or to depict the scope of the various aspects described herein. The sole purpose of this overview is to present some concepts in a concise form as an introduction to the more detailed descriptions that follow.

[0005] In one or more embodiments, a system is provided, comprising: a model configuration component configured to define a digital twin of an industrial asset based on model configuration input data, the digital twin defining the industrial asset according to hierarchical elements, wherein the digital twin includes data tags corresponding to data items generated from the industrial asset, and the data tags respectively conform to one of a set of basic information data types, the set of basic information data types including at least a state data type, a rate data type, an odometer data type, and an event data type; and an artificial intelligence (AI) engine component configured to apply AI analytics to the digital twin to identify key variables indicative of the overall performance of the industrial asset, related variables affecting the values ​​of the key variables, and functional relationships between the key variables and related variables, and to attach AI fields to the data tags corresponding to the key variables, the AI ​​fields identifying the related variables and the functional relationships between the key variables and related variables.

[0006] Furthermore, one or more embodiments provide a method comprising: defining a digital twin of an industrial asset in hierarchical elements on a system including a processor based on configuration input data, wherein the digital twin includes data tags corresponding to data items held on devices of the industrial asset, the data tags respectively conforming to basic information data types in a set of basic information data types, and the set of basic information data types including at least state data types, rate data types, odometer data types, and event data types; performing AI analysis on the digital twin by the system; identifying key variables indicative of the quality of operation of the industrial asset, related variables determining the values ​​of the key variables, and functional relationships between the key variables and related variables based on the results of the AI ​​analysis by the system; and adding AI fields to the data tags corresponding to the key variables by the system, wherein the AI ​​fields identify the related variables and the functional relationships between the key variables and related variables.

[0007] Furthermore, according to one or more embodiments, a non-transitory computer-readable medium storing instructions is provided, the instructions being executed to cause a system to perform an operation comprising: defining a digital twin of an industrial asset based on configuration input data, wherein the digital twin includes data tags corresponding to data items held in the equipment of the industrial asset, the data tags respectively conforming to basic information data types in a set of basic information data types, and the set of basic information data types including at least a state data type, a rate data type, an odometer data type, and an event data type; performing AI analysis on the digital twin; identifying key variables indicative of the performance quality of the industrial asset, determining the values ​​of the key variables, and the functional relationship between the key variables and the related variables based on the results of the AI ​​analysis; and appending AI fields to the data tags corresponding to the key variables, wherein the AI ​​fields identify the related variables and the functional relationship between the key variables and the related variables.

[0008] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various modes that can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent when considered in conjunction with the accompanying drawings, based on the following detailed description. Attached Figure Description

[0009] Figure 1 This is a block diagram of an example industrial control environment.

[0010] Figure 2 This is a conceptual diagram illustrating the flow of industrial data across various information levels in a typical industrial environment.

[0011] Figure 3 This is a block diagram of an example industrial device that supports the Basic Information Data Type (BIDT).

[0012] Figure 4 It is a block diagram of a gateway device that can discover BIDTs on one or more industrial units and present the associated data in a formatted manner according to a user-defined asset model.

[0013] Figure 5 It is a block diagram of an application server system that can aggregate asset models from gateway devices into one or more factory models and present formatted presentation data received from gateway devices based on the aggregated factory models.

[0014] Figure 6 These are illustrations of four example BIDTs that can be supported by one or more implementations of an industrial device.

[0015] Figure 7This is a diagram illustrating the development of BIDT in the label database of industrial equipment.

[0016] Figure 8 This is a diagram showing how BIDT is stored in the tag database.

[0017] Figure 9 This is a diagram showing the runtime operation of an example industrial unit supporting BIDT.

[0018] Figure 10 This is a diagram illustrating the configuration of a gateway device with one or more asset model definitions.

[0019] Figure 11 It is a graphical representation of an example asset model formatted as a production model.

[0020] Figure 12 It is a graphical representation of an example asset model formatted as a design model.

[0021] Figure 13 This is a diagram illustrating the contextualized presentation of the BIDT data flow from industrial installations to application server systems.

[0022] Figure 14 This is a diagram illustrating how the application server system collects and integrates the logical asset model into the common factory model.

[0023] Figure 15 It is an example factory model generated by the application server system through the integration of multiple asset models received from corresponding multiple gateway devices.

[0024] Figure 16 It is a screenshot that can be rendered by the application server system's rendering component based on the aggregated factory model of sample data.

[0025] Figure 17 It is a diagram depicting a gateway device on which a first asset model for transmitting data to a cloud-based application server system and a second asset model for presenting BIDT data to local on-premise client devices are defined.

[0026] Figure 18 This is a diagram illustrating an example network architecture that includes industrial devices, gateway devices, and cloud-based application server systems.

[0027] Figure 19 This is a block diagram of an example architecture that uses a gateway device registry to manage proxy communication to a customer's cloud platform.

[0028] Figure 20This is a flowchart of an example method for configuring and utilizing BIDT data tags in an industrial controller to transmit industrial data to a visualization system.

[0029] Figure 21 This is a flowchart of an example method for discovering and retrieving data from BIDT data tags based on an asset model.

[0030] Figure 22 This is a flowchart of an example method for aggregating asset models and using the aggregated models to generate graphical representations of industrial data.

[0031] Figure 23 It is a diagram showing the integration of an asset model of an industrial asset with a mechanical model of the industrial asset to produce a digital twin representing the asset.

[0032] Figure 24 This diagram illustrates the integration of an asset (automation) model and a machinery model based on industrial assets to generate asset data.

[0033] Figure 25 This diagram illustrates the parallel development of asset models and mechanical models for industrial assets.

[0034] Figure 26 This is a diagram of an example architecture that uses interconnected asset and machinery models to generate playback simulations of past industrial asset operations.

[0035] Figure 27 This diagram illustrates the integration of an asset (automation) model and a machinery model based on industrial assets to generate supplementary computational asset data.

[0036] Figure 28 This is a block diagram illustrating an example virtual reality system that uses digital twins to generate virtual reality presentations that replay past asset behaviors.

[0037] Figure 29 This is a generalized block diagram of a software testing system that uses digital twins to verify control programs.

[0038] Figure 30 This is a diagram illustrating the use of digital twins for the implementation of collective oversight and control of industrial assets.

[0039] Figure 31 This is an example of a time-series data record that illustrates the disadvantages associated with asynchronous data recording.

[0040] Figure 32 Example data recording instructions for programming synchronous data records of BIDT data, which can be supported by device configuration applications, are shown.

[0041] Figure 33This is a diagram illustrating an example interconnection of data recording instructions used to facilitate coordinated data recording of BIDT attributes defined in one or more industrial installations.

[0042] Figure 34 It is by Figure 33 The configuration described herein produces example time-series data records.

[0043] Figure 35 This is another example of an interconnected diagram of linked data record instructions.

[0044] Figure 36 This is a flowchart of an example method for linking points of automated and non-automated models of industrial assets using common references to BIDT data tags.

[0045] Figure 37 This is a flowchart of an example method for configuring the synchronous recording of industrial data.

[0046] Figure 38 This is a diagram illustrating an example architecture that includes AI engine components capable of applying AI analytics to digital twins for contextualization, verification, and adaptation purposes.

[0047] Figure 39 This is a diagram illustrating the contextualization of the AI ​​engine components for the BIDT of digital twins.

[0048] Figure 40 This is a diagram illustrating an example architecture in which the AI ​​engine component contextualizes intelligent tags for the digital twin based on the analysis of the digital twin's data topology and real-time or historical process data.

[0049] Figure 41 This is an example data pattern showing a BIDT smart tag that has been enhanced by AI engine components to include AI fields that define various AI attributes.

[0050] Figure 42 This diagram illustrates the use of AI-based simulations to validate digital twins of physical industrial assets or systems being modeled.

[0051] Figure 43 This is a diagram illustrating an example architecture that can be used to adapt the Digital Twin 2306 to other systems or scenarios prior to deployment.

[0052] Figure 44a This is a flowchart of the first part of an example method for enhancing digital twins of industrial assets, including AI-based verification of the digital twin and metadata for interaction with external AI analytics systems.

[0053] Figure 44bThis is a flowchart of the second part of an example method for enhancing digital twins of industrial assets, including AI-based verification of the digital twin and metadata for interaction with external AI analytics systems.

[0054] Figure 45 This is an example computing environment.

[0055] Figure 46 This is an example of a networked environment. Detailed Implementation

[0056] The subject matter disclosure will now be described with reference to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a complete understanding. However, it will be apparent that the subject matter disclosure can be practiced without these specific details. In other instances, well-known structures and apparatuses are shown in block diagram form to facilitate their description.

[0057] As used herein, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” and “interface” are intended to refer to a computer-related entity or an entity associated with or part of an operating device having one or more specific functions, wherein such an entity may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to: a process running on a processor, a processor, a hard disk drive, multiple storage drives including attached solid-state drives (e.g., screw-on or bolt-on) or removable attached solid-state drives (optical or magnetic storage media); an object; an executable; an execution thread; a computer-executable program; and / or a computer. As an example, an application running on a server and the server itself may both be components. One or more components may reside within an executing process and / or thread, and components may reside on one computer and / or be distributed among two or more computers. Furthermore, the components described herein may be executed from various computer-readable storage media on which various data structures are stored. Components can communicate via local and / or remote processes, for example, based on signals having one or more data packets (e.g., data from a component interacting with a local system, another component in a distributed system, and / or other systems via signals across a network such as the Internet). As another example, a component can be a device having specific functions provided by mechanical parts operated by electrical or electronic circuitry, which is operated by software or firmware applications executed by a processor, wherein the processor may be internal or external to the device and executes at least a portion of the software or firmware application. As yet another example, a component can be a device providing specific functions through electronic components without mechanical parts, the electronic components including a processor to execute software or firmware that at least partially provides the functions of the electronic components. As yet another example, an interface can include input / output (I / O) components and their associated processors, applications, or application programming interface (API) components. While the foregoing examples relate to multiple aspects of components, the illustrated aspects or features also apply to systems, platforms, interfaces, layers, controllers, terminals, etc.

[0058] As used in this paper, the terms "infer" and "inference" generally refer to the process of reasoning or inferring the state of a system, environment, and / or user based on a set of observations captured via events and / or data. For example, inference can be used to identify a specific context or action, or to generate a probability distribution about a state. Inference can be probabilistic, that is, the calculation of a probability distribution of the state of interest based on considerations of data and events. Inference can also refer to techniques used to construct higher-level events from a set of events and / or data. Such inference results in the construction of new events or actions from a set of observed events and / or stored event data, regardless of whether the events are closely related in time or whether the events and data come from one or more event and data sources.

[0059] Furthermore, the term "or" is intended to mean an inclusive "or," not an exclusive "or." That is, unless otherwise specified or is clear from the context, the phrase "X adopts A or B" is intended to mean any natural inclusive arrangement. Specifically, any of the following instances satisfy the phrase "X adopts A or B": X adopts A; X adopts B; or X adopts both A and B. Additionally, unless otherwise specified or is clearly indicated by the context as a singular form, the articles "a" and "an" as used in this application and the appended claims should generally be interpreted as meaning "one or more."

[0060] Furthermore, the term "set" used herein excludes an empty set; for example, a set containing no elements. Therefore, a "set" in the subject matter disclosure includes one or more elements or entities. For illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources; and so on. Similarly, the term "group" used herein refers to a set of one or more entities; for example, a node group refers to one or more nodes.

[0061] Various aspects or features will be presented based on systems that may include many devices, components, modules, etc. It is to be understood and recognized that individual systems may include additional devices, components, modules, etc., and / or individual systems may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Combinations of these methods may also be used.

[0062] Industrial controllers and their associated I / O devices are central to the operation of modern automation systems. These controllers interact with field devices on the plant floor to control automated processes related to purposes such as product manufacturing, material handling, batch processing, supervisory control, and other applications. Industrial controllers store and execute user-defined control programs to implement decisions related to the controlled processes. Such programs can include, but are not limited to, ladder logic, sequential function charts, function block diagrams, structured text, or other such platforms.

[0063] Figure 1 This is a block diagram of an example industrial control environment 100. In this example, multiple industrial controllers 118 are deployed throughout the industrial plant environment to monitor and control corresponding industrial systems or processes related to product manufacturing, processing, motion control, batch handling, material handling, or other such industrial functions. The industrial controllers 118 typically execute corresponding control programs to monitor and control industrial units 120 that comprise controlled industrial assets or systems (e.g., industrial machines). One or more industrial controllers 118 may also include software controllers executing on a personal computer or other hardware platform or on a cloud platform. Some hybrid devices may also combine controller functionality with other functions (e.g., visualization). The control programs executed by the industrial controllers 118 may include any conceivable type of code for processing input signals read from the industrial units 120 and controlling output signals generated by the industrial controllers, including but not limited to ladder logic, sequential function charts, function block diagrams, or structured text.

[0064] Industrial device 120 may include both input and output devices. The input devices provide data related to the controlled industrial system to industrial controller 118, and the output devices respond to control signals generated by industrial controller 118 to control various aspects of the industrial system. Example input devices may include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), manual operator control devices (e.g., buttons, selector switches, etc.), safety monitoring devices (e.g., safety mats, safety cords, light curtains, etc.), and other such devices. Output devices may include motor drives, pneumatic actuators, signaling devices, robot control inputs, valves, etc.

[0065] Industrial controller 118 can interface with industrial device 120 via hardwired or network connection. For example, industrial controller 118 may be equipped with native hardwired inputs and outputs to communicate with industrial device 120 and control the device. Native controller I / O may include digital I / O that sends discrete voltage signals to and receives discrete voltage signals from field devices, or analog I / O that sends analog voltage or current signals to and receives analog voltage or current signals from devices. Controller I / O can communicate with the controller's processor via a backplane, allowing digital and analog signals to be read and controlled by the control program. Industrial controller 118 can also communicate with industrial device 120 via a network, such as using a communication module or integrated networking port. Exemplary networks may include the Internet, intranet, Ethernet, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH / DH+), remote I / O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, etc. The industrial controller 118 may also store persistent data values ​​that can be referenced by the control program and used for control decisions, including but not limited to: measured or calculated values ​​representing the operating status of the controlled machine or process (e.g., fill level, position, alarm, etc.), or captured time-series data collected during the operation of the automated system (e.g., status information at multiple time points, diagnostic occurrences, etc.). Similarly, some intelligent devices—including but not limited to motor drives, instruments, or condition monitoring modules—may store data values ​​used to control and / or visualize the operating status. Such devices may also capture recorded time-series data or events for later retrieval and viewing.

[0066] Industrial automation systems typically include one or more personal machine interfaces (HMIs) 114, enabling factory personnel to view telemetry and status data associated with the automation system and to control aspects of system operation. The HMI 114 can communicate with one or more industrial controllers 118 via a factory network 116 and exchange data with them to visualize information related to the controlled industrial process on one or more pre-developed operator interface screens. The HMI 114 can also be configured to allow operators to submit data to designated data tags or storage addresses on the industrial controllers 118, providing operators with a means to issue commands to the controlled system (e.g., cycle start commands, device actuation commands, etc.), modify setpoint values, etc. The HMI 114 can generate one or more displays through which operators interact with the industrial controllers 118 and thus with the controlled process and / or system. Example displays can use graphical representations of processes to visualize the current state of industrial systems or their associated devices: the graphical representation of the process displays measured or calculated values, employs state-based color or position animations, presents alarm notifications, or uses other such techniques to present relevant data to the operator. The data presented in this manner is read from the industrial controller 118 by the HMI 114 and presented on one or more displays according to a display format selected by the HMI developer. The HMI may include a fixed or mobile device with a user-installed or pre-installed operating system and user-installed or pre-installed graphical application software.

[0067] Some industrial environments may also include other systems or devices related to specific aspects of the controlled industrial system. These systems or devices may include, for example, a data historian 110 or a device document storage device 104, which aggregates and stores production information collected from the industrial controller 118 or other data sources, while the device document storage device 104 contains electronic documents for the various industrial devices that make up the controlled industrial system. Other systems may include an inventory tracking system 102, a work order management system 106, a repository of machine or process diagrams and documents, a supplier product document storage device, a supplier knowledge base, an internal knowledge base, a work scheduling application, or other such systems, some or all of which may reside on the industrial environment's office network 108.

[0068] Industrial assets and their associated industrial assets can generate a large amount of information during operation. Figure 2This is a conceptual diagram illustrating the flow of industrial data across various information levels in a typical industrial environment. At the factory floor level, industrial assets 206—e.g., industrial machines, production lines, industrial robots, etc.—perform corresponding tasks related to the manufacture, packaging, or disposal of products; the control of industrial processes; or other such industrial functions. These industrial assets 206 are directly monitored and controlled by industrial devices 204. For example, proximity switches, telemetry devices, optical sensors, or other such monitoring devices can be used to monitor various states and metrics of industrial assets 206 (e.g., actuator position, motor speed, temperature, flow rate, pressure, human presence, etc.). Industrial devices facilitating the control of industrial assets 206 can include, for example, motor drives, pneumatic actuators, remote I / O devices, or other such equipment. Industrial devices 204 may also include HMIs (e.g., HMI 114).

[0069] Industrial controller 202 performs monitoring and control of industrial asset 206 via industrial device 204. In this respect, industrial device 204 serves as both an input and output of industrial controller 202, which controls its output industrial device based on user-defined control routines (e.g., ladder logic programs, sequential function chart programs, etc.) and the current values ​​and states of the input industrial device. Data generated by industrial device 204 reflects the current state of industrial asset 206. This data is read by industrial controller 202, which can generate additional data (e.g., calculated supplementary data, aggregated values, etc.) based on these industrial device states and values.

[0070] At the user level, customized applications—such as reporting applications, visualization applications, enterprise resource planning applications, manufacturing execution systems, etc.—can collect a selected subset of information available in industrial controller 206 and present that information to the user as formatted data 210 according to the data presentation format defined in application 208.

[0071] Collecting and delivering some or all of this information to users in a meaningful presentation format can provide valuable insights into the past, present, and future operation of industrial assets 202. However, the highly distributed nature of data available across numerous industrial units associated with the various industrial machines or systems that constitute an industrial enterprise presents challenges regarding the collection and formatting of data for common presentation to client devices that can be delivered to users. Furthermore, much of the information available on a given set of industrial units includes uncontextualized, unstructured data (e.g., integers, real numbers, or discrete values ​​stored in data tables on industrial controllers), the meaning of which must be defined by the application 208 used to present the data. This burdens the developers of such applications 208, who must specify the meaning of each item of unstructured data received and presented by these applications so that the data will be meaningful to the viewer (e.g., product counts, productivity, system temperature or pressure, historical trends, etc.).

[0072] To address these and other issues, one or more embodiments of this disclosure provide an industrial data presentation system that supports meaningful presentation of generated and transmitted industrial data using structured data types. In one or more embodiments, industrial devices and / or controllers are configured to support structured data types—referred to herein as Basic Information Data Types (BIDTs)—which comprise a finite set of structured information data types. In an example implementation, the basic information data types may include four structured information data types representing (1) rate, (2) status, (3) odometer, and (4) event. Within the industrial device or controller configuration, a user can define associations between a given physical asset (e.g., a machine, production line, etc.) and one or more of the basic information data types. This may include, for example, defining one or more data tags representing a metric or status of the physical asset, and associating each tag with one of the basic information data types. Each basic information data type has associated metadata that can be configured by the user to customize the data tags for a given industrial application (e.g., maximum and minimum values ​​for the rate data type, flip values ​​for the odometer data type, event or status names for the event and status data types, any parent-child relationships between data tags, etc.).

[0073] Once BIDT is configured in an industrial unit or controller, it can be discovered by external data collection and / or visualization systems, including local systems sharing a network with the industrial unit or remote cloud-based systems. For example, a gateway device can be configured with one or more asset models referencing BIDT data tags on the industrial unit. The asset model assigns groups of BIDT data tags to corresponding hierarchical elements (e.g., production facilities, production areas or production lines, and industrial assets, equipment units, industrial units, etc.). The gateway device can retrieve industrial data from the BIDT data tags, along with associated user-defined metadata for each tag. The gateway device or a separate application server system can then generate a graphical representation of the industrial data based on a selected asset model and the BIDT metadata.

[0074] BIDT can also facilitate simplified integration of automated models of industrial assets with non-automated models (e.g., mechanical, financial, thermal models, etc.) by providing a common naming convention. This common naming convention allows both models to reference selected items from real-time or historical asset data. In this way, automation domain attributes of the automated model can be linked to corresponding attributes in the non-automated model (e.g., machine domain attributes of the mechanical model) via a common data source reference.

[0075] Figure 3 This is a block diagram of an example industrial apparatus 302 supporting basic information data types according to one or more embodiments of this disclosure. Aspects of the systems, devices, or processes described in this disclosure can constitute machine-executable components implemented within a machine, for example, in one or more computer-readable media (or media) associated with one or more machines. Such components, when executed by one or more machines—e.g., computers, computing devices, automation devices, virtual machines, etc.—can cause the machines to perform the described operations.

[0076] Industrial device 302 may include virtually any type of data-generating industrial device, including but not limited to industrial controllers, motor drives, HMI terminals, vision systems, industrial optical scanners, or other such devices or systems. Industrial device 302 may include a program execution unit 304, an I / O control unit 306, a BIDT configuration unit 308, a BIDT publishing unit 310, a networking unit 312, a user interface unit 314, one or more processors 318, and a memory 320. In various embodiments, one or more of the program execution unit 304, I / O control unit 306, BIDT configuration unit 308, BIDT publishing unit 310, networking unit 312, user interface unit 314, one or more processors 318, and memory 320 may be electrically coupled and / or communicatively coupled to each other to perform one or more of the functions of industrial device 302. In some embodiments, components 304, 306, 308, 310, 312, and 314 may include software instructions stored on memory 320 and executed by processor 318. Industrial device 302 may also be associated with… Figure 3 Interacting with other hardware and / or software components not depicted herein. For example, processor 318 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0077] The program execution unit 304 can be configured to compile and execute a user-defined control program. In various embodiments, the control program can be written in any suitable programming format (e.g., ladder logic, sequential function chart, structured text, etc.) and downloaded to the industrial device 302. Typically, the control program uses data values ​​read from the analog and digital inputs of the industrial device as input variables and sets the values ​​of the analog and digital outputs of the industrial device in part based on the input values ​​according to the control program instructions. The I / O control unit 306 can be configured to control the electrical output signals of the digital and analog electrical outputs of the industrial device according to the control program output, and convert the electrical signals on the analog and digital inputs of the industrial device into data values ​​that can be processed by the program execution unit 304.

[0078] The BIDT configuration component 308 can be configured to set metadata values ​​associated with BIDT data tags defined for the industrial device 302 based on metadata configuration input data. As will be described in more detail below, in addition to standard general data types (e.g., real, analog, digital, etc.), the industrial device 302 is configured to support industry-specific data types, referred to herein as Basic Information Data Types (BIDTs). Data tags associated with these Basic Information Data Types have associated metadata that can be configured by the user via the BIDT configuration component 308 to customize the data tags for a given industrial application. For convenience, data tags associated with Basic Information Data Types are referred to herein as “BIDTs”. User-defined BIDTs 322 are stored in memory 320 (e.g., in the industrial device’s tag database along with other defined data tags of other data types).

[0079] BIDT publishing component 310 is configured to expose the defined BIDT 322 to external systems, thereby allowing BIDT 322 to be discovered by such systems via local and / or remote networks. Networking component 312 can be configured to exchange data with one or more external devices via wired or wireless networks using any suitable network protocol. User interface component 314 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, haptic, etc.). In some embodiments, user interface component 314 can be configured to interface communicatively with a development application running on a client device (e.g., laptop computer, tablet computer, smartphone, etc.) communicatively connected to industrial device 302 (e.g., via hardwired or wireless connection). User interface component 314 can then receive user input data and present output data via the development application. In other embodiments, user interface component 314 can be configured to generate and provide suitable graphical interface screens to client devices and exchange data via these graphical interface screens. The input data that can be received via the user interface component 314 may include, but is not limited to, user-defined control programs or routines, data tag definitions, BIDT metadata configuration data, or other such data.

[0080] One or more processors 318 may perform one or more of the functions described herein with reference to the systems and / or methods disclosed herein. Memory 320 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the systems and / or methods disclosed herein with reference to the systems ...

[0081] Figure 4This is a block diagram of a gateway device 402 capable of discovering BIDTs on one or more industrial installations and presenting associated data in a formatted manner according to a user-defined asset model. Gateway device 402 may include a discovery unit 406, a model configuration unit 408, an application server interface unit 410, a presentation unit 412, a user interface unit 414, one or more processors 418, and a memory 420. In various embodiments, one or more of the discovery unit 406, model configuration unit 408, application server interface unit 410, presentation unit 412, user interface unit 414, one or more processors 418, and memory 420 may be electrically coupled and / or communicatively coupled to each other to perform one or more of the functions of gateway device 402. In some embodiments, components 404, 406, 408, 410, 412, and 414 may include software instructions stored in memory 420 and executed by processor 418. Gateway device 402 may also be associated with… Figure 4 It may interact with other hardware and / or software components not depicted herein. For example, processor 418 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0082] Discovery component 406 can be configured to discover BIDTs (e.g., BIDT 322) defined on industrial installations (e.g., industrial installation 302) communicatively connected to gateway device 402. Discovery component 406 can also be configured to retrieve data and metadata associated with the BIDTs for use in generating industrial data representations. Model configuration component 408 can be configured to create and store one or more asset models 422 based on user-defined asset model definitions. These asset models can represent industrial assets or collections of industrial assets according to hierarchical elements of industrial facilities or sets of facilities, where these hierarchical elements can include, but are not limited to, plants, production areas or production lines, industrial machines or other industrial assets, equipment units constituting industrial assets, industrial devices associated with industrial assets (e.g., controllers, motor drives, vision system devices, safety devices, etc.), or other such elements. Asset model 422 can also assign groups of BIDTs to corresponding elements in the hierarchical model. Asset model 422 can be customized to suit the information needs of various types of information consumers (e.g., line operators, engineers, plant managers, etc.).

[0083] Application server interface component 410 can be configured to expose asset models 422 and industrial data collected from industrial installations (e.g., industrial installation 302) to an application server (e.g., application server system 502 discussed below), which can aggregate multiple asset models 422 into a larger aggregated plant model or enterprise model and generate a graphical representation of the industrial data based on the plant model. Presentation component 412 can be configured to generate a data presentation—e.g., in the form of a graphical display layout, a collection of widgets, etc.—that presents a selected subset of the industrial data received from discovery component 406 based on one or more of the asset models 422. In some embodiments, presentation component 412 can be configured to present data associated with a BIDT using appropriate BIDT-specific widgets (or other graphical display elements) selected from a predefined set of widgets.

[0084] User interface component 414 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, haptic, etc.). In some embodiments, user interface component 414 can be configured to interface communicatively with a client application running on a client device (e.g., a laptop computer, tablet computer, smartphone, etc.) communicatively connected to gateway device 402 (e.g., via hardwired or wireless connection). User interface component 414 can then receive user input data and present output data via the client application. In other embodiments, user interface component 414 can be configured to generate and provide suitable graphical interface screens to the client device and exchange data via these graphical interface screens. Input data that can be received via user interface component 414 may include, but is not limited to, asset model definitions stored as asset model 422 or other such data.

[0085] One or more processors 418 may perform one or more of the functions described herein with reference to the systems and / or methods disclosed herein. Memory 420 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the systems and / or methods disclosed herein.

[0086] Figure 5This is a block diagram of an application server system 502 capable of aggregating asset models 422 from a gateway device (e.g., gateway device 402) into one or more factory models 522 and formatting associated data received from gateway device 402 according to the aggregated factory models 522. The application server system 502 may include a gateway interface component 504, a factory model component 506, a presentation component 508, a destination interface component 510, a predictive analytics component 512, an AI engine component 514, one or more processors 518, and a memory 520. In various embodiments, one or more of the gateway interface component 504, factory model component 506, presentation component 508, destination interface component 510, predictive analytics component 512, AI engine component 514, one or more processors 518, and memory 520 may be electrically coupled and / or communicatively coupled to each other to perform one or more of the functions of the application server system 502. In some implementations, components 504, 506, 508, and 510 may include software instructions stored on memory 520 and executed by processor 518. Application server system 502 may also be compatible with... Figure 5 It may interact with other hardware and / or software components not depicted herein. For example, processor 518 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0087] Gateway interface component 504 can be configured to exchange data with one or more gateway devices (e.g., gateway device 402) via a wired or wireless network. In some embodiments, application server system 502 may be a pre-installed device residing in a factory floor, and gateway interface component 504 may exchange data with gateway device 402 via a local factory network and / or office network. In other embodiments, application server system 502 may reside on a cloud platform. In such embodiments, gateway interface component 504 may exchange data with gateway device 402 via a combination of public networks (e.g., the Internet layer) and private networks (e.g., factory networks or office networks at industrial facilities).

[0088] Plant model component 506 can be configured to discover asset models 422 held on one or more gateway devices 402 and aggregate these discovered asset models 422 into a general plant model 522 for an industrial facility or enterprise. Plant model 522 can define hierarchical relationships between industrial assets of a given plant facility, or between assets distributed across geographically different plant facilities. Plant model 522 also defines relationships between BIDT data items associated with a given industrial asset by assigning BIDT groups defined in the industrial units associated with the industrial asset to corresponding hierarchical elements (e.g., production line, industrial asset identifier, equipment unit, industrial unit, etc.) in plant model 522. By defining relationships between assets that constitute an industrial facility or enterprise, plant model 522 similarly defines relationships between data items associated with those assets. The hierarchical relationships defined by plant model 522 can be utilized by application server system 502 to present information about assets to users in a structured manner.

[0089] Presentation component 508 can be configured to generate a data presentation—e.g., in the form of a graphical display layout, a set of widgets 524, etc.—that presents a selected subset of data received from gateway device 402 based on one or more of the plant models 522. In some embodiments, presentation component 508 can be configured to present data associated with basic information data type tags using appropriate BIDT-specific widgets (or other graphical display elements) selected from a predefined set of widgets 524. Destination interface component 510 can be configured to exchange data with one or more destination client devices via a wired or wireless network (e.g., a private plant or office network, a cloud platform, or a public network such as the Internet). This can include delivering graphical data presentations to client devices based on one or more of the plant models 522. Predictive analytics component 512 can be configured to perform predictive analytics on stored time-series industrial asset data.

[0090] AI Engine Component 514 can be configured to apply AI analytics to digital twins that use BIDT as the underlying data foundation to facilitate the discovery of new relationships between digital twin variables, the verification of digital twins relative to the industrial assets they model, and the adaptability of digital twins for use with other assets or under other operating conditions.

[0091] One or more processors 518 may perform one or more of the functions described herein with reference to the systems and / or methods disclosed herein. Memory 520 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the systems and / or methods disclosed herein.

[0092] Figure 6 This is an illustration of four example basic information data types that can be supported by one or more implementations of industrial device 302. These data types can complement other standard data types (e.g., integers, real numbers, Booleans, strings, floating-point numbers, etc.) typically supported by industrial controllers or other industrial devices. Typically, a data tag is a data structure defined within the industrial device that references a memory location within the device (e.g., an input value, output value, or internal data register) and corresponds to a specific data item. Data tags can be configured to have a specified data type (or can be instances of a specified data type), such as Boolean, floating-point, integer, double integer, string, etc. During development, controller tags can be created and maintained in the industrial device's tag database. The BIDT described herein is an additional data type that caters to industrial automation applications and complements traditional data types.

[0093] In the example shown, the basic information data type includes a limited set of four structured information data types—Status BIDT 602, Rate BIDT 604, Odometer BIDT 606, and Event BIDT 608. Although the examples described herein assume that the supported BIDTs include these four data types, it should be understood that some implementations may include other BIDT data types without departing from the scope of this disclosure.

[0094] Each BIDT includes fields for storing the current values ​​of the BIDT (e.g., status values, rate values, odometer values, and event values) and one or more metadata fields configured to store user-defined configuration data for that BIDT. The metadata values ​​of each BIDT can be customized for the management and presentation of associated BIDT data values ​​based on the specific industrial asset or industrial application associated with the BIDT.

[0095] The values ​​contained in state BIDT 602 can represent the current state of an industrial asset or device (e.g., a machine, production line, motor drive, etc.). State data contained in state BIDT 602 can represent one of a set of predefined states that represent the current state or condition of the associated industrial asset or device. For example, a state BIDT can convey an S88 state, a packaging machine language state, the current state of a state machine defined for the asset, the state of a valve (e.g., open or closed), the state of a motor (e.g., running, idle, faulty, etc.), or other types of states.

[0096] The user-configurable metadata associated with state BIDT 602 (which can be configured by BIDT configuration unit 308 based on user input received via user interface unit 314) can define a state machine representing the available state of the associated asset, wherein each defined state is configured to be invoked in response to a detected condition. For example, each defined state can be linked via metadata to one or more other related data tags defined in industrial device 302 (e.g., data tags indicating the state of a sensor or switch), such that the current state indicated by state BIDT 602 is a function of the current value of the related data tag.

[0097] The values ​​included in Rate BIDT 604 can be integer or real values ​​representing the measured rate of a metric associated with an industrial asset or installation. Rate values ​​can be instantaneous rates or values ​​representing the rate of change of a metric over a period of time. For example, rate values ​​included in Rate BIDT 604 can represent temperature, pressure, speed (e.g., the speed of a conveyor or other motor-driven machine component), total equipment efficiency (OEE), or other such metrics.

[0098] User-configurable metadata associated with a rate BIDT 604 can define the maximum and minimum values ​​for the corresponding rate, ensuring that the values ​​included in the rate BIDT 604 do not deviate outside the window defined by the maximum and minimum value metadata. Metadata can also identify one or more data sources that determine an event (e.g., one or more other data tags or input addresses). For example, the metadata for a rate BIDT 604 can define whether the corresponding rate value is an aggregation of multiple other values ​​contained in other defined data tags. In this case, the user can define the rate value as the average or sum of two or more identified data tags, or the integral of the data tags over time. Another metadata field can be used to specify the engineering units to be associated with the rate.

[0099] The values ​​contained in the BIDT 606 odometer can represent cumulative quantities associated with industrial assets. For example, the BIDT 606 odometer can be configured to represent cumulative quantities with flip values, such as the parts count associated with an industrial asset. In such cases, the metadata associated with the BIDT 606 odometer can include the definition of the flip value. The BIDT 606 odometer can also be configured to represent quantities over defined time intervals, such as energy consumption associated with an asset. In the case of quantities over defined time intervals, the metadata associated with the BIDT 606 odometer can include the definition of the time interval, which can be defined by the start and end times of a day, by the start time of a time interval, by a defined duration, or as another time definition format. The metadata associated with the BIDT 606 odometer can also define one or more data sources that drive the odometer value. For example, the metadata can define a data tag associated with a cycle completion event, such that the odometer value increases when the cycle completion data tag goes high. The odometer value can also be defined as an aggregation of multiple values. In such cases, the metadata can identify two or more data tags whose values ​​will be aggregated or summed to produce the odometer value. Metadata can also define the units of measurement associated with odometer values ​​(e.g., bottle, operating cycle, megawatt-hour, etc.).

[0100] The values ​​included in event BIDT 608 can represent transient or persistent events associated with industrial assets. For example, event BIDT 608 can represent transient events such as button events (e.g., "Service button pressed"), sensor events (e.g., "Part present," "Person detected," etc.), safety device events (e.g., "Light curtain breached"), or another such transient event. Persistent events that can be represented by event BIDT 608 can include, but are not limited to, events associated with alarm states (e.g., "Alarm unacknowledged," "Alarm acknowledged," etc.). Other examples of persistent events that can be represented by event BIDT 608 can include persistent events with identifiers and states. For example, an event associated with a batch process can include a batch number (identifier) ​​and associated events (e.g., "Start," "Execute," "Complete," etc.). User-configurable metadata associated with event BIDT 610 can include identifiers of additional data tags whose states aggregate to determine the event to be represented by event BIDT 610. Alternatively, if the event represented by event BIDT 608 is a function of only a single input (e.g., a button input), the metadata can identify the appropriate input address of the industrial device.

[0101] In addition to the metadata for each basic information data type described above, BIDTs may also include configurable metadata fields that define communication or discovery parameters for the corresponding BIDT. For example, each BIDT may include an update rate metadata parameter that allows the user to set the rate or frequency at which the BIDT sends its data to the gateway device to update the corresponding data presentation. Such metadata fields may allow the user to set the update cycle of the BIDT (e.g., a 60-second cycle, which causes the BIDT to send updated values ​​every 60 seconds), or specify that the BIDT will send its updated values ​​substantially continuously (e.g., every 5 milliseconds to every 10 seconds).

[0102] It should be understood that the above combination Figure 6 The BIDT described is intended to be exemplary, and other types of BIDTs are also within the scope of one or more embodiments of this disclosure.

[0103] In the example scenario, users can configure BIDT in industrial controllers or other industrial devices, as well as other data tags to be used by the control program, during control program development. Figure 7 This diagram illustrates the configuration of BIDTs in a tag database 702 of an industrial device 302 supporting BIDTs. The industrial device 302 may be, for example, an industrial controller (e.g., a programmable logic controller or other type of programmable automation controller) configured to execute an industrial control program 704 to facilitate the monitoring and control of industrial machines or processes. The industrial device 302 includes a tag database 702 storing data tag definitions. The data tag definitions are configured by the user in collaboration with the development of the control program 704 (e.g., a ladder logic program, a sequential function chart program, etc.) and define data tags 712 of various data types used to store and identify analog and digital data values ​​generated and consumed by the control program 704. Example standard data types that can be represented by data tags 712 may include, for example, integer data types, real number data types, Boolean data types, etc. In addition to these standard data types, one or more of the data tags 712 may include BIDTs (e.g., BIDTs 602, 604, 606, and 608) associated with the basic information data types described herein. These BIDTs are also referred to as smart tags.

[0104] In this example scenario, a user can configure both the control program 704 and the data tag definitions using a device configuration application 708 running on a client device 710 (e.g., a laptop computer, desktop computer, tablet computer, etc.) that interfaces to the industrial device 302. In various implementations, the client device 710 can interface with the industrial device 302 via a hardwired connection (e.g., a Universal Serial Bus connection, Ethernet connection, serial connection, etc.) or a wireless connection (e.g., near-field, WiFi, etc.) supported by the user interface component 314. The device configuration application 708 can execute a program development environment that can be used to develop the control program 704 and its associated data tags 712, which include any BIDTs associated with one or more industrial assets to be controlled using the control program 704.

[0105] During development, the BIDT configuration component 308 of industrial device 302 can create BIDTs corresponding to any of the aforementioned BIDT types (status, rate, odometer, and event, or other supported BIDT types) based on the BIDT configuration input 706 downloaded to industrial device 302 from client device 710. Using device configuration application 708, users can also configure metadata associated with each BIDT to customize the BIDT for a given industrial application. For example, for status BIDT 602 associated with a bottle filling machine to be controlled by industrial device 302, the user can specify various states to be represented by tags (e.g., running, home, abnormal, idle, etc.). In some embodiments, BIDT configuration component 308 may support multiple predefined states that can be selected by the user and associated with a given status BIDT. Alternatively, the user can define names for one or more states to associate with the status BIDT.

[0106] For the rate BIDT 604, which represents the speed at which bottles are fed to the filling machine, the user can specify a maximum and minimum speed value. Therefore, the rate BIDT 604 will not generate speed values ​​outside the range defined by the maximum and minimum values, and can generate an error or alarm output if the measured speed value exceeds the defined maximum or falls below the defined minimum. Another rate BIDT 604, representing average temperature, can be configured to average multiple analog temperature input values ​​specified by the user in the metadata. For the odometer BIDT 606, representing product counts (e.g., the number of filled bottles output by the filling machine), the user can configure the associated metadata to define data labels that trigger an increase in the odometer value (e.g., an input label representing a "filling cycle complete" event or another BIDT), as well as a shift start event and a shift end time, between which the value of the odometer BIDT 606 will increase before being reset to zero. The metadata of events associated with components of the filling machine in BIDT 608 can define input addresses or data tags that indicate the status of the device that determines the event (e.g., a button, a light sensor, etc.), or alarm data tags that correspond to alarms that determine the event with their status (e.g., abnormal, normal, acknowledged, unacknowledged, etc.).

[0107] Once a data tag (both standard and BIDT) is configured, the tag database 702 stores the configured data tag 712 on the memory 320 of the industrial device 302, where the data tag 712 can be accessed by the control program 704. Figure 8 This is a diagram showing the storage of BIDTs in the tag database 702, illustrating sample data fields used for the corresponding type of BIDT. Figure 8 In the example depicted, data tag 1 802 is a status BIDT that has metadata fields for the name of the industrial asset associated with the tag (e.g., the name of a bottle filling machine, die-casting furnace, stamping machine, etc.), the name of the status represented by tag 802, the identifier of one or more device inputs or other data tags that determine the status, the identifier of production and non-production status, etc.

[0108] Data tag 2 804 is a rate BIDT, which has a metadata field for the industrial asset name, a rate name represented by a rate value (e.g., line 3 conveyor speed), the maximum and minimum values ​​of the basic rate value and / or instantaneous rate, the associated data tags at which the values ​​are aggregated to obtain the rate value, the metadata field for the unit of the rate value, or other such metadata fields. Data tag 3 806 is an odometer BIDT, which has a metadata field for the asset name, a name of the odometer value (e.g., filling bottle, #4 die casting energy consumption, etc.), a flip value representing the value of the odometer value (at which the value will return to zero), the time interval at which the odometer value will be incremented (e.g., the start and end times corresponding to a work shift), one or more associated data tags that trigger the increment of the odometer value, the metadata field for the unit associated with the odometer value, or other such metadata fields. Data tag 4 808 is an event BIDT, which has a metadata field for the asset name, a name of one or more events represented by the event BIDT, an identifier for one or more inputs or data tags that determine the event, or other such metadata fields.

[0109] It should be understood that the above is combined Figure 8 The metadata fields described are intended to be illustrative only, and the metadata of the BIDT can have any suitable set of data fields that allow users to match the BIDT with an industrial application performed by the industrial unit 302.

[0110] After the industrial unit 302 is programmed and configured (including the creation of any BIDT to be used by the control program 704), the industrial unit 302 can be deployed on the factory floor to facilitate control over one or more industrial assets or processes. Figure 9 This is a diagram illustrating the runtime operation of an example industrial unit 302 supporting BIDT. In this example, it is assumed that industrial unit 302 is an industrial controller (e.g., a PLC or other type of programmable automation controller). Controlled asset or process 906 can represent any industrial machine, production line, process, or operation under the control of industrial unit 302. Controlled asset or process 906 can have multiple associated input and output devices (e.g., ...). Figure 2 The industrial device 204 receives command signals from or sends telemetry data to the industrial device 302 via any suitable combination of hardwired or networked connections to regulate controlled operation. The industrial device 302 may also include one or more I / O interfaces 904 providing hardwired or networked connections to controlled equipment and industrial devices associated with the controlled asset or process 906. These I / O interfaces 904 may include, for example, digital and / or analog input modules, digital and / or analog output modules, networking modules, etc.

[0111] The I / O table 902 within the memory 320 of the industrial device can maintain the current analog and digital values ​​of various inputs and outputs read from or written to the I / O interface 904. That is, data signals read from field devices by the I / O interface 904 (e.g., analog or digital input modules) can be written to the input / output table 902 (e.g., by the I / O control unit 306). Some or all of these input values ​​can be linked to corresponding data tags (standard or BIDT data tags) maintained in a tag database 702, which can be read by the control program 704 or by an external application. These input values ​​can then be read from the appropriate data tags by the control program 704, which updates its control variables accordingly. Similarly, output values ​​generated by the control program 704 can be written to output data tags defined in the tag database 702, causing the corresponding output register in the I / O data table 902 to be updated. Then, the I / O control unit 306 generates an appropriate analog or digital output signal at the output point of the I / O interface 904 based on the updated output value. It should be understood that this overview of industrial controller functionality is intended to be exemplary only, and the BIDT described herein can be implemented on other types of industrial controllers with different data update processes, or on different classes of industrial devices.

[0112] The BIDT in the tag database 702 can be discovered by external systems, enabling BIDT data—with associated metadata tailored to the industrial applications performed by industrial unit 302—to be retrieved and organized by those external systems based on user-defined asset and / or plant models. In one or more embodiments, gateway device 402 can be used to collect, format, and present data from one or more industrial units 302 with BIDT capabilities. Figure 10 This diagram illustrates the configuration of a gateway device 402 having one or more asset model definitions. The gateway device 402 can be configured using a gateway configuration application 1006 executed on a client device 1004 (e.g., a laptop computer, desktop computer, tablet computer, etc.). In some embodiments, the gateway configuration application 1006 may be an integrated tool of a device configuration application 708 for programming and configuring the industrial device 302.

[0113] Gateway configuration application 1006 allows users to define a collection of industrial automation applications, or an asset structure or model of industrial automation applications, that are being monitored and controlled by one or more industrial devices 302 with BIDT capabilities. These asset models define the hierarchical relationships between industrial assets, associated industrial devices, production lines or areas, and data generated by various devices associated with the industrial applications. Using gateway configuration application 1006, users can define these asset models as model definitions 1002, which can be downloaded to gateway device 402 and stored thereon as asset models 422.

[0114] To facilitate the creation of model definition 1002, gateway configuration application 1006 can be configured to generate and present a suitable configuration screen on client device 1004, guiding the user through the process of defining these asset models 422 for their own industrial application. Model definition 1002 can be defined as referencing BIDT data tags defined on one or more industrial units 302. Specifically, model definition 1002 can define hierarchical elements of industrial assets or asset sets as nodes in a hierarchy and assign selected groups of BIDT data tags to the corresponding elements associated with the BIDT data tags (e.g., nodes associated with industrial assets, equipment units associated with assets, or industrial units associated with assets). Thus, asset model 422 is configured by the user to associate the corresponding BIDTs with selected industrial machines, units, production lines, and / or plant facilities, and to define the hierarchical relationships between these elements.

[0115] In an implementation of the gateway configuration application 1006 as an integrated tool for the device configuration application 708, the model building tool of the gateway configuration application 1006 allows a user to build a model definition 1002 by browsing selected BIDTs defined in one or more industrial device configuration files (e.g., a configuration file downloaded to industrial device 302 and defining control program 704 and tag database 702). Users can create nodes representing industrial facilities, production lines or areas within industrial facilities, industrial assets within each production line (e.g., industrial machines, industrial robots, etc.), equipment units associated with a given industrial asset (e.g., loader, pusher, processing station, etc.), and / or industrial devices (e.g., controllers, drives, etc.) associated with each industrial asset. The selected BIDTs defined on the various industrial devices 302a, 302b, and 302c can then be associated with the corresponding nodes defined in the model definition 1002 to generate an asset model 422, which can be downloaded to the gateway device 402. Asset Model 422 allows users to define hierarchical assets or plant architectures and group BIDTs within a framework associated with selected nodes representing plant production areas or production lines, industrial assets, and / or equipment and devices associated with assets.

[0116] The asset model 422 defined on gateway device 402—working in conjunction with the BIDT defined on industrial device 302—contextualizes data generated by industrial applications and facilitates the generation of contextualized data presentation. For a given industrial application, multiple asset models 422 can be created and maintained on gateway device 402, where each asset model 422 can represent a different view of the industrial application. The different views represented by asset models 422 can be customized according to the needs of specific user roles. For example, an asset model 422 for a given industrial application can represent a production model view of the industrial application. Figure 11 This is a graphical representation of an example asset model formatted as production model 1102. Example production model 1102 has a single factory node 1104, under which are multiple line nodes 1106 (line 1, line 2, and line 3), which are child nodes relative to factory node 1104. Line nodes 1106 represent various production lines within the factory represented by factory node 1104. Each line node 1106 has several child machine nodes 1108, which represent machines (e.g., cartoners, case packers, flow packaging, packaging systems) deployed on the lines represented by the associated line nodes 1106. Each machine node 1108 is associated with several monitoring values ​​1110, which are data values ​​obtained from corresponding BIDTs configured on industrial unit 302. Monitoring values ​​1110 may correspond to production and operational statistics, such as productivity (obtained from rate BIDT), operational and production status (obtained from status BIDT), or line events (obtained from event BIDT). Figure 11 As can be seen, each group of BIDT data labels—represented by monitoring value 1110—is assigned to selected machines and lines within the plant, as defined in the asset model definition. This example production model 1102 produces a view of the industrial facility (including lines 1, 2, and 3) that can be adapted to the operators or shift managers responsible for the day-to-day operation of the lines.

[0117] Figure 12This is a graphical representation of an example asset model formatted as Design Model 1202. Design Model 1202 is configured to present a view of data from industrial applications in a contextualized manner suitable for plant engineers, original equipment manufacturers (OEMs), or system designers. Similar to Production Model 1102, the design model includes a plant node 1204 with several sub-line nodes 1214. In this example, the sub-nodes of each line node 1214 may include machine nodes 1206 (e.g., a packaging system) representing the machines of the line represented by line node 1214, and platform nodes 1210 representing the various platforms of the machines (e.g., forming machines, feeding devices, loaders, etc.). Each machine node 1206 may be associated with monitoring values ​​1208 related to the production and operation of the machine (obtained from a BIDT configured on the relevant industrial unit 302). Each platform node 1210 may be associated with monitoring values ​​representing the current operating statistics of that platform of the machine (also obtained from the corresponding BIDT). Some platform nodes 1210 may also have child nodes representing various equipment components of the platform (e.g., device node 1212 representing a finding wheel that is part of the feeding device). For example... Figure 11 The production model 1102 depicted in the diagram allows users to configure the design model 1202 by defining various hierarchical nodes of the model and assigning selected BIDT tag groups (monitoring values) to selected nodes of the model. The system allows users to define the nodes of the model based on any user-defined hierarchical plant or enterprise structure, which can include user-defined hierarchical levels (e.g., production lines, production cells, production stations, etc.).

[0118] It should be understood that the production model 1102 and design model 1202 described above are intended to be exemplary only, and the asset models described herein are not limited to these two types of views. Generally, any suitable user-defined asset model 422 that utilizes data from BIDT to present a contextualized view of industrial asset data is within the scope of one or more embodiments of this disclosure.

[0119] As in Figure 11 and Figure 12As can be seen in the example asset structure model, BIDTs are attributes of their associated parent nodes. For example, the monitoring value 1110 of the cartoning machine—obtained from a corresponding BIDT data tag on one or more industrial units 302—is an attribute of the cartoning machine product node 1108. During model development, users can define various types of nodes, such as plant nodes, line nodes, product nodes, equipment nodes, or other types of nodes that collectively constitute an industrial enterprise or a specific set of industrial applications within an industrial enterprise, and define the hierarchical relationships between these nodes. Users can then assign the selected BIDTs to their appropriate nodes to generate an asset model, which can be downloaded to and stored on the gateway device 402.

[0120] Each industrial device 302's BIDT publishing component 310 exposes the industrial device 302's BIDT to the asset model 422 defined on the gateway device 402. Therefore, when the gateway device 402 is deployed on a cloud platform or factory network with secure remote access to the industrial device 302, the asset model 422 enables the gateway device 402 to retrieve data from the corresponding BIDT and metadata parameters associated with each BIDT, in order to generate a contextualized representation of industrial application data based on the asset model 402.

[0121] Figure 13 This is a diagram illustrating a contextualized flow of BIDT data, from industrial unit 302 to application server system 502. In this example, multiple industrial units 302 (e.g., 302a, 302b, and 302c) have been programmed to control corresponding industrial assets 1310 (e.g., industrial machines, production lines, etc.). Each industrial unit 302 has been configured with the above-described combination... Figures 6 to 9 The aforementioned BIDT 322 (or smart tags). Gateway device 402 has been configured with the above-described combination. Figures 10 to 12 The aforementioned asset model 422. Asset model 422 defines corresponding customized views of BIDT data.

[0122] During operation, industrial units 302a-302c monitor and control their respective industrial assets 1310 (e.g., via corresponding input and output devices associated with the respective industrial assets 1310). Gateway device 402 is networked to the respective industrial units 302a-302c. For example, gateway device 402 may be a pre-installed device residing on the same factory network as industrial units 302a-302c. In another implementation, gateway device 402 may reside on a cloud platform and be able to securely access the factory network from the cloud platform (e.g., via firewall devices).

[0123] The BIDT publishing component 310 of each industrial unit 302 exposes the data and metadata associated with each configured BIDT 322 to the gateway unit 402, thereby enabling the discovery component 406 of the gateway unit 402 to access and retrieve the BIDT data and metadata. For each model 422 defined on the gateway unit 402, the model configuration component 408 of the gateway unit 402 retrieves the data and metadata of each BIDT referenced by the model 422 (specified by the user-defined model definition 1002) and creates a logical model 1302 of the data based on the model 422 and the BIDT data and metadata. The logical model 1302 organizes the data from the BIDTs according to the user-defined hierarchical asset model 422.

[0124] Gateway device 402 includes an application server interface component 410 (see application server interface component 410) that communicatively connects gateway device 402 to application server system 502. Figure 4 Despite Figure 13 Application server system 502 is described as a separate system relative to gateway device 402. In some embodiments, application server system 502 may be an integrated application of gateway device 402. Application server system 502 is configured to receive a logical model 1302 from gateway device 402 and provide data display presentation 1304 to authorized client devices 1308. For example, presentation component 508 of application server system 502 may generate an application view of BIDT data based on the logical model and associated BIDT data and metadata received from gateway device 402, and destination interface component 510 of application server system 502 may send this application view as data display presentation 1304 to one or more client devices 1308. In some scenarios, application server system 502 may also store a selected subset of contextualized data 1312 in a historian device 1306 that is integrated with or communicatively connected to application server system 502.

[0125] The data presentation 1304 shows that contextualized data from BIDT can be presented in a format that largely matches the plant and asset hierarchy defined in Asset Model 422. Figure 13 In the example depicted, application server system 502 is described as receiving logical model 1302, along with BIDT data and metadata, from a single gateway device 402, which receives and contextualizes BIDT data from multiple industrial devices 302a-302c. Figure 14As shown, in some embodiments, the application server system 502 can be configured to collect logical model 1302, along with BIDT data and metadata, from multiple gateway devices (e.g., gateway devices 402a-402c) and integrate logical model 1302 into a common factory model 522. In an example embodiment, gateway devices 402a-402c can reside in different areas of a given factory facility, and the application server system 502 can be a provisioned device or a cloud-based system that receives defined asset models 1406a-1406c and data and metadata from BIDT defined on each gateway device 402a-402c from the respective gateway devices 402a-402c. In another example implementation, gateway devices 402a-402c can reside in geographically disparate industrial facilities, where geographically disparate industrial facility factories and / or office networks are linked to a cloud platform on which the application server system 502 executes.

[0126] Gateway devices 402a-402c, as described in the previous examples, are located from the corresponding industrial devices ( Figure 14 (Not shown) Collects BIDT data 1408a-1408c. Each of the gateway devices 402a-402c, as discussed above, has one or more asset models 1406a-1406b. Application server system 502 retrieves asset models 1406a-1406c from the corresponding gateway devices 402a-402c, and the factory model component 506 of application server system 502 integrates asset models 1406a-1406c into aggregate factory model 522, which serves as the basis for formatting and presenting BIDT data via data presentation 1402.

[0127] Figure 15 This is an example factory model 522 generated by application server system 502 by integrating multiple asset models received from corresponding gateway devices 402. In this example, gateway interface component 504 of application server system 502 has discovered two new asset models 1502 and 1504 residing on two corresponding gateway devices 402, and has integrated models 1502 and 1504 into the larger factory model 522. Asset model 1502 corresponds to an asset group named group 01, which resides at the factory facility indicated by factory node 1506 (client site 1). Therefore, factory model component 506 of application server system 502 has inserted asset model 1502 under the appropriate asset group node 1508 (group 01) under factory node 1506. Plant model component 506 can determine the appropriate location within plant model 522 to connect asset model 1502 based on user-defined contextual information associated with asset model 1502 (e.g., a clear definition of the production area and plant facility where the asset represented by asset model 1502 resides). Figure 15 As shown, asset model 1502 defines the main device (asset 01) and several slave devices (asset 0101, asset 0102) that constitute the asset.

[0128] Asset model 1504 represents a second asset located in the same plant facility, customer site, and production line (line 02). Therefore, asset model 1504 is inserted under the same plant node 1506 and production line node (line 02).

[0129] Figure 16 This is a screenshot of a sample data presentation 1604 generated by the presentation component 508 of the application server system 502 based on the aggregated factory model 522. The sample data presentation 1604 includes a navigation menu 1602 with a hierarchical structure conforming to the hierarchical structure of the factory model 522. For example, the navigation menu includes a hierarchical tree structure with nodes representing one or more factory facilities as defined in the factory model 522 and associated production areas, production lines, industrial assets, and / or industrial units. Selection of any node in the navigation menu invokes the corresponding data presentation on the data display area 1608 of the data presentation 1604. The data display area 1608 presents a selected subset of BIDT data formatted according to a predefined set of visualizations, widgets, or graphical widgets, corresponding to the selected node (e.g., a node corresponding to a production area or production line, industrial asset, industrial unit, etc.). The visualization or widget (e.g., widget 524) may be stored on the application server system 502 and selectively invoked by the presentation component 508 in response to selection of a node from the navigation menu 1602.

[0130] In some implementations, the presentation component 508 of the application server system 505 may support different graphical widgets corresponding to the respective BIDT types. For example, an odometer widget may be defined to display data from an odometer BIDT (e.g., an integer value display widget). Thus, when a user selects a node from the navigation menu corresponding to an industrial unit, industrial asset, production line, or plant with one or more associated odometer BIDT data tags (as defined in asset model 422), the presentation component 508 may invoke the odometer widget to display the corresponding odometer data on the data display area 1608. Other BIDT data types may also be associated with one or more corresponding graphical widgets that can be invoked by the presentation component 208 to display these BIDT data items. Example graphical widgets that the application server system 502 may support for presenting BIDT data may include, but are not limited to, displays of integer or real values ​​for industrial assets, status or event text displays, bar charts, line charts, animated state machine graphics, animated graphical representations of industrial assets whose visual state depends on the current state, event, or value reported by the BIDT data tags, or other such widgets.

[0131] In some implementations, presentation component 508 can automatically design the data presentation to be displayed in data display area 1608 based on the type of industrial asset being viewed and the associated BIDT data type. For example, if a user selects a node corresponding to an industrial machine with associated odometer, status, rate, and event BIDTs (such as those defined by the plant model 522 to which the industrial machine belongs), presentation component 508 can invoke and arrange a set of graphical presentation widgets to present the associated BIDT data and any appropriate auxiliary data. In an example implementation, presentation component 508 can invoke an appropriate number of BIDT-specific widgets for presenting status, rate, odometer, and event data and organize these widgets into an appropriate presentation, wherein each widget or data item is appropriately labeled. Presentation component 508 can determine an appropriate label for each data item based on one or both of the asset model definition (e.g., the name of the corresponding node assigned to asset model 422) or BIDT metadata (e.g., event or status name, BIDT data label name, etc.).

[0132] The presentation unit 508 can also generate and display auxiliary data based on the BIDT data. For example, when a node with an associated rate BIDT is selected in the navigation menu 1602, the presentation unit 508 can display the current rate value using appropriate graphical widgets and a time-based trend graph showing the rate BIDT value over time. Similarly, when presenting an event BIDT, the presentation unit can present a list of timestamps for the current event specified by the event BIDT and the most recent event associated with the event BIDT. To populate such auxiliary data display, the application system server can store historical contextualized data 1312 from the BIDT in the history recorder device 1306 during operation (see...). Figure 13 The historical recorder device 1306 can be an integrated storage area of ​​the application server system 502 or a separate historical data storage device. To populate the graphical trend or event records, the presentation component 508 can utilize the stored history (e.g., timestamped events generated by the Event BIDT, historical trend data from the Rate BIDT, etc.).

[0133] In some implementations, application server system 502 may allow users to customize data presentation for any optional node presented in navigation menu 1602. For example, presentation component 508 may be configured to dynamically design and generate default presentations for a given node (e.g., industrial asset) based on the type and number of BIDTs associated with that node. This may include selecting appropriate widgets to display the current value of the BIDT, selecting additional widgets to display supplementary information about the BIDT (e.g., historical trends, event logs, etc.), and orienting these widgets on the data display area 1608. Presentation component 508 may also allow users to modify or enhance these dynamically generated default presentations by moving selected widgets to preferred positions, adding or removing graphical widgets, relabeling data items, etc. These modified presentations can then be saved so that presentation component 508 will re-present these customized presentations whenever a node is selected.

[0134] The format of the presentation generated by presentation component 508 will depend on the invoked asset and / or factory models. In some implementations, different asset models 422 and / or factory models 522 may be associated with different user roles. For example, production asset models (e.g., Figure 11 The production model (1102) can be defined for use by plant operators, while the design asset model (e.g., Figure 12 The design model 1202 can be defined for a plant engineer or OEM. When a user accesses the application server system 502 to invoke a view of the system, asset and / or plant models associated with the user can be invoked, and the presentation component 508 can construct a data presentation based on user- or role-specific models. In an example implementation, the appropriate asset model can be determined based on the user's login credentials. For example, after the user provides a user identifier and any security credentials (e.g., password, biometric information, etc.), the user's identity can be cross-referenced with a role database maintained on the application server system, and asset and / or plant models associated with that user role (e.g., operator, engineer, plant manager, OEM, etc.) can be invoked and used as the basis for data visualization.

[0135] It should be recognized that, Figure 16 The example visualizations depicted are merely exemplary, and any suitable graphical arrangement and presentation of the data are within the scope of one or more embodiments of this disclosure.

[0136] Furthermore, despite the above combination Figures 14 to 16 The described example depicts the graphical representation as generated and transmitted by the application server system 502, but some implementations of the gateway device 402 can also be configured to generate graphical representations of BIDT data based on its stored asset model 422 (using the presentation component 412).

[0137] In addition to allowing the creation of different asset models 422 that conform to the appropriate presentation of BIDT data for different types of viewers (e.g., operators, OEMs, engineers, etc.), some implementations may also allow different asset models 422 to be defined on a given gateway device 402 according to the corresponding different destination platforms. Figure 17 It is a diagram depicting a gateway device 402 on which a first asset model 422a for transmitting data to a cloud-based application server system 502 and a second asset model 422b for presenting BIDT data to a local pre-installed client device 1702 are defined.

[0138] In this example, asset models 422a and 422b are both used to group and contextualize data from BIDT 322a-322c defined on industrial units 302a-302c. Asset model 422a is configured to be transmitted to a cloud-based application server system 502a, which runs on a cloud platform 1704 having a remote communication channel to gateway unit 402. The cloud-based application server system 502a performs functions similar to those of the application server system described above; for example, it receives asset model 422a along with associated BIDT data and metadata from gateway unit 402, integrates asset model 422a into a larger plant or enterprise model (which may include asset models from multiple geographically different gateway units 402), and presents data conforming to the aggregated plant model 1706 to an authorized remote client unit 1702 with access to the cloud system server.

[0139] Asset model 422b is configured to be transmitted to local device 1708 (e.g., a local client device having an integrated application server system for generating BIDT data rendering, or a local server device performing an application server system that provides BIDT data rendering to multiple client devices). Each model 422a and 422b may have associated destination metadata that defines the application server system to which the model is exposed (which may include one or both remote and local systems). Gateway device 402 will expose and / or transmit each model 422a and 422b to the application server system defined by the metadata (e.g., application server system 502a or 502b).

[0140] Figure 18This diagram illustrates an example network architecture including industrial device 302, gateway device 402, and cloud-based application server system 502. In this example, industrial device 302 is an industrial controller, each executing control program 1814, with several BIDTs 322 configured on each controller. Industrial device 302 is connected to a factory network 116 (e.g., a generic industrial protocol network, Ethernet / IP network, etc.) that facilitates data exchange between industrial devices on a factory floor. Factory network 116 can be wired or wireless. In the example shown, gateway device 402 resides on a separate office network 108 connected to factory network 116 (e.g., via router 1816 or other network infrastructure device). However, in other implementations, gateway device 402 may also be installed directly on factory network 116, or connected to each industrial device 302 via separate wired or wireless connections.

[0141] As described in the previous examples, gateway device 402 may be configured with one or more asset models 422 that define the grouping of BIDT 322 within a user-defined hierarchical representation of a plant, production area, and / or industrial asset. The BIDT publishing component 310 of industrial device 302 exposes BIDT 322 to gateway device 402 via communication channels traversing plant network 116 and office network 108 (i.e., BIDT publishing component 310 enables BIDT 322 to be communicatively accessed by the discovery component 406 of gateway device 402).

[0142] In this example, application server system 502 is a cloud-based system residing on cloud platform 1806 and executing as a cloud-based service accessible by authorized remote client device 1804 and gateway device 402. Cloud platform 1806 can be any infrastructure that allows shared computing services to be accessed and utilized by cloud-enabled devices. Cloud platform 1806 can be a public cloud accessible via the Internet by device 1804 with an Internet connection and appropriate authorization to utilize application server system 502. In some scenarios, cloud platform 1806 can be configured as a Platform as a Service (PaaS) by a cloud provider, and application server system 502 can reside on and execute on cloud platform 1806 as a cloud-based service. In some such configurations, access to cloud platform 1806 and the associated application server system 502 can be offered to customers as a subscription service by the owner of application server system 502. Alternatively, cloud platform 1906 can be a private cloud operated internally by an industrial enterprise (owner of a factory facility). An example private cloud platform may include a hosted application server system 502 and a set of servers residing on a corporate network protected by a firewall.

[0143] If the cloud platform 1806 is a web-based cloud, the application server interface component 410 of the gateway device 402 can interact with the application server system 502 via a secure internet connection. In some embodiments, the gateway device may also be implemented as an integrated component of a network infrastructure device, such as a network switch, router, or hub. In such embodiments, the network infrastructure device performs the network connectivity functions of a network switch, hub, or router, as well as the functions of the gateway device 402 as described above.

[0144] In one or more embodiments in which the application server system 502 is executed on the cloud platform 1806, the communication channel between the application server system 502 and the gateway device 402 on the cloud platform 1806 can be managed through a gateway device registry executed on the cloud platform. Figure 19 This is a block diagram of an example architecture for managing proxy communication with a customer's cloud platform 1806 using a gateway device registry. In this example, a provisioned gateway device registry 1904 resides in the same cloud space as the customer's cloud platform 1806, but on a separate registry cloud. The registry cloud and gateway device registry 1904 can be managed by a service provider that will offer the customer's cloud platform as a PaaS (Platform as a Service). Gateway device registry 1904 can enforce secure access to the customer's cloud platform 1806 and ensure that only authenticated devices and users access the customer's collected data in cloud platform 1806. When a new customer cloud platform is established as part of a PaaS agreement, the new customer cloud platform can be subscribed to gateway device registry 1904, allowing communication with the gateway device of the new cloud platform to be regulated through the registry.

[0145] Gateway device 402 may be one of several gateway devices 402 distributed throughout the customer's industrial enterprise. Figure 19In the example shown, gateway device 402 is identified as gateway device 1 to distinguish it from other pre-built gateway devices. Gateway device 402 may have a physical address (e.g., a MAC address or other physical address) that uniquely identifies it. Gateway device registry 1904 stores a record of gateway device 402 associated with a physical address (99-03-71-4B-LO-F 1 in this example), logically linking gateway device 1 and the physical hardware platform on which gateway device 402 operates. This association between the physical addresses of the hardware platforms of gateway device 1 and gateway device 402 can be entered into gateway device registry 1904 by system manager 1902 at a support facility associated with a cloud service provider. System manager 1902 can also enter other configuration parameters that will be used by gateway device registry 1904 to manage secure connections to customer cloud platform 1806. Configuration information for managing the connectivity of gateway devices to cloud platform 1806 can be maintained in registry storage device 1906 on registry cloud.

[0146] When gateway device 402 has BIDT data available for transmission to application server system 502, application server interface component 410 of gateway device 402 can send a request to gateway device registry 1904 to grant permission for a cloud connector port to be used as a communication channel between gateway device 402 and cloud platform 1806. The request may include, for example, the identifier of gateway device 1, the physical address of gateway device 402, and the identifier of the specific customer-specific cloud platform 1806 with which the connection is requested. Gateway device registry 1904 will grant or deny a certificate for establishing a channel to gateway device 402 based on the information provided in the request. For example, gateway device registry 1904 may reference registry storage device 1906 to verify that the physical address of gateway device 402 from which the request is received is associated with the specific gateway device (gateway device 1) requesting the channel. By verifying that a connection request for gateway device 1 has been received from a previously registered gateway device 404, gateway device registry ensures that gateway device 1 cannot be used to establish a connection with cloud platform 1806 if gateway device 1 is improperly moved or if the gateway device installation is copied to another physical hardware platform. If the gateway device configuration is moved from gateway device 402 to a different computing device without registering the new device in the gateway device registry 1904, the registry will reject any communication requests originating from the new device on behalf of gateway device 402.

[0147] When the gateway device registry 1904 determines that the connection request is valid (based on the information received in the request and the previous registration information for gateway device 1 in registry storage device 1906), the gateway device registry 1904 grants gateway device 402 a certificate allowing the gateway device to open a temporary communication channel to customer cloud platform 1806. Therefore, the cloud application programming interface (API) managed by the application server interface component 410 of gateway device 402 establishes a communication channel to cloud platform 1806 and sends BIDT data and associated metadata to application server system 502 on cloud platform 1806 as described above in the previous example. In some implementations, the cloud API assigns an expiration time to the communication channel when the channel is created. The expiration time can be defined by the service provider via cloud device registry 1904 or by the end user via user interface component 414 on the client. Typically, the expiration time will be set to exceed the expected duration required to send BIDT data and metadata. If gateway device 402 has completed the transmission of BIDT data to the cloud platform before the channel's expiration time has elapsed, the channel can be automatically closed upon completion of the data transmission or when the expiration time has elapsed. If the gateway device 402 has not completed the transfer of BIDT data and metadata to the cloud platform by the expiration time, the gateway device 402 may request the reactivation of the channel in the gateway device registry 1904 to allow additional signal exchange to complete the data transfer.

[0148] The above combination Figure 19 The example sequences described for ensuring access to and secure communication with the cloud platform 1806 via an authorized registration gateway device are merely exemplary, and it should be understood that any suitable protocol or architecture used to establish secure communication and BIDT data transmission between the gateway device 402 and the cloud-based application server system 502 is within the scope of one or more embodiments of this disclosure.

[0149] The basic information data types and associated services described in this document can be used to simplify the creation of customized industrial data visualizations using a concise, adaptable, and scalable architecture. A given industrial asset, asset set, or industrial application can be described according to a customized BIDT at the controller level. Asset models of industrial assets can be created by user-defined groupings of these BIDTs, where multiple different asset models can be defined for different user roles or views. These asset models, along with the data and metadata associated with the BIDT, are used to generate graphical representations of the asset data constructed based on the models. Application server systems can use appropriate graphical widgets or other graphical elements to represent the BIDT data on these representations. These appropriate graphical widgets or other graphical elements can include widgets specific to a given type of BIDT (e.g., status, rate, odometer, event, etc.). When an industrial asset is added, removed, or modified, the associated asset model can be reconfigured to add, remove, modify, or reposition nodes, and the data representation will be updated accordingly. Maintaining the gateway device's ability to discover the BIDT allows for easy integration of newly added BIDTs instantiated on industrial controllers or other industrial devices into the asset model and associated graphical data representation.

[0150] Figures 20 to 22 Various methods according to one or more embodiments of this application are illustrated. Although for the purpose of simplicity, one or more methods illustrated herein are shown and described as a series of actions, it should be understood and recognized that the invention is not limited to the order of actions, as some actions may occur and / or simultaneously in a different order than other actions shown and described herein. For example, those skilled in the art will understand and recognize that a method may alternatively be represented as, for example, a series of interrelated states or events in a state diagram. Furthermore, not all actions shown are required to implement the method according to the invention. Additionally, an interaction diagram may represent a method or manner according to this disclosure when different entities demonstrate different parts of the method. Moreover, two or more of the disclosed example methods may be implemented in combination with each other to achieve one or more features or advantages described herein.

[0151] Figure 20An example method 2000 for configuring and utilizing BIDT data tags in an industrial controller to transmit industrial data to a visualization system is illustrated. Initially, at 2002, one or more data tags are defined on the industrial device, wherein the data tags conform to one or more Basic Information Data Types (BIDTs), and the BIDTs include at least one of Rate BIDT, Status BIDT, Odometer BIDT, or Event BIDT. A Rate BIDT data tag can represent an integer or real value of the measured rate of a metric associated with an industrial asset or device. A Status BIDT data tag can represent the current state of an industrial asset or device (e.g., a machine, production line, motor drive, etc.). An Odometer BIDT data tag can represent a cumulative quantity associated with the industrial asset (e.g., the cumulative number of flip values, or a quantity within a defined time interval). An Event BIDT data type can represent a momentary or continuous event associated with the industrial asset (e.g., a button event, sensor event, safety device event, and alarm event, etc.).

[0152] At step 2004, metadata is configured for the corresponding BIDT tag defined in step 2002. The metadata includes user-defined parameters for the corresponding BIDT data tag, where the user-defined parameters are specific to the type of each BIDT data tag. For example, user-configurable metadata associated with a rate BIDT data tag may include, but is not limited to: definitions of the maximum and minimum values ​​of the corresponding rate values, the identity of one or more other data tags or input addresses whose values ​​are aggregated (e.g., summed, averaged, integrated, etc.) to produce the rate value, the unit of measurement associated with the rate value, or other such metadata. Metadata for a status BIDT data tag may include, but is not limited to: a definition of the available status of the industrial asset to which the data tag is assigned, the identity of one or more other data tags whose values ​​determine the status, or other such metadata. Metadata associated with an odometer BIDT may include, but is not limited to: the identity of one or more data tags driving the odometer value, the identity of two or more data tags whose values ​​are to be aggregated or summed to produce the odometer value, the unit of measurement associated with the odometer value (e.g., product count, megawatt-hours consumed, etc.), or other such metadata. The metadata associated with an event BIDT data tag may include, but is not limited to: the device input address or other data tag identity that determines the event to be represented by the event BIDT data tag, the name of the event represented by the event BIDT data tag, or other such metadata.

[0153] In 2006, BIDT data tags were exposed to gateway devices networked to industrial controllers. These gateway devices stored asset models referencing the BIDT data tags, and the asset models defined the hierarchical grouping of the BIDT data tags. The asset models defined on the gateway devices could correspond to application data that could be used to generate customized graphical representations of asset data, or the desired hierarchical organization of industrial assets. In 2008, data associated with the BIDT data tags, along with metadata defined for the BIDT data tags, was sent to the gateway devices, where the data and metadata were used to generate graphical representations of the BIDT data based on the asset models.

[0154] Figure 21 An example method 2100 for discovering BIDT data tags and retrieving data from BIDT data tags based on an asset model is illustrated. Initially, at 2102, an asset model is defined on a gateway device, wherein the asset model defines a hierarchical grouping of BIDT data tags defined on one or more industrial units. The asset model may define a hierarchical arrangement of plant elements (e.g., plant facilities, production areas or lines, industrial assets, industrial equipment or devices constituting industrial assets, etc.) and may map selected BIDT data tags to corresponding elements in the hierarchy.

[0155] At 2104, the BIDT tags referenced by the asset model defined in step 2102 are discovered on one or more industrial units via a gateway device. This may involve discovering the BIDT data tags via a network (e.g., wired and / or wireless factory networks, public networks such as the Internet, etc.). At 2106, data from the BIDT data tags, along with metadata associated with the BIDT data tags, is retrieved from one or more industrial units via the gateway device. At 2108, a graphical representation of the data retrieved in step 2106 is generated based on the asset model and BIDT metadata. In some embodiments, the presentation may include a browsable navigation menu with a hierarchical structure similar to the hierarchical structure defined by the asset model, where elements (e.g., production lines, assets, equipment items, industrial units, etc.) are selected from the hierarchical navigation menu and one or more graphical widgets or other graphical elements are arranged to display the BIDT data associated with the selected element.

[0156] Figure 22 An example method 2200 is shown for aggregating asset models and using the aggregated models to generate a graphical representation of industrial data. Initially, at 2202, multiple asset models representing corresponding industrial assets or groups of assets are received from one or more gateway devices. As in the previous example, the asset models define groupings of BIDT data tags within a hierarchical organization of plant elements.

[0157] At 2204, the asset models are integrated (e.g., at the application server system) to generate a plant model, the definition of which includes a hierarchical plant or enterprise structure of multiple industrial assets. At 2206, industrial data and associated metadata are retrieved from BIDT tags defined on one or more industrial units, wherein the BIDT tags from which the data is retrieved are referenced by the asset models constituting the plant model. In some embodiments, BIDT data and metadata may be received from a gateway device that receives the asset models from which they are received. At 2208, a graphical representation of the data retrieved in step 2206 is generated based on the plant model and metadata. The graphical representation can organize the data according to the hierarchical structure defined by the plant model.

[0158] The asset model 422 and plant model 522 described above represent the static and dynamic attributes of industrial assets, defined according to groupings of BIDT 322 within the user-defined hierarchical representation of the asset. The asset model 422 for a given industrial asset can define a hierarchical arrangement of sub-assets constituting the defined asset and identify BIDT tags corresponding to the static and / or dynamic attributes of each sub-assets. For example, a depositor may include an inlet, a hopper, and a piston. Therefore, the asset model 422 representing the depositor can define the inlet, hopper, and piston as sub-assets or sub-nodes of a larger industrial asset. The asset model 422 can also identify BIDT tags defined on one or more industrial units corresponding to the dynamic or static attributes of each sub-assets. For example, the inlet of the depositor may have an associated speed rate obtained from a BIDT named Depositor.Inlet.Speed_Rate (speed BIDT). An entry point can also have an execution state and a production state obtained from the corresponding BIDTs named Depositor.Inlet.Execution_State and Depositor.Inlet.Production_State. The entry point's batch event value can be obtained from the BIDT named Depositor.Inlet.Batch_Event.

[0159] The asset model 422 for the molding machine asset can define the hierarchical automation organization of these sub-assets and their associated BIDT 322. The hierarchical automation organization can include as many hierarchical levels as needed to describe the industrial asset. For example, a sub-asset can also have its own sub-assets, which are defined as child nodes of the sub-assets in the asset model 422. Furthermore, the plant model 522, which includes the set of asset models 422, can cover the entire production line or a collection of production lines (e.g., ...). Figure 11 and Figure 12 In the example depicted, the asset node and its associated child nodes are defined as child nodes of the production line node to which the asset belongs.

[0160] By defining the organization of industrial assets and their sub-assets, and linking the static and dynamic attributes of the assets to their corresponding BIDTs, asset model 422 and plant model 522 can be used as automated models of industrial machines, assets, production areas, or plants. In one or more embodiments, using BIDTs to define asset model 422 also allows for easy integration of asset model 422 with non-automated models of industrial assets using common BIDT nomenclature. Linking the attributes of asset (automation) model 422 to corresponding attributes of non-automation models (e.g., mechanical models, business models, thermal models, or other types of non-automation models) can produce composite models of industrial assets that can be used for a variety of purposes, including but not limited to overall real-time or historical visualization of asset information, predictive analytics, simulation, training, software validation, or other such uses.

[0161] Figure 23 This diagram illustrates the integration of an asset model 422 of industrial asset 2302 with a mechanical model 2304 (a non-automated model) of industrial asset 2302 to produce a digital twin 2306 of asset 2302. While the examples described herein depict the creation of a digital twin by linking the asset (automated) model 422 with the mechanical model, it should be recognized that the techniques described herein can also be used to link automated models with other types of non-automated models, including but not limited to thermal models defining the thermal characteristics of the components constituting the industrial asset, business or financial models defining financial information associated with the operation of the asset (e.g., material or energy costs based on operating characteristics or operating time, product output associated with profits, etc.), or another type of model defining the non-automated characteristics of the asset.

[0162] As described above, asset model 422 can define the hierarchical arrangement or organization of the machines and / or industrial installations constituting industrial asset 2302, as well as the device-level BIDT corresponding to monitored values, events, states, rates, or other dynamic attributes associated with various machines and installations. Asset model 422 can contextualize monitored telemetry values ​​(e.g., temperature, pressure, speed, torque, etc.), machine and installation states, control events, product counts, energy consumption, and other dynamic control and operational attributes. Therefore, asset model 422 can be viewed as an automated model that describes the static and dynamic attributes of industrial asset 2302 as contextualized and organized BIDT data.

[0163] Mechanical model 2304 defines the mechanical properties of industrial asset 2302. Example mechanical model 2304 for industrial asset 2302 may define: the gear ratio and / or gear diameter of the gearbox used in industrial asset 2302, the type and size of the actuator used in industrial asset 2302, the inertia and coefficient of friction of the mechanical parts or surfaces of industrial asset 2302, the relative position or orientation of the mechanical parts, or other such mechanical properties. Mechanical model 2304 may also define mechanical formulas representing mechanical transformations applied by the parts of the industrial asset (e.g., formulas representing torque, speed, or force transformations across industrial asset 2302).

[0164] If the automation model (implemented by asset model 422) can be linked to the machinery model 2304, allowing contextualized data to be shared between the two models, the resulting composite model can be used as a digital twin 2306 of industrial asset 2302. When provided with real-time or historical BIDT data generated by the industrial asset 2302 being modeled, the digital twin 2306 describes the real-time or historical behavior of industrial asset 2302 as a whole. Figure 24 This diagram illustrates the integration of an asset (automation) model 422 based on industrial asset 2302 with a mechanical model 2304 to generate supplementary asset behavior data 2402. Asset model 422 can contextualize measured control data 2404 read from industrial installations (e.g., sensors, telemetry devices, controllers, drives, etc.) during the control and operation of industrial asset 2302. This data can be obtained from a BIDT configured on the industrial installation, as described in previous examples. Measured asset data may include the position of machine parts or articles of manufacture, speeds (e.g., speeds of conveyors or other motor-driven assets, robot operating speeds, etc.), flow rates, pressures, currents, indicators of part or human presence, or other such measurements. By linking some of these control domain values ​​to mechanical model 2304, additional calculated data 2402 for industrial asset 2302 can be generated by applying mechanical properties and formulas defined by mechanical model 2304 to the measured control domain data.

[0165] In the example scenario, industrial asset 2302 may include a conveyor that transfers parts between two workstations. Measured control data 2404 may include torque, acceleration, and speed values ​​(read from the motor drive) of the motor driving the conveyor. These control values ​​(contextualized by asset model 422) may be combined with mechanical model attributes (e.g., the conveyor's coefficient of friction, roller diameter, or inertia) to calculate additional data 2402 (e.g., forces acting on the product being conveyed, the product's velocity or displacement over a defined time period, product hysteresis, or other such information). Because many mechanical attributes defined in mechanical model 2304 are transformative (e.g., ratios or mechanical coefficients present in asset gears, cranks, surfaces, etc.), these mechanical attributes, along with the associated mechanical formulas defined by mechanical model 2304, can be applied to the contextualized measured automated values ​​(e.g., torque, motor speed, pressure, etc.) provided by asset model 422 to calculate the force, velocity, position, or other dynamic attributes of the machine parts or articles of the industrial asset. Therefore, the combined asset model 422 and mechanical model 2304 can be used to generate a more holistic and comprehensive representation of industrial asset 2302, thereby describing the static control and mechanical properties of the asset as well as the dynamic asset and product behavior based on measurement and contextualized automated data calculations.

[0166] For a given industrial asset 2304 for which both automation and mechanical models have been developed, there may be thousands of potential connection points between the automation and mechanical models; that is, connections between the contextualized automation values ​​provided by asset model 422 and the points in mechanical model 2304 to which these values ​​are applied in the mechanical domain. For example, to calculate how torque applied by a motor translates into speed or force applied to a product relying on a motor-driven conveyor, a connection must be defined between the relevant measured torque value in asset model 422 and the location in the mechanical domain where the torque is applied (a point defined in mechanical model 2304). Typically, even if both automation and mechanical models exist for a given industrial asset, these links between the properties of the automation model and the mechanical model must be defined manually, which can be a time-consuming, laborious, and error-prone process. The complexity of integrating automation and mechanical models is even greater when the automation and mechanical models are developed by two different engineering entities using different protocols and naming conventions for the respective models.

[0167] BIDT-based model development can alleviate the problems associated with interconnecting automation and mechanical models. For example, some implementations of model configuration component 408 may allow the development of asset model 422 and mechanical model 2304 using a common development platform and a common BIDT-based nomenclature. Figure 25This diagram illustrates the parallel development of asset model 422 and mechanical model 2304 for an industrial asset. In the example shown, model configuration application 2502 executes on client device 2504 (e.g., laptop computer, desktop computer, tablet computer, etc.). In some implementations, gateway configuration application 1006 can be used as model configuration application 2502 (e.g., for an implementation where gateway configuration application 1006 supports the definition of mechanical models of the asset in addition to asset model 422). Model configuration application 2502 can also be an integrated tool for device configuration application 708 for programming and configuring industrial device 302. In other implementations, model configuration application 2502 can be another type of industrial design application that supports the parallel development of asset (automation) model 422 and mechanical model 2304 for an industrial asset or a collection of industrial assets.

[0168] Similar to gateway configuration application 1006, model configuration application 2502 can present suitable model configuration interfaces on client device 2504. These model configuration interfaces may include interactive features that guide the user through the process of defining an asset model 422 and a machinery model for a given industrial asset. Also similar to gateway configuration application 1006, the configuration interface generated by model configuration application 2502 may include interactive features that reference BIDT data tags defined for one or more industrial units 302 associated with the industrial asset being modeled. In an implementation where model configuration application 2502 is an integrated tool of device configuration application 708 for defining BIDTs for industrial units, the development interface may allow the user to browse or reference BIDT definitions for configuring one or more industrial units in the tag database 702, and assign BIDTs selected according to the BIDT definitions for inclusion in one or both of asset model 422 and machinery model 2304, similar to the asset model configuration workflow of gateway configuration application 1006 described above.

[0169] In the case of asset model 422, model configuration application 2502 allows users to create nodes representing the following: industrial units, production lines or areas within an industrial facility, industrial assets within each production line (e.g., industrial machines, industrial robots, etc.), equipment units associated with a given industrial asset (e.g., loaders, pushers, processing stations, etc.), and / or industrial units (e.g., controllers, drives, etc.) associated with the industrial asset being modeled. Users can then combine these as described above. Figure 10 The selected BIDT 322 (representing the measured control value, event, status, odometer count, etc.) is assigned to the corresponding node of the asset model 422.

[0170] The same model configuration application 2502 can also be used to develop a mechanical model 2304 for an industrial asset (or group of assets). Model configuration application 2502 allows users to map or link attributes of the mechanical model 2304 (e.g., torque, acceleration, flow rate, current, etc.) to corresponding attributes of the asset model 422 via references to the relevant BIDT 322. In this respect, BIDT represents a common nomenclature shared by the asset model 422 (used as an automation model of the asset) and the mechanical model 2304, allowing easy mapping or linking of industrial asset attributes (measured and contextualized automation values) between the two models. For example, to map torque values ​​from the asset model 422 to corresponding mechanical domain attributes of the mechanical model 2304 (e.g., a representation of the mechanical component to which torque is applied), both the asset model 422 and the mechanical model 2304 can be configured to reference the appropriate BIDT corresponding to the torque values ​​(e.g., ...). Figure 25 (see BIDT 322a in the document). In this way, by means of a common reference to the BIDT representing the attribute (BIDT also see... Figure 25 The BIDT 322b in the model (which is referenced by both asset model 422 and machine model 2304, thereby creating a link between model attributes that reference BIDT 322b) can easily map attributes between asset model 422 and machine model 2304. This allows asset (automation) model 422 and machine model 2304 to understand each other based on their mutual references to the BIDT.

[0171] The parallel development of asset model 422 and machine model 2304 using model configuration application 2502 allows the two models to share a common organization and defined attribute structure. A BIDT-based type system shared by asset model 422 and machine model 2304 creates attribute mappings between the two models, allowing the application of mechanical formulas or transformations defined by machine model 2304 to contextualized automated data for measurements to generate additional real-time or historical behavioral or response data for the industrial asset (including, but not limited to, force, position, orientation, shape, or temperature of mechanical components). The combined asset model 422 and machine model 2304—with attributes linked via common BIDT references—can serve as a mechatronic model or digital twin 2306 of the industrial asset, generating more comprehensive information about the industrial asset than either model alone could produce. Typically, digital twin 2306 comprises multiple different models (asset model 422 and machine model 2304) of the industrial asset interacting to simulate its behavior.

[0172] This combined model representing the virtualization of industrial assets can be used in a variety of applications. For example, the Digital Twin 2306 can be used to: drive virtual simulations of assets in conjunction with testing control software to be deployed in an industrial environment; serve as a training tool to simulate the asset's response to human interaction; predict future asset behavior or replay past asset behavior based on analysis of historical automation data; perform real-time or historical operational analysis; or other such applications. Depending on the type of application performed by the Digital Twin 2306, the Digital Twin 2306 can be fed live (real-time) data from the BIDT during industrial asset operation, or it can be fed historical time-series BIDT data generated and stored during previous operations of the asset.

[0173] Figure 26 This is a diagram of an example architecture for generating playback simulations of past industrial asset operations using interconnected asset models 422 and machinery models 2304. In this example, it is assumed that the behavior playback functionality is implemented on an application server system 502, on which asset models 422 and machinery models 2304, storing one or more industrial assets. However, in some implementations, the playback functionality described below can be implemented on other types of host devices or platforms, including but not limited to gateway devices (e.g., gateway device 402), provisioned server devices, cloud-based systems, or other such platforms.

[0174] As described in the previous example, an industrial device 302 deployed at a factory facility is programmed to monitor and / or control one or more industrial assets 1310 (e.g., machines, production lines, workstations, robot-based systems, etc.). The device configuration of the corresponding industrial device 302 includes a BIDT definition, which defines a BIDT 322 for storing and contextualizing data measured or generated by the industrial device 302.

[0175] During the operation of the industrial asset, industrial unit 302 monitors and controls its corresponding industrial asset 1310, and BIDT 322 stores data values, statuses, events, or other attributes measured and / or generated by industrial unit 302. In this example, contextualized BIDT data 2608 is read from BIDT 322 and stored in historical data storage device 2606 as time-series historical data. Any suitable architecture can be used to transfer contextualized data 2608 to historical data storage device 2606. For example, as in Figure 13 In the example architecture described, a pre-built or cloud-based gateway device 402 ( Figure 26(Not shown) is networked to the corresponding industrial device 302, and the BIDT publishing component 310 of each industrial device 302 can expose data and metadata associated with each configured BIDT 322 to the gateway device 402, thereby enabling the BIDT data and metadata to be accessed and retrieved by the discovery component 406. The gateway device 402 can periodically or on an event-driven basis retrieve contextual data 2608 and record contextual data 2608 in the historical data storage device 2606. In some embodiments, the industrial device 302 can be combined with the following Figures 31 to 35 A more detailed description of the synchronous, interconnected data logging scheme for recording its corresponding BIDT data values ​​is provided. Historical data storage device 2606 may include a cloud-based data storage device or may reside on a factory facility. Other architectures are also within the scope of one or more implementations.

[0176] The BIDT data recorded to the historical data storage device 2606 is recorded along with a timestamp, enabling data values ​​from different devices and systems to be synchronized for collective analysis and playback. As will be described in more detail below, some embodiments of the industrial device 302 may include programming features that allow users to configure links between selected BIDTs whose data must be accurately synchronized for analysis or playback purposes.

[0177] Historical data can be further contextualized through linked asset model 422 and machinery model 2304 (which together serve as a digital twin 2306 of industrial asset 1310). As described above, each model 422 and 2304 is configured to reference selected historical BIDT data representing the historical operations of industrial asset 1310 (e.g., speed, torque, location, positioning, pressure, flow rate, voltage, etc.). Similar to the above combination... Figure 13The described system, application server system 502, has a presentation component 508 configured to provide data display presentations 2610 to authorized client devices that interface with system 502. These presentations 2610 are generated based on historical BIDT data contextualized by digital twin 2306 and can conform to virtually any presentation format. For example, presentation 2610 may include an animated graphical representation of an industrial asset presented on a client device, wherein the animation of the components of the industrial asset presentation is controlled by its corresponding time-series BIDT values, states, events, etc., read from historical data storage device 2606. Presentation 2610 may also overlay alphanumeric data display on the industrial asset representation representing contextualized BIDT data values ​​(e.g., temperature, operating mode, etc.). In another example format, presentation 2610 may include a 3D VR presentation transmitted to a suitable virtual reality (VR) client device (e.g., a VR headset or other type of wearable computer), the VR client device presenting a virtual representation of industrial asset 1310 based on digital twin 2306, wherein the VR presentation of the industrial asset is animated based on time-series historical BIDT data.

[0178] Since the contextualized BIDT data 2608 is timestamped and synchronized when stored in the historical data storage device 2606, a time-series subset of this historical data can be selected by the presentation component 508 and presented as a successive time-series animation of the virtual industrial asset. In this way, the presentation component 508 can utilize the digital twin 2306 and the historical data via presentation 2610 to generate a virtual “replay” of past operations of the industrial asset. In an example implementation, the presentation component 508 can present a playback control on a client device (e.g., a wearable computer or another type of client device) that allows the user to generate playback instructions 2602 and send them to system 502. For example, playback instructions 2602 may include: specifying a past time range to view, selecting the industrial asset to view, instructions to scroll the asset operation playback forward or backward in time, or other such instructions. In response to playback command 2602, presentation component 508 can retrieve a subset of historical BIDT data 2608 corresponding to the selected industrial asset and the selected time range from historical data storage device 2606, and generate an animated virtual playback of the operation of the selected asset based on the retrieved time series data.

[0179] The presentation component 508 can generate a virtualized representation 2610 of the industrial asset based in part on the organization defined by the asset model 422 and the machine model 2304. In an example implementation where the representation 2610 is a VR representation, the presentation component 508 can present a three-dimensional graphical representation of the industrial asset or production area on a client device in part based on the organization of production lines, machines, and / or equipment defined by the asset model 422 and / or the machine model 2304. The presentation component 508 can then animate this representation based on a time-series stream of visualization data 2604 across a user-selected time range, wherein the visualization data 2604 includes a subset of historical BIDT data corresponding to the selected time range and contextualized by the asset model 422. For example, the animation could include animation of the movement of actuators, robots, conveyors, motor-driven machine axes, or other movable parts of the industrial asset based on a relevant subset of historical BIDT data indicating the location of components at the corresponding time instance. Animations may also include other graphical objects animated from relevant subsets of BIDT data, such as temperature or pressure gauges, alphanumeric overlays representing performance metrics or alarms, or other such objects.

[0180] Typically, the virtualized presentation 2610's animation state at a given moment is a function of a set of historical visualization data 2604 corresponding to the same historical moment or timestamp. Streaming visualization data 2604 temporally or in a time-series manner across a selected historical time range of interest allows the virtualized presentation 2610 to recreate the operation of industrial assets across the selected time range as an animation.

[0181] Additionally, the presentation component 508 can utilize the BIDT-based attribute mapping between the asset model 422 and the machinery model 2304 to generate additional time-series machinery information for inclusion in the presentation 2610. Figure 27 This is a diagram illustrating the integration of asset (automation) model 422 based on industrial asset 2302 and machine model 2304 to generate supplementary calculated asset behavior data. Similar to... Figure 24 The example depicted above illustrates how the integration of asset model 422 and mechanical model 2304 via a common reference to a BIDT data source allows application server system 502 (or another visualization or analysis system) to calculate additional asset behavior data 2402 based on measured automated values. Figure 27In the example depicted, automated values ​​(e.g., torque, acceleration, speed, etc.) are obtained as contextualized BIDT data 2608 read from historical data storage device 2606. The calculated asset behavior data 2402 can supplement the automated values ​​already stored in historical data storage device 2606 for reporting, analysis, or visualization applications. The asset behavior data 2402 can be generated as a time-series value with the same time base as the contextualized BIDT data 2608 used to calculate the behavior data 2402.

[0182] In some implementations, after the calculated behavioral data 2402 has been generated, system 502 (or another system utilizing models 422 and 2304) can timestamp the calculated data 2402 and record it in the historical data storage device 2606. Each timestamp identifies the historical moment of the corresponding item that caused the calculation of data 2402 and corresponds to the moment of the contextualized BIDT data value used for the calculation of data 2402. Timestamping the calculated data 2402 in this manner allows system 502 (or other systems) to record the calculated data 2402 in the historical data storage device 2606 with reference to the same time point as the BIDT data value that caused the calculation of data 2402, thereby supplementing the measured automated values ​​with the calculated dynamic asset behavior, attributes, and mechanical status.

[0183] In addition to time-series visualization of the past behavior and operations of flowing industrial assets, some implementations can extend visualization to predicting future behavior of assets based on predictive analytics performed on digital twins and historical data. Return to Figure 26 Some such implementations may include a predictive analytics component 512 configured to generate predicted future values ​​of measured BIDT data 2608 and calculated behavioral data 2402 based on analysis of historical BIDT data 2608. The predictive analytics component 512 may predict future asset behavior based on trends in asset behavior learned from various asset conditions or states identified through mining of historical BIDT data 2608 and the application of digital twin 2306. In such implementations, the playback instruction 2602 may include an instruction to advance the visualization to a future time frame. In response to such an instruction, the presentation component 508 may utilize the predicted behavioral information generated by the predictive analytics component 512 to present an animated visualization of the predicted future asset performance.

[0184] As mentioned above, some example systems can generate virtual reality (VR) presentations based on historical BIDT data and supplementary data based on digital twin 2306 contextualization and / or computation. Figure 28This is a block diagram illustrating an example VR system 2802 that uses a digital twin 2306 to generate a VR presentation replaying past asset behavior. In some implementations, the VR system 2802 may be integrated with an application server system 502 and may reside on a cloud platform or other private or public network with communicative access to the factory network 116. Alternatively, the VR system 2802 may reside on a gateway device (e.g., gateway device 402) or communicatively connect to the factory network 116 and reside on a local server within the factory facility.

[0185] VR system 2802 may include a device interface component 2814 that collects BIDT data 2808 from industrial installations and systems 2816 distributed across industrial environments. In some embodiments, device interface component 2814 may be configured to retrieve selected data items from industrial installations and systems 2816 via network 116 according to asset model 422, which specifies BIDT tags from which data is to be collected. Device interface component 2814 timestamps the collected BIDT data 2808 and stores the collected BIDT data 2808 along with the timestamp on historical data storage device 2606, and presentation component 508 uses the historical time-series data and supplementary mechanical information of the assets calculated using digital twin 2306 to populate and animate VR presentations 2086 of one or more industrial assets using the contextualized historical data. Presentation component 508 transmits these VR presentations to a suitable wearable device 2812 for presentation.

[0186] Wearable device 2812 may interface with VR system 2802 via a wired or wireless network interface, a near-field communication interface, or other such device interfaces suitable for implementing VR system 2802 on a specific platform. In some embodiments, presentation unit 508 may be configured to verify authorization for wearable device 2812 to access VR system 2802 before allowing VR presentation data 2806 to be transmitted to wearable device 2812. Presentation unit 508 may authenticate wearable device or its owner by using password verification, biometric identification (e.g., retinal scan information collected by wearable device 2812 from the user and submitted to presentation unit 508), comparing the identifier of wearable device 2812 against a set of known authorized devices, or other such verification techniques.

[0187] When VR presentation data 2806 is received and executed by wearable device 206, VR presentation data 2806 presents an interactive 3D VR presentation of one or more industrial assets on the display of the wearable device. Presentation component 508 can design the visual layout of the VR presentation based on the asset organization defined by digital twin 2306. For example, based in part on the identified production lines, machines, equipment, and other entities defined by digital twin 2306, and the relationships between these entities also defined by digital twin 2306, presentation component 508 can present 3D graphical VR representations of these entities and animate the presentation using a selected subset of historical BIDT data and supplementary data generated by applying mechanical model 2304 to the BIDT data (e.g., calculated data 2402). In some embodiments, VR system 2805 may also maintain one or more plant models 2818 that define the visual representation of the physical layout of the area represented by the VR presentation. For example, a factory model 2818 for a given industrial area (e.g., production area, work cell, assembly line, etc.) can define a graphical representation of the industrial assets (including machines, conveyors, control cabinets, and / or industrial installations) located within that area, as well as the physical relationships between these industrial assets. For each industrial asset, the factory model 2818 can define the asset's physical dimensions and color, as well as any animations supported by the graphical representation (e.g., color-changing animations, positional animations reflecting the asset's movement, etc.). The factory model 2818 also defines other physical relationships between industrial assets that may not be defined in the asset model 422, including the relative positions and orientations of assets in the factory floor, conduits or pipes extending between assets, and other physical definitions.

[0188] The presentation engine, supported by presentation unit 508, is configured to generate an interactive VR presentation of the industrial area based on the industrial asset presentation definitions specified in digital twin 2306 (and one or more factory models 2818 in the implementation, wherein the implementation uses such models). Presentation unit 508 populates the VR presentation with a selected subset of historical BIDT data 2808 (and additional dynamic statistics, such as calculated data 2402, calculated by presentation unit 508 by applying mechanical model 2304 to BIDT data 2808), and transmits the resulting aggregated VR presentation to wearable device 2812 as VR presentation data 2806. Presentation unit 508 can generate VR presentations such that alphanumeric items of the BIDT data (e.g., speed, pressure, flow rate, voltage, etc.) are overlaid on or near a graphical representation of the industrial asset associated with the data item.

[0189] The presentation component 508 can also control the view presented by the VR presentation based on the interaction input 2804 received from the wearable device 2812. The interaction input 2804 can specify the current viewing direction of the wearer of the wearable device 2812, which is used by the presentation component 508 to control the viewing angle of the VR presentation. In the case of historical playback of asset behavior, the interaction input 2804 can also include control over the time range of the playback and playback instructions for scrolling forward and backward during playback (similar to playback instruction 2602).

[0190] Because the digital twin 2306 models both the automation and mechanical characteristics of industrial assets, it can be used to simulate the expected behavior of industrial assets (e.g., responses to control inputs in the directions of movement, speed, temperature, flow rate, fill level, fluid dynamics, product displacement, etc.) in relation to test control programs or device configurations. Figure 29 This is a general block diagram of a software testing system 2906 that uses a digital twin 2306 to verify a control program 2908. In this example, the controller simulation component 2910 of the software testing system 2906 serves as an industrial controller simulator that executes the control program 2908 against the digital twin 2306.

[0191] Analog component 2912 can utilize the automation and mechanical characteristics modeled by digital twin 2306 to simulate various aspects of a physical industrial system to be monitored and regulated by control program 2908. Analog component 2912 can virtually interface control program 2908 with digital twin 2306 to facilitate the exchange of analog I / O data between program 2908 and digital twin 2306, thereby simulating real-world control. Control program 2908 can include any conceivable type of code for processing input signals read into the controller and controlling output signals from the controller, including but not limited to ladder logic, sequential function charts, function block diagrams, or structured text. Control program 2908 is designed to regulate the automated system being modeled by digital twin 2306. Analog component 2912 generates digital and analog I / O values ​​based on the static and dynamic characteristics of the physical system modeled by digital twin 2306, representing data similar to that expected to be generated by the physical system, such as sensor outputs, metering outputs, or other plant data. The analog output data 2904 is provided to the simulation component 2910 of the execution control program 2908, which receives the data as one or more virtual physical inputs. The control program 2908 processes these inputs according to a user-defined algorithm and generates digital and / or analog controller output data 2902 based on the processing. This output data 2902 represents the physical output (e.g., PID loop control output, solenoid excitation output, motor control output, actuator control output, robot control output, etc.) generated by the controller of the execution control program 2908 and sent to hardwired field devices of the automation system. The controller output data 2902 is provided to the appropriate input points of the digital twin 2306, which updates the analog output data 2904 accordingly.

[0192] In addition to generating simulation output data 2904, simulation component 2912 can also generate asset response data 2918 based on the expected behavior of the modeled industrial asset in response to the simulation controller output data 2902 and the analysis of simulated data exchange. For example, based on the automation and mechanical characteristics of the industrial asset modeled in digital twin 2306, simulation component 2912 can predict the expected behavior of the modeled industrial asset and the behavior of the product being manufactured through the asset in response to controller output data 2902, and transmit this predicted behavior as asset response data 2918. Example behaviors represented by asset response data 2918 may include, but are not limited to: the movement of the product through the industrial asset (including speed, acceleration, position, hysteresis, etc.), the flow rate of fluid through the asset, the expected energy consumption of the asset, the expected degradation rate of the mechanical components of the asset (partially based on the friction coefficient information defined in mechanical model 2304), the expected force applied to the corresponding components of the asset during operation, or other such behaviors.

[0193] User interface 2916 can generate visualizations 2914 that present simulation results on client devices. Visualization 2914 can present asset response data 2918 and other statistics related to the simulation session in any suitable format. For example, visualization 2914 may include an animated representation of the industrial system being simulated, similar to the presentation 2610 described above. Some sets of asset behavior and simulation data can also be presented as an alphanumeric overlay on visualization 2914.

[0194] This simulation technology can be used to test and debug control programs without putting field equipment and machines at risk, to simulate modifications to plant or machine operations and estimate how such modifications will affect certain key performance indicators or financial metrics, or to perform other types of analysis.

[0195] According to another type of application, the digital twin 2306 and its corresponding real-world industrial assets can be analyzed in parallel, and the results of the analysis can be used to implement supplementary supervisory controls on the assets or for reporting purposes. Figure 30 This diagram illustrates the use of a digital twin 2306 to combine collective monitoring and control of industrial assets. In this example, the automation system 3008 includes an industrial controller 3014 that exchanges monitoring and control signals with several industrial I / O devices 3020 to facilitate local control of industrial machines or processes according to a local control program 3012 (e.g., ladder logic program, sequential function chart, etc.) executed by the controller 3014.

[0196] In this example, the operation analysis and control system 3002 executes on a cloud platform and interfaces with the automation system 3008 via a gateway device 3010 that shares a network with the industrial controller 3014. As an alternative to cloud-based analysis and control, some implementations of system 3002 may reside on a server device, which is located within the factory facility. During operation, the device interface component 2814 of the operation analysis and control system collects the values ​​of corresponding BIDT tags configured on the industrial controller and / or other industrial devices of the automation system 3008. To facilitate substantially real-time analysis and supplementary control, the device interface component 2814 collects these BIDT data values ​​substantially continuously or at a high update frequency.

[0197] Similar to the previous example, the collected BIDT data 3016 is stored in historical data storage device 2606 and can be contextualized, enhanced (e.g., by generating calculated data 2402), and analyzed using digital twin 2306. In this example, predictive analytics component 512 is configured to perform predictive analytics on historical BIDT data 3016 and historical supplementary data (e.g., calculated data 2402) to identify potential future operational problems that may necessitate modifications to current control. In the example implementation, the control component 3004 of the operation analysis and control system 3002 can execute a supervisory procedure 3006, which generates supplementary control data 3018 directed to controller 3014 based on the results of the predictive analytics. Typically, supervisory procedure 3006 can be designed to modify the control of automation system 3008 to mitigate predicted future performance problems identified by the predictive analytics of digital twin 2306 based on BIDT data 3016. Examples of predictive performance problems that can be identified by predictive analytics component 512 may include, but are not limited to: deviations of key performance parameters of automation system 3008 from defined acceptable ranges, failure to meet defined production targets within the required timeframe, excessive energy consumption of automation system 3008, or other such problems.

[0198] Control unit 3004 can be linked to predictive analytics unit 512 to notify monitoring program 3006 when a performance problem is predicted, and monitoring program 3006 can be configured to generate control data 3018 in response to the predicted performance problem. This control data 3018 is designed to modify the control of automation system 3008 in a way that mitigates the predicted performance problem. For example, control data 3018 may include: instructions to modify one or more control setpoints defined in local industrial controller 3014; instructions to initiate execution of alternative control routines in local industrial controller 3014; instructions to change the operating mode of automation system 3008; or other such instructions. In the illustrated example architecture, device interface unit 2814 sends control data 3018 to industrial controller 3014 via gateway device 3010.

[0199] In addition to performing supervisory control of the automation system 3008 based on predicted operational problems, or as an alternative, some implementations of the operation analysis and control system 3002 can also be configured to generate report or notification data in response to predictions of performance problems related to the automation system 3008. For example, based on predictive analysis of historical BIDT data 3016 contextualized by digital twin 2306, predictive analysis component 512 can identify impending failures of components of the automation system 3008 (e.g., bearings, pumps, or motors), impending depletion of materials supplied to the automation system 3008, or other such concerns. In response to the identification of such a problem, device interface component 2814 can generate a notification of the problem and send it to one or more client devices associated with relevant plant personnel.

[0200] Device interface component 2814 can determine, based on asset model 422 of digital twin 2306, which plant-side BIDT data items to collect for storage and processing. For example, device interface component 2814 can determine which plant-side BIDT tag is referenced by asset model 422 and collect data associated with these referenced tags from the appropriate local devices constituting automation system 3008. For control data 3018, device interface component 2814 can determine which data tag corresponds to each of the digital and analog output values ​​defined by supervisory program 3006 and send these output values ​​to their appropriate data tags or registers in the plant-side industrial device (e.g., controller 3014). Depending on the configuration, device interface component 304 can send these values ​​directly to the corresponding plant shop device or via gateway device 3010.

[0201] This configuration creates a two-tiered control architecture, whereby the immediate control functions of the automation system 3008 are locally controlled by the control program 3012 executing on the local industrial controller 3014, while higher-level control of the automation system 3008 is performed by the operations analysis and control system 3002 based on the supervisory program 3006 and predictive analytics performed on historical BIDT data 3016 contextualized by the digital twin 2306. Users can design the supervisory program 3006 to essentially manage any high-level objective of an industrial enterprise. For example, the cloud-based supervisory program 3006 can be configured to adjust the productivity of the automation system 3008 based on part productivity measured at an upstream system supplying parts or materials to the automation system 3008 or demand measured at a downstream system or facility. For example, such a change in productivity can be performed by writing a new setpoint value to a data tag in the controller 3014 that sets the speed of the automation system 3008.

[0202] In another example of cloud-based supervised control, a factory floor controller 3014 or another device can perform autonomous control of an automation system 3008, such as proportional-integral-derivative (PID) loop control of a motion system. During this local control, the device interface component 2814 can read operational values ​​(e.g., loop regulation parameter values, current speed and position of the motion system, current or predicted control output signals generated by the local controller, etc.) and timestamped states related to the control of the local automation system 3008, whereby the asset model 422 collects these states and operational values ​​based on references to these data items. Based on these values, as well as supplementary data generated by applying a digital twin 2306 to historical BIDT data 3016 (e.g., calculated asset behavior data 2402), the predictive analytics component 512 can predict the future state (e.g., position, speed, etc.) or trajectory of the motion system, and generate new control setpoint values ​​or other control parameters for the local controller based on these predicted states, anticipating where the motion system will be in the future. The cloud-based system can then send these new setpoints or control values ​​to the local controller 3014.

[0203] To facilitate time-series visualization and analysis using the interconnected asset (automation) model 422 and the machine model 2304, as in the example above, both models should be provided with synchronized time-series data. However, in many data collection applications, time-series data items generated from multiple different sources may not be strictly synchronized according to a common time base or time domain. This can introduce inaccuracies when attempting to correlate events that appear to occur at the same point in time, because interpolation between timestamps is necessary to estimate when one event occurs relative to another.

[0204] Figure 31This is an example of a time-series data record illustrating the drawbacks associated with asynchronous data recording. In this example, three data tag attributes associated with the depositor used in the cookie manufacturing process—Depositor.BatchEvent, Depositor.BatchEvent.Energy, and Depositor.BatchEvent.CookieCount—are recorded as historical data. The tag attribute Depositor.BatchEvent, indicating the state of the production process, is recorded only when the state changes. The other tag attributes—Depositor.BatchEvent.Energy and Depositor.BatchEvent.CookieCount—are numerical values ​​recorded periodically. Initially, the state of Depositor.BatchEvent is "Production-Idle," and the transition to this state is recorded as the first data record (indicated by arrow 1). Because the Energy value and CookieCount value are recorded periodically, many records of Energy and CookieCount values ​​follow the Depositor.BatchEvent "Production-Idle" data record. When the batch mode changes to "Production Choc.ChipStarted", the value of Depositor.BatchEvent is recorded (indicated by arrow 2), and the periodic recording of energy value and cookie count value continues.

[0205] To enable the analysis application to determine the Energy value when the process switched to the "Production Choc.Chip Started" state (at time 9:00:30.600), the application must interpolate between the Energy values ​​of the two closest records (record A and record B) immediately before and after the BatchEvent record. This is because the BatchEvent state and Energy value are not recorded synchronously, and therefore no Energy record with a timestamp exactly matching the timestamp of the BatchEvent record is recorded. Although the interpolated Energy value corresponding to the BatchEvent record can be a close approximation of the actual Energy value at the time of the event of interest, it is still likely less accurate than the actual Energy value at the time of the event. Furthermore, because Energy values ​​and cookie counts are recorded periodically, historical data records can include a large number of Energy values ​​and cookie counts that may not be necessary for the analysis purposes.

[0206] To address these and other issues, some implementations of industrial devices employing BIDT data tags can support the synchronous recording of their associated data in an interconnected manner. In such implementations, device configuration application 708 may include a programming tool that allows users to link BIDT tag attributes to each other based on defined parent-child relationships for the purpose of synchronous recording of BIDT data values. Figure 32 Example data logging instructions 3202 for programming synchronous data logging of BIDT data, which can be supported by device configuration application 708, are shown. Although instructions 3202 are described as function blocks, it should be understood that data logging instructions can be implemented on virtually any programming platform.

[0207] The data logging instruction 3202 can be added to the control program using the device configuration application 708 (e.g., Figure 7 The control procedure 704 is part of the BIDT configuration 706. Each data logging instruction may include a BIDT attribute reference 3210 that identifies the BIDT attribute to be recorded based on the instruction. As part of the data logging instruction configuration, the user may also specify whether the BIDT attribute identified by reference 3210 will be recorded based on rate, variable change, or interconnected time domain.

[0208] When instruction 3202 is configured to record according to a rate, it causes the identified BIDT attribute to be recorded periodically at a frequency specified by the user as part of the instruction configuration. When instruction 3202 is configured to record based on a variable change, it causes the identified BIDT attribute to be recorded each time a linked process variable changes its value or state. The process variable can be the value of the referenced BIDT attribute itself or another process variable linked to the recording instruction 3202 via process variable input 3208. For numeric attributes, the variable change configuration can also allow the user to specify the extent (e.g., 2% or greater) that the attribute value must change before the attribute is recorded. When instruction 3202 is configured to record based on interconnected time domains, it causes the identified BIDT attribute to be recorded when a recording signal is received at the instruction's time domain input 3206. This setting allows BIDT attributes to be recorded as child nodes under the control of the parent node providing the time domain input signal. The time-domain output 3204 of the instruction can be linked to other data record instructions associated with other BIDT attributes to facilitate coordination among linked attributes.

[0209] Figure 33This is a diagram illustrating an example interconnection of data logging instructions 3202 used to facilitate the coordination of BIDT attributes defined in one or more industrial installations. In the example shown, logging instruction 3202a is configured to reference a batch event BIDT attribute (corresponding to...). Figure 31 The parent node of the Depositor.BatchEvent batch event property. Directive 3202a is configured to record changes based on variable changes, so that when the property changes state, the value of the batch event property will be recorded.

[0210] Instruction 3202b references the Cookie Count (BIDT) attribute (corresponding to...) Figure 31 The Depositor.BatchEvent.CookieCount property in the code, while instruction 3202c references the Energy BIDT property (corresponding to...). Figure 31 The Depositor.BatchEvent.Energy property in the `Depositor.BatchEvent.Energy` property. The time-domain output 3204 of the recording instruction 3202 is connected to the time-domain inputs 3206a and 3206b of two other data recording instructions 3202b and 3202c, which are set to record according to the time domain. This interconnected configuration presents cookie count attribute sub-nodes and energy attribute sub-nodes for batch event attributes for data recording purposes. Therefore, the values ​​of the cookie count attribute and energy attribute will only be recorded when the value of the batch event attribute is recorded—which occurs when the value of the batch event attribute changes state. Therefore, according to... Figure 33 The configuration described herein stipulates that when the batch event attribute changes state, three BIDT attributes—batch event, cookie count, and energy—will be recorded simultaneously.

[0211] Figure 34 It is by Figure 33 The example time-series data record produced by the configuration depicted is shown below. As this data record illustrates, when a batch event changes state, each data record of the batch event change (indicated by the arrow) is recorded along with concurrent records of the energy value and cookie count value. As can be seen in the timestamp column, for each instance of a batch event state change, the timestamps of the batch event, energy value, and cookie count value are equal. Therefore, it is not necessary to... Figure 31In scenarios depicted where energy and cookie counts are recorded periodically and asynchronously with batch event states, values ​​for energy or cookie counts corresponding to the time of batch event changes are inserted. Furthermore, since energy and cookie count values ​​are recorded only in response to batch event states, rather than periodically, the number of unnecessary energy and cookie count records is reduced or eliminated, thus saving on data storage utilization.

[0212] Executing data logging instruction 3202 on an industrial device enables the industrial device to record interconnected BIDT attributes to any appropriate destination data storage area, including local storage devices on the industrial device, remote networked storage devices, or cloud-based or Internet-based storage devices.

[0213] Data logging instruction 3202 can be arranged and configured to create logical cascades of relevant BIDT attributes to be logged synchronously. Figure 35 This is another example interconnected diagram of linked data logging instructions 3202. In this example, logging instruction 3202a is configured to periodically log its corresponding BIDT attribute (BIDT attribute 1) at a rate of once every 500 ms. Logging instructions 3202b, 3202c, and 3202d are configured as time-domain child nodes of instruction 3202a, such that these BIDT attributes (attribute 2, attribute 3, and attribute 4) will also be logged synchronously with BIDT attribute 1 at a rate of 500 ms. A fifth logging instruction 3202e is linked to logging instruction 3202b. This logical cascading can be designed to conform to the hierarchy of industrial assets—for example, line-level attributes, machine-level attributes, equipment-level attributes, and device-level attributes.

[0214] The aforementioned technique for configuring interconnected, synchronized data records allows users to easily group BIDT attributes whose values ​​should be associated for analytical or reporting purposes. The resulting data records will include a set of related data values ​​with synchronized timestamps, facilitating more accurate correlations of industrial asset behavior, status, events, performance variables, locations, etc. Furthermore, by configuring historical data records so that selected data values ​​are recorded only when they need to be correlated with other asset attributes, rather than periodically, data traffic associated with the transmission of unnecessary data values ​​is reduced.

[0215] The synchronized historical BIDT data values ​​generated by recording instruction 3202 can improve the fidelity of visualization, analysis, and reporting applications utilizing digital twin 2306. For example, since asset (automation) model 422 and machine model 2304 reference common BIDT labels that use a common time domain for data recording, it ensures that the analytical values ​​generated by applying digital twin 2306 to historical BIDT data (e.g., calculated data 2402 generated by applying machine model 2304 to automation data) more accurately represent the state of asset attributes at a given point in time.

[0216] Figures 36 to 37 Various methods according to one or more embodiments of this application are illustrated. Although, for the sake of simplicity, the one or more methods shown herein are shown and described as a series of actions, it should be understood and recognized that the subject matter innovation is not limited by the order of the actions, as certain actions may occur in a different order than those shown and described herein and / or occur simultaneously with other actions according to the subject matter innovation. For example, those skilled in the art will understand and recognize that a method may alternatively be represented as, for example, a series of interrelated states or events in a state diagram. Furthermore, not all actions shown are necessary to implement the method according to the present innovation. Additionally, an interaction diagram may represent a method or manner according to the present disclosure when different entities demonstrate different parts of the method. Furthermore, two or more of the disclosed example methods may be implemented in combination with each other to accomplish one or more features or advantages described herein.

[0217] Figure 36 An example method 3600 is shown for linking points of automated and non-automated models of an industrial asset using common references to BIDT data tags. Initially, at 3602, one or more data tags are defined on the industrial unit, wherein the data tags conform to one or more Basic Information Data Types (BIDTs), and the BIDTs include at least one of a rate BIDT, a status BIDT, an odometer BIDT, or an event BIDT. A rate BIDT data tag can represent an integer or real value of the measured rate of a metric associated with the industrial asset or unit. A status BIDT data tag can represent the current state of the industrial asset or unit (e.g., a machine, production line, motor drive, etc.). An odometer BIDT data tag can represent a cumulative quantity associated with the industrial asset (e.g., a cumulative quantity with a flip value, or a quantity over a defined time interval). An event BIDT data type can represent a momentary or continuous event associated with the industrial asset (e.g., a button event, sensor event, safety device event, and alarm event, etc.).

[0218] At 3604, metadata is configured for the corresponding BIDT tag defined in step 3602. The metadata includes user-defined parameters for the corresponding BIDT data tag, where the user-defined parameters are specific to the type of each BIDT data tag. For example, user-configurable metadata associated with a rate BIDT data tag may include, but is not limited to: definitions of the maximum and minimum values ​​corresponding to the rate value, the identities of one or more other data tags or input addresses whose values ​​are aggregated (e.g., summed, averaged, integrated, etc.) to produce the rate value, the unit of measurement associated with the rate value, or other such metadata. Metadata for a status BIDT data tag may include, but is not limited to: definitions of the availability status of the industrial asset to which the data tag is assigned, the identities of one or more other data tags whose values ​​determine the status, or other such metadata. Metadata associated with an odometer BIDT may include, but is not limited to: the identities of one or more data sources driving the odometer value, the identities of two or more data tags whose values ​​are to be aggregated or summed to produce the odometer value, the unit of measurement associated with the odometer value (e.g., product count, megawatt-hours consumed, etc.), or other such metadata. The metadata associated with an event BIDT data tag may include, but is not limited to: the device input address or other data tag identity that determines the event to be represented by the event BIDT data tag, the name of the event represented by the event BIDT data tag, or other such metadata.

[0219] At 3606, configure the automated model of the industrial asset. This automated model is configured to reference BIDT data tags and define the grouping of the referenced BIDT data tags. The automated model can correspond to application data that can be used to generate a customized graphical representation of the asset data or the desired hierarchical organization of the industrial asset. At 3608, configure the non-automated model of the industrial asset. This non-automated model can be, for example, a mechanical model defining the mechanical characteristics of the industrial asset (e.g., gear ratios and / or diameters, friction information, inertia information, etc.), a thermal model defining the thermal characteristics of the components constituting the industrial asset, a business or financial model defining financial information associated with the operation of the asset (e.g., material or energy costs based on operating characteristics or operating time, product output associated with profits, etc.), or another type of model defining the non-automated characteristics of the asset.

[0220] At point 3610, a visual representation of historical data values ​​for BIDT data labels is generated based on hierarchical grouping and supplementary attribute data defined by an automated model, where the supplementary attribute data is generated for the industrial asset based on the application of historical data values ​​to a non-automated model. The visual representation can be, for example, an animated virtual reality presentation or other types of graphical representation, showcasing an animated reproduction of the asset's historical performance across a selected time range, a report on the historical asset's performance, or another type of visual representation.

[0221] Figure 37 An example method 3700 for configuring synchronized recording of industrial data is shown. Initially, at 3702, one or more data tags conforming to one or more basic information data types are defined on the industrial device (similar to step 3602 of method 3600). At 3704, metadata for the corresponding BIDT data tags defined in step 3702 is configured (similar to step 3604 of method 3600). At 3706, a link is defined between a first BIDT data tag and one or more second BIDT data tags. This link configures synchronized data recording of the first BIDT data tag and the one or more second BIDT data tags to which the first data tag is linked. This link sets the first BIDT data tag as the parent node of one or more second BIDT data tags that are child nodes for data recording purposes.

[0222] At 3708, a condition is defined for recording the value of the first BIDT data tag. This condition specifies that the value of the first BIDT data tag will be recorded when the value changes state (or changes from the current value beyond a defined tolerance); the value will be recorded periodically according to a defined data recording rate; or the value will be recorded in response to a trigger condition defined as a function of another data tag or entity.

[0223] At step 3710, it is determined whether the condition defined in step 3707 has been met. If the condition is not met (No at step 3710), the method continues to monitor the condition defined in step 3708. If the condition is met (Yes at step 3710), the method proceeds to step 3712, where the value of the first BIDT data tag and one or more second BIDT data tags is recorded when the condition is met. The link defined in step 3706 ensures that the first BIDT data tag and one or more interconnected second BIDT data tags are recorded synchronously, thereby ensuring that all interconnected values ​​have a common timestamp. This improves the accuracy of time-based analysis of historical BIDT data by eliminating the need for estimates of the BIDT tags inserted corresponding to the timestamps of events.

[0224] The aforementioned disclosure describes the structure of example BIDTs 322—also known as smart tags—and their use as the foundation for creating digital twins 2306 for industrial systems. Example applications of these digital twins 2306 are also described—including visualization, analytics, data augmentation, simulation, and control applications. The contextualized data infrastructure of the BIDTs 322 also allows the digital twins 2306 to be easily integrated with artificial intelligence (AI) tools and systems. For example, AI-based development or analysis of the digital twin 2306 can be aided and simplified through metadata and contextual relationships defined by the BIDTs 322 constituting the digital twin 2306, and relationships between devices and components defined by the asset model 422 (components of the digital twin 2306). AI-based development and analysis are also aided by supplementary data generated by the digital twin 2306 that cannot be directly obtained from plant data, such as combinations of the above. Figure 24 and Figure 27 The discussion focuses on the computational asset behavior data 2402. This supplementary data can fill gaps in data that can be obtained directly from factory floor equipment, machines, and processes, resulting in more comprehensive AI analytics solutions.

[0225] In some implementations, AI analytics can also be used to verify the fidelity of the digital twin 2306 itself relative to the industrial asset being modeled, or to enhance the quality of the digital twin 2306 to produce a more accurate model of the industrial asset. Figure 38 This is a diagram illustrating an example architecture including an AI engine component 514 capable of applying AI analysis to the digital twin 2306 for contextualization, verification, and adaptation purposes. Figure 38 (and Figure 5 In the example described, AI engine component 514 is an integrated component of application server system 502. However, in some implementations, AI engine component 514 may be a component of a separate system or tool capable of accessing digital twin 2306 to contextualize, verify, and / or adapt digital twin 2306.

[0226] Typically, if significant relationships between variables (e.g., asset characteristics and responses, process measurements, etc.) can be encoded as attributes of BIDT 322 itself, then AI-based validation of the digital twin 2306—that is, confirming that the digital twin 2306 accurately models a given industrial asset or process—can be simplified and largely automated. This not only applies useful constraints to the AI ​​analysis of the digital twin 2306—reducing analytical overhead and guiding the AI ​​to search for useful findings more quickly—but also allows these relationships to be transferred along with the digital twin 2306 for use in other installations of the industrial asset being modeled.

[0227] To this end, AI engine component 514 can be configured to discover key variables defined in digital twin 2306, and the relationships between these key variables and other variables defined in digital twin 2306. Once discovered, AI engine component 514 can encode these relationships in the relevant BIDT 322 itself, as additional attributes or fields attached to the BIDT.

[0228] By leveraging these verification attributes encoded in the BIDT 322 (smart tag) of the digital twin, the AI ​​engine component 514 can apply AI analytics, along with real-time or historical process data from the modeled industrial asset, to the digital twin 2306 to verify the fidelity of the digital twin relative to the industrial asset. This AI-driven verification is aided by relationships built into the BIDT 322 itself, as well as higher-level relationships defined in the digital twin 2306 (e.g., hierarchical relationships defined by the asset model 422, the relationship between the asset model 422 and the machine model 2304, etc.).

[0229] In some scenarios, the digital twin 2306 can be designed to model a specific industrial asset or automated system that is substantially replicated at another factory location. In such scenarios, the AI ​​engine component 514 can verify the duplicated instance of the digital twin 2306 for the new installation of the asset. If the AI ​​engine component 514 identifies elements in the digital twin 2306 that do not accurately model the corresponding physical or behavioral characteristics of the newly installed industrial asset, the AI ​​engine component 514 can also perform a digital twin adaptation process, which modifies the new instance of the digital twin 2306 as needed to make the digital twin 2306 consistent with the physical industrial system.

[0230] Modifying the smart tags (BIDT 322) that constitute the digital twin 2306 to include AI-ready contextualized metadata allows other analytics systems—such as other AI systems or other types of analytics systems 3802, predictive analytics components 512, other digital models 3804, etc.—to easily interface with the digital twin 2306 and can assist these other analytics systems in converging to the desired analytical results more quickly and efficiently. The additional contextualization encoded in the smart tags themselves can be utilized by these other analytics systems to reduce the search space to be examined regarding predicting future outcomes or generating insights into the performance of past and current assets.

[0231] Figure 39This is a contextualized diagram illustrating the AI ​​engine component 514's BIDT 322 for the digital twin. In this example, the digital twin 2306 has a format similar to that described in the examples discussed above, including an asset model 422 representing industrial assets or collections of industrial assets according to hierarchical elements of industrial facilities or sets of facilities. The asset model 422 also associates selected BIDT 322 with corresponding elements of the hierarchical model. The digital twin 2306 also includes a mechanical model 2304 (or another type of non-automated model) linked to the asset model 322 via a common BIDT reference.

[0232] To facilitate the validation of the digital twin 2306 and to simplify subsequent AI analysis using the digital twin 2306, the AI ​​engine component 514 can modify some or all of the BIDT 322 that constitutes the digital twin 2306 to add AI-contextualized metadata in the form of additional fields or attributes. These additional fields or attributes can encode relationships between learned modeling variables (e.g., process measurements, device outputs, or states, etc.) that are not yet defined in the digital twin 2306, as well as parameters that define the type of analytical problem to be solved by the analysis engine utilizing the digital twin 2306.

[0233] To this end, AI engine component 514 can apply correlation and / or causal analysis to the digital twin 2306 to identify one or more BIDT322 variables representing important or key variables of the industrial asset or process being modeled by the digital twin 2306. Key variables may represent key performance indicators (KPIs) of the modeled asset or process, or other critical and important aspects of the system being modeled. Typically, key variables represent the overall performance quality of the industrial asset.

[0234] In some scenarios, AI engine component 514 can identify key variables in part based on industry knowledge of the type of industrial asset or process modeled by digital twin 2306. For example, it may be known that product output is a primary concern for a certain type of industrial production line. Therefore, if AI engine component 514 determines or infers that digital twin 2306 models an industrial system corresponding to this type of production line, then BIDT 322 representing product output can be selected as a key variable. In some implementations using this method to identify key variables, AI engine component 514 can reference an industry knowledge base that defines key variables for different types of industrial systems (e.g., machines, production lines, processes, verticals, etc.) and identify key variables by associating the type of industrial system being modeled with the industry knowledge base. In other scenarios, one or more key variables can be explicitly identified or defined by the user. Typically, for a given digital twin 2306, there can be more than one key variable or KPI. Other types of key variables may include, but are not limited to, energy consumption, energy efficiency, cycle time, asset availability, capacity utilization, or other such variables modeled by BIDT 322 that constitutes the digital twin 2306.

[0235] If industry domain knowledge for the industrial system being modeled is unavailable, AI engine component 514 can apply data science methods to digital twin 2306 to identify which variables best indicate the overall performance quality of the industrial asset or process being modeled. For example, AI engine component 514 can define and solve an optimization problem to identify key or important variables modeled by digital twin 2306 (i.e., those variables that best indicate the overall performance or operational quality of the modeled asset). In this regard, a predefined BIDT data structure, along with hierarchical relationships defined by digital twin 2306 (e.g., the structure and relationships defined by asset model 422 and machine model 2304), simplifies this key variable identification analysis by reducing the search space used for the optimization problem. For example, if the asset model 422 of the digital twin 2306 defines a set of production lines with both shared resources (e.g., a common main power source, a common source of input materials or parts, etc.) and isolation characteristics (e.g., different sets of equipment, isolated power supplies, independent operating characteristics, etc.), then the AI ​​engine component 514 can use these asset model definitions as useful constraints for searching relationships between variables modeled by the digital twin 2306. That is, the AI ​​engine component 514 can limit the search space for correlations (and / or causations) to the set of variables that may have potential relationships according to the asset model definitions, omitting searches for correlations between variables on different production lines known to be independent or unrelated based on the asset model definitions. In one or more embodiments, the BIDT data structure can be used to assign values ​​to integer variables that enhance the BIDT data structure and indicate whether a causal relationship between two variables is possible. Since determining causality is computationally expensive, defining integer variables that limit the search space is a key enabling step in virtually all real-world problems of reasonable size.

[0236] Once one or more key variables are identified by the digital twin 2306, the AI ​​engine component 514 can perform further analysis on the model to identify relationships between the key variables and other variables present in the digital twin 2306. That is, for each key variable, the AI ​​engine component 514 can determine which other variables modeled by the digital twin 2306 can be used to predict the value of the key variable. In cases where the digital twin is a complete and accurate representation of a physical process, the model built by the AI ​​engine for the key variables may not provide new insights that do not yet exist. However, in real-world scenarios, such complete and perfectly accurate models do not exist; therefore, the model built by the AI ​​engine provides significant value in the monitoring and validation of the digital twin. This can include, for example, performing correlation or causal analysis on the digital twin 2306 to identify variables that have the most significant impact on other variables. In an example scenario, the digital twin 2306 could model a water pumping system that includes a set of electric water pumps that generate water flow for other processes. Based on correlation or causal analysis performed on the digital twin 2306, AI engine component 514 can identify and quantify the correlation between the water flow generated by each pump and the power consumption of the pump. In such a scenario, the variable representing flow rate can be identified as a key variable for each pump, and variables identified as contributing to the flow rate value may include the amount of power consumed by the pump (in kilowatts) and the water pressure. Encoding these relationships in the BIDT 322 of the digital twin 2306 can improve the plant analysis or simulation subsequently performed on the digital twin 2306 by other analysis systems (e.g., an optimizer that analyzes the digital twin 2306 to identify a subset of pumps that can meet the total flow demand while consuming the least power).

[0237] Similar to the analysis performed to identify key variables, this correlation or causal analysis can be guided in part by the relational topology defined by the digital twin 2306 (e.g., by the asset model 422 and the machinery model 2304) and by the data structure of the BIDT 322 itself. That is, the relationships between devices, measurements, equipment, and equipment attributes already defined by the digital twin 2306 can constrain the AI ​​engine components' searches for relationships between key variables and other variables, thereby reducing the overhead and time required to identify these key relationships.

[0238] In some cases, for example, using with Figure 30 Similar to the architecture shown, the AI ​​engine component 514 can discover the relationships between key variables and other modeled variables based on both the data topology of the digital twin 2306 itself and the actual process data collected from the modeled industrial assets. Figure 40The diagram illustrates an example architecture in which AI engine component 514 contextualizes the smart tags of digital twin 2306 based on analysis of the data topology of digital twin 2306 and real-time or historical process data collected from the devices of the automation system 3008 being modeled—in the form of BIDT data 3016 (e.g., process data retrieved from BIDT 322 defined on the devices of automation system 3008). As described above... Figure 30 The BIDT data 3016 (real-time process data) can be obtained from the devices of the automation system 3008 via the device interface component 2814, and this BIDT data 3016 is stored as time-series historical process data 4002 in the historical data storage device 2606. This historical process data 4002 represents the time-series values ​​(e.g., flow measurement, speed measurement, power statistics, etc.) of the corresponding smart tags (BIDT 322) defined by the digital twin 2306. Therefore, the AI ​​engine component 514 can discover new relationships between key variables and other variables of the digital twin 2306 based on the analysis of the historical process data 4002 and the relationships between these data values ​​already defined by the digital twin 2306.

[0239] AI engine component 514 can also identify relationships between key variables and calculated values ​​that are not available from the plant equipment itself, such as those mentioned above. Figure 24 and Figure 27 The asset behavior data 2402 discussed in the calculation.

[0240] In general, the search topology extracted from the structure of BIDT 322 and the asset and machinery model definitions of the digital twin 2306 can significantly constrain the parameters of the optimization problem solved by AI engine component 514, thereby significantly reducing the time and expertise required to analyze the digital twin 2306 to identify key variables and their correlations with other variables. This alleviates the need to involve data science experts in the process of analyzing and validating digital models of industrial assets.

[0241] Once the key variables (represented by the corresponding key BIDT 322 or its associated attributes) and their relationships with other modeled variables have been identified, the AI ​​engine component 514 can enhance the relevant BIDT smart tags by adding AI contextualized metadata. This may involve adding new AI fields to the BIDT 322 representing the key variables and to the relevant BIDT 322 that have been identified as having an influence on the key variables. Figure 41This illustrates a sample data pattern of BIDT smart tags 4102 that has been enhanced by AI engine component 514 to include AI fields 4104 defining various AI attributes. The smart tags 4102 have a format similar to their original BIDT 322, but modified by adding AI fields 4104. The values ​​of the new AI fields 4104 can encode relationships found between key variables and their related variables (those that directly affect the values ​​of the key variables), as well as other information that can assist in model validation and adaptation.

[0242] For example, a new AI field 4104 can be added to the key variable smart label 4102, which identifies the smart label 4102 as representing the key variable. Additional AI fields 4104 can identify other smart labels 4102 that affect the value of the key variable. If the AI ​​engine component 514 is able to learn a mathematical model of the key variable as a function of other related variables (e.g., based on the data topology of the digital twin 2306 and the available historical process data 4002), that model can also be included in one or more AI fields 4104 (e.g., as a mathematical function defining the relationship between pump flow output, pump power consumption, and water pressure). In some scenarios, the AI ​​engine component 514 can discover such mathematical relationships or models based on the analysis of the digital model 2306 and actual process data collected from the industrial asset being modeled.

[0243] In some implementations, AI field 4104 may also define the type or category of analytical problem to be solved relative to the key variables (e.g., modeling, clustering, optimization, minimization, etc.). AI engine component 514 may determine the type of analytical problem based on several factors, including but not limited to the type of industrial asset or process modeled by digital twin 2306 and the identity of the key variables. Encapsulating these problem statements within the structure of BIDT 322 itself enables programmatic access to the nature of the data analysis to be performed on digital twin 2306 by the analysis engine (e.g., AI engine). Because the analytical problem statement is embedded within the data structure of digital twin 2306 itself, real-time analysis systems interfaced with digital twin 2306 can recognize the prescribed type of analysis defined by AI field 4104 and perform the defined analysis with minimal user intervention, even if digital twin 2306 is moved to different platforms (e.g., edge devices, cloud platforms, servers, embedded platforms, etc.). In this way, the smart tag 4102 can be used as a standardized interface to the digital twin 2306, through which other analysis systems can learn the expected or beneficial types of analysis to be performed on the digital twin 2306 (e.g., minimizing energy consumption, maximizing product output, maximizing efficiency, selection of a subset of available industrial assets to be deployed to achieve the desired results under given constraints, etc.).

[0244] If the user's analytical objectives change, the analytical problem attributes of BIDT 322 can also be modified programmatically in real time. For example, Digital Twin 2306 might initially be used to solve problems that minimize fuel consumption using industrial assets it models (e.g., in situations like...). Figure 30 (In the context of the monitoring and control system shown). If it is decided to prioritize the minimization of emissions rather than fuel use, the AI ​​field 4104 defining the problem statement can be programmatically modified to reflect this new analytical problem, thereby communicating the new operational objective to the analysis system.

[0245] The AI ​​field 4104, which enhances the relationships between variables in an industrial system modeled with additional records in BIDT 322, makes these relationships visible attributes of the generated smart labels 4102, which can be communicated by analysis and simulation systems (e.g., analysis system 3802) that interface with the digital twin 2306, as well as by other digital models 3804 (see [link to documentation]). Figure 38Access and utilization. In some implementations, the smart tag 4102 can also be viewed on a client device via a model interface generated by the presentation component 508. In an example format, the smart tag 4102 can be presented as an array of tags, such that selecting a specific smart tag 4102 representing a measured or calculated process variable (e.g., line efficiency, pump flow rate, etc.) causes a list of other variables affecting the selected variable to be displayed (e.g., power consumption, pressure, etc.).

[0246] Including model details describing the dependencies of key variables on other variables in the BIDT allows for easier application of various types of validation analyses to the digital twin 2306. For example, AI engine component 514 can systematically use real-time operational data to determine the sensitivity of key variable predictions to each of the variables influencing the key variable. If the relationships between the variables used as a measure of the digital twin's validity are insensitive to poor data quality, a reliable predictive model can be used for validation of the digital twin 2306. If model information is transparent and programmatically accessible via smart tag 4102, the continuous evaluation of the model's sensitivity (and triggering actions to modify the digital twin 2306 if necessary) can be automated.

[0247] In addition to generating a more AI-ready model of industrial assets, enhancing the smart tags of the digital twin 2306 in this way provides a more robust foundation for verifying the fidelity of the digital twin 2306 when it is used in different operational scenarios or transferred to other factory locations. Figure 42 This diagram illustrates the use of AI-based simulation to validate a digital twin 2306 against a physical industrial asset or system being modeled. Due to the complexity of the model, validating a digital model for the asset it models presents challenges for industrial system designers in terms of accuracy and fidelity, often requiring the involvement of data science experts in the development, validation, and deployment of such models. The data contextualization and variable relationships directly built into the smart tag 4102 of the digital twin 2306 can greatly simplify and essentially automate the process of validating the digital twin 2306 against the corresponding physical industrial asset or system. The AI ​​engine component 514, together with the simulation component 2912, can apply AI intelligence to the granular smart tag data structure as part of the design and modeling process to validate the consistency, integrity, and effectiveness of the digital twin 2306 relative to the industrial asset, making the involvement of data scientists unnecessary.

[0248] In the example scenario, digital twin 2306 can be developed to model industrial assets under specific operating conditions. To validate the model, real-time or historical process data 4202 from the physical industrial asset (e.g., collected and stored by device interface component 2814) can be applied to digital twin 2306 via simulation component 2912. Process data 4202 represents actual measurement and status data (e.g., flow rate, energy consumption, temperature, pressure, speed, etc.) generated by the devices constituting the industrial asset being modeled, and is typically timestamped, allowing simulation component 2912 to apply data 4202 to digital twin 2306 in a time-series manner, thereby simulating the operation of the industrial asset over a certain time frame. Simulation component 2912 generates simulation result data 4204 representing the simulated asset response to process data 4202, where the simulated asset response is based on relationships defined by digital twin 2306 (e.g., by asset and machinery models) and data relationships recorded in AI field 4104 of smart tag 4102. The simulation results data 4204 may also include other calculated metrics of asset performance (e.g., KPIs, efficiency, cycle time, etc.) based on data relationships modeled through the digital twin 2306 and its smart tag 4102.

[0249] AI engine component 514 can apply verification algorithms to the digital twin 2306, simulation results 4204, and actual process data 4202 to verify whether specific modeled attributes and quality of the digital twin 2306 accurately match the corresponding attributes and quality of the physical system. For example, AI engine component 514 can compare selected simulation results with their corresponding real values ​​generated from physical industrial assets and determine whether the simulation results generated based on the relationships modeled in the digital twin 2306 and its smart tags 4102 are within the defined tolerances of their corresponding actual asset outputs. This comparison can be performed on various aspects and relationships of the modeled assets, allowing deviations between the model and its corresponding physical assets to be identified at a high granular level, and appropriate modifications to the digital twin 2306 to be made.

[0250] In some implementations, detected discrepancies between aspects of the modeled industrial asset (e.g., pump efficiency, power consumption in a given operating mode, etc.) and their corresponding actual values ​​can be visually presented by the presentation component 508 on a graphical representation of the modeled industrial asset; for example, by highlighting devices, equipment, or components of the industrial asset that have characteristics or attributes not accurately modeled by the digital twin 2306. For these discrepancies in the digital twin 2306, some implementations of the AI ​​engine component 514 can also perform modifications 4206 on the digital twin 2306 to align these labeled aspects of the model with the physical industrial asset. This can include, for example, updating the relationships between variables defined in the AI ​​field 4104 of the smart tag 4102.

[0251] When a digital twin 2306 or a copy thereof is migrated for use with industrial assets that are similar to but not identical to the industrial assets for which the digital twin 2306 was developed, it is useful to verify and, if necessary, update the digital twin 2306 to ensure a high level of fidelity. For example, the digital twin 2306 can be developed to model a specific industrial system (e.g., a pumping system). As described above, the development of the digital twin 2306 can involve AI contextualizing the smart tag 4102 via AI engine component 514 to organize the discovered relationships between variables modeling the industrial system (e.g., measured telemetry values, KPIs, device status, power statistics, etc.) and specifying the analytical problem to be solved for the selected variables or the type of analysis to be performed (e.g., optimization, minimization, clustering, etc.). It can then be decided that a copy of the resulting digital twin 2306 will be used at another plant facility to perform analysis or supervisory control on a similar industrial system. During operation at other factory facilities, AI engine component 514 can monitor simulation result data 4204 generated by simulation component 2912 when process data 4202 (e.g., efficiency, power consumption, etc.) from the new industrial system is applied. Specifically, AI engine component 514 can monitor deviations between simulated attributes or responses generated by digital twin 2306 and expected values ​​of those attributes or responses learned during operation of digital twin 2306 using the original industrial system. Such deviations indicate aspects of digital twin 2306 that can be modified to improve its fidelity relative to the new industrial system.

[0252] To facilitate the identification and labeling of these deviations, some of the AI ​​fields 4104 added by the AI ​​engine component 514 to the smart tag 4102 may include normal operation statistics for the variables represented by the corresponding smart tag 4102. These normal operation statistics can be learned by the AI ​​engine component 514 based on extended monitoring of the digital twin's output during the operation of the original industrial system. These normal or expected statistics may include expected efficiency, expected power consumption, expected flow rate or temperature, or other such characteristics of the modeled system. Once these expected statistics have been learned, the AI ​​engine component 514 can add these expected values ​​to the new AI fields 4104 of its corresponding smart tag 4102. In this way, the baseline operation of the important attributes and characteristics of the original industrial system can be encoded within the digital twin itself. When the digital twin 2306 is deployed at a new facility, the AI ​​engine component 514 can compare these recorded expected statistics with corresponding new values ​​of these statistics generated by applying real-time or historical process data 4202 from the new plant to the digital twin 2306. If a calculated attribute deviates from its corresponding expected value beyond a defined tolerance, AI engine component 514 can mark the attribute as potentially requiring inspection or modification. AI engine component 514 can also modify the digital twin 2306 as needed to align the model with the physical asset. In some cases, this may involve modifying one or more relationships defined in the AI ​​field of smart tag 4102.

[0253] When modification 4206 is performed on digital twin 2306 to resolve discovered inconsistencies between digital twin 2306 and the modeled assets, AI engine component 514 can apply techniques similar to those described above for discovering update relationships between key variables of digital twin 2306 and other modeling variables. When time-series process data 4202 from the new industrial system is applied, these update relationships can be identified based on analysis of the digital twin's output. Since some characteristics of digital twin 2306 can be verified by AI engine component 514—meaning that relationships previously defined for these characteristics still apply to the new industrial system—AI engine component 514 only needs to re-evaluate the modeling relationships of those characteristics that failed verification, thereby minimizing the time required to produce a deployable digital twin 2306 for use in the new system.

[0254] In some implementations, presentation component 508 may be configured to present a graphical representation (e.g., as a 3D or VR representation of the asset) of the industrial asset being modeled by digital twin 2306, and graphically indicate unverified portions of the digital model, or portions identified as potentially invalid based on analysis by AI engine component 514. For example, presentation component 508 may present verified components, devices, or apparatuses of the digital model in green, while presenting potentially invalid attributes of the model in red.

[0255] A similar process for validating and updating the digital twin 2306 can be applied to scenarios where the original digital twin 2306 may not accurately model industrial assets across different operating conditions. For example, a digital twin 2306 designed to augment available measurements from an industrial process with supplementary values ​​(e.g., efficiency values, product or machine displacement, power consumption estimates, etc.) may accurately model the asset's response during fall operation but may be inaccurate for summer operating conditions. Therefore, the AI ​​engine component 514 can evaluate the calculated or simulated output of the digital twin in response to process data 4202 generated during summer operation and apply model modifications 4206 as needed to adapt the digital twin 2306 for summer operation.

[0256] Simulation and AI analytics can also be applied to digital twin 2306 to make the model suitable for use with another industrial system or in different operations before deploying the adapted digital twin, as an alternative to validating and adapting digital twin 2306 after deployment. Figure 43 This diagram illustrates an example architecture that can be used to adapt the digital twin 2306 to other systems or scenarios prior to deployment. In this development scenario, the original digital twin 2306a models the automation system 3008 and is used to enhance the measurement process data 4002 from the system 3008 using additional information (e.g., efficiency, hysteresis, displacement, etc.) generated by applying the measurement process data 4002 to the digital twin 2306a. The control unit 3004 can also perform supplementary control of the automation system 3008 based on the information generated by the digital twin 2306a (or based on predictive analysis performed on the digital twin and process data 4002) according to the supervisory program 3006, as described above in the previous example (see, for example, Figure 30 ).

[0257] Furthermore, a replica of the digital twin 2306b can be evaluated by the AI ​​engine component 514 for use with the industrial automation system 3008 under different operating conditions where the original digital twin 2306a might not be suitable. For example, the automation system 3008 could be a refrigeration unit currently operating in the fall. However, the refrigeration unit may operate differently in the summer, and therefore the original digital twin 2306a might not accurately model the system 3008 during the summer months. Therefore, during the fall operation of the system 3008, the second digital twin 2306b is validated and made suitable for summer use before summer operation. The simulation component 2912 and the AI ​​engine component 514 can use the second digital twin 2306b to simulate the operation of the automation system 3008 during summer conditions. In this regard, selected variables or parameters of the second digital twin 2306b can be modified to simulate the expected changes in system operation during summer conditions, and the simulation component 2912 can simulate summer operation by applying process data 4002 from system 3008 under its current autumn operating conditions to the modified digital twin 2306b. The AI ​​engine component 514 can apply AI-based learning algorithms to the simulation results and, based on the results of this analysis, modify the digital twin 2306b as needed to make the model consistent with the expected summer operating characteristics. This preliminary simulation of summer operation can accelerate model development and ensure that a robust digital twin 2306b is ready for deployment before the model is needed.

[0258] By using the AI ​​attribute enhancements described herein to build smart tags 4102 on top of the digital twin 2306, the model validation structure becomes an inherent attribute of the smart tag infrastructure of the digital twin and can be transferred between digital twin installations. AI engine component 514 can interface with these enhanced smart tags 4102 to verify the fidelity of the digital twin 2306 by validating the relationships between modeled attributes and measurements and adapting these relationships as needed. In this way, AI analytics becomes not only a client of the digital twin 2306 but also part of the model development itself. The enhanced smart tags also make the digital twin 2306 AI-ready, thereby simplifying the process of interfaceing the digital twin 2306 with AI analytics systems or other types of analytics systems by encoding key variable dependencies and analytical objectives within the smart tags 4102 themselves.

[0259] In any of the example scenarios described above, AI engine component 514 can apply artificial intelligence analytics to digital twin 2306 and device data obtained from the modeled asset to identify key variables, identify related variables affecting the key variables, learn the relationships between the key variables and those variables affecting the key variables, and validate the digital twin. In some implementations, AI engine component 514 can infer or extrapolate the state of the digital twin or the asset it models based on a set of observations captured via events or data. For example, inference can be used to identify specific situations or actions, or a probability distribution of states can be generated. This inference can be probabilistic—that is, calculating the probability distribution of states of interest based on considerations of data and events. Inference can also involve techniques for composing higher-level events using a set of events or data. This inference results in the construction of new events or actions using a set of observed events or stored event data, regardless of whether the events are closely related in time or whether the events and data come from one or more event and data sources. Various explicit or implicit training schemes or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, etc.) can be used to perform automatic or inferential actions related to the subject matter being protected.

[0260] Some implementations of AI engine component 514 may use classifiers to learn, infer, or verify relationships defined in the digital twin 2306. A classifier is a function that maps an input attribute vector x = (x1, x2, x3, x4, xn) to a confidence level that the input belongs to a class; that is, f(x) = confidence(class). This classification may employ probabilistic or statistical analysis (e.g., considering analytical utility and cost) to predict or infer actions that a user expects to perform automatically. Support Vector Machines (SVMs) are example classifiers that may be employed in some implementations. SVMs operate by searching for hypersurfaces in the space of possible inputs. Hypersurfaces attempt to separate triggering criteria from non-triggering events. Intuitively, this makes the classification correct for test data that is close to, but not equivalent to, the training data. Other directed and non-directed model classification methods that may be employed in implementations of AI engine component 514 may include, but are not limited to, Naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, intelligent agents, and probabilistic classification models that provide different dependency patterns. The classification used in this article also includes statistical regression, which can be used to develop priority models.

[0261] Figures 44a to 44bVarious methods according to one or more embodiments of the subject matter application are illustrated. Although the methods shown herein are illustrated and described as a series of actions for the sake of simplicity, it should be understood and recognized that the subject matter innovation is not limited by the order of the actions, as certain actions may occur in a different order than those shown and described herein and / or simultaneously with other actions according to the subject matter innovation. For example, those skilled in the art will understand and recognize that the method may alternatively be represented as, for example, a series of interrelated states or events in a state diagram. Furthermore, not all actions shown are necessary to implement the method according to the invention. Additionally, the interaction diagram may represent the method or manner disclosed in the subject matter when different entities demonstrate different parts of the method. Furthermore, two or more of the disclosed example methods may be implemented in combination with each other to accomplish one or more features or advantages described herein.

[0262] Figure 44a The first part of example method 4400a for enhancing digital twins of industrial assets by including metadata, which typically facilitates AI-based verification of the digital twin and interaction with external AI analytics systems, is shown. Initially, at 4402, the digital twin of the industrial asset is configured. A digital twin defines a hierarchical grouping of smart data tags defined on one or more industrial installations, where the smart tags conform to one or more Basic Information Data Types (BIDTs). BIDTs may include at least one of rate BIDTs, status BIDTs, odometer BIDTs, or event BIDTs.

[0263] At step 4404, AI analytics is applied to the digital twin to identify key variables defined in the digital twin that indicate the overall performance of the industrial asset. Key variables may be, for example, efficiency values, flow rates, production output rates, energy consumption, or another key variable or KPI of the industrial asset. At step 4406, AI analytics is applied to the digital twin and historical time-series process data collected from the industrial asset, identifying other variables defined in the digital twin that influence the values ​​of the key variables identified at step 4404.

[0264] At 4408, the functional relationship between the key variable identified in step 4404 and other variables that influence the value of the key variable, identified in step 4406, is identified. At 4410, an AI field is added to the smart tag corresponding to the key variable identified in step 4404. The AI ​​field identifies the other variables identified in step 4406 and their functional relationships with the key variable, identified in step 4408. Enhancing the smart tag in this way can produce an enhanced digital twin in which the functional relationship between the key variable and other variables that influence the key variable is encoded, which can be validated using AI-based model validation methods. In some implementations, one or more additional AI fields may be added to the smart tag to identify the type of problem or analysis algorithm to be solved relative to the key variable (e.g., optimization, minimization, clustering, modeling, etc.). This AI field can be referenced by an external analysis system to convey the type of analysis to be applied to the digital twin, and in particular to the variables specifically identified in the digital twin.

[0265] This method is achieved through Figure 44b The second part, 4400b, continues. At 4412, artificial intelligence is applied to the enhanced digital twin and subsequent process data collected from the industrial asset or another industrial asset to verify the fidelity of the digital twin. Validation of the digital twin involves verifying that the digital twin accurately models the behavior, responses, and characteristics of the industrial asset or other industrial assets. In some scenarios, the digital twin can be validated against the same industrial asset in different operating scenarios or contexts. In other scenarios, the digital twin can be deployed at another plant facility for use with another similar industrial asset and validated against that other industrial asset.

[0266] At step 4414, based on the analysis performed at step 4412, it is determined whether all relationships defined by the digital twin are valid. This may involve verifying the relationships encoded in the smart tags constituting the digital twin, such as the relationships between key variables and related variables recorded at step 4410. If the AI ​​analysis performed at step 4412 finds one or more relationships invalid (no at step 4414), the method proceeds to step 4416, where one or more relationships defined by the digital twin are modified based on the results of the AI ​​analysis to make the digital twin consistent with the physical industrial asset. In some implementations, even after a relationship is found to be valid (yes at step 4414), the AI ​​analysis can still be applied periodically or continuously to the digital twin relative to the modeled asset, making it possible to identify and reflect changes in the asset's performance or behavior due to component degradation or changes in operating conditions in the digital twin.

[0267] The embodiments, systems, and components described herein, as well as industrial control systems and industrial automation environments in which the various aspects set forth in this subject matter specification can be performed, may include computer or network components capable of interacting across networks, such as servers, clients, programmable logic controllers (PLCs), automation controllers, communication modules, mobile computers, wireless components, control components, and so on. Computers and servers include one or more processors configured to execute instructions stored in a medium, which is an electronic integrated circuit that performs logical operations using electrical signals. The medium may be, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, and removable memory devices, which may include memory sticks, memory cards, flash memory drives, external hard disk drives, and so on.

[0268] Similarly, the term PLC or automation controller as used herein can encompass functionality that can be shared across multiple components, systems, and / or networks. As an example, one or more PLCs or automation controllers can communicate and collaborate with various networked devices across a network. This can include virtually any type of control device, communication module, computer, input / output (I / O) device, sensor, actuator, instrumentation, and human-machine interface (HMI) communicating via a network, where the network includes control, automation, and / or public networks. PLCs or automation controllers can also communicate with and control a variety of other devices, such as standard or safety-rated I / O modules, including analog, digital, programmable / intelligent I / O modules, other programmable controllers, communication modules, sensors, actuators, output devices, and so on.

[0269] Networks can include public networks such as the Internet, intranets, and automation networks. Automation networks include Control and Information Protocol (CIP) networks, including DeviceNet, ControlNet, and Ethernet / IP. Other networks include Ethernet, Data Highway and Data Highway Plus (DH / DH+), remote I / O, Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, Near Field Communication (NFC), Bluetooth, and so on. Furthermore, network devices can include a variety of development possibilities (hardware and / or software components). These include components such as switches with Virtual Local Area Network (VLAN) capabilities, Local Area Network (LAN) devices, Wide Area Network (WAN) devices, agents, gateways, routers, firewalls, Virtual Private Network (VPN) devices, servers, clients, computers, configuration tools, testing tools, and / or other devices.

[0270] In order to provide context for the various aspects of the disclosed topic, Figure 45 and Figure 46 The following discussion aims to provide a brief, general description of the suitable environment in which the various aspects of the disclosed topics can be realized.

[0271] Reference Figure 45 An example environment 4510 for implementing the aspects of the foregoing subject matter includes a computer 4512. The computer 4512 includes a processing unit 4514, system memory 4516, and a system bus 4518. The system bus 4518 couples system components, including but not limited to system memory 4516, to the processing unit 4514. The processing unit 4514 can be any of a variety of available processors. Multi-core microprocessors and other multiprocessor architectures can also be used as the processing unit 4514.

[0272] The system bus 4518 can be any of several types of bus architectures, including memory bus or memory controller, peripheral bus or external bus, and / or local bus using any of the various available bus architectures, including but not limited to 8-bit bus, Industry Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended Industry Standard Architecture (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), PCMCIA Bus, and Small Computer System Interface (SCSI).

[0273] System memory 4516 includes volatile memory 4520 and non-volatile memory 4522. A basic input / output system (BIOS) containing basic routines for transferring information between components within computer 4512, such as during startup, is stored in non-volatile memory 4522. By way of illustration and not limitation, non-volatile memory 4522 may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory 4520 includes random access memory (RAM), which acts as an external cache memory. By way of illustration and not limitation, RAM can be obtained in many forms, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

[0274] Computer 4512 also includes removable / non-removable, volatile / non-volatile computer storage media. Figure 45Disk storage device 4524 is illustrated, for example. Disk storage device 4524 includes, but is not limited to, devices such as disk drives, floppy disk drives, magnetic tape drives, Jaz drives, Zip drives, LS-100 drives, flash memory cards, or Memory Sticks. Furthermore, disk storage device 4524 may include a standalone storage medium or a storage medium combined with other storage media, including but not limited to optical disc drives, such as optical disc read-only memory devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), or digital universal optical disc ROM drives (DVD-ROM). To facilitate connection of disk storage device 4524 to system bus 4518, a removable or non-removable interface, such as interface 4526, is typically used.

[0275] It is important to recognize that, Figure 45 Software that acts as an intermediary between the user and the basic computer resources described in a suitable operating environment 4510 is described. This software includes an operating system 4528. The operating system 4528, which may be stored on a disk storage device 4524, is used to control and allocate the resources of the computer 4512. System application 4530 utilizes the operating system 4528 to manage resources through program modules 4532 and program data 4534 stored in system memory 4516 or on disk storage device 4524. It should be understood that one or more embodiments of the subject matter disclosure may be implemented using various operating systems or combinations of operating systems.

[0276] Users input commands or information to computer 4512 via input device 4536. Input device 4536 includes, but is not limited to, pointing devices such as mice, trackballs, pens, touchpads, keyboards, microphones, joysticks, game pads, satellite dish antennas, scanners, TV tuners, digital cameras, digital camcorders, webcams, etc. These input devices and other input devices are connected to processing unit 4514 via interface port 4538 through system bus 4518. Interface port 4538 includes, for example, serial ports, parallel ports, game ports, and Universal Serial Bus (USB). Output device 4540 uses some of the ports of the same type as input device 4536. Thus, for example, a USB port can be used to provide input to computer 4512 and to output information from computer 4512 to output device 4540. Output adapter 4542 is provided to indicate the presence of some output devices 4540, such as monitors, speakers, and printers, as well as other output devices 4540 that require special adapters. By way of example and not limitation, output adapter 4542 includes a graphics card and a sound card that provide a means of connection between output device 4540 and system bus 4518. It should be noted that other devices and / or systems of devices provide both input and output capabilities, such as remote computer 4544.

[0277] Computer 4512 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 4544. Remote computer 4544 can be a personal computer, server, router, network PC, workstation, microprocessor-based appliance, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 4512. For simplicity, only memory storage device 4546 is shown alongside remote computer 4544. Remote computer 4544 is logically connected to computer 4512 via network interface 4548 and then physically connected via communication connection 4550. Network interface 4548 includes communication networks such as local area networks (LANs) and wide area networks (WANs). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Wire Distributed Data Interface (CDDI), Ethernet / IEEE 802.3, Token Ring / IEEE 802.5, and so on. WAN technologies include, but are not limited to, point-to-point links, circuit-switched networks like Integrated Services Digital Network (ISDN) and its variants, packet-switched networks, and Digital Subscriber Line (DSL). Network interface 4548 may also include near field communication (NFC) or Bluetooth communication.

[0278] Communication connection 4550 refers to the hardware / software used to connect network interface 4548 to system bus 4518. Although communication connection 4550 is shown as being inside computer 4512 for clarity, it can also be outside computer 4512. For illustrative purposes only, the hardware / software necessary to connect to network interface 4548 includes internal and external technologies such as modems including conventional telephone-grade modems, cable modems, and DSL modems, ISDN adapters, and Ethernet cards.

[0279] Figure 46This is a schematic block diagram of a sample computing environment 4600 with which the disclosed subject matter can interact. The sample computing environment 4600 includes one or more clients 4602. Clients 4602 can be hardware and / or software (e.g., threads, processes, computing devices). The sample computing environment 4600 also includes one or more servers 4604. Servers 4604 can also be hardware and / or software (e.g., threads, processes, computing devices). Servers 4604 can accommodate threads to perform transformations by employing one or more implementations as described herein. One possible communication between clients 4602 and servers 4604 can be in the form of data packets suitable for transfer between two or more computer processes. The sample computing environment 4600 includes a communication framework 4606 that can be used to facilitate communication between clients 4602 and servers 4604. Clients 4602 are operatively connected to one or more client data storage devices 4608 that can be used to locally store information to clients 4602. Similarly, server 4604 is operatively connected to one or more server data storage devices 4610 that can be used to locally store information to server 4604.

[0280] The above description includes examples of subject matter innovation. It is certainly impossible to describe every conceivable combination of components or methods in order to describe the disclosed subject matter, but those skilled in the art will recognize that many further combinations and substitutions of subject matter innovation are possible. Therefore, the disclosed subject matter is intended to cover all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0281] In particular, regarding the various functions performed by the aforementioned components, devices, circuits, systems, etc., unless otherwise indicated, the terminology used to describe such components (including references to "means") is intended to correspond to any component that performs the specified function of the described component (e.g., functionally equivalent), even if the component is not structurally equivalent to the disclosed structure that performs the function of the exemplary aspects shown herein of the disclosed subject matter. In this regard, it will also be appreciated that the disclosed subject matter includes systems and computer-readable media having computer-executable instructions for actions and / or events of various methods for performing the disclosed subject matter.

[0282] Furthermore, while a particular feature of the disclosed subject matter may be disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations that may be desirable and advantageous for any given or particular application. Moreover, with regard to the use of the terms "containing" and "comprising" and variations thereof in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term "comprising".

[0283] In this application, the word "exemplary" is used to indicate that it is used as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the word "exemplary" is intended to present the concept in a concrete manner.

[0284] The various aspects or features described herein can be implemented as methods, apparatus, or articles of art using standard programming and / or engineering techniques. As used herein, the term "article of art" is intended to include computer programs accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes…), optical discs [e.g., high-density disks (CDs), digital versatile optical discs (DVDs)…], smart cards, and flash memory devices (e.g., cards, sticks, key drives…).

Claims

1. A system for digital twins of industrial assets, comprising: Memory, which stores executable components; A processor operatively coupled to the memory executes the executable components, the executable components including: The model configuration component is configured as follows: A digital twin of an industrial asset is defined based on model configuration input data. The digital twin defines the industrial asset according to hierarchical elements, wherein the digital twin includes data tags corresponding to data items generated from the industrial asset, and the data tags respectively conform to one of the basic information data types in a set of basic information data types; and The artificial intelligence (AI) engine component is configured as follows: Solving the optimization problem involves applying correlation and / or causal AI analysis to the digital twin to identify at least one data label, the data label representing a key variable indicating the overall performance of the industrial asset, related variables affecting the value of the key variable, and a functional relationship between the key variable and the related variables, wherein the set of basic information data types reduces the search space for the optimization problem; Additional fields are appended to the data labels corresponding to the key variables in the data labels, wherein the additional fields identify the relevant variables and the functional relationship between the key variables and the relevant variables; and The fidelity of the digital twin to the industrial asset is verified based on the additional fields and real-time or historical process data from the industrial asset.

2. The system according to claim 1, wherein, The AI ​​engine component is also configured to attach an additional field to the data label, the additional field identifying the type of AI analysis to be performed on the digital twin by the analysis system relative to the key variables, and The type of AI analysis is at least one of optimization, minimization, clustering, or modeling.

3. The system according to claim 1, wherein, The digital twin includes an asset model defining the industrial asset according to the hierarchical elements and a mechanical model defining the mechanical attributes of the industrial asset. The asset model and the machinery model reference the data tags.

4. The system of claim 1 further includes a device interface component configured to receive process data from the data item of the industrial asset. in, The AI ​​engine component is also configured to determine, based on AI verification analysis performed on the digital twin and the process data, whether the digital twin models aspects of the industrial asset within a defined accuracy.

5. The system of claim 4, further comprising a presentation component, the presentation component being configured to: On a client device, a graphical representation of the industrial assets is presented based on the digital twin, and In response to the AI ​​engine component determining that an aspect of the industrial asset is not modeled by the digital twin within the defined accuracy, the aspect of the industrial asset is graphically identified on the graphical representation.

6. The system according to claim 4, wherein, The AI ​​engine component is also configured to: in response to determining, based on the results of the AI ​​validation analysis, that the functional relationship between the key variable and the relevant variable is invalid, Based on further AI verification analysis performed on the digital twin and the process data, the corrected functional relationship between the key variables and the relevant variables is learned, and Modify one or more of the additional fields of the data label to replace the functional relation with the corrected functional relation.

7. The system of claim 4, further comprising a simulation component configured to perform a simulation of the industrial asset under operating conditions different from the current operating conditions of the industrial asset, based on the digital twin and the process data. in, The AI ​​engine component is also configured to: in response to determining, based on analysis of the results of the simulation, that the digital twin has not modeled the characteristics of the industrial asset under the different operating conditions within a defined accuracy, modify the digital twin to make the characteristics conform to the defined accuracy.

8. The system according to claim 4, wherein, The AI ​​engine component is also configured to: enhance the process data using computed asset behavior data generated from the application of the process data to the digital twin, and perform the AI ​​verification analysis on the digital twin, the process data, and the computed asset behavior data.

9. The system according to claim 8, wherein, The calculated asset behavior data includes at least one of the following: displacement of a product manufactured by the industrial asset, displacement of a component of the industrial asset, hysteresis of the product, velocity of the product, or force applied to the product.

10. A method for creating a digital twin of industrial assets, comprising: A digital twin is defined on a system including a processor based on configuration input data. The digital twin defines an industrial asset according to hierarchical elements, wherein the digital twin includes data tags corresponding to data items held on the device of the industrial asset, and the data tags respectively conform to one of the basic information data types in a set of basic information data types. The system performs correlation and / or causal AI analysis on the digital twin; The system solves the optimization problem to identify at least one data label based on the results of the AI ​​analysis. The data label represents a key variable indicating the quality of the operation of the industrial asset, a related variable determining the value of the key variable, and a functional relationship between the key variable and the related variable. The set of basic information data types reduces the search space for the optimization problem. The system adds additional fields to the data labels corresponding to the key variables in the data labels, wherein the additional fields identify the relevant variables and the functional relationship between the key variables and the relevant variables; and The system verifies the fidelity of the digital twin to the industrial asset based on the additional fields and real-time or historical process data from the industrial asset.

11. The method of claim 10, further comprising: The system adds another additional field to the data label, the additional field identifying the type of AI analysis to be performed by the analysis system on the digital twin relative to the key variables, wherein the type of AI analysis is at least one of optimization, minimization, clustering, or modeling.

12. The method according to claim 10, wherein, The definition of the digital twin includes defining it as an asset model of the industrial asset and a mechanical model of the industrial asset. The asset model defines the industrial assets according to the hierarchical elements. The mechanical model defines the mechanical properties of the industrial asset, and The asset model and the machinery model reference the data tags.

13. The method of claim 10, further comprising: Process data collected by the system from the data items of the industrial assets; The system applies AI verification and analysis to the digital twin and the process data; as well as The system determines whether the digital twin models aspects of the industrial asset within a defined accuracy range based on the results of the AI ​​verification analysis.

14. The method of claim 13, further comprising: The system presents a graphical representation of the industrial assets on a client device; as well as In response to the determination, based on the results of the AI ​​verification analysis, that the digital twin has not modeled aspects of the industrial asset within the defined accuracy, the aspects of the industrial asset are graphically identified on the graphical representation.

15. The method of claim 13, further comprising: The determination of the functional relationship between the key variable and the related variable based on the results of the AI ​​validation analysis is invalid: The system learns the corrected functional relationship between the key variables and the relevant variables based on further AI verification analysis performed on the digital twin and the process data. The system modifies one or more of the additional fields of the data label to replace the functional relationship with the corrected functional relationship.

16. The method of claim 13, further comprising: The system performs a simulation of the industrial asset under operating conditions different from the current operating conditions of the industrial asset, based on the digital twin and the process data. In response to an analysis of the simulation results determining that the digital twin fails to model the characteristics of the industrial asset under the different operating conditions within a defined accuracy range, the system modifies the digital twin to make the characteristics conform to the defined accuracy range.

17. The method of claim 13, further comprising: The system generates computed asset behavior data by applying the process data to the digital twin; as well as The system performs the AI ​​verification analysis on the digital twin, the process data, and the calculated asset behavior data.

18. The method according to claim 17, wherein, The calculated asset behavior data includes at least one of the following: displacement of a product manufactured by the industrial asset, displacement of a component of the industrial asset, hysteresis of the product, velocity of the product, or force applied to the product.

19. A non-transitory computer-readable medium storing instructions that, in response to being executed, cause a system including a processor to perform operations, the operations comprising: A digital twin of an industrial asset is defined based on configuration input data, with the digital twin including data tags corresponding to data items held on the device of the industrial asset, and the data tags each conforming to one of the basic information data types in a set of basic information data types. Perform relevant and / or causal AI analysis on digital twins; Solving the optimization problem involves identifying at least one data label based on the results of the AI ​​analysis. The data label represents a key variable indicating the performance quality of the industrial asset, a related variable determining the value of the key variable, and a functional relationship between the key variable and the related variable. The set of basic information data types reduces the search space for the optimization problem. Additional fields are appended to the data labels corresponding to the key variables in the data labels, wherein the additional fields identify the relevant variables and the functional relationship between the key variables and the relevant variables; and The fidelity of the digital twin to the industrial asset is verified based on the additional fields and real-time or historical process data from the industrial asset.

20. The non-transitory computer-readable medium of claim 19, further comprising attaching an additional field to the data tag, the additional field identifying the type of AI analysis to be performed by the analysis system on the digital twin relative to the key variables, wherein, The type of AI analysis is at least one of optimization, minimization, clustering, or modeling.

Images