Edge device feature engineering application

Abstract

An edge device feature engineering application is provided. An industrial gateway device supports an interactive feature engineering tool that guides a user through an intuitive process to configure data analysis for a key performance indicator (KPI) of interest. A feature engineering interface presents an interactive model view that displays available data points organized hierarchically according to a plant, machine, machine attribute, or other element. A user can select data points from the model view that have an impact on the KPI of interest. The interface also allows the user to define an executable script that defines a mathematical relationship between the selected data points and the KPI. The configuration produces an output model that defines a reduced set of data points to collect and analyze, along with the executable script, to evaluate the relationship of the KPI's status to the reduced data point values.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to industrial automation systems, such as feature engineering involving industrial data. Background Technology

[0002] 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 factory floor to control automated processes related to purposes such as product manufacturing, material handling, batch processing, supervisory control, and other such applications. Industrial controllers store and execute user-defined control programs to make decisions about 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. Summary of the Invention

[0003] A brief overview is provided below to offer a basic understanding of some of the aspects described herein. This overview is neither a comprehensive review nor intended to identify key / important elements or describe 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.

[0004] In one or more embodiments, a system is provided, comprising: a memory storing executable components, wherein the memory further stores an asset model that models an industrial process according to hierarchical elements, and the asset model references data tags defined on one or more industrial devices implementing the industrial process; a user interface component configured to: display an interactive model view of the asset model on a client device via an interface, receive a selection of a subset of data tags via interaction with the interactive model view, and receive script input defining an executable script via interaction with the interface display, the executable script defining a mathematical relationship between the subset of data tags and the state of performance indicators of the industrial process; and a model generation component configured to generate an output model based on the selection and script input, the output model defining a subset of data tags and the executable script, wherein the output model configures the system to: retrieve industrial data associated with a subset of data tags from one or more industrial devices for each unit processed by the industrial process, and execute the executable script on the industrial data.

[0005] Furthermore, one or more embodiments provide a method comprising: registering an asset model on a system including a processor, the asset model modeling an industrial process according to hierarchical elements, wherein the asset model references data tags defined on one or more industrial units performing the industrial process; presenting an interface display on a client device by the system, the interface display presenting an interactive model view of the asset model; receiving, via interaction with the interactive model view, a selection of a subset of data tags by the system; receiving, via interaction with the interface display, script input defining an executable script, wherein the executable script defines a mathematical relationship between the subset of data tags and the state of performance indicators of the industrial process; generating, based on the selection and script input, an output model defining the subset of data tags and the executable script by the system; and for each unit generated by the industrial process: retrieving, based on the output model, industrial data associated with the subset of data tags from one or more industrial units; and executing the executable script on the industrial data.

[0006] Furthermore, according to one or more embodiments, a non-transitory computer-readable medium is provided, on which instructions are stored, which, in response to being executed, cause a system to perform operations including: storing an asset model on a gateway device, the asset model modeling an industrial process according to hierarchical elements, wherein the asset model references data tags defined on one or more industrial devices executing the industrial process; presenting an interface display on a client device, the interface display presenting an interactive model view of the asset model; receiving a selection of a subset of data tags via interaction with the interactive model view; receiving script input defining an executable script via interaction with the interface display, wherein the executable script defines a mathematical relationship between a subset of data tags and the state of performance indicators of the industrial process; and generating an output model based on the selection and script input, the output model defining a subset of data tags and the executable script, wherein the output model configures the gateway device to: for each unit generated by the industrial process: retrieve industrial data associated with a subset of data tags from one or more industrial devices; and execute the executable script on the industrial data.

[0007] 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 will become apparent from the following detailed description taken in conjunction with the accompanying drawings. Attached Figure Description

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

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

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

[0011] Figure 4 It is a block diagram of a gateway device that can discover BIDTs on one or more industrial devices and supports feature engineering configuration tools.

[0012] 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.

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

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

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

[0016] Figure 9 This is a diagram illustrating the runtime operation of an example industrial unit that supports BIDT.

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

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

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

[0020] Figure 13 This is a diagram illustrating the flow of BIDT data from industrial equipment to an application server system, which provides a contextualized representation of the BIDT data transmission.

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

[0022] Figure 15 This is a diagram illustrating the workflow for creating a condensed, KPI-specific output model using a feature engineering configuration tool supported by a gateway device.

[0023] Figure 16 It is an example interactive model view that can be presented by the user interface component of the gateway device.

[0024] Figure 17a and Figure 17b It is a representation of the sample output model for the corresponding two KPIs, generated based on the user's selection of relevant attributes from the interactive model view.

[0025] Figure 18 This diagram illustrates how the gateway device collects and processes BIDT data based on a condensed output model.

[0026] Figure 19 This is an example data storage pattern where the values ​​of attributes defined by the output model are stored for multiple unique identifiers.

[0027] Figure 20a This is a flowchart of the first part of an example method for configuring feature engineering applications in industrial processes.

[0028] Figure 20b This is a flowchart of the second part of an example method for configuring feature engineering applications in industrial processes.

[0029] Figure 21 This is an example computing environment.

[0030] Figure 22 This is an example computing environment. Detailed Implementation

[0031] 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 thorough understanding thereof. 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.

[0032] 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 (optical or magnetic storage media) including attached (e.g., screw-tightened or bolted) or removably attached solid-state storage drives; an object; an executable file; an execution thread; a computer-executable program, and / or a computer. By way of example, an application running on a server and the server itself can both be components. One or more components may reside within a process and / or an execution 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 on various computer-readable storage media storing various data structures. Components can communicate via local and / or remote processing, 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 across a network such as the Internet). As another example, a component can be a device having specific functions provided by mechanical components 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 that provides specific functions via electronic components rather than mechanical components, which may include a processor to execute software or firmware that at least partially provides the functions of the electronic components. As yet another example, interfaces (one or more) may 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 are also applicable to systems, platforms, interfaces, layers, controllers, terminals, etc.

[0033] As used herein, the terms “inference” and “inference” generally refer to the process of deducing or inferring the state of a system, environment, and / or user from a set of observations captured, such as 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, i.e., a calculation of the probability distribution of states 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 leads to the construction of new events or actions from a set of observed events and / or stored event data, regardless of whether the events are temporally related or whether the events and data originate from a single event and data source or from several event and data sources.

[0034] Furthermore, the term "or" signifies inclusive "or" rather than exclusive "or." That is, unless otherwise specified or clearly indicated by the context, the phrase "X adopts A or B" means any of the naturally inclusive permutations. 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 clearly indicated by the context as a singular form, nouns used in this application and the appended claims should generally be interpreted as having a plural meaning.

[0035] Furthermore, the term "set" as used herein excludes an empty set; for example, a set containing no elements. Therefore, "set" as disclosed in this subject matter 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" as used herein refers to an aggregation of one or more entities; for example, a group of nodes refers to one or more nodes.

