Patent Description:
An industrial automation system may include an industrial automation layer including a number of industrial automation components. The industrial automation components may include a wide range of components, such as valves, electric motors, a wide range of sensors, other suitable monitoring devices, or the like. The industrial automation components may provide data indicative of information or status therefrom. Moreover, the industrial automation components may include programming terminals, automation controllers, input/output (I/O) modules, communication networks, human-machine interface (HMI) terminals, and the like, to receive statuses and/or information in the form of data. The industrial automation system may provide the received statuses and/or information in various informative formats to an operator, such as alerts to change or adjust operation of one or more components of the industrial automation system or adjusting operation of one or more actuators, to manage the industrial automation system, or the like.

Generally, the networked components described above may be associated with information, such as different statuses, sensing data, or the like. The information may relate to an operation of the industrial automation system and may be monitored by one or more automation control and monitoring systems. Certain communication systems are used to transmit the information to an automation control and monitoring system of the industrial automation system. For example, each networked device may communicate with one or more automation control and monitoring systems via wired or wireless communication networks. With this in mind, it may be useful to improve methods for communication between automation control and monitoring systems and networked devices within industrial automation systems. <CIT> relates to a cloud-based operator interface system that runs as a cloud service on a cloud platform. The cloud-based operator interface system collects industrial data from one or more industrial systems via respective cloud gateway devices. A set of predefined operator interface screens are stored on cloud storage associated with the operator interface system, and delivered to authorized Internet-capable client devices upon request. The industrial data received from the cloud gateways can be delivered to the client devices from the cloud platform via the operator interface screens. Additional cloud-side services can correlate and analyzes the industrial data on the cloud platform to facilitate additional reporting, alarming, and notification features. <CIT> relates to a method and system for enabling devices within an industrial automation system to become aware of certain attributes pertaining to the industrial automation system or a part of the industrial automation system, in which the devices are located. More specifically, it relates to systems and methods for industrial automation devices to analyze received data with respect to various parts of the industrial automation system or the industrial automation system as a whole.

It is the object of the present invention to provide an improved method and system for facilitating data communication with an external component by providing structured data to an external component using a different data structure.

In one embodiment, a tangible, non-transitory, machine-readable medium, comprising machine-readable instructions that, when executed by a processor, cause the processor of an industrial automation system to perform actions. The actions include receiving a request to transmit a first dataset to an external component communicatively coupled to the processor, determining a first data structure of the first dataset based on an information model associated with the first dataset, detecting a second data structure of one or more datasets associated with the external component, and determining a relationship between the first data structure and the second data structure. The actions further include converting the first dataset into a second dataset structured according to the second data structure based on the relationship and transmitting the second dataset to the external component.

In another embodiment, an industrial automation system is described. The industrial automation system includes multiple devices for performing multiple operations. Moreover, one or multiple processors perform operations. The operations include receiving a request to transmit a first dataset to an external component communicatively coupled to the processor, determining a first data structure of the first dataset based on an information model associated with the first dataset, detecting a second data structure of one or more datasets associated with the external component, and determining a relationship between the first data structure and the second data structure. The operations further include converting the first dataset into a second dataset structured according to the second data structure based on the relationship and transmitting the second dataset to the external component.

In yet another embodiment, a method of operating an industrial automation system is described. The method includes using a computing device to perform operations that includes receiving a request to transmit a first dataset to an external component communicatively coupled to the computing device, determining a first data structure of the first dataset based on an information model associated with the first dataset, detecting a second data structure of one or more datasets associated with the external component, and determining a relationship between the first data structure and the second data structure. The method further includes converting the first dataset into a second dataset structured according to the second data structure based on the relationship and transmitting the second dataset to the external component.

These and other features, aspects, and advantages of the embodiments described in the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:.

The present disclosure relates generally to systems and methods for collecting data and context of data stored on industrial automation components, such as controllers, devices, and the like. Data models may be used to detail a relationship between certain, constraints, rules, data, data values, operations, or other types of information. The data models may specify relationships between kinds or types of data with respect to other types of data. As such, the data models may provide context with regard to how certain datasets are related to other datasets. As a result, a stable and organized structure of information may be provided to different software platforms, devices, and the like. By way of example, in an industrial automation system that employs operational technology (OT) systems and information technology (IT) systems, data communicated between the OT systems and the IT systems may not include the context (e.g., properties) of the data when the data is transmitted. Instead, raw values of the data may be transmitted without providing the appropriate context regarding the data.

With this mind, the embodiments described herein may include a component, such as a computing device, that may collect and preserve the context of the data acquired from various devices, such that the computing device may transmit the acquired data along with the context of the data. For example, if a data model defines a dataset A as including datasets B and C, the computing device may acquire dataset B along with dataset C when facilitating a request for dataset A. In certain embodiments, the data model may provide a context with regard to related datasets. The data model may be defined with respect to the datasets as SmartTags (e.g., metadata) or another suitable data structure capable of detailing the relationships between datasets in the data model. By providing the data model with retrieved datasets, the computing device may provide contextual information regarding relationships between various devices and components in the industrial automation system and enable a coherent data transfer between devices.

In addition to retrieving datasets with specific data structures related to the respective data model, the computing device may provide a user interface that enables a user to provide the context or information model associated with a particular dataset. In this way, the user may add a data model or context to datasets, such that the retrieved data may continue to be transmitted to other devices with the appropriate context.

By providing data with its context, different software platforms may synthesize or analyze the retrieved data more efficiently. For instance, unstructured component data provided without context may be pre-processed to group relevant datasets together prior to the datasets being analyzed. Moreover, by retrieving the datasets with the appropriate context, the computing device may acquire datasets and display how the datasets are related via a particular context.

In addition to retrieving datasets with SmartTags and/or other data structures related to the respective data model, the computing device may provide a user interface for a user to input transition conditions or transaction conditions to define a workflow for transferring the datasets using the context and/or data model associated with one or more datasets. For instance, the user may describe a workflow using the SmartTags and the transaction conditions to control the transition of data between a data generating component of the industrial automation system and a data destination component. For example, the user may describe a transaction condition by defining a triggering event (e.g., when data value exceeds <NUM>) for data retrieved from a first data source (e.g., a temperature sensor) to initiate capturing data from a second data source (e.g., pressure sensor). In addition, the transaction conditions may define how data will be collected from a data source. That is, the transaction conditions may detail that data is accessed from a data source using a particular driver and collection path. In this way, the present embodiments described below better enable the user to describe different datasets, associate a dataset to one or more other datasets by defining a relationship between the respective datasets, define transaction conditions to detail a custom workflow for data communication through an industrial automation system using the data model described herein. Additional details with regard to providing context with datasets and defining the manner in which the datasets are retrieved from a source and sent to a destination will be described below with reference to <FIG>.

By way of introduction, <FIG> depicts a block diagram embodiment of an example industrial automation system <NUM> in which the present embodiments may be implemented. The industrial automation system <NUM> may be any system in the material handling, packaging industries, manufacturing, processing, batch processing, or any technical field that employs the use of one or more industrial automation components. In one embodiment, the industrial automation system <NUM> may include a factory <NUM> that may encompass part of the entire industrial automation system <NUM>. As such, the industrial automation system <NUM> may include other factories <NUM> that may be employed with the factory <NUM> to perform an industrial automation process or the like.

Each factory <NUM> (or factory <NUM>) may be divided into a number of areas <NUM>, which may include different production processes that use different types of industrial automation components. In one example, one area <NUM> may include a sub-assembly production process and another area <NUM> may include a core production process. In another example, each area <NUM> may be related to a different operation being performed in the manufacturing process. For instance, in a jellybean manufacturing system, the areas <NUM> may include a jelly bean making area, a packaging area, a water filtration area, and the like. In yet another example, the area <NUM> may include a production line in which a particular industrial process may be performed. Referring back to the jellybean manufacturing system example, the production line may include a cooking line in which the jelly beans may be created, a sorting line where the jelly beans may be sorted according to a respective flavor, and a packaging line where the sorted jelly beans may be packaged into boxes or the like.