[0036] Various aspects or features will be presented according to the system, which 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.

[0037] Figure 1This is a block diagram of an example industrial control environment 100. In this example, several industrial controllers 118 are deployed throughout the industrial plant environment to monitor and control relevant 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 facilitate the monitoring and control of 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.

[0038] Industrial device 120 may include input devices and output devices, wherein the input devices provide data relating 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.

[0039] Industrial controller 118 can communicatively interface with industrial device 120 via hardwired or network connections. For example, industrial controller 118 may be equipped with local hardwired inputs and outputs that communicate with industrial device 120 to influence the control of the device. Local controller I / O may include digital I / O or analog I / O; digital I / O sends discrete voltage signals to and receives discrete voltage signals from field devices, while analog I / O sends and receives analog voltage or current signals from and from the devices. Controller I / O can communicate with the controller's processor via a backplane, allowing digital and analog signals to be read into 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 continuous 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., tank level, position, warnings, 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 time-series data or events on records for later retrieval and viewing.

[0040] 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 facilitate the visualization of 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, thereby 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 may use graphical representations of processes displaying measured or calculated values ​​to visualize the current status of an industrial system or its associated devices, employ color or position animations based on status, present alarm notifications, or use 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 displayed on one or more screens 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.

[0041] 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 that aggregates and stores production information collected from industrial controller 118 or other data sources, a device document repository containing electronic documents of various industrial devices constituting the controlled industrial system, an inventory tracking system, a work order management system, a repository of machine or process diagrams and documents, a supplier product document repository, 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 office network 108 of the industrial environment.

[0042] Higher-level systems 126 can perform functions less directly related to the control of industrial automation systems on the factory floor and instead target higher-level functions such as long-term planning, high-level supervisory control, analysis, reporting, or others. These systems 126 can reside on an office network 108 located externally to the factory facilities, or on a cloud platform accessible from the office and / or factory networks. Higher-level systems 126 can include, but are not limited to, cloud storage and analytics systems, big data analytics systems, manufacturing execution systems, data lakes, reporting systems, etc. In some scenarios, applications running at these higher enterprise levels can be configured to analyze control system operational data, and the results of this analysis can be fed back to the operator at the control system or directly to the controller 118 or device 120 within the control system.

[0043] Industrial assets and their associated industrial assets can generate a large amount of information during operation. Figure 2 This 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).

[0044] 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.

[0045] 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 the information available in industrial controller 202 and present that information to the user as formatted data 210 according to the data presentation format defined in application 208.

[0046] Collecting and transmitting 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 asset 202. However, the highly distributed nature of data available across numerous industrial units associated with the various industrial machines or systems constituting an industrial enterprise presents challenges to collecting and formatting data for common presentation by client devices that can be transmitted 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.).

[0047] To address these and other issues, one or more embodiments of this disclosure provide an industrial data presentation system that supports the use of structured data types for meaningful presentation of generated and transmitted industrial data. 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 example implementations, basic information data types may include structured information data types representing, for example, rates, states, odometers, and events. Within the industrial device or controller configuration, a user can define associations between corresponding physical assets (e.g., machines, production lines, etc.) and one or more basic information data types. This may include, for example, defining one or more data tags representing metrics or states of the physical assets, 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 state names for the event and state data types, any parent-child relationships between data tags, etc.).

[0048] 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.

[0049] In some implementations, the gateway device may also support feature engineering tools that provide an intuitive workflow for defining a subset of available BIDT data points known to influence the KPIs of interest, and executable scripts that define the mathematical relationships between the selected data points and the state of the KPIs. These relationships can be documented as an output model that configures the gateway to collect a reduced set of relevant data points and evaluates the health of the KPIs based on scripts applied to the collected data.

[0050] 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, apparatus, or processes described in this disclosure can constitute machine-executable components implemented within (one or more) machines, 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., (one or more) computers, (one or more) computing devices, (one or more) automation devices, (one or more) virtual machines, etc.), can cause (one or more) machines to perform the described operations.

[0051] 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 in memory 320 and executed by (one or more) processors 318. Industrial device 302 can also be with Figure 3 Interacting with other hardware and / or software components not depicted herein. For example, (one or more) processors 318 may interact with one or more external user interface devices (e.g., keyboard, mouse, display monitor, touchscreen, or other such interface devices).

[0052] 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.

[0053] 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” or Smart Objects. User-defined BIDTs 322 are stored in memory 320 (e.g., along with other defined data tags of other data types stored in the industrial device's tag database).

[0054] BIDT publishing component 310 is configured to expose the defined BIDT 322 to external systems, thereby enabling the 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 communicatively interface 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.

[0055] 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 by reference to the disclosed systems and / or methods.

[0056] Figure 4This is a block diagram of a gateway device 402 capable of discovering BIDTs on one or more industrial installations, formatting the presentation of associated data according to a user-defined asset model, and providing feature engineering tools that allow users to easily define reduced data models and algorithms to be applied to contextual data collected from BIDTs. Gateway device 402 may include a discovery unit 406, a model configuration unit 408, an application server interface unit 410, an analysis unit 412, a user interface unit 414, a model generation unit 416, 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, analysis unit 412, user interface unit 414, model generation unit 416, 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, 414, and 416 may include software instructions stored on memory 420 and executable by processor (one or more) 418. Gateway device 402 may also be compatible with... Figure 4 Interacting with other hardware and / or software components not depicted herein. For example, (one or more) processors 418 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0057] 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 or contextual data models. Asset 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 422 can represent industrial assets or collections of industrial assets according to hierarchical elements of industrial facilities or sets of facilities, wherein 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 models 422 can also assign groups of BIDTs to corresponding elements of the hierarchical model. Asset models 422 can be customized to suit the information needs of various types of information consumers (e.g., line operators, engineers, plant managers, etc.).

[0058] Application server interface component 410 can be configured to expose industrial data and asset models 422 collected from industrial equipment (e.g., industrial equipment 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.

[0059] Model generation component 412 can be configured to generate condensed output models 424 for respective process key performance indicators (KPIs) based on user selection of data points of interest from a larger asset model 422. Output models 424 define a subset of available data points collected from the BIDT of the industrial unit associated with the KPI of interest and maintain the context and relationships between those data points defined by the asset model 422 and the BIDT metadata. Model generation component 412 can also associate user-defined algorithms or scripts with each condensed output model 424. The algorithm is applied to the data points defined by the output model 424 and defines criteria for evaluating the KPIs represented by the output model 424, and determines whether actions are necessary based on the evaluation (e.g., rejecting product items, notifying of quality issues, etc.).

[0060] User interface component 414 can be configured to receive user input and present output to the user in any suitable form (e.g., visual, audio, tactile, etc.). In some embodiments, user interface component 414 can be configured to communicatively interface 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 suitable graphical interface screens and provide them 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.

[0061] The analysis unit 416 can be configured to apply user-defined algorithms associated with each output model 424 to a subset of data defined by the output model 424, and to perform actions (if any) based on the results produced by the algorithms.

[0062] 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 information and / or computer-executable instructions for performing the functions described herein with reference to the systems and / or methods disclosed herein with reference to the system.

[0063] Figure 5 This 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, 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, one or more processors 518, and memory 520 may be electrically coupled and / or communicatively coupled to each other to perform one or more functions of the application server system 502. In some embodiments, components 504, 506, 508, and 510 may include software instructions stored on memory 520 and executed by processors 518. The application server system 502 may also be associated with… Figure 5 Interacting 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.

[0064] 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).