The area <NUM> may also be associated with physical locations of a number of industrial automation components <NUM>, referred hereinafter as components <NUM>. The components <NUM> may include a wide range of valves, electric motors, a wide range of sensors, other suitable monitoring devices, or the like. The areas <NUM> may also be related to different discipline areas of the industrial automation system <NUM>, such as batch operation areas, continuous operation areas, discrete operation areas, inventory operation areas, and the like.

The areas <NUM> may be subdivided into smaller units, or cells <NUM>, which may be further subdivided into components <NUM>. Using the example described above, the sub-assembly production process area <NUM> may be subdivided into cells <NUM> that may denote a particular group of components <NUM> that may be used to perform one aspect of the sub-assembly production process. As such, the cell <NUM> may include a portion of the area <NUM> such as first part of a production line. The cell <NUM> may also include different parts of a particular procedure.

These cells <NUM> may then be further subdivided into components <NUM>, which may correspond to individual industrial automation components, such as controllers, input/output (I/O) modules, motor control centers, motors, human machine interfaces (HMIs), operator interfaces, contactors, starters, sensors, drives, relays, protection devices, switchgear, compressors, network switches (e.g., Ethernet switches, modular-managed, fixed-managed, service-router, industrial, unmanaged, etc.) and the like. Although the factory <NUM>, the factory <NUM>, the areas <NUM>, and the cells <NUM> are termed as factories, areas, and cells, it should be noted that in various industries these groupings may be termed differently.

The components <NUM> may also be related to various industrial equipment such as mixers, machine conveyors, tanks, skids, specialized original equipment manufacturer machines, and the like. The components <NUM> may also be associated with devices used by the equipment such as scanners, gauges, valves, flow meters, and the like. In one embodiment, every aspect of the component <NUM> may be controlled or operated by a single controller (e.g., control system). In another embodiment, the control and operation of each aspect of the component <NUM> may be distributed via multiple controllers (e.g., control system).

The components <NUM> may be used within the corresponding cell <NUM>, area <NUM>, and/or factory <NUM> to perform various operations for the respective cell <NUM>, area <NUM>, and/or factory <NUM>. In certain embodiments, the components <NUM> may be communicatively coupled to each other, to an industrial control system <NUM>, or the like. In some embodiments, components <NUM> may include routers, switching gateways, and other common devices that may facilitate the communicatively coupling of the components <NUM>. Additionally, the industrial control system <NUM>, referred hereinafter as the control system <NUM>, may also be communicatively coupled to one or more sub-systems that may monitor and/or control the operations of each respective cell <NUM>, area <NUM>, or factory <NUM>.

In one embodiment, the control system <NUM> may include a computation device that may include communication abilities, processing abilities, and the like. For example, the control system <NUM> may be a controller, such as a programmable logic controller (PLC), a programmable automation controller (PAC), or any other controller that may monitor, control, and operate an industrial automation component <NUM>. In other embodiments, the control system <NUM> may be incorporated into one or more components <NUM> (e.g., edge computation devices) or may be implemented as a stand-alone computation device (e.g., general purpose computer), such as a desktop computer, a laptop computer, a tablet computer, a mobile device computing device, or the like.

In certain embodiments, the control system <NUM> may be implemented within devices and enable components <NUM> to connect and communicate with each other. For instance, the control system <NUM> may be implemented within network routers and/or switches. In this manner, the network routers and/or switches may host the control system <NUM> to control and operate the components <NUM> and may be communicatively coupled to a respective network router and/or switch. Since network routers and/or switches may serve as a hub for data transfers between the components <NUM>, the control system <NUM> embedded within the routers and/or switches may be strategically positioned within a data network to have access or receive data associated with various components <NUM>. As such, the control system <NUM> may perform various types of analyses on the received data and may then control and operate the respective components <NUM> more efficiently or effectively based on the results of the analysis.

In addition to the physical devices mentioned above, the control system <NUM> may include a software-based emulation of any of the aforementioned physical devices. For example, the control system <NUM> may be implemented as software modules that may perform similar operations as certain hardware controllers, devices, and the like. As such, the control system <NUM> may create virtual instances of the hardware components (e.g., controllers, I/O modules). These virtual instances may provide more flexible ways in which the control system <NUM> may be implemented to monitor and control the components <NUM>.

In one embodiment, the control system <NUM> may be implemented virtually in a cloud-accessible platform (i.e., cloud-computing system), one or more servers, in various computing devices (e.g., general purpose computers), and the like. As such, the control system <NUM> may operate as a soft controller or as a control engine running in the cloud-computing system. By virtually implementing the control system <NUM> in a cloud-computing system, the control system <NUM> may use a distributed computing architecture to perform various analyses and control operations. As more data associated with the components <NUM>, the cells <NUM>, the areas <NUM>, and the factories <NUM> become available, the distributed computing architecture in the cloud-computing system may enable the control system <NUM> to provide data analysis more efficiently. That is, since the cloud-computing system may incorporate numerous computing systems and processors to perform the data analysis, the results of the analysis may be available more quickly. In this way, the respective operations of the components <NUM>, the cells <NUM>, the areas <NUM>, and the factories <NUM> may be controlled in real-time or near real-time.

Keeping the foregoing in mind, it should be understood that the control system <NUM>, as mentioned throughout this disclosure, may be implemented as physical components (e.g., hardware-based) and/or virtual components (e.g., software-based) used to monitor and/or operate the components <NUM>, the cells <NUM>, the areas <NUM>, and the factories <NUM>. Moreover, by providing the ability to incorporate the control system <NUM> into various types of environments, the industrial automation system <NUM> may be well suited to expand and grow with the addition of new components <NUM>.

In certain embodiments, a computing device <NUM> may be connected to one or multiple control systems, such as the control system <NUM>. The computing device <NUM> may receive data from the one or multiple control systems associated with the respective components <NUM>. The computing device <NUM> may provide structure to the received data, for example by allocating the received data to datasets according to a data model. The computing device <NUM> may use data models to provide context to the received data from the control system <NUM>. In some embodiments, the computing device <NUM> may receive data from components <NUM> between multiple cells <NUM>, multiple areas <NUM>, and/or different factories <NUM> and/or <NUM>. The computing device <NUM> described herein may be referred to as the information gateway, gateway, edge computing device, or by other names in different embodiments.

In some embodiments, the computing device <NUM> may be implemented into different physical devices, such as control system <NUM> and/or component <NUM>, network routers and/or switches, or a stand-alone computing device (e.g., general purpose computer), such as a desktop computer, a laptop computer, a tablet computer, a mobile device computing device, or the like. In other embodiments, the computing device <NUM> may be implemented as a controller, such as a programmable logic controller (PLC), a programmable automation controller (PAC), or any other controller that may monitor, control, and operate an industrial automation device or component. Additionally, the computing device <NUM> may include a software-based emulation of any of the aforementioned physical devices.

As mentioned above, the computing device <NUM> may be a controller or any computing device that may include communication abilities, processing abilities, and the like. <FIG> illustrates a detailed block diagram <NUM> of components in the computing device <NUM> that may be used to perform the techniques described herein.

Referring now to <FIG>, the computing device <NUM> may include a communication component <NUM>, a processor <NUM>, a memory <NUM>, a storage <NUM>, input/output (I/O) module <NUM> including I/O ports, a display <NUM>, and the like. The communication component <NUM> may be a wireless or wired component that may facilitate communication between the components <NUM>, the control system <NUM> of the cell <NUM>, the area <NUM>, the factory <NUM> or factory <NUM>, and the like.

The communication component <NUM> may be a wireless or wired communication component that facilitates communication between the computing device <NUM> and other suitable electronic devices. The processor <NUM> may be any type of computer processor or microprocessor capable of executing computer-executable code. The processor <NUM> may also include multiple processors that may perform the operations described below.