[0065] 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 grouped BIDTs defined in the industrial units associated with the industrial asset to the corresponding hierarchical elements of plant model 522 (e.g., production line, industrial asset identifier, equipment unit, industrial unit, etc.). 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.

[0066] The presentation component 508 can be configured to generate a data presentation—for example, in the form of a graphical display layout, a set of widgets 524, etc.—that presents a selected subset of data received from the gateway device 402 according to one or more of the factory models 522. In some embodiments, the presentation component 508 can be configured to present data associated with a basic information data type label using appropriate BIDT-specific widgets (or other graphical display elements) selected from a predefined set of widgets 524. The 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 factory or office network, a cloud platform, or a public network such as the Internet). This can include delivering graphical data presentations to client devices according to one or more of the factory models 522.

[0067] 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 information and / or computer-executable instructions for performing the functions described herein with reference to the systems and / or methods disclosed herein with reference to the system.

[0068] Figure 6This 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.

[0069] 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 recognized that some implementations may include other BIDT data types without departing from the scope of this disclosure.

[0070] 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.

[0071] 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 indicate 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.

[0072] 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, where 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 representing the state of sensors or switches, indicating the defined state), such that the current state indicated by state BIDT 602 is a function of the current value of the related data tag.

[0073] 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.

[0074] 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.

[0075] 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 a defined time interval, such as energy consumption associated with an asset. In the case of quantities over a defined time interval, 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.).

[0076] The values ​​contained 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 other such transient events. 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 other 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.

[0077] 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 can 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).

[0078] It should be recognized 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.

[0079] 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 collaboratively by the user and the development of the control program 704 (e.g., a ladder logic program, a sequential function chart program, etc.) and define data tags 712 for storing and identifying various data types of 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.

[0080] 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.) communicatively connected to the industrial device 302. In various embodiments, 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.

[0081] 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 be associated with the status BIDT.

[0082] 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.).

[0083] Once the data tags (both standard and BIDT) are configured, the tag database 702 stores the configured data tags 712 in the memory 320 of the industrial device 302, where the data tags 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 following: 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.

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

[0085] It should be recognized that the above combination Figure 8 The metadata fields described are intended to be illustrative only, and the metadata of the BIDT may have any suitable set of data fields that enable the user to match the BIDT with an industrial application performed by the industrial unit 302.

[0086] 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 of 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.

[0087] 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 input modules or digital input modules) can be written to the I / O 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.

[0088] 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.

[0089] Gateway configuration application 1006 enables 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.

[0090] 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 devices 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 devices associated with assets). Thus, asset model 422 is configured by the user to associate the corresponding BIDTs with selected industrial machines, devices, production lines, and / or plant facilities, and to define the hierarchical relationships between these elements.

[0091] 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 enables users to construct 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 model definition 1002 to generate asset model 422, which can be downloaded to gateway device 402. Asset Model 422 enables 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.

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

[0093] 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 an industrial application 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., equipment node 1212 representing a feed wheel as part of a feeding device). 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. This system enables 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.).

[0094] 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.

[0095] As in Figure 11 and Figure 12 As 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.

[0096] The BIDT publishing component 310 of each industrial device 302 exposes the BIDT of the industrial device 302 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 to generate a contextualized representation of industrial application data based on the asset model 422.

[0097] Figure 13 This is a diagram illustrating the flow of BIDT data from industrial unit 302 to application server system 502, where application server system 502 transmits a contextualized representation of the BIDT data. 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 is configured with the above-described combination... Figures 6 to 9 The aforementioned BIDT 322 (or smart tags). Gateway device 402 is configured with the above-described combination. Figures 10 to 12 The various asset models 422 are described above. Asset model 422 defines the corresponding customized views of BIDT data.

[0098] 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).

[0099] 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.

[0100] Gateway device 402 includes an application server interface component 410 (see application server system 502) 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 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 received from gateway device 402 and associated BIDT data and metadata, 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 an archive storage device 1306 (e.g., a history recorder device, a cloud-based storage device, etc.) integrated with or communicatively connected to application server system 502.

[0101] 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 portrayed 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 14 As shown, in some embodiments, 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 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 the factory and / or office networks of the geographically disparate industrial facilities are linked to a cloud platform on which application server system 502 executes.

[0102] As described in the previous examples, gateway devices 402a-402c access the corresponding industrial devices ( Figure 14 (Not shown) Collects BIDT data 1408a-1408c. Each configuration of gateway devices 402a-402c has one or more asset models 1406a-1406b (as discussed above). 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.

[0103] The contextual plant data provided by the unit-level BIDT 344, together with the asset model 422 defining the hierarchical relationships between the items in this contextual data, can transform unstructured industrial process data into structured, contextualized data. During operation, the gateway device 402 can collect contextualized BIDT data from industrial units on the plant floor, structure the data according to the asset model 422, and store the resulting organized and contextualized data, for example, in local or cloud storage devices, essentially in real time. For a given industrial process, this structured data can be collected at a rate determined by a defined frequency or triggering condition (e.g., the completion of an industrial process item applied to a product), based on the sampling required to meaningfully capture the industrial process.

[0104] As described above, the BIDT data collected by gateway device 402 from industrial unit 302 is determined by the BIDT defined by asset model 422. While the contextualization and structuring of stored process data can help analytical systems gain meaningful insights into industrial processes, the specific analytical use cases of interest—such as quality, energy, overall equipment efficiency (OEE), etc.—may vary only based on a small subset of the collected data. Using big data approach to collect and analyze the complete set of available BIDT data to assess the performance of industrial processes across various metrics can be too time-consuming. Insights obtained using such big data approach may not be available in a timely manner for proactive use to inform personnel of process quality issues or to modify industrial processes to correct performance or quality degradation.

[0105] To address these and other issues, one or more implementations of gateway device 402 may support feature engineering tools that allow users to easily define condensed, use-case-specific output models and associated algorithms for evaluating various KPIs in an industry process-aligned manner. These tools can leverage data organization, achievable by BIDT 322 and asset model 422, to create intuitive and simple workflows for configuring feature engineering analysis of industry processes. The output model 424 created using the feature engineering tools can define a finite subset of the entire set of available data points relevant to a specific use case or KPI. Gateway device 402 can record or stream this condensed dataset according to a defined sampling strategy, and user-defined algorithms can be applied to this condensed dataset to assess the health of the KPIs.

[0106] Figure 15 This diagram illustrates the workflow for creating a condensed, KPI-specific output model 424 using a feature engineering configuration tool supported by gateway device 402. While the examples shown herein depict the creation of the condensed output model 424 via interaction with gateway device 402—specifically, using a feature engineering interface 1504 generated by the user interface component 414 of the gateway device—in some embodiments, the feature engineering tool described herein may be implemented on a separate system with access to asset model 422, and the resulting output model 424 may be mounted on gateway device 402 for execution. As in the previous example, gateway device 402 may be a locally provisioned device residing on the same factory network as the industrial equipment from which BIDT data is to be collected, or it may reside on a cloud platform and collect data from the industrial equipment via a secure channel between the cloud platform and the industrial equipment.

[0107] User interface component 414 can generate and provide a feature engineering interface 1504 to client device 504. This feature engineering interface 1504 guides the user through the process of creating a condensed, KPI-specific output model 424 from an existing asset model 442 (or plant model 522), and creating associated scripts 1502 for evaluating the health of various KPIs in the industrial process. Generally, each output model 424 is specific to a particular KPI or other metric of interest in the industrial process, and the health of that particular KPI or other metric will be evaluated substantially in real time. Example KPIs may include, but are not limited to, fluid viscosity, component sealing, process temperature, or other such performance indicators.

[0108] Users can submit feature engineering configuration inputs 1506 via interaction with interface 1504. These configuration inputs 1506 define the output model 424 as a selected subset of asset model attributes (corresponding to BIDT data tags or data points), define the scripts 1502 to be applied to the selected attributes, and define the endpoints for the resulting output model 424. To begin the process of defining the output model 424, the feature engineering interface 1504 allows the user to select asset model 422 from which to develop a condensed KPI-specific output model 424. Users can also select the product identifier (i.e., the product processed or manufactured by the monitored industrial system) of the product from which the output model 424 is to be defined. Based on the selected model 422 and product, the feature engineering interface 1504 presents an interactive, hierarchical view of the asset model 422 and its associated BIDT data points.

[0109] Figure 16 This is an example interactive model view 1602 that can be presented by the user interface component 414. Model view 1602 depicts a hierarchical organization of data points (corresponding to BIDT 322 defined on an industrial unit operating on a factory floor) defined by the user-selected asset model 422. In the example shown, the selected product—represented by the product identifier UID1—will be processed by different processing stations, represented by respective machine nodes 1610, including a forming machine, a filling machine, and a vision system (VISION 1) that uses optical inspection to verify that each unit of the product has been correctly processed. Below each machine node 1610, one or more attribute nodes 1612 are defined, representing various measured process attributes (e.g., temperature, position, speed, visual inspection results, etc.) obtainable from the corresponding machine. During the operation of the industrial process, the values ​​of these attributes are obtained by the gateway device 402 from the BIDT 322 corresponding to these attributes. These values ​​are represented by data nodes 1614 defined below their corresponding attribute nodes 1616. Depending on the type of machine or process being monitored, if multiple instances of the attribute are obtained from the machine (e.g., multiple temperature or speed measurements for different aspects of a process performed by the machine), there may be more than one value for a given attribute.

[0110] By interacting with the model view 1602 presented on the feature engineering interface 1504, users can select which attributes are relevant to or have a significant impact on the KPIs of interest. In some implementations, these selections can be made by selecting the data node 1614 corresponding to the relevant attributes. Figure 16In the example shown, the user has selected the forming machine temperature value represented by data node 1606 and two vision machine inspection result values ​​represented by node 1608. Since a given KPI may vary only based on a relatively small subset of available BIDT data points, this attribute selection process allows the user to define a reduced subset of relevant data points to be collected and analyzed for each KPI of interest.

[0111] Based on the user's selection of attributes from the model view 1602, the model generation component 412 generates an output model 424 based on the user-selected attributes. Figure 17a and Figure 17b These are example output models 424a and 424b, generated based on the relevant attributes selected by the user from model view 1602, for the corresponding two KPIs—viscosity and sealing performance. Each reduced or condensed model 424 includes only the attributes (BIDT data points) related to the KPI of interest selected by the user from model view 1602.

[0112] Furthermore, for each output model 424, the user can create one or more scripts 1502 via interaction with the feature engineering interface 1504. Scripts 1502 define the relationship between selected attributes and the KPIs used to construct the output model 424. These scripts 1502 can be written to apply virtually any mathematical function—e.g., mean, integral, derivative, maximum or minimum, or other such functions—to a user-selected set of attributes. Generally, scripts 1502 can mathematically define individual or collective states of the selected attributes, which translate into acceptable or unacceptable states for the KPIs. Gateway device 402 can support any suitable language for creating scripts 1502, including text-based scripting languages. Some implementations of gateway device 402 can also support the creation of scripts 1502 using a graphical script generator.

[0113] like Figure 17a and Figure 17b As shown, script 1502 can be developed for and associated with a single attribute of output model 424. These attribute-specific scripts 1502 can apply transformations to their associated attributes, including but not limited to averaging, normalization, applying maximum or minimum limits, integration, differentiation, or other such transformations. Script 1502 can also reference multiple attributes of output model 424 as variables, such that script 1502 defines the overall state of the corresponding KPI as a function of the collective state of the attributes referenced as variables in script 1502.

[0114] As part of the output model definition, users can also define data processing timing or conditions for each KPI-specific output model 424, which will trigger the recording and analysis of selected attributes defined by model 424. In some scenarios, if the KPI of interest requires high-granularity data to accurately assess the health of the KPI, users can choose to record the values ​​of selected attributes for each unit of interest. If the unit of interest is a product unit, this might involve recording the attribute values ​​for each product unit that cycles through the industrial process. If the unit of interest is a component of the industrial process itself (e.g., a machine component such as a fly bar, conveyor belt, actuator, or other such component), the attribute values ​​for each cycle of the industrial process can be recorded. Alternatively, if smaller-granularity data is sufficient to determine the health of the KPI (e.g., the KPI is not expected to change significantly between consecutive product units), users can choose to record values ​​every N units of interest (or every N cycles of the process), where N is an integer (e.g., every 10 units, every 100 units, etc.).

[0115] Users can also define endpoints or destinations for the data or analysis results generated by output model 424. In various examples, endpoints can be specified as on-premises or remote databases (e.g., cloud-based storage devices), industrial units whose operation depends on the health of the KPIs being evaluated, notification or reporting systems, or other such destinations.

[0116] The resulting output model 424 defines a subset of the total available BIDT data points to be collected and analyzed for each unit of interest to be processed by machines on the factory floor. The script 1502 associated with model 424 defines how the values ​​of these data points translate into the overall health status of the corresponding KPIs. Once created, output model 424 can be stored on gateway device 402, which collects and processes BIDT data 1408 based on output model 424 and its associated script 1502. Figure 18 This diagram illustrates the collection and processing of BIDT data 1408 by gateway device 402 according to a condensed output model 424. During operation, machines and production lines manufacturing a given product unit—including machines defined in asset model 422—are monitored and controlled by one or more industrial units 302 with BIDT capabilities. When a unit of interest is processed by a machine, gateway device 402 collects BIDT data 1408 from the BIDTs 322 of the industrial units 302. Specifically, gateway device 402 collects and stores data values ​​from a subset of available BIDTs 322 defined by the condensed KPI-specific output model 424 registered on gateway device 402. Therefore, relative to the above... Figure 13In the associated scenarios (where data and metadata are retrieved from all BIDTs 322 referenced by asset model 422), gateway device 402 collects only a subset of reduced, downsampled data (and BIDT metadata, if appropriate) from those BIDTs 322 referenced by the condensed output model 424 created by the user from asset model 422.

[0117] When an analysis event of output model 424 is triggered, gateway device 402 collects and stores a set of BIDT data 1408 of output model 424, and performs analysis on data 1408 at a time determined by the user for the data processing timing defined for model 424. As described above, the analysis event is triggered based on the data processing timing defined by the user for output model 424. Analysis can be triggered for each new unit of interest in the industrial process, for every N units of interest (where N is an integer greater than 1), or according to another data processing criterion. When an analysis event is triggered, the attribute value of the current unit of interest (corresponding to...) is... Figure 16 When data node 1614 (shown in the diagram) becomes available (e.g., when the unit of interest has been processed by all machines), these values ​​are collected by gateway device 402 from the appropriate BIDT 322. Once BIDT data 1408 and metadata are collected for the complete output model 424 of the current unit of interest, the analysis unit 416 of the gateway device executes the optimization script 1502 associated with model 424 for the collected data values ​​to determine the status, health, or acceptability of the corresponding KPI.

[0118] The result 1804 of the analysis can be directed to a terminal system or device defined by the user during the model creation workflow. In an example scenario, the analysis component 416 can be configured to send the analysis result 1804a (i.e., the result of executing script 1502 on the collected BIDT data values) to a local system or device 1802. This may involve sending the set of collected BIDT data values ​​and the health status assessment of the KPIs determined by script 1502 to a local database or other storage system for archiving. In another example, the analysis component 416 can send a command directed to an industrial device as analysis result 1804a to modify the operation of downstream machines based on the assessment of the KPI health status. In an exemplary control scenario, the gateway device 402 can be configured to instruct a machine to reject the current unit or batch of a product in response to the determination that the KPI estimate indicates a product quality problem.

[0119] Gateway device 402 can also be configured to send analysis results 1804b to higher-level systems 1806 for archiving, analysis, reporting, or notification purposes. These higher-level systems 1806 can execute on a cloud platform accessible to gateway device 402 or on a server within the factory facility. In an example scenario, gateway device 402 may, in response to determining that the results of a KPI assessment—i.e., those generated by script 1502—do not meet quality or performance standards, instruct a notification system to send a notification to a designated person's client device. Gateway device 402 can also provide collected BIDT data 1408 and / or analysis results 1804b to reporting or visualization systems (e.g., cloud-based HMIs) or higher-level analytics systems, such as Manufacturing Execution System (MES) or Enterprise Resource Planning (ERP) systems. These different endpoints can be configured by the user as part of an output model creation workflow.

[0120] Gateway device 402 can be configured to store collected BIDT data values ​​such that these values ​​are arranged according to unique identifiers (e.g., product identifiers or machine cycle identifiers). Figure 19 This is an exemplary data storage mode in which the values ​​of attributes defined by output model 424 are stored for multiple unique identifiers. For each unique identifier (UID1, UID2, etc.) of the unit of interest, gateway device 402 stores a set of values ​​corresponding to a subset of available BIDT 322 defined by output model 424; that is, as Figure 16 As shown, the user selects attributes from asset model 422 to be incorporated into the condensed output model 424. Each stored value corresponds to a data node 1614 selected by the user from the interactive model view 1602 during the output model creation workflow. Thus, each value can be identified by its hierarchical model position with respect to the originating machine (represented by machine node 1610) and the machine attribute quantified by the data value (represented by attribute node 1612).

[0121] Typically, configuring industrial data analytics requires the involvement of data scientists who may lack direct expertise in the relevant industrial sector. This necessitates coordination between data scientists and domain experts (such as industrial engineers) to develop industrial data collection and analysis applications. This process can be time-consuming and labor-intensive, and the accuracy of the resulting applications may be affected by a lack of understanding of the analyzed industrial system due to poor communication on the data scientist's side. In contrast, the feature engineering tools supported by gateway device 402 provide users with a simple and intuitive workflow for defining reduced datasets known to be relevant to specific KPIs of interest. This workflow is achieved by pre-contextualizing and pre-structuring the data using the aforementioned BIDT 322 and asset model 422. By presenting a contextualized view of available data structured in a user-understandable manner familiar with industrial processes, the feature engineering workflow described herein allows users with relevant domain expertise to configure their own feature engineering analyses and easily define how to consume or use the results of these analyses.

[0122] Furthermore, because gateway device 402 collects and analyzes a reduced BIDT dataset 1408 known to be associated with each KPI of interest, the health status of industrial processes can be assessed more quickly compared to big data approaches where analysis is applied to larger datasets that include data points unrelated to the health metrics of interest. This allows gateway device 402 or other analytical systems consuming the analysis results 1804 to initiate basic real-time responses to detected process health issues, such as rejecting products from the process or initiating machine shutdowns. This approach can also produce more accurate process health monitoring by focusing analysis only on data points known to have an impact on the KPIs being examined. Gateway device 402 can store and execute multiple user-defined output models 424, allowing for the assessment of multiple metrics of process quality in essentially real-time. These models 424 can assess a range of different metrics of industrial processes, including but not limited to product quality, energy consumption, overall equipment efficiency, or other such metrics.

[0123] Furthermore, the output model 424 generated using the above workflow can be extended to other automated systems performing similar industrial processes. In this respect, the output model 424 can be replicated or otherwise applied to multiple similar automated systems to facilitate focused data collection and KPI evaluation for these systems. Since the output model 424 references BIDT 322 through its device-level nomenclature, model 424 can be applied to any industrial system by aligning the BIDT nomenclature with that of model 424.

[0124] Figures 20a to 20bMethods according to one or more embodiments of this subject matter application are illustrated. Although the methods shown herein are shown and described as a series of actions for the purpose of simplification, it should be understood and recognized that the subject matter's inventiveness is not limited by the order of the actions, as some actions may occur in a different order than those shown and described herein and / or simultaneously with other actions shown and described herein. 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 required to implement the method according to this invention. Additionally, (one or more) interaction diagrams may represent the methods or ways in which different entities implement different parts of the method, according to the subject matter disclosure. Furthermore, 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.

[0125] Figure 20a The first part of an example method 2000a for configuring characteristic engineering applications of industrial processes is shown. Initially, at 2002, a view of an asset model stored on a gateway device is presented on an interface display transmitted to a client device. The asset model defines a hierarchical grouping of BIDT data tags defined on one or more industrial units. The asset model can define a hierarchical arrangement of plant elements—e.g., plant facilities, production areas or production lines, industrial assets, industrial equipment or devices constituting industrial assets, etc.—and map selected BIDT data tags to the corresponding elements of the hierarchy.

[0126] At step 2004, via interaction with the model view presented at step 2002, a selection of a subset of BIDT data labels to be estimated is received regarding the evaluation of key performance indicators (KPIs) of the industrial process. In an example implementation, the interface displays nodes of the model view that allow the user to select data points (BIDT data labels) known to have an impact on the KPIs.

[0127] At 2006, the definitions of one or more scripts are received via an interface. The scripts can define the state of the KPI as a mathematical function of one or more of the BIDT data tags selected in step 2004. At 2008, the definitions of actions to be initiated on the terminal device or system in response to the KPI state meeting a condition are received via an interface. The condition can be, for example, an indication that the KPI has deteriorated to the point requiring notification to personnel or control measures. Actions can include, for example, sending a notification to a designated person, generating control instructions for industrial machines or equipment (e.g., instructions to refuse a product in processing or a batch of products, instructions to stop the machine, etc.), or other such actions. At 2010, an output model is generated based on the subset of BIDT data tags selected in step 2004, the scripts defined in step 2006, and the actions defined in step 2008.

[0128] Then, the method proceeds to... Figure 20b The second part, 2000b, is shown. At 2012, during the operation of the industrial process, data and metadata generated from a subset of BIDT tags defined by the model are retrieved from the industrial unit. At 2014, it is determined whether a data analysis condition is met. This data analysis condition may, for example, arrive at the Nth unit of interest in the industrial process, where N is an integer. Other data analysis conditions are also within the scope of one or more implementations. If the data analysis condition is not met (No at step 2014), the method returns to step 2014, and the gateway device continues to retrieve data from the subset of data tags. Alternatively, if the data analysis condition is met (Yes at step 2014), the method proceeds to step 2016, where the values ​​of the subset of BIDT data tags are stored for archiving storage and analysis.

[0129] At step 2018, a script is executed for the value stored in step 2016 to determine the state of the KPI for which output model 424 is created. At step 2020, it is determined whether the state of the KPI determined based on the result of the script execution in step 2018 satisfies the conditions defined in step 2008. If the state of the KPI does not satisfy the conditions (no in step 2020), the method returns to step 2012 and repeats steps 2012 to 2020. If it is determined that the state of the KPI satisfies the defined conditions (yes in step 2020), the method proceeds to step 2022, where the action defined in step 2008 is initiated and directed to the specified endpoint device or system.

[0130] The embodiments, systems, and components described herein, as well as the control systems and automation environments in which the various aspects set forth in this subject matter specification can perform, may include computer or network components capable of interacting across a network, such as servers, clients, programmable logic controllers (PLCs), automation controllers, communication modules, mobile computers, onboard computers of mobile vehicles, wireless components, control components, etc. Computers and servers include one or more processors (electronic integrated circuits that perform logic operations using electrical signals) configured to execute instructions stored in media such as random access memory (RAM), read-only memory (ROM), hard disk drives, and removable memory devices, wherein removable memory devices may include memory sticks, memory cards, flash drives, external hard disk drives, etc.

[0131] Similarly, as used herein, the term PLC or automation controller can include 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 broadly include any type of control device, communication module, computer, input / output (I / O) device, sensor, actuator, and human-machine interface (HMI) that communicates via networks including 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, etc.

[0132] Networks can include public networks such as the Internet, intranets, and automation networks, including DeviceNet, ControlNet, security networks, and Ethernet / IP Control and Information Protocol (CIP) networks. Other networks include Ethernet, DH / DH+, remote I / O, fieldbus, Modbus, PROFIBUS, CAN, wireless networks, serial protocols, etc. Additionally, network devices can include a wide range of possibilities (hardware and / or software components). These include components such as switches with Virtual Local Area Network (VLAN) capabilities, LANs, WANs, agents, gateways, routers, firewalls, Virtual Private Network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and / or other devices.

[0133] In order to provide context for the various aspects of the disclosed topic, Figure 21 and Figure 22The following discussion is intended to provide a brief general description of suitable environments in which the various aspects of the disclosed subject matter can be implemented. Although implementations have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that implementations can also be implemented by combining other program modules and / or as a combination of software and hardware.

[0134] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will recognize that the methods of this invention can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, each of which can be operatively coupled to one or more associated devices.

[0135] The implementations shown herein can also be practiced in a distributed computing environment, where certain tasks are performed by a remote processing device linked via a communication network. In a distributed computing environment, program modules can reside in either local or remote memory storage.

[0136] Computing devices typically include various media, which can include computer-readable storage media, machine-readable storage media, and / or communication media, these two terms being used differently from each other herein. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible by a computer, and includes both volatile and non-volatile media, removable media, and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented using any method or technique for storing information such as computer-readable instructions or machine-readable instructions, program modules, structured data, or unstructured data.

[0137] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other storage technologies, optical disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media that can be used to store desired information. In this regard, the terms “tangible” or “non-transitory” as used herein with respect to storage devices, memories, or computer-readable media should be understood to exclude the propagation of transient signals themselves as a modifier and not to waive the rights to all standard storage devices, memories, or computer-readable media that do not merely propagate transient signals themselves.

[0138] Computer-readable storage media can be accessed by one or more local or remote computing devices (e.g., via access requests, queries, or other data retrieval protocols) to perform various operations on the information stored by the media.

[0139] Communication media typically implement computer-readable instructions, data structures, program modules, or other structured or unstructured data in the form of data signals, such as modulated data signals (e.g., carrier waves or other transmission mechanisms), and include any information transmission or delivery medium. The terms "modulated data signal" or "signal" refer to a signal whose characteristics are set or altered in a manner that encodes information as one or more signals. By way of example and not limitation, communication media include wired media (e.g., wired networks or direct wired connections) and wireless media (e.g., acoustic, RF, infrared, and other wireless media).

[0140] Refer again Figure 21 An example environment 2100 for implementing various embodiments of the aspects described herein includes a computer 2102, which includes a processing unit 2104, system memory 2106, and a system bus 2108. The system bus 2108 couples system components, including but not limited to system memory 2106, to the processing unit 2104. The processing unit 2104 can be any processor from a variety of commercially available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 2104.

[0141] System bus 2108 can be any of several types of bus architectures, which can also interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of the various commercially available bus architectures. System memory 2106 includes ROM 2110 and RAM 2112. The Basic Input / Output System (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, and contains basic routines that facilitate the transfer of information between components within computer 2102, for example, during startup. RAM 2112 can also include high-speed RAM, such as static RAM for caching data.

[0142] Computer 2102 also includes an internal hard disk drive (HDD) 2114 (e.g., EIDE, SATA), one or more external storage devices 2116 (e.g., disk drive (FDD) 2116, memory stick or flash drive reader, memory card reader, etc.), and an optical disc drive 2120 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). Although the internal HDD 2114 is shown as residing within computer 2102, it can also be configured for external use in a suitable rack (not shown). Additionally, although not shown in environment 2100, solid-state drives (SSDs) may be used in addition to or in place of HDD 2114. HDD 2114, (one or more) external storage devices 2116, and optical disc drive 2120 can be connected to system bus 2108 via HDD interface 2124, external storage interface 2126, and optical disc drive interface 2128, respectively. The interface 2124 for the external drive implementation may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are within the scope of the implementations described herein.

[0143] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 2102, the drive and storage medium are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to various types of storage devices, those skilled in the art will recognize that other types of computer-readable storage media, whether currently existing or developed in the future, may also be used in the example operating environment, and furthermore, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0144] Multiple program modules, including an operating system 2130, one or more application programs 2132, other program modules 2134, and program data 2136, can be stored in the driver and RAM 2112. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 2112. The systems and methods described herein can be implemented using a variety of commercially available operating systems or combinations of operating systems.