The memory <NUM> and the storage <NUM> may be any suitable articles of manufacture that can serve as media to store processor-executable code, data, or the like. These articles of manufacture may represent computer-readable media (i.e., any suitable form of memory or storage) that may store the processor-executable code used by the processor <NUM> to perform the presently disclosed techniques. In some embodiments, the memory <NUM> may include a volatile data storage unit, such as a random-access memory (RAM) and the storage <NUM> may include a non-volatile data storage unit, such as a hard disk. The memory <NUM> and the storage <NUM> may also be used to store the data, data model, and the like. The memory <NUM> and the storage <NUM> may represent non-transitory computer-readable media (i.e., any suitable form of memory or storage) that may store the processor-executable code used by the processor <NUM> to perform various techniques described herein. It should be noted that non-transitory merely indicates that the media is tangible and not a signal.

The computing device <NUM> may also include an input/output (I/O) module <NUM>. The I/O module <NUM> may enable the computing device <NUM> to communicate with various devices in the industrial automation system. Moreover, the I/O module <NUM> may enable the computing device <NUM> to receive data from the control system <NUM> and/or other control systems. The I/O module <NUM> may be interfaces that may couple to other peripheral components such as input devices (e.g., keyboard, mouse), sensors, input/output (I/O) modules, and the like.

The display <NUM> may operate to depict visualizations associated with software or executable code being processed by the processor. In one embodiment, the display may be a touch display capable of receiving inputs from a user. For example, the display <NUM> may be any suitable type of display, such as a liquid crystal display (LCD), plasma display, or an organic light emitting diode (OLED) display. Additionally, in one embodiment, the display <NUM> may be provided in conjunction with a touch-sensitive mechanism (e.g., a touch screen) that may function as part of a control interface. The display <NUM> may provide a user with information about the data received via the communication component <NUM>. The information may include data received from control system <NUM> or other control systems and may be associated with various components. The display <NUM> may also be used by a user to provide input to the computing device <NUM>, such as defining data models with the respective data structures querying for certain data to be collected from various components of the factory <NUM> among other things.

It should be noted that the components described above with regard to the computing device <NUM> are by way of example and the computing device <NUM> may include additional or fewer components as shown. Although the block diagram <NUM> is depicted with respect to the computing device <NUM>, it should be noted that the computing device <NUM> may be associated with any suitable computing system described herein. It also should be noted that, the computing device <NUM> or other suitable components may include all or some of the described components to perform the various techniques described herein.

An example industrial automation system <NUM> of a packaging factory <NUM> and how the packaging factory <NUM> may be divided and sub-divided into areas <NUM> and cells <NUM> are depicted in <FIG>. As illustrated in <FIG>, the packaging factory <NUM> may represent an exemplary high-speed packaging line that may be employed in the food and beverage industry that may process beverage containers (i.e., a beverage line). As such, the packaging factory <NUM> may include industrial automation components that, for example, may enable machine components to fill, label, package, or palletize containers. The packaging factory <NUM> may also include one or more conveyor sections that may transport, align, or buffer containers between the machine components. Although <FIG> illustrates a packaging factory, it should be noted that the embodiments described herein are not limited for use with a packaging factory. Instead, it should be understood that the embodiments described herein may be employed in any industrial automation environment.

As illustrated in <FIG>, the packaging factory <NUM> may include machine components configured to conduct a particular function with respect to the beverage packaging process. For example, the beverage packaging process begins at a loading station <NUM>, where pallets of empty cans or bottles to be filled are fed into packaging factory <NUM> via a conveyor section <NUM>. The conveyor section <NUM> transports the empty cans from the loading station <NUM> to a washing station <NUM>, where the empty cans and bottles are washed and prepared for filling. As the washed cans and bottles exit the washing station <NUM>, the conveyor section <NUM> may gradually transition into an aligning conveyor section <NUM>, such that the washed cans and bottles enter a filling and sealing station <NUM> in a single-file line.

The filling and sealing station <NUM> may function at an optimal rate when the washed cans and bottles enter the filling and sealing station <NUM> in a steady, uniform stream. However, if the transition between the conveyor section <NUM> and the aligning conveyor section <NUM> is erratic or faster than desired, the filling and sealing station <NUM> may not function at an optimal rate. As such, optimizing performance parameters (e.g., speed, size, function, position/arrangement or quantity) of the conveyor sections (i.e., conveyor section <NUM> or aligning conveyor section <NUM>) may be beneficial to the efficiency of the packaging factory <NUM>.

As the sealed cans exit the filling and sealing station <NUM>, a buffering conveyor section <NUM> may hold the sealed cans to delay their entry into the next station. In addition, the buffering conveyor section <NUM> may transport the sealed cans in a single-file line so that the sealed cans arrive at a sterilization station <NUM> or a labeling station <NUM> at a desired time with the desired quantity of cans. Similar to the filling and sealing station <NUM>, the packaging station <NUM> or the labeling station <NUM> functions efficiently when the buffering conveyor section <NUM> operates at optimal performance parameters (e.g., optimal speed, size, function, position/arrangement or quantity). After the cans and bottles have been sterilized and/or labeled, they are packaged into cases (e.g., <NUM>-pack, <NUM>-pack, etc.) at a packaging station <NUM>, before they are palletized for transport at station <NUM> or stored in a warehouse <NUM>. Clearly, for other applications, the particular system components, the conveyors and their function will be different and specially adapted to the application.

The packaging factory <NUM> may also include the computing device <NUM> and the control system <NUM>, which may be located in a control room <NUM>, distributed onto one or more sensors <NUM>, and/or the like. The control system <NUM> may be coupled to the one or more sensors <NUM>, which may monitor various aspects of the machine components or conveyor sections of the packaging factory <NUM>. The sensors <NUM> may include any type of sensor, such as a pressure sensor, an accelerometer, a heat sensor, a motion sensor, a voltage sensor, and the like. The sensors <NUM> may be located in various positions within the packaging factory <NUM> and may measure a parameter value of interest relating to the beverage packaging process during the operation of the packaging factory <NUM>. For example, in certain embodiments, the sensors <NUM> may include sensors configured to measure the rate of bottles or containers per minute (BPM) entering or leaving a machine component (i.e., stations <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> or <NUM>), or the rate of accumulation of bottles on a portion of a conveyor section (e.g., conveyor section <NUM> or <NUM>). In general, any sensors <NUM> capable of measuring a parameter value of interest relating to the beverage packaging process of the packaging factory <NUM> (e.g., rate, pressure, speed, accumulation, density, distance, position/arrangement, quantity, size, and so forth) may be used.

In some embodiments, the packaging factory <NUM> may include a number of industrial automation power components <NUM> that may be used to control power used by various machine components in the packaging factory <NUM>. The power components <NUM> may include devices, such as drives, motors, inverters, switch gear, and the like, which may be used to operate a corresponding machine component. For example, the conveyor section <NUM> may rotate using a motor, which may be controlled via a power component <NUM>, such as a variable frequency drive.

The power component <NUM> may include a control system <NUM> that may monitor and control the operations of the respective power component <NUM>. As such, the power component <NUM> may correspond to the component <NUM> described above with respect to <FIG>. Referring back to the example above, the control system <NUM> of the power component <NUM>, such as the drive used to control the motor rotating the conveyor section <NUM>, may monitor a voltage provided to the motor and may determine the speed at which the conveyor section <NUM> may be moving. In one embodiment, the control system <NUM> of the power component <NUM> may send the data related to the speed of conveyor section <NUM> to the control system <NUM>, or to other control systems that may control other components <NUM>. In this manner, the control system <NUM> or to other control systems may be aware of the operations of the power component <NUM> and may account for these operations when determining how its respective component should operate.

Keeping the packaging factory <NUM> of <FIG> in mind, the control system <NUM> may receive data from multiple power components <NUM> dispersed throughout the packaging factory <NUM>. In some embodiments, the control system <NUM> may contextualize the received data with respect to pre-defined scopes or hierarchical levels. In other embodiments, the computing device <NUM> may query for data from the control system <NUM> and may contextualize the data according to different data models as described above. For example, <FIG> illustrates a communication network <NUM> in which the computing device <NUM> of the packaging factory <NUM> may be communicatively coupled to multiple components <NUM> and/or their respective control systems <NUM>.