[0145] Computer 2102 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediate program may emulate the hardware environment used for operating system 2130, and the emulated hardware may optionally be different from the hardware used for operating system 2130. Figure 21 The hardware is shown in the diagram. In such an implementation, the operating system 2130 may include one of a plurality of virtual machines (VMs) hosted on the computer 2102. Furthermore, the operating system 2130 may provide a runtime environment for the application 2132, such as the Java Runtime Environment or the .NET Framework. A runtime environment is a consistent execution environment that enables the application 2132 to run on any operating system that includes a runtime environment. Similarly, the operating system 2130 may support containers, and the application 2132 may be in the form of a container, which is a lightweight, standalone, executable software package that includes, for example, code, runtime, system tools, system libraries, and application settings.

[0146] Furthermore, security modules such as Trusted Processing Modules (TPMs) can be used to enable computer 2102. For example, using a TPM, the bootloader hashes the next bootloader in a timely manner and waits for the result to match a security value before loading the next bootloader. This process can occur at any level of the computer 2102's code execution stack, such as at the application execution level or at the operating system (OS) kernel level, thereby achieving security at any level of code execution.

[0147] Users can input commands and information into computer 2102 through one or more wired / wireless input devices, such as keyboard 2138, touchscreen 2140, and pointing devices such as mouse 2142. Other input devices (not shown) may include microphone, infrared (IR) remote control, radio frequency (RF) remote control or other remote control, joystick, virtual reality controller and / or virtual reality headset, gaming pad, stylus, image input device such as (one or more) camera devices, gesture sensor input device, visual motion sensor input device, emotion or face detection device, biometric input device such as fingerprint or iris scanner, etc. These and other input devices are typically connected to processing unit 2104 via input device interface 2144, which can be coupled to system bus 2108, but may also be connected via other interfaces such as parallel port, IEEE 1394 serial port, game port, USB port, IR interface, etc. Connect via interfaces, etc.

[0148] Monitor 2144 or other types of display devices can also be connected to system bus 2108 via an interface such as video adapter 2146. In addition to monitor 2144, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0149] Computer 2102 can operate in a networked environment via logical connections to one or more remote computers (e.g., (one or more) remote computers 2148) via wired and / or wireless communications. The (one or more) remote computers 2148 can be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment electronics, peer-to-peer devices, or other common network nodes, and typically include many or all of the elements described with respect to computer 2102; however, for the sake of brevity, only memory / storage device 2150 is shown.

[0150] The described logical connections include wired / wireless connections to a local area network (LAN) 2152 and / or a larger network (e.g., a wide area network (WAN) 2154). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks such as intranets, all of which can be connected to global communication networks such as the Internet.

[0151] When used in a LAN networking environment, computer 2102 can connect to local network 2152 via a wired and / or wireless communication network interface or adapter 2156. Adapter 2156 can facilitate wired or wireless communication to LAN 2152, and LAN 2152 may also include a wireless access point (AP) disposed thereon for wireless communication with adapter 2156.

[0152] When used in a WAN networking environment, computer 2102 may include modem 2158, or may be connected to a communication server on WAN 2154 via other means (e.g., via the Internet) for establishing communication over WAN 2154. Modem 2158 may be built-in or external, wired or wireless, and may be connected to system bus 2108 via input device interface 2122. In a networking environment, program modules depicted relative to computer 2102 or parts thereof may be stored in remote memory / storage device 2150. It will be appreciated that the network connection shown is an example, and other means for establishing communication links between computers may be used.