In one embodiment, the scopes of the packaging factory <NUM> may be categorized based on functions of the components <NUM> and/or the cells <NUM> of the packaging factory <NUM>. For instance, referring to <FIG>, the loading station <NUM> may be categorized as cell <NUM>, the washing station <NUM> may be categorized as cell <NUM>, the sealing station <NUM> may be categorized as cell <NUM>, the sterilization station <NUM> may be categorized as cell <NUM>, the labeling station may be categorized as cell <NUM>, and the packaging station <NUM> may be categorized as cell <NUM>.

In some embodiments, a user may define, access, and/or modify a data model <NUM> via the computing device <NUM>. The user may include a factory operator personnel and may use a data destination component <NUM>. The data destination component <NUM> may include a user interface and a data center, such as a local data center <NUM> or a cloud-based data center <NUM>.

Keeping the foregoing in mind, the computing device <NUM> may use the communication component <NUM> to facilitate operations of the communication network <NUM>. For example, the computing device <NUM> may use the communication component <NUM> to communicate with one or more control systems <NUM>, such as a control system <NUM>, a control system <NUM>, and/or a control system <NUM>. The control system <NUM> may monitor and/or control the operations of a component <NUM> or a collection of components <NUM> in a cell <NUM>, an area <NUM>, or a factory <NUM>. For example, the control system <NUM>, <NUM>, and/or <NUM> may receive data or information from assets, controllers, and the like (e.g., the components <NUM>) that may be located in the cells <NUM>, the areas <NUM>, or the factory <NUM>. The computing device <NUM> may then receive the data collected from the control systems <NUM>, <NUM>, and <NUM> by using the communication component <NUM>.

In one embodiment, the computing device <NUM> may receive data related to how the industrial automation system <NUM> may be subdivided, how each area <NUM>, cell <NUM>, and the various components <NUM> may interact with each other, which components <NUM> are part of each factory <NUM>, area <NUM>, or cell <NUM>, or the like. For example, each area <NUM> may be related to a particular manufacturing process. As such, the data received by the computing device <NUM> may be processed or contextualized according to the data model <NUM>. For example, the data model <NUM> may represent the received data as part of other datasets, under different labels, and/or in different hierarchy levels of a data structure hierarchy.

In certain embodiments, the computing device <NUM> may present the received data with context and in the form of the data model <NUM>. The control systems <NUM>, <NUM>, and/or <NUM> may each identify a relationship of the one or more components <NUM> to a respective cell <NUM> or area <NUM> based on the data model <NUM>. Subsequently, the control systems <NUM>, <NUM>, and/or <NUM> may provide the identified relationships to the computing device <NUM>.

For instance, the computing device <NUM> may receive data from control systems <NUM>, <NUM>, and <NUM>, each associated with different components <NUM>. Upon receiving the data associated with the components <NUM>, the computing device <NUM> may identify a data model, such as the data model <NUM>, associated with the received data. The computing device <NUM> may then provide a representation of the received data according to the data model <NUM>, thereby providing a user with context regarding the received data. For example, the data model <NUM> may indicate that the received data is associated with the factory <NUM>, the area <NUM>, the cell <NUM>, and/or the component <NUM>.

The data model <NUM> may be defined to process the received data associated with specific components <NUM>. Moreover, the computing device <NUM> may use the data model <NUM> to extract specific details of each component <NUM>. That is, the computing device <NUM> may process the received data to provide context to datasets received from each industrial component, such as speed, flow, temperature, and acceleration, among other variables. In addition, the data model <NUM> may provide contextualized data including associations or relationships with other devices, systems, plants, servers, types of devices, or other categories to classify the received data.

In some embodiments, the data model <NUM> may be pre-defined in the storage <NUM> of the computing device <NUM>. The data model <NUM>, a portion of the data model <NUM>, or a component associated with the model <NUM> may be transmitted from the control systems <NUM>, <NUM>, and/or <NUM> to the computing system <NUM>. In certain embodiments, a user may define the data model <NUM> for received data via a user interface of computing system <NUM>, for example by using the display <NUM>. The computing device <NUM> may receive instructions definitive of a data model <NUM>, the computing device <NUM> may store the received data model <NUM> on the storage <NUM>, and may use the user-defined data model <NUM> to organize the received raw data <NUM>. Subsequently, the computing device <NUM> may provide the structured data <NUM> to the destination component <NUM> and/or the user in response to receiving the request for information (e.g., speed data, flow data, and temperature data).

The data model <NUM> may provide structure to the received raw data <NUM>, such that the received raw data <NUM> may be provided to the user in the form of structured data <NUM>. The structured data <NUM> may include datasets and/or one or more hierarchal representations of the datasets. The data model <NUM> may also be incorporated into a workflow that may include transaction conditions and conditional transactions between components of the data model <NUM> while providing the structured data <NUM> with the transferred datasets. In some embodiments, the user may define such transactions by determining one or more aspects of the datasets based on the data model <NUM> via the computing device <NUM>. In different embodiments, the user may define the transactions by specifying how the datasets are to be retrieved and transferred based on one or more relationships between the datasets of the data model <NUM>. For example, the user may define a transaction to retrieve datasets from data components of a data model associated with a data source, and transferring the retrieved datasets to data components of a different data model that may be part of the data destination component. The different data model may be data model provided by a third party provider in the local data center <NUM> or the cloud-based data center <NUM> to facilitate the transfer.

The datasets may correspond to different factories, areas, cells, components, and/or properties of components, among other things, as shown in more detail in <FIG>. The relationships of the datasets may correspond to how different factories, areas, cells, and/or components are related to each other. For example, in a hierarchical representation of the datasets, a factory dataset may include one or more area datasets.

The computing device <NUM> may then provide structured data <NUM> to the local data center <NUM> or the cloud-based data center <NUM>. For example, the computing device <NUM> may receive a request for information and provide contextualized data in response to receiving the request using the data model <NUM>. The computing device <NUM> may provide the contextualized data to a data center or the user. That is, the computing device <NUM> may provide a portion of the structured data <NUM> to the data center or the user in response to receiving the request for information (e.g., speed data, flow data, and temperature data).

By the way of example, <FIG> illustrates raw data <NUM> that may be transmitted from the control systems <NUM>, <NUM>, and/or <NUM> to the computing system <NUM>. The raw data <NUM> may be unstructured and may include all the data provided by the control systems <NUM>, <NUM>, and <NUM>. Since the raw data <NUM> is unstructured, processing the raw data <NUM> may prove to be comprehensive and computationally expensive due to the lack of structure or organization.

On the other hand, <FIG> depicts an example of structured data <NUM> organized according to the data model <NUM>. The data structure <NUM> may be associated with the hierarchy levels of the data model <NUM> and the respective data sources, such as control systems <NUM>, <NUM>, and/or <NUM>. As such, hierarchical representation of the data structure <NUM> may include different datasets <NUM> in hierarchical levels corresponding to different factories <NUM> or <NUM>, areas <NUM>, cells <NUM>, components <NUM>, properties of individual components <NUM>, and other properties of one or more datasets to name a few examples. Indeed, the data structure <NUM> may detail a relationship between datasets <NUM> with respect to hierarchy, dependencies between datasets <NUM>, and the like.

In some embodiments, the computing device <NUM> may also receive transaction data <NUM> related the structured data <NUM>. The transaction data <NUM> may include event driven conditions that specify one or more conditions in which data is to be transmitted to other components. Moreover, the transaction data <NUM> may specify details that help facilitate a dataset transaction between a data source and a data destination. The transaction data <NUM> may be received based on a selection of a driver or a data collection scheme/format to retrieve data from a data source received by a user input. In this way, the driver may detail how transactions between different components are to be facilitated. In one embodiment, a user may select a driver that represents the manner (e.g., format) in which the requested datasets are to be retrieved from a data source. By way of example, the driver may be defined as FactoryTalk Live Data, EtherNet/IP (Common Industrial Protocol (CIP)), OPC Direct Access (e.g., machine to machine communication protocol for industrial automation developed by the OPC Foundation), or any suitable communication protocol. In some embodiments, the transaction data <NUM> may be defined for each component or each type of component that may be associated with the factories, areas, cells, and the like. In addition to the communication protocol, the transaction data <NUM> may include one or more defined rules, relationships, and/or triggering events that characterize how datasets are stored the data model <NUM>.

The hierarchy representation of the structured data <NUM> may be pre-defined, user-defined, or modifiable by a user by the way of a graphical user interface (GUI) visualization as described in more detail below. It should be understood that the visualization is describing one embodiment and the interaction between a user and the computing device <NUM> may be provided by any viable interface.

With the forgoing in mind, <FIG> illustrates a procedure <NUM> for contextualizing raw data according to a data model, such as the data model <NUM>. The procedure <NUM> may be performed by the computing device <NUM> or any suitable computing device for defining datasets <NUM> and/or the transaction data <NUM>. It should be understood that the order of the procedure <NUM> is provided by way of example and the procedure <NUM> may be performed in any suitable order.

Referring now to <FIG>, at block <NUM>, the computing device <NUM> may detect the one or multiple control systems <NUM>, such as control systems <NUM>, <NUM>, and/or <NUM> of the <FIG>. Control systems <NUM> may communicatively couple to the computing device <NUM> using wired connection or wireless connection. In different embodiments, the computing device <NUM> may detect the control system <NUM> upon connection, for example by the way of a pre-installed driver on the computing device or a respective driver module for the connected control system <NUM>.

At block <NUM>, after detection of the one or multiple connected control systems <NUM>, the computing device <NUM> may present the connected control systems <NUM> via a display. For example, the computing device <NUM> may provide a list of all the detected control systems <NUM> as illustrated in visualization <NUM> of <FIG>. The visualization <NUM> may include detected control systems <NUM> and/or other viable sources of data represented for selection by the user, when a data sources tab <NUM> is selected. That is, the user may define the data model <NUM> using the data sources presented by the visualization <NUM>. In some examples, the sources of data in the visualization <NUM> are auto-detected, whereas in other examples, the visualized sources of data or at least a number of visualized sources of data are configured by the user.

Referring to <FIG>, the visualization <NUM> may provide the user with additional functionality. The additional functionality may include adding new control systems using an input visualization <NUM>, removing a detected control system using an input visualization <NUM>, refreshing the list of control systems using an input visualization <NUM>, clearing the list of control systems using an input visualization <NUM>, and/or editing properties of the detected control system using an input visualization <NUM>. Referring back to <FIG>, at block <NUM>, the computing device <NUM> may receive input indicative of a selection of a detected control system <NUM> as a first source of data. After receiving the selection, the computing device <NUM> may access the selected control system <NUM> and receive raw data <NUM> associated with the selected control system <NUM>.

At block <NUM>, the computing device <NUM> may present a list of data models <NUM> that may be used for contextualizing data associated with the selected control system <NUM> at block <NUM>. <FIG> may depict an embodiment of a visualization <NUM> that provides an example list of data models <NUM> selectable by the user via display <NUM>.

The visualization <NUM> may include a configuration tab <NUM> including one or multiple child tabs. For example, the child tabs may include the data sources tab <NUM>, a models tab <NUM>, and an applications tab <NUM>. The data sources tab <NUM> may include one or multiple control systems <NUM> selectable by the user to identify sources of data. The models tab <NUM> may include the data models <NUM> selectable by the user to be used with the selected sources of data (e.g., one or multiple control systems <NUM>). The applications tab <NUM> may include the destination components <NUM> where the structured data <NUM> may be sent. The models tab <NUM> and the applications tab <NUM> are discussed in more details below. It should be appreciated that in different embodiments, a visualization for contextualizing raw data according to a data model may include additional or fewer tabs, may visualize a single tab including different portions associated with different information such as selectable data sources, selectable data models, and/or selectable data destination components or applications to be used.

Referring back to <FIG>, the models tab <NUM> may include multiple data models <NUM> available for selection by the user. For example, the user may select the data model <NUM> to be used with a selected control system <NUM>, as depicted in the <FIG>. Furthermore, a user may create data models via add data model feature <NUM>, remove existing data models via delete data model feature <NUM> and/or edit the existing data models <NUM> via edit data model feature <NUM> of the visualization <NUM>. The data model <NUM> defines a hierarchy or relationship between different datasets in the data model <NUM>.

At block <NUM>, the computing device <NUM> may receive input to create a new data model for the selected control system. The user may use the add data model feature <NUM> of visualization <NUM> to create the data model <NUM>. The add data model feature <NUM> may prompt the user to provide details for the new data model <NUM>. For instance, the add data model feature <NUM> may prompt the user to a visualization <NUM> depicted in <FIG> and may include an example of tools provided to the user for creating a hierarchical representation <NUM> associated with components of the data model <NUM>. In some embodiments, one or multiple properties associated with the data source, the detected control system, the respective sensor, and/or the industrial automation component may be configured, re-configured, and/or used as a triggering event by the user via a properties pane <NUM> described with respect to <FIG>.

The visualization <NUM> may include the sources of data, such as the one or multiple control systems <NUM> (e.g., as described with respect to visualization <NUM>), which may be represented by tags <NUM> (e.g., SmartTags). A dataset or a portion of a dataset of the one or multiple datasets <NUM> may be represented by the tags <NUM>. For example, the user may use an input visualization <NUM> to add and/or describe the tags <NUM> to represent a control system <NUM> or a portion of data sourced from the control system <NUM>. The visualization <NUM> may also include the data model <NUM>, for example selected previously in the visualization <NUM> by the user, or defined by the user using the add data model feature <NUM>. Moreover, the visualization <NUM> may include the properties pane <NUM> including one or multiple properties associated with a selected data source (e.g., by selecting a data source) or a selected component of the data model <NUM> (e.g., node <NUM> or child <NUM>).

In some embodiments, the user may select a component <NUM> of the data model <NUM> using the visualization <NUM> and one or multiple properties <NUM> associated with the selected component <NUM> may be provided to the user via the properties pane <NUM>. The selected component <NUM> may be the dataset <NUM>, and may include the transaction data <NUM>, among other components. The properties <NUM> may include different values associated with the selected component <NUM>, values associated with datasets associated with the selected component <NUM>, the transaction conditions associated with the selected component <NUM>, or other properties associated with the selected component. For example, the properties <NUM> may include a visualization of values of datasets associated with the selected component <NUM>. Moreover, the properties pane <NUM> may include properties associated with the transaction data <NUM>. That is, the properties pane <NUM> may provide a visualization of transaction data <NUM>, including event driven conditions that specify one or more conditions in which data associated with selected component <NUM> may be transmitted to other components, one or more defined rules, relationships, and/or triggering events that characterize how datasets associated with the selected component <NUM> are stored the data model <NUM>, and/or other properties associated with the selected component <NUM>. The user may define and/or modify the transaction data (e.g., transaction data <NUM>) using the properties pane <NUM>.

At block <NUM>, the computing device <NUM> may receive input to define components of the data model <NUM>. The visualization <NUM> may include an add component feature <NUM> and a remove component feature <NUM> that may add and remove components to the data model <NUM>. By the way of example, the user may use the add component feature <NUM> to define a parent component "node <NUM>" and a child component "child <NUM>". For example, the parent component "node <NUM>" may be defined as a parent component that includes the child component "child <NUM>" as described below.