[0153] When used in a LAN or WAN networking environment, computer 2102 can access cloud storage systems or other network-based storage systems, in addition to or replacing the external storage device 2116 described above. Typically, a connection between computer 2102 and the cloud storage system can be established via LAN 2152 or WAN 2154, for example, through adapter 2156 or modem 2158. When connecting computer 2102 to an associated cloud storage system, external storage interface 2126 can manage the storage provided by the cloud storage system as if it were any other type of external storage, with the assistance of adapter 2156 and / or modem 2158. For example, external storage interface 2126 can be configured to provide access to cloud storage sources as if these sources were physically connected to computer 2102.

[0154] Computer 2102 is operable to communicate with any wireless device or entity operatively positioned in a wireless communication network, such as a printer, scanner, desktop and / or portable computer, portable data assistant, communication satellite, any device or location associated with a wirelessly detectable tag (e.g., kiosk, newsstand, shop shelf, etc.), and telephone. This can include Wi-Fi and Wireless technology. Therefore, communication can be a predefined structure in relation to a conventional network, or simply ad hoc communication between at least two devices.

[0155] Figure 22This is a schematic block diagram of a sample computing environment 2200 that can interact with the disclosed subject matter. The sample computing environment 2200 includes one or more clients 2202. The one or more clients 2202 can be hardware and / or software (e.g., threads, processes, computing devices). The sample computing environment 2200 also includes one or more servers 2204. The one or more servers 2204 can also be hardware and / or software (e.g., threads, processes, computing devices). For example, server 2204 can accommodate threads to perform transformations by employing one or more implementations as described herein. One possible communication between client 2202 and server 2204 can be in the form of data packets suitable for transmission between two or more computer processes. The sample computing environment 2200 includes a communication framework 2206 that can be used to facilitate communication between the one or more clients 2202 and the one or more servers 2204. One or more clients 2202 are operably connected to one or more client data storage devices 2208, which can be used to store information locally on the clients 2202. Similarly, one or more servers 2204 are operably connected to one or more server data storage devices 2210, which can be used to store information locally on the servers 2204.