At block <NUM>, the user may receive input to define a data structure, such as the hierarchical representation <NUM>, associated with a selected part of the data model <NUM>. For example, the user may associate data model component "node <NUM>" to the data model component "child <NUM>", such that the data model component "child <NUM>" is represented as being a part of the data model component "node <NUM>", as depicted in <FIG> as part of the hierarchical representation <NUM>. In this way, the user is enabled to define the hierarchical representation <NUM> of the structured data <NUM>. That is, the user may bind tags to associate the data model components by using different features in different embodiments, such as drag and dropping the tags <NUM> to hierarchical level in the hierarchical representation <NUM> to associate datasets to other components. In different embodiments related to the described methods, the user may associate different number of data model components to define the hierarchical representation <NUM>. It should be noted that components of the data model <NUM> may include the datasets <NUM> (e.g., represented by the tags <NUM>) along with transaction data <NUM>. The user may describe a workflow that specifies how the datasets <NUM> and the transaction data <NUM> is used.

In such embodiments, the user may define one or multiple datasets <NUM> and/or the transaction data <NUM> for each of the hierarchical levels of the data model <NUM>, for particular datasets in the data model <NUM>, for different data sources in the industrial automation system <NUM>, and the like. The transaction data <NUM> may include triggering events defined with respect to properties <NUM> of a selected component of the data model <NUM>. The workflow may be defined using transaction data (e.g., transaction data <NUM>) with transaction conditions that may define a relationship between the components of the data model <NUM>, and/or between the components of the data model <NUM> and other data models and/or data destination component <NUM>. The workflow may include one or multiple triggering events, conditional relationships, or a combination of both, using the properties <NUM> of a selected component (e.g., the selected component <NUM>). For example, one or multiple conditions (e.g., temperature to exceed <NUM> degrees) may be satisfied with respect to properties of the retrieved data in order for the computing device <NUM> to perform certain actions (e.g., data transfer, control equipment) with respect to the retrieved data or other components in the industrial automation system <NUM>. The workflow may also automate a process internal to the components of the data model <NUM> and/or by mapping the components of the data model <NUM> to one or multiple external data models.

Moving on to block <NUM>, the computing device <NUM> may receive input to associate the raw data <NUM> of the selected control system <NUM> to a part of data model <NUM> and/or one or more data model components. By the way of example, a user may select data model component "node <NUM>" and the data sources tab <NUM> to select one or more data sources (e.g., the selected control system <NUM>) to be associated with the data model component "node <NUM>". Multiple tags <NUM> may represent available data sources configured, for example, using the visualization <NUM> of <FIG>. That is, the user may select one or more data sources from an available data sources window, as depicted in visualization <NUM> of <FIG>, to be associated with the data model component "node <NUM>". The user may repeat this process for "child <NUM>" and other components of the data model <NUM>.

At block <NUM>, the computing device <NUM> may store the defined model(s) in the storage <NUM>. The data model may be saved on the memory <NUM> or storage <NUM> of the computing device <NUM>.

At block <NUM>, the computing device <NUM> may present the available data destination components <NUM> in which the data, data model <NUM>, or both may be sent, in response to the applications tab <NUM> is selected. For example, <FIG> may include a visualization <NUM> that may depict the application tab <NUM> of the configuration tab <NUM>. The application tab <NUM> may include multiple data destination components <NUM>. The application tab <NUM> may enable the user to select one or multiple data destination components <NUM>. The data destination components <NUM> may include a local data center <NUM>, the cloud-based data center <NUM>, and various other applications or programs that may be used to store, organize, or analyze the data. The user may associate the new data model <NUM> or specific components of the new data model <NUM> to one or multiple data destination components.

The selection of the application may include mapping one or more datasets <NUM> of the data model <NUM> to one or multiple datasets associated with a second data model associated with a third-party application. For example, <FIG> depicts a visualization <NUM> including the data model <NUM> and a second data model <NUM> associated with a third party application. The second data model <NUM> may be selected by the user using the applications tab <NUM> and the visualization <NUM> of <FIG>. In some embodiments, the user may use the described tools to describe a workflow that coordinates how the datasets <NUM> are retrieved and stored based on the transaction data <NUM>. In this way, the datasets <NUM> may be tailored to a specific third-party application in accordance to the transaction data <NUM>, which may be specified by the user. Indeed, the transaction data <NUM> may be configurable, such that the datasets <NUM>, conditions for collecting the datasets, and conditions for mapping the datasets to a destination component <NUM> within the second data model <NUM> may be configurable or set by a user.

It should be noted that the procedure <NUM>, visualization <NUM>, visualization <NUM>, visualization <NUM>, visualization <NUM>, and visualization <NUM> described above are provided for illustrative and descriptive purposes and should not be used as limitations to the scope of the disclosure. For instance, the procedure <NUM> may be performed in any viable order, some procedure steps may be added, and some of the aforementioned blocks may be removed partly depending on the application of the procedure. Any viable electronic display may be used with the computing device <NUM>, including a non-graphical user interface. The viable user interface may provide a coherent data flow between an industrial automation system <NUM> and various data destination components <NUM> in different embodiments.

As described above, the procedure <NUM> may be used for defining the data model <NUM> or a selected part of the data model <NUM> by the user. Referring now to <FIG>, a process <NUM> may describe an example for requesting and receiving data from the control system <NUM> using the defined data model <NUM>. For example, the computing device <NUM> may use the data model <NUM> to provide contextualized data to a data requestor using the process <NUM> as described in detail below.

At block <NUM>, the computing device <NUM> may receive a data request. The data request may be from the data destination component <NUM>, based on the transaction data <NUM>, or both. As discussed above, the transaction data <NUM> may define a trigger or threshold for a value in a dataset that causes the request to be sent from the data destination component <NUM>. Alternatively, the computing device <NUM> may automatically generate the request based on the value in the dataset meeting or exceeding the threshold defined in the transaction data <NUM>. For instance, if the dataset corresponds to pressure data, the transaction data <NUM> associated with the pressure data may specify that the pressure data should be sent to the data destination component <NUM> if the value exceeds <NUM> psa. In any case, in response to receiving the data request, the computing device <NUM> may use the data model <NUM> to identify a respective control system <NUM> associated with the requested data.

At block <NUM>, the computing device <NUM> may submit the data request to the respective control system <NUM>. In some embodiments, the request may be associated with one or multiple respective control systems <NUM> and may be formatted in accordance with conditions specified in the transaction data <NUM>. That is, the transaction data <NUM> associated with the requested dataset may specify a communication protocol (e.g., request type, syntax, communication port) that the computing device <NUM> should use to request access.

At block <NUM>, the computing device <NUM> may receive raw data <NUM> from the respective control system <NUM>. In some embodiments, the computing device <NUM> may receive the raw data <NUM> with a respective data model, such as the data model <NUM>, from the respective control system <NUM>. That is, the data model <NUM> may be part of the metadata of the raw data <NUM>, may be stored in a database accessible to the computing system <NUM>, provided with the request, part of the transaction data <NUM>, or the like. As such, the computing device <NUM> may use the data model <NUM> to provide context for the received raw data <NUM>.

At block <NUM>, the computing device <NUM> may send the requested data to the data destination component <NUM>. In some embodiments, the computing device <NUM> may organize the raw data according to the data model <NUM>. For example, the computing device <NUM> may structure the received raw data <NUM> with respect to the received data model <NUM> and send the structured raw data <NUM> to the data destination component <NUM>. For instance, if the requested raw data <NUM> is associated with a child node of another dataset, the computing device <NUM> may send the requested raw data <NUM> with the datasets associated with the parent node.

In some embodiments, the computing device <NUM> sends the requested data to the data destination component <NUM> as structured data in accordance with the data model <NUM> or with reference to the data model <NUM>. In any case, the data destination component <NUM> may, in turn, store the data in accordance with the data model <NUM>. As such, the data sets retrieved by the data destination component <NUM> may maintain its context providing a user with a more comprehensive view of the relational nature of the datasets.

By performing the embodiments described herein, computing systems may bind data sets, data models <NUM>, and transaction data <NUM>, such that data destination components <NUM> (e.g., applications) may efficiently collect and organize data with its appropriate context. That is, the binding process associates tags, models and transactions with an instance of an application such that pre-defined properties or defaults may be utilized for storing and/or collecting datasets in an efficient manner. Moreover, the present embodiments described herein enable new properties to be entered by a user for a particular instance (e.g., dataset) to allow datasets to be contextualized for more effective data presentation. It should be noted that the structured context of the datasets and the conditions of the transactions described herein enable the respective computing devices to operate more efficiently by coordinating the flow of data through limited network connection bandwidths. Further, the contextualized data provides a specific format in which datasets can be stored to enable users to understand and other devices to process the datasets more effectively.

In addition to binding the datasets <NUM>, the transaction data <NUM>, and other types of data to contextualize data employing the data model <NUM>, the present embodiments described herein are also directed towards systems and methods for adapting or implementing certain functions using an adapter component that may be part of the computing device <NUM> to export the contextualized data to external devices. More specifically, the present disclosure is related to leveraging tools provided in a software development kit (SDK) or other tools provided by an external platform, such that functions that operate with the external platform may be executing natively by the computing device <NUM> using the adapter component.

Because of the large number of system variables that may be monitored and controlled in real time or near real-time, the computing device <NUM> may monitor data generated by the industrial automation system <NUM>, which may be associated with vast amounts of near real-time data. The large quantity of data generated by the industrial automation system <NUM> may make it possible to apply a broad range of plant analytics to the automation systems and processes that make up an industrial enterprise or business. Reports, charts, and other human-readable formats are often available or may be created for plant personnel and others wishing to monitor and review the generated data in either a real-time mode or at a later time after the data has been stored.

With this in mind, the computing device <NUM> may employ an adapter component to acquire the industrial automation data for purposes such as those described above from various data sources that are located in the industrial automation system <NUM>. The adapter component (e.g., implemented in hardware or software) may interact with a respective external platform via a respective protocol and appropriately translate/interpret the data received from each data source to acquire the data stored therein. In addition to acquiring the data from various data sources, the adapter component may interact with external software platforms (e.g., IoT platforms) that may provide visualization tools, analytic tools, monitoring tools, and the like to help organize and glean information from the collected data.

With the foregoing in mind, an industrial automation system <NUM> provides the structured data <NUM> to an external component (e.g., external platform, external device) such as a data center, operational technology (OT) systems, and/or information technology (IT) systems. The external component uses a different data structure for storing and/or processing the data. In some embodiments, the computing device <NUM> may generate and use an adapter component to associate the structured data to the data structure of the external component using a native data model (e.g., the data model <NUM>) of the industrial automation system <NUM>.

In some embodiments, the computing device <NUM> may obtain an application program interface (API) and/or a software development kit (SDK) of the external component. The API and/or SDK may specify an external data model (or part of the data model) that is to be used by the external component. The computing device <NUM> may determine a relationship between the structured data <NUM> of the data model <NUM> and the external data structure of the external component based on the obtained API and/or SDK. Using the relationship between the structured data <NUM> and the external data structure, the computing device <NUM> may generate the adapter component. The adapter component may associate data and the context of the data of the data model <NUM> to the external data structure of the external component. As such, the computing device <NUM> may use the adapter component to provide data with context according to the identified relationship to the external component.

In specific embodiments, the computing device <NUM> may provide a dedicated adapter component for mapping structured data to an external data structure of each external component connected to the computing device <NUM>. For example, the computing device <NUM> may provide different adapter components for different external components based on obtaining the respective APIs and/or SDKs. That said, in some other embodiments, the computing device <NUM> may determine an adapter component for mapping structured data <NUM> to multiple external components. For example, the computing device <NUM> may provide an adapter component for multiple external components based on obtaining the respective APIs and/or SDKs. Nevertheless, by providing and using the adapter components, the computing device <NUM> may use a native data model while providing structured data to external components configured using a different data structure.

<FIG> illustrates a communication network <NUM> in which the computing device <NUM> of the packaging factory <NUM> may be communicatively coupled to multiple components <NUM> and/or their respective control systems <NUM>. In the depicted embodiment, the computing device <NUM> may receive raw data <NUM> from the control systems <NUM>, <NUM>, and/or <NUM>. Moreover, the computing device <NUM> determines the structured data <NUM> according to the data model <NUM> detailed above. As mentioned above, the computing device <NUM> may provide the structured data <NUM> to the data destination component <NUM>.

In the depicted embodiment, the computing device <NUM> provides the structured data <NUM> to an external component <NUM> by mapping the structured data <NUM> to a data model of the external component <NUM>. For example, the computing device <NUM> may communicatively couple the external component <NUM> using a WebSocket connection. However, in other embodiments, other suitable connections may be used. Nevertheless, the computing device <NUM> may obtain an API and/or SDK data <NUM> of the external component <NUM> to facilitate data communication with the external component <NUM> using the native data model of the computing device <NUM> (e.g., the data model <NUM>).

The API and/or SDK data <NUM> may provide a representation of the expected data structure of the external component <NUM> to the computing device <NUM>. The computing device <NUM> generates an adapter component <NUM> based on the received API and/or SDK data <NUM>. That is, the computing device <NUM> may generate a software engine or program a hardware component (e.g., logic circuitry) to operate as the adapter component <NUM> to facilitate providing a representation of the structured data <NUM> to the external component <NUM> using the data structure of the external component <NUM>. The adapter component <NUM> may identify a relationship between the data model <NUM> and the data structure of the external component <NUM> based on the API and/or SDK data <NUM>.

In some embodiments, the adapter component <NUM> may include logic circuitry to identify and provide the relationship between the data model <NUM> and the structured data of the external component <NUM>. In some embodiments, the adapter component <NUM> may generate an endpoint <NUM> based on the mapped relationship between the data model <NUM> and the data structure of the external component <NUM> to communicate structured data <NUM>. The structured data <NUM> may be data received by the adapter component <NUM> and organized according to an external data structure interpretable by the external component <NUM>. The endpoint <NUM> may be a port or point of communication that may stream data directly to the external component according to the external data structure. For example, the computing device <NUM> may use the endpoint <NUM> as a proxy for providing contextualized data to the external component <NUM>. That is, the adapter component <NUM> may modify the structured data <NUM>, such that the endpoint <NUM> receives the structured data <NUM>, which is provided directly to the external component <NUM>.

By way of example, model structures (e.g., data model <NUM>) generated from a function provided within the computing device <NUM> may not be carried through to the external component <NUM> without manually receiving the data and manually creating the model structure of the external component <NUM>. However, the adapter component <NUM> may replicate the model structure and tags within the external component <NUM> by accessing an API and/or SDK data <NUM> of the external component <NUM>, as mentioned above. For instance, in one embodiment, the adapter component <NUM> may call this API and/or SDK data <NUM> from the computing device <NUM> through a WebSocket connection over a network TCP/IP connection. This would result in a performance gain over other applications that may use other protocols or APIs (e.g., REST API) over other connections (e.g., HTTP connection).

Moreover, the adapter component <NUM> may use the API and/or SDK data <NUM> of the external component <NUM> to automate a setup and configuration of applications, data entries, and the like within the external component <NUM> without performing a manual input or a file export and import operation. For example, in one embodiment, the adapter component <NUM> may use an SDK (e.g., of the API and/or SDK data <NUM>) associated with the external component <NUM> to generate tools, functions, APIs, and the like that may enable the adapter component <NUM> to interface with the external component <NUM>. In this way, the adapter component <NUM> may leverage its translation and interconnectivity capabilities with the tools provided in the SDK of the external component <NUM> to create native tools and commands that may enable a user to generate and execute functions that will be performed on the external component <NUM> via the computing device <NUM>. As a result, the data generated or acquired using the native tools of the computing device <NUM> may be provided to the external component <NUM>, such that the external component <NUM> may maintain the data format, tags, and other properties generated within the computing device <NUM>.