[0156] The above description includes examples of subject matter innovation. For the purposes of describing the disclosed subject matter, it is certainly impossible to describe every conceivable combination of components or methods; however, those skilled in the art will recognize that many other combinations and arrangements 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.

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

[0158] Furthermore, while specific features of the disclosed subject matter may have been disclosed for only one of several implementations, such features may be combined with one or more other features of other implementations, which 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".

[0159] In this application, the term "exemplary" is used to mean something 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 term "exemplary" is intended to present the concept in a specific manner.

[0160] 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 a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes…), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs)…), smart cards, and flash memory storage devices (e.g., cards, sticks, key drives…).

Claims

1. A system comprising: a memory storing executable components, wherein the memory further stores an asset model that models an industrial process in terms of hierarchical elements and that references data tags defined on one or more industrial devices that implement the industrial process; and a processor operatively coupled to the memory that executes the executable components, the executable components including: a user interface component configured to: display, via an interface, an interactive model view that presents the asset model on a client device, receive, via interaction with the interactive model view, a selection of a subset of the data tags, and receive, via interaction with the interface display, script input that defines an executable script that defines a mathematical relationship between the subset of the data tags and a state of a performance indicator of the industrial process; and a model generation component configured to generate, based on the selection and the script input, an output model that defines the subset of the data tags and the executable script, wherein the output model configures the system to, for each unit processed by the industrial process, retrieve, from the one or more industrial devices, industrial data associated with the subset of the data tags and execute the executable script on the industrial data.

2. The system of claim 1, wherein: the asset model includes a plurality of hierarchical levels, and the hierarchical elements of the asset model represent at least one of: a plant facility, a production area, a production line, a production unit, a production station, a machine, an industrial asset, a device unit, or an industrial device.

3. The system of claim 1, wherein, the user interface component is configured to receive the selection of the subset of the data tags as a selection of data nodes of the interactive model view that represent the subset of the data tags.

4. The system of claim 1, wherein: executing the executable script on the industrial data produces a result that indicates a health of the performance indicator, and the user interface component is further configured to receive, via interaction with the interface display, a definition of an action to be performed in response to determining that the result satisfies a criterion that indicates a degraded health of the performance indicator.

5. The system of claim 4, wherein, the action is at least one of: transmitting, to a client device, a notification of the degraded health of the performance indicator; control instructions that point to one or more units of a rejected product of an industrial device; or control instructions that point to a machine of the industrial process that change an operation of the machine.

6. The system of claim 1, wherein: the user interface component is further configured to receive, via interaction with an interface display, a definition of a trigger event that will trigger execution of the executable script on the industrial data, and the model generation component is configured to encode the trigger event as part of the output model.

7. The system of claim 6, wherein, the definition of the trigger event is an instruction to execute the executable script for every N units processed by the industrial process, where N is an integer.

8. The system of claim 1, wherein, The output model further configures the system to store a set of values of industrial data associated with the subset of data tags in association with respective units.

9. The system of claim 1, wherein, The data tags each conform to one of a set of basic information data types, the set of basic information data types including at least a status data type, a rate data type, an odometer data type, and an event data type.

10. The system of claim 9, wherein, the status data type represents a set of available statuses associated with an industrial asset of the industrial process, the rate data type represents a rate associated with an industrial asset of the industrial process, the odometer data type represents a cumulative quantity associated with an industrial asset of the industrial process, and the event data type represents an instantaneous event or a persistent event associated with an industrial asset of the industrial process.

11. A method comprising: registering, on a system comprising a processor, an asset model that models an industrial process in terms of hierarchical elements, wherein the asset model references data tags defined on one or more industrial devices that execute the industrial process; presenting, by the system, an interface display on a client device, the interface display presenting an interactive model view of the asset model; receiving, by the system, a selection of a subset of the data tags via interaction with the interactive model view; receiving, by the system, script input that defines an executable script via interaction with the interface display, wherein the executable script defines a mathematical relationship between the subset of data tags and a status of a performance indicator of the industrial process; generating, by the system, an output model based on the selection and the script input, the output model defining the subset of data tags and the executable script; and for each unit produced by the industrial process: retrieving, by the system, industrial data associated with the subset of data tags from the one or more industrial devices based on the output model; and executing the executable script on the industrial data.

12. The method of claim 11, wherein: the asset model comprises a plurality of hierarchical levels, and the hierarchical elements of the asset model represent at least one of: a plant facility, a production area, a production line, a production unit, a production station, a machine, an industrial asset, a device unit, or an industrial device.

13. The method of claim 11, wherein, Receiving the selection of the subset of data tags comprises receiving a selection of a data node of the interactive model view that represents the subset of data tags.

14. The method of claim 11, wherein: executing the executable script on the industrial data produces a result that indicates a health of the performance indicator, and the method further comprises receiving, by the system, a definition of an action to be performed in response to determining that the result satisfies a criterion that indicates a degraded health of the performance indicator via interaction with the interface display.

15. The method of claim 14, wherein, The action is at least one of: transmitting a notification of a degrading health of the performance indicator to a client device; directing a control instruction to the industrial device that rejects one or more units; or directing a control instruction to the industrial device that changes an operation of a machine of the industrial process.

16. The method of claim 11, further comprising: receiving, by the system via interaction with the interface display, a definition of a trigger event that is to trigger execution of the executable script on the industrial data, and encoding, by the system, the trigger event as part of the output model.

17. The method of claim 16, wherein, The definition of the trigger event is an instruction to execute the executable script for every N units processed by the industrial process, where N is an integer.

18. The method of claim 11, further comprising: storing, by the system, a set of values of the subset of data tags in association with respective instances of the performance indicator based on the output model.

19. A non-transitory computer-readable medium having instructions stored thereon that, in response to execution, cause a system including a processor to perform operations comprising: storing, on a gateway device, an asset model that models an industrial process in terms of hierarchical elements, wherein the asset model references data tags defined on one or more industrial devices that execute the industrial process; presenting, on a client device, an interface display that presents an interactive model view of the asset model; receiving, via interaction with the interactive model view, a selection of a subset of the data tags; receiving, via interaction with the interface display, script input that defines an executable script, wherein the executable script defines a mathematical relationship between the subset of data tags and a status of a performance indicator of the industrial process; and generating, based on the selection and the script input, an output model that defines the subset of data tags and the executable script, wherein the output model configures the gateway device to, for each unit produced by the industrial process: retrieve, from the one or more industrial devices, industrial data associated with the subset of data tags; and execute the executable script on the industrial data.

20. The non-transitory computer-readable medium of claim 19, wherein: execution of the executable script on the industrial data produces a result that indicates a health of the performance indicator, and the operations further comprise receiving, via interaction with the interface display, a definition of an action to perform in response to determining that the result satisfies a criterion that indicates a degrading health of the performance indicator.

Images