In some embodiments, the computing device <NUM> may coordinate with the adapter component <NUM> to employ the native tools generated using the SDK of the external component <NUM> to perform automated operations in the external component <NUM>. For example, data acquired by the computing device <NUM> may include an information model (e.g., data model <NUM>) that provides relationship data regarding the respective data with other datasets. To provide this context to the external component <NUM>, the adapter component <NUM> may parse the data using the tools to identify the corresponding information model associated with the external component <NUM>. The adapter component <NUM> may then generate commands for performing operations that include sending the data and the information model to the external component <NUM>. The commands, when received by the external component <NUM>, may cause the external component <NUM> to create data entries, such that the context of the received data is stored within the external component <NUM> using the format of the external component <NUM>. That is, the commands may cause the external component <NUM> to automatically create the data entries and bindings to represent the data received by the external component <NUM> in accordance with the corresponding information model based on the data model <NUM> stored with the computing device <NUM>.

Keeping the foregoing in mind, in some embodiments, the external component <NUM> may correspond to one or more applications in communication with the computing device <NUM>, applications being executed on the computing device <NUM>, and the like. Each external component <NUM> may be accessed or executed by one or more other client devices and may seek data stored or contained in data storages or data sources coupled to adapter components <NUM>. Indeed, the external component <NUM> may be accessed by the client devices, which may seek to acquire data stored in one or more of data sources that are inaccessible to the client devices. To facilitate the connection of the external component <NUM> to appropriate data sources, the computing device <NUM> may receive data communications from the external component <NUM> and route the data communications to the adapter component <NUM> associated with the particular external component <NUM>. As discussed above, the adapter component <NUM> may convert or modify the data communications received from the external component <NUM> into a format or the data model <NUM> that is discernable by the computing device <NUM>.

In addition, the adapter component <NUM> may use a certain protocol that enables it to interact with the external component <NUM> and acquire the data therefrom. As a result, the adapter component <NUM> may allow a variety of applications to request the data from a variety of data sources without the respective host device directly connecting to the data source and without the external component <NUM> or the computing device <NUM> to be configured with any particular protocol to communicate with the respective data source. That is, the adapter component <NUM> may enable the computing device <NUM> to bridge between various client devices and other industry standard devices, protocols, and applications.

In some embodiments, the adapter component <NUM> may also provide the ability to perform certain operations on the external component <NUM> that may collect, analyze, and store data provided by the computing device <NUM>. Indeed, some of these operations may include creating entities or entries within the external component <NUM> from outside sources via the adapter component <NUM>, reading entity structures and data from the external component <NUM> for outside sources (e.g., client devices) via the adapter component <NUM>, updating and modifying entity structures and data in the external component <NUM> from outside sources (e.g., client devices) via the adapter component <NUM>, deleting entities, entity structural elements, and data in the external component <NUM> via the adapter component <NUM>, and the like.

Indeed, by employing the adapter component <NUM> described herein, the computing device <NUM> may avoid pulling or extracting data directly from other connected client devices to the external platform using either manual processes or manual file XML (Extensible Markup Language) exports and imports that may be used for creating entity structures, updating entity structures, and deleting entity structures within the external platform. Instead, by performing the embodiments disclosed herein using the adapter component <NUM>, the computing device <NUM> may access multiple data sources that operate according to different programming languages using the same native functions of the computing device <NUM>, such that the collected data may be directly provided to the external component <NUM> in a format that the external component <NUM> may be able to interpret and use.

Since the adapter component <NUM> may enable the common gateway platform (e.g., the information gateway, gateway, edge computing device) to interact with the external component <NUM>, the computing device <NUM> may provide functionalities of the external component <NUM> as native functions of the computing device <NUM>. That is, the adapter component <NUM> may provide functions to connect, create, read, write, update, delete, run commands and queries, and disconnect from the external component <NUM> using native commands and actions interpretable by the computing device <NUM>. As a result, the ability of the computing device <NUM> to understand and engage with various types of components using various programming languages may be extended to the functions of the external component <NUM>, which may not be able to interpret data received directly from various types of components.

<FIG> illustrates a procedure <NUM> for providing the structured data <NUM> to the external component <NUM>. The procedure <NUM> may be performed by the adapter component <NUM> or any suitable computing device. The adapter component <NUM> may associate datasets <NUM> and/or the transaction data <NUM>, described above with respect to <FIG>, to datasets of the external component <NUM> using the API and/or SDK data <NUM> of the external component <NUM>. It should be understood that the order of the procedure <NUM> is provided by way of example and the procedure <NUM> may be performed in any suitable order.

Referring now to <FIG>, at block <NUM>, the adapter component <NUM> may receive a request to stream structured data <NUM> to the external component <NUM>. The request may be provided via client devices or other applications accessible to the computing device <NUM>. As discussed above, the computing device <NUM> may communicatively couple the external component <NUM> or other devices using a WebSocket connection or other suitable communication protocols.

At block <NUM>, the adapter component <NUM> may retrieve a first data model (e.g., the data model <NUM>) associated with the structured data <NUM>. Subsequently, at block <NUM>, the adapter component <NUM> may determine the datasets <NUM> and/or the transaction data <NUM> associated with the structured data <NUM> based on the first data model. At block <NUM>, the adapter component <NUM> may receive an indication of a second data model associated with the external component <NUM>. In some embodiments, the adapter component <NUM> may determine the second data model based on the API and/or SDK data <NUM> of the external component <NUM>. Accordingly, the adapter component <NUM> may identify the external data structure of the external component <NUM>.

At block <NUM>, the adapter component <NUM> may determine a relationship between the first data model and the second data model. The adapter component <NUM> may determine a representation of the data structure of the external component <NUM> based on the first data model and the second data model. For example, the adapter component <NUM> generates a table associated with the determined relationship between the first data model and the second data model. That is, the table indicates related variable names, related operations, related functions, related data types, and other related properties between the first data model and the second data model.

At block <NUM>, the adapter component <NUM> may map the structured data <NUM> to respective datasets of the second data model based on the determined relationship. In one embodiment, the adapter component <NUM> may generate the endpoint <NUM> that may include the mapping of the structured data <NUM> to the datasets of the second data model. As such, the endpoint <NUM> may be configured to receive the structured data <NUM> and automatically convert it to the stream structured data <NUM>. At block <NUM>, the adapter component <NUM> may transmit the structured data <NUM> to mapped datasets of the external component according to the second data model via the endpoint <NUM>. Accordingly, the computing device <NUM> may use the native data model (first data model) for streaming data in structured form to the external component <NUM> in accordance with the external structure of the external component <NUM>. Moreover, similar processes may be used for providing streaming data in structured form to other external components using various data models.

While only certain features of the invention have been illustrated and described herein, many modifications and changes will occur to those skilled in the art.

Claim 1:
A tangible, non-transitory, machine-readable medium, comprising machine-readable instructions that, when executed by a processor (<NUM>) of an industrial system, cause the processor to perform actions for facilitating data communication with an external component by providing structured data to an external component using a different data structure, the actions comprising:
receiving a request to transmit a first dataset (<NUM>) to an external component (<NUM>, <NUM>) communicatively coupled to the processor;
determining a first data structure (<NUM>) of the first dataset organized according to a first information model (<NUM>, <NUM>) associated with the first dataset;
detecting a second data structure of one or more datasets, the second data structure being used by the external component, the second data structure organized according to a second information model (<NUM>) differing from the first information model, wherein the first and second information models specify hierarchical relationships between types of data and further relationships between types of data such as constraints, rules, data values and operations, the detecting comprising retrieving, from the external component, an application program interface (<NUM>), API, or a software development kit (<NUM>), SDK, wherein the API or the SDK provides a representation of the second data structure and wherein the API or the SDK are used to generate an adapter component (<NUM>);
determining a relationship between the first data structure and the second data structure, including generating, by the adapter component, a table indicating one or more of related variable names, related operations, related functions and related data types between the first information model and the second information model;
converting the first dataset into a second dataset (<NUM>) structured according to the second data structure based on the relationship; and
transmitting the second dataset to the external component.