REAL-TIME TRACKING OF PRODUCT USING A CLOUD PLATFORM

A cloud-based product tracking system is provided. The product tracking system runs on a cloud platform and collects data from multiple devices throughout a supply chain, the data relating to production, transportation, storage, and sales of a product. Related subsets of the collected data are aggregated and correlated at the cloud platform based on contextual metadata associated with the data, a data model of the supply chain and systems therein, or other such factors. The cloud-based tracking system analyzes the correlated information to determine a status of a product within the supply chain. The tracking system also leverages the correlated data to analyze product flow, identify inefficiencies within the supply chain, and generate recommendations for modifying portions of the supply chain to mitigate the identified inefficiencies.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/587,531, filed on Feb. 9, 2012, and entitled “INDUSTRIAL AUTOMATION CLOUD COMPUTING SYSTEMS AND METHODS,” and U.S. Provisional Patent Application Ser. No. 61/642,964, filed May 4, 2012, and entitled “CLOUD GATEWAY FOR INDUSTRIAL AUTOMATION INFORMATION.” This application is also related to U.S. patent application Ser. No. 10/162,315, filed on Jun. 4, 2002 (which issued as U.S. Pat. No. 7,151,966 on Dec. 19, 2006), and entitled “SYSTEM AND METHODOLGY PROVIDING OPEN INTERFACE AND DISTRIBUTED PROCESSING IN AN INDUSTRIAL CONTROLLER ENVIRONMENT.” The entireties of these applications are incorporated herein by reference.

TECHNICAL FIELD

The subject application relates generally to industrial automation, and, more particularly, to tracking of products through a manufacturing and supply chain using a cloud platform.

BACKGROUND

Industrial controllers and their associated I/O devices are central to the operation of modern automation systems. These controllers interact with field devices on the plant floor to control automated processes relating to such objectives as product manufacture, material handling, batch processing, supervisory control, and other such applications. Industrial controllers store and execute user-defined control programs to effect decision-making in connection with the controlled process. Such programs can include, but are not limited to, ladder logic, sequential function charts, function block diagrams, structured text, or other such programming structures.

Manufacturing operations, including control of industrial processes by the industrial controllers described above, represent one component of a larger business enterprise. On a higher level, business operations such as financial analysis, marketing, sales, order management, long term business planning, resource management, inventory management, and the like collectively represent another element of the enterprise. Moreover, the plant-floor and business level operations of the manufacturing facility collectively represent only one entity of a larger product supply chain that can also include entities such as material suppliers, inventory or warehousing, shipping, and retail. All of these supply chain entities are capable of generating vast amounts of near real-time and historical data. On the manufacturing side, this data can include production statistics, data relating to machine health, alarm statuses, operator feedback, electrical or mechanical load data, and other such manufacturing data. Warehouses typically track incoming and outgoing shipments in order to maintain accurate inventory records. Sales data maintained by a retail entity can be used to drive production schedules, inventory levels, and purchase planning at the manufacturing and supplier sides.

Although operations at the various supply chain entities are related to and often dependent upon one another, data generated at the various supply chain entities—or even at different areas within the same entity—is often only loosely integrated, with slow (e.g., non-real-time, non-automated) information exchange between the entities. Consequently, analyzing potential correlations between data sets generated at the various stages of the supply chain can be challenging. Moreover, the lack of integration between the supply chain entities can render accurate, near real-time product tracking through the supply chain difficult.

The above-described deficiencies of today's industrial control and business systems are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.

SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

One or more embodiments of the present disclosure relate to the use of cloud-based services to facilitate near real-time product tracking through a supply chain. To this end, a cloud-based product tracking system running as a service on a cloud platform can receive product data from various supply chain entities and leverage the collected data to provide product tracking or supply chain analysis information. Data received by the product tracking system can include industrial data received from one or more industrial automation systems; inventory data; near real-time shipping information; business-level data including sales, finance, and purchasing information; and other such supply chain information.

The supply chain data can be provided to the cloud-based product tracking system by cloud-capable industrial devices located at the respective industrial systems or supply chain entities. The data can also be provided by cloud gateways that gather data from industrial devices, business servers, and the like, and push the data to the product tracking system. In this manner, the cloud-based product tracking system can collect product-related data from multiple entities, potentially at different geographic locations, and store, filter, associate, correlate, and/or aggregate the collected data in meaningful ways according to the needs of the user. The product tracking system can generate displays screens for rendering near real-time tracking information based on the collected data, and deliver the displays to authorized Internet-capable display devices via the Internet. Thus, the cloud-based product tracking system can allow authorized users to remotely track products through the supply chain using any suitable computing device having access to the Internet (e.g., phone, desktop computer, laptop computer, tablet computer, etc.).

The product tracking system can allow near real-time product information to be compared with business-level metrics. For example, personnel can use product tracking data provided by the cloud-based product tracking system to compare a sales order with a current location of a product within a supply chain. The product tracking system can also apply cloud-side analytics to the collected data to identify actual or potential bottlenecks or other inefficiencies in the supply chain, and provide guidance regarding possible modifications to production or supply chain processes that may mitigate such inefficiencies. In some embodiments, the product tracking system can also be integrated with business-level systems to dynamically modify orders for supplies, shipping orders, or other business-level operations based on current supply chain information.

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level overview of an industrial enterprise that leverages cloud-based services.

FIG. 2 is a block diagram of a cloud-based product tracking system.

FIG. 3 illustrates an exemplary cloud-based architecture for tracking product through an industrial supply chain.

FIG. 4 is a block diagram illustrating components of an exemplary cloud-based product tracking system.

FIG. 5 illustrates an exemplary configuration in which an industrial device acts as a cloud proxy for other industrial devices comprising an automation system.

FIG. 6 illustrates transformation of raw industrial data into contextualized data.

FIG. 7 illustrates an embodiment in which a firewall box serves as a cloud proxy for a set of industrial devices.

FIG. 8 illustrates an exemplary cloud gateway configuration for sending data from a mobile system to a cloud platform.

FIG. 9 illustrates exemplary configuration data for a cloud interface component.

FIG. 10 illustrates an exemplary organizational hierarchy that can be used as a basis for a data model of a manufacturing entity within a supply chain.

FIG. 11 illustrates an exemplary supply chain.

FIG. 12 illustrates an exemplary architecture for issuing supply chain management instructions from a cloud platform.

FIG. 13 is a high-level overview depicting synchronization of a device clock with a cloud clock.

FIG. 14 illustrates an exemplary cloud-based notification architecture.

FIG. 15 is a flowchart of an example methodology for tracking product through a supply chain using a cloud platform.

FIG. 16 is a flowchart of an example methodology for identifying inefficiencies in a supply chain using a cloud platform.

FIG. 17 is an example computing environment.

FIG. 18 is an example networking environment.

 DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the subject disclosure can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate a description thereof.

As used in this application, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” “interface” are intended to refer to a computer-related entity or an entity related to, or that is part of, an operational apparatus with one or more specific functionalities, wherein such entities can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical or magnetic storage medium) including affixed (e.g., screwed or bolted) or removably affixed solid-state storage drives; an object; an executable; a thread of execution; a computer-executable program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Also, components as described herein can execute from various computer readable storage media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry which is operated by a software or a firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that provides at least in part the functionality of the electronic components. As further yet another example, interface(s) can include input/output (I/O) components as well as associated processor, application, or Application Programming Interface (API) components. While the foregoing examples are directed to aspects of a component, the exemplified aspects or features also apply to a system, platform, interface, layer, controller, terminal, and the like.

As used herein, the terms “to infer” and “inference” refer generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.

In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form.

Furthermore, the term “set” as employed herein excludes the empty set; e.g., the set with no elements therein. Thus, a “set” in the subject disclosure includes one or more elements or entities. As an illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources; etc. Likewise, the term “group” as utilized herein refers to a collection of one or more entities; e.g., a group of nodes refers to one or more nodes.

Various aspects or features will be presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches also can be used.

FIG. 1 illustrates a high-level overview of an exemplary industrial enterprise that leverages cloud-based services, including but not limited to the product tracking services described herein. The enterprise comprises one or more industrial facilities 104, each having a number of industrial devices 108 and 110 in use. The industrial devices 108 and 110 can make up one or more automation systems operating within the respective facilities 104. Exemplary automation systems can include, but are not limited to, batch control systems (e.g., mixing systems), continuous control systems (e.g., PID control systems), or discrete control systems. Industrial devices 108 and 110 can include such devices as industrial controllers (e.g., programmable logic controllers or other types of programmable automation controllers); field devices such as sensors and meters; motor drives; human-machine interfaces (HMIs); industrial robots, barcode markers and readers; vision system devices (e.g., vision cameras); smart welders; or other such industrial devices.

Exemplary automation systems can include one or more industrial controllers that facilitate monitoring and control of their respective processes. The controllers exchange data with the field devices using native hardwired I/O or via a plant network such as Ethernet/IP, Data Highway Plus, ControlNet, Devicenet, or the like. A given controller typically receives any combination of digital or analog signals from the field devices indicating a current state of the devices and their associated processes (e.g., temperature, position, part presence or absence, fluid level, etc.), and executes a user-defined control program that performs automated decision-making for the controlled processes based on the received signals. The controller then outputs appropriate digital and/or analog control signaling to the field devices in accordance with the decisions made by the control program. These outputs can include device actuation signals, temperature or position control signals, operational commands to a machining or material handling robot, mixer control signals, motion control signals, and the like. The control program can comprise any suitable type of code used to process input signals read into the controller and to control output signals generated by the controller, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, or other such platforms.

Although the exemplary overview illustrated in FIG. 1 depicts the industrial devices 108 and 110 as residing in stationary industrial facilities 104, the industrial devices may also be part of a mobile control application, such as a system contained in a truck or other service vehicle.

According to one or more embodiments of this disclosure, industrial devices 108 and 110 can be coupled to a cloud platform to leverage cloud-based applications. That is, the industrial device 108 and 110 can be configured to discover and interact with cloud-based computing services 112 hosted by cloud platform 102. Cloud platform 102 can be any infrastructure that allows shared computing services 112 to be accessed and utilized by cloud-capable devices. Cloud platform 102 can be a public cloud accessible via the Internet by devices having Internet connectivity and appropriate authorizations to utilize the services. Alternatively, cloud platform 102 can be a private cloud operated internally by the enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud computing services 112 and residing on a corporate network protected by a firewall.

Cloud services 112 can include, but are not limited to, data storage, data analysis, product tracking, control applications (e.g., applications that can generate and deliver control instructions to industrial devices 108 and 110 based on analysis of near real-time system data or other factors), visualization applications such as cloud-based HMIs, reporting applications, Enterprise Resource Planning (ERP) applications, notification services, or other such applications. If cloud platform 102 is a web-based cloud, industrial devices 108 and 110 at the respective industrial facilities 104 may interact with cloud services 112 via the Internet. In an exemplary configuration, industrial devices 108 and 110 may access the cloud services 112 through separate cloud gateways 106 at the respective industrial facilities 104, where the industrial devices 108 and 110 connect to the cloud gateways 106 through a physical or wireless local area network or radio link. In another exemplary configuration, the industrial devices may access the cloud platform directly using an integrated cloud interface.

Providing industrial devices with cloud capability can offer a number of advantages particular to industrial automation. For one, cloud-based storage offered by the cloud platform can be easily scaled to accommodate the large quantities of data generated daily by an industrial enterprise. Moreover, multiple industrial facilities or supply chain entities at different geographical locations can migrate their respective automation data to the cloud for aggregation, collation, collective analysis, and enterprise-level reporting without the need to establish a private network between the facilities. Industrial devices 108 and 110 having smart configuration capability can be configured to automatically detect and communicate with the cloud platform 102 upon installation at any facility, simplifying integration with existing cloud-based data storage, analysis, or reporting applications used by the enterprise. In another exemplary application, cloud-based diagnostic applications can monitor the health of respective automation systems or their associated industrial devices across an entire plant, or across multiple industrial facilities that make up an enterprise. Cloud-based lot control applications can be used to track a unit of product through its stages of production and collect production data for each unit as it passes through each stage (e.g., barcode identifier, production statistics for each stage of production, quality test data, abnormal flags, etc.). These industrial cloud-computing applications are only intended to be exemplary, and the systems and methods described herein are not limited to these particular applications. The cloud platform 102 can allow builders of industrial applications to provide scalable solutions as a service, removing the burden of maintenance, upgrading, and backup of the underlying infrastructure and framework.

FIG. 2 is a block diagram of a product tracking system that can be implemented on a cloud platform to facilitate tracking a status of a product through a supply chain. Aspects of the systems, apparatuses, or processes explained in this disclosure can constitute machine-executable components embodied within machine(s), e.g., embodied in one or more computer-readable mediums (or media) associated with one or more machines. Such components, when executed by one or more machines, e.g., computer(s), computing device(s), automation device(s), virtual machine(s), etc., can cause the machine(s) to perform the operations described.

Product tracking system 202 can include a device interface component 204, a client interface component 206, a correlation component 208, a tracking component 210, one or more processors 212, and memory 214. In various embodiments, one or more of the device interface component 204, client interface component 206, correlation component 208, tracking component 210, one or more processors 212, and memory 214 can be electrically and/or communicatively coupled to one another to perform one or more of the functions of the product tracking system 202. In some embodiments, components 204, 206, 208, and 210 can comprise software instructions stored on memory 214 and executed by processor(s) 212. Product tracking system 202 may also interact with other hardware and/or software components not depicted in FIG. 2. For example, processor(s) 212 may interact with one or more external user interface devices, such as a keyboard, a mouse, a display monitor, a touchscreen, or other such interface devices.

Device interface component 204 can be configured to receive industrial data or other product related data sent by one or more cloud-capable industrial device, cloud gateways, or other sources of product data. Client interface component 206 can be configured to receive a request for product data from a remote client device via an Internet connection, and to deliver the requested data to the client device. This can include delivery of pre-configured display screens to the remote devices and rendering the product data via the displays screens. Correlation component 208 can be configured to aggregate and correlate subsets of the data received by device interface component 204. Tracking component 210 can be configured to determine a current status of a product within an industrial supply chain based on the data received by device interface component 204 and correlations determined by correlation component 208. The one or more processors 212 can perform one or more of the functions described herein with reference to the systems and/or methods disclosed. Memory 214 can be a computer-readable storage medium storing computer-executable instructions and/or information for performing the functions described herein with reference to the systems and/or methods disclosed.

FIG. 3 illustrates an exemplary cloud-based architecture for tracking product through an industrial supply chain. An exemplary simplified supply chain can include a supplier 304, a manufacturing facility 306, a warehouse 308, and a retail entity 310. However, the supply chain can comprise more or fewer entities without departing from the scope of this disclosure. For simplicity, FIG. 3 depicts a single block for each supply chain entity. However, it is to be appreciated that a given supply chain can comprise multiple entities for each entity type. For example, a manufacturing facility may rely on materials provided by multiple suppliers. Likewise, the supply chain may include multiple warehouse entities to provide storage for various products produced by the manufacturing facility, and multiple retail entities for selling the products to end customers.

The various supply chain entities can generate a large amount of data in connection with their roles in the supply chain. For example, supplier 304 and manufacturing facility 306 can include plant floor devices that generate near real-time and historical industrial data relating to production of the materials or products, as well as business-level information relating to purchase orders, intakes, shipments, enterprise resource planning (ERP), and the like. Warehouse 308 can maintain records of incoming and outgoing product and track inventory levels for respective products. Retail entity 310 can track sales, retail inventory, financial information, demand metrics, and other such information. Additional information relating to transportation of materials or products between stages of the supply chain can also be generated, including but not limited to geographical location obtained from global positioning systems.

According to one or more embodiments of the present disclosure, data sources associated with each of the supply chain entities can provide industrial or business data to a cloud platform 302 to facilitate cloud-based tracking of products through the supply chain. Cloud platform 302 can execute product tracking services that aggregate and correlate data provided by the various supply chain stages, and provide information about a product's state within the supply chain based on the analysis. These cloud-based services can include, but are not limited to, tracking the product's physical location within the supply chain, dynamically managing inventory based on demand data and current production statuses, dynamically managing orders for materials or products based on comparisons between pending orders and a current state of an ordered product, providing metrics relating to the flow of products through the supply chain, or identifying and trouble-shooting inefficiencies in product flows through the supply chain. These and other services will be described in more detail below.

FIG. 4 is a block diagram illustrating components of an exemplary cloud-based product tracking system. As described in previous examples, cloud-based product tracking system 402 can reside on a cloud platform and receive data from respective data generating devices 404. In one or more embodiments, the cloud-based product tracking system 402 can reside and execute on the cloud platform as a cloud-based service, and access to the cloud platform and product tracking system 402 can be provided to customers as a subscription service by a provider of the product tracking services.

Devices 404 can comprise substantially any type of device that contains, collects, or generates data relating to a product or material within a supply chain. For example, industrial devices 4041 and 4042 can be plant floor devices that are part of respective automation systems at supply and manufacturing entities of the supply chain. These devices can include, but are not limited to, industrial controllers, sensors, meters, motor drives, HMI terminals, industrial robots, or other such industrial devices. Industrial devices 4041 and 4042 can be configured with cloud capabilities that allow the devices to be communicatively coupled to the cloud platform and exchange data with services residing thereon. Alternatively, industrial devices 4041 and 4042 can provide their data to the cloud platform via respective cloud proxy devices or other cloud gateways that collect data from multiple devices and move the data to the cloud platform for storage and processing. These various configurations are described in more detail below.

As illustrated in FIG. 4, data from an inventory server 4043 at a warehouse stage of the supply chain can also provide data to product tracking system 402. Inventory server 4043 can maintain, for example, current inventory levels for various products, records of product intakes and shipments, product order information, available warehouse capacity, and other such information. It is to be appreciated that other types of devices can provide data to product tracking system 402 in addition to devices 4041-4043. For example, mobile cloud gateways can be embedded on cargo vehicles that transport materials and product between supply chain entities. These cloud gateways can provide GPS information to the cloud indicating a current geographical location of a product shipment as the shipment is being transported through the supply chain. Additionally, sales and demand information can be provided to product tracking system 402 by retail servers associated with retail outlets. At the supply and manufacturing stages, higher level business systems (e.g., ERP systems, reporting applications, financial systems, etc.) can provide business data relating to operations of the respective facilities. Devices 404 can be associated with respective automation systems at geographically diverse industrial facilities, or at different areas within the same facility which may or may not reside on a common local area network.

Data provided by devices 404 can be received by product tracking system 402 via a device interface component 414. Devices 404 can send their respective data to cloud-based product tracking system 402 at a frequency defined by the product tracking system 402. For example, an administrator or other user with suitable administrative privileges can define an upload frequency individually for the respective devices 404, and device interface component 414 can provide corresponding configuration instructions to the respective devices 404 configuring the upload frequencies accordingly. Alternatively or in addition, product tracking system 402 may dynamically select a suitable upload frequency for the respective devices 404 during operation. For example, in order to control costs associated with cloud resource utilization, an administrator can, in one or more embodiments, configure a maximum total bandwidth usage for the cloud-based product tracking system 402, such that the total instantaneous bandwidth usage for data traffic between the devices 404 and cloud-based product tracking system 402 is not to exceed the configured maximum bandwidth. In such embodiments, cloud-based product tracking system 402 can monitor the total bandwidth utilization substantially in real-time, and dynamically reduce the upload frequency of one or more devices 404 in response to a determination that the total bandwidth usage is approaching the defined maximum bandwidth.

In another example, an administrator can configure a limit on the total amount of cloud storage to be utilized. Accordingly, if the product tracking system 402 determines that this storage limit is being approached, the product tracking system can begin deleting the oldest data from cloud storage according to a preconfigured deletion routine. In an alternative approach, the product tracking system 402 can send an instruction to one or more devices 404 to reduce their upload frequencies in response to determining that the storage limit is being approached, thereby slowing the consumption of cloud storage resources. The cloud-based product tracking system 402 can select which devices 404 are to be adjusted based on respective criticalities of the control systems associated with the devices 404. For example, cloud-based product tracking system 402 can maintain individual device profiles (not shown) defining relative priorities of the industrial systems associated with each of the devices 404, and can leverage this information in connection with determining which devices 404 are to be selected for reduced upload frequency in the event that one or more cloud resources are being used at an excessive rate.

The supply chain data from devices 404 are received at device interface component 414, which can store the received data on cloud storage 426. In one or more embodiments, the received supply chain data can first be filtered by a filter component 416, which can be configured to remove redundant or unnecessary data prior to storage. Filter component 416 can filter the data according to any specified filtering criterion, which may be defined by a filter profile or filter configuration data associated with product tracking system 402. For example, valid data ranges can be defined for selected items of data received from devices 404, and filter component 416 can be configured to delete data values that fall outside these defined ranges. In this way, outlier data indicative of faulty data measurements can be filtered out prior to storage on the cloud platform. Filter component 416 can also be configured to identify redundant data collected from two or more of devices 404, and discard redundant instances of the same data. In some embodiments, filter component 416 can leverage contextual information associated with the data to identify such instances of redundant data. Note that server-side filtering will accrue data transition costs and affect available bandwidth even though the data is not actively used. However, this approach is necessary if the used gateway does not offer corresponding client-side filtering. For more capable gateways, client-side filtering as described below is the preferred option.

Cloud storage 426 can comprise a subset of the cloud platform's storage resources provisioned to an end user entity (e.g., an industrial enterprise) for the purpose of storing the received supply chain data. For example, cloud storage 426 can be provided to an industrial enterprise as part of a subscription service that includes access to the cloud-based product tracking system 402 and its associated cloud services.

As noted above, product or supply chain data can be provided to the cloud platform by cloud-capable industrial devices (e.g., industrial controllers, meters, historians, etc.) or through cloud proxy devices that collect data from such industrial devices and provide the data to the cloud platform. Turning briefly to FIG. 5, an exemplary configuration is illustrated in which an industrial device acts as a cloud proxy for other industrial devices comprising an automation system. In the present example, an automation system (as might be part of a supply or manufacturing entity of a supply chain) comprises a plurality of industrial devices 5061-506N which collectively monitor and/or control one or more controlled processes 502. The industrial devices 5061-506N respectively generate and/or collect process data relating to the controlled process(es) 502. For industrial controllers such as PLCs or other automation controllers, this can include collecting data from telemetry devices connected to the controller's I/O, generating data internally based on measured process values, etc.

In the configuration depicted in FIG. 5, industrial device 5061 acts as a proxy for industrial devices 5062-506N, whereby data 514 from devices 5062-506N is sent to the cloud via proxy industrial device 5061. Industrial devices 5062-506N can deliver their data 514 to proxy industrial device 5061 over plant network or backplane 512 (e.g., a Common Industrial Protocol network or other suitable network protocol). Using such a configuration, it is only necessary to interface one industrial device to the cloud platform (via cloud interface component 508). Accordingly, proxy industrial device 5061 can include a transformation component 510 for applying suitable transformations to the collective data 514 collected from industrial devices 5062-506N, as well as its own control data. Such transformations can include, for example, filtering, pruning, re-formatting, summarizing, or compressing the data prior to moving the data to the cloud platform. Since data is being gathered from multiple industrial devices according to this configuration, there is a possibility that redundant data may be provided to industrial device 5061 from more than one source. Accordingly, transformation component 510 may be configured to filter such redundant data prior to delivering the refined data to the cloud-based application. Transformation component 510 may also be configured to summarize the gathered data 514 according to defined summarization criteria. The transformed data can then be pushed to the cloud as cloud data 504 via cloud interface component 508.

In some embodiments, transformation component 510 can apply contextual metadata to the received data 514. Turning briefly to FIG. 6, transformation of raw industrial data into contextualized data by the transformation component is illustrated. Transformation component 604 receives raw industrial data 602 and enhances the data 602 with one or more pieces of context data to yield contextualized data 606. For example, transformation component 604 can apply a time stamp to the raw data 602 indicating a time, a date, and/or a production shift when the data was generated. The applied context data may also identify a production area that yielded the data, a particular product that was being produced when the data was generated, and/or a state of a machine (e.g., auto, semi-auto, abnormal, etc.) at the time the data was generated. Such data can be leveraged by the cloud-based product tracking system to identify when a product or lot has passed through a particular production area of a supplier or manufacturing facility. Other examples of context information include an employee on shift at the time the data was generated, a lot number with which the data is associated, or an alarm that was active at the time the data was generated. Transformation component 604 can also apply an actionable data tag to the raw data if it is determined that the data requires action to be taken by plant personnel or by the cloud-based application.

Transformation component 604 an also apply contextual information to the raw data 602 that reflects the data's location within a hierarchical organizational model. Such an organization model can represent an industrial enterprise in terms of multiple hierarchical levels. In an exemplary organizational model, the hierarchical levels can include—from lowest to highest—a workcell level, a line level, an area level, a site level, and an enterprise level. Devices that are components of a given automation system can be described and identified in terms of these hierarchical levels, allowing a common terminology to be used across the entire enterprise to identify devices, machines, and data within the enterprise. Some exemplary organizational models may also define relationships between various supply chain entities (e.g. suppliers, manufacturers, inventory, retail, etc.). In some embodiments, the organizational model can be known to the transformation component 604, which can stamp raw data 602 with a hierarchical identification tag that indicates the data's origin within the organizational hierarchy (e.g., Company:Marysville:DieCastArea:#1Headline:LeakTestCell).

While the proxy device illustrated in FIG. 5 is depicted as an industrial device that itself performs monitoring and/or control of a portion of controlled process(es) 502, other types of devices can also be configured to serve as a cloud proxies for multiple industrial devices according to one or more embodiments of this disclosure. For example, FIG. 7 illustrates an embodiment in which a firewall box 712 serves as a cloud proxy for a set of industrial devices 7061-706N. Firewall box 712 can act as a network infrastructure device that allows plant network 716 to access an outside network such as the Internet, while also providing firewall protection that prevents unauthorized access to the plant network 716 from the Internet. In addition to these firewall functions, the firewall box 712 can include a cloud interface component 708 that interfaces the firewall box 712 with one or more cloud-based services, such as the cloud-based product tracking system described herein. In a similar manner to proxy industrial device 5061 of FIG. 5, the firewall box 712 can collect industrial data 714 from industrial devices 7061-706N, which monitor and control respective portions of controlled process(es) 702. Firewall box 712 can also include a transformation component 710 that applies suitable transformations to the gathered industrial data 714 prior to pushing the data to the cloud-based application as cloud data 704. As described in previous examples, these transformations can include, but are not limited to, compression, truncation, summarization, filtering, aggregation, addition of contextual metadata, or other such transformations in accordance with user-defined or cloud-defined requirements. Beneficially, firewall box 712 can allow industrial devices 7061-706N to interact with the cloud platform without directly exposing the industrial devices to the Internet.

As noted above, in addition to receiving data from fixed-location industrial systems or supply chain entities, the cloud-based product tracking system can also collect data from mobile systems, such as control and/or monitoring systems embedded in a truck or other cargo vehicle that transports products between supply chain entities. FIG. 8 illustrates an exemplary cloud gateway configuration that can be used to send data from such mobile systems to a cloud platform for tracking purposes. In the present example, it will be assumed that data is to be collected from a machine health monitoring system running on board a truck, which can provide useful information regarding a transportation status of products loaded on the truck. However, it is to be understood that the systems and methods described are applicable for collecting data from any mobile control and/or monitoring system and sending the data to a cloud platform. For example, these techniques can also be applied to product health monitoring applications to determine whether an inventory server behaves correctly.

A transportation vehicle can be provided with a local computer 802 running a cloud gateway service 810. Local computer 802 may be a ruggedized computer having a reinforced casing designed to withstand the vibration and turbulence that can be experienced during travel on-board the truck. Cloud gateway service 810 can perform similar functions to cloud interface components 508 and 708 of FIGS. 5 and 7. Communication services 812, also running on local computer 802, can facilitate communication with a controller 814, which is used to monitor and/or control the on-board machine health system. The local computer 802 can also optionally include a local human-machine interface (HMI) 808 for local visualization of controller data at the truck.

In one or more embodiments, the cloud gateway service 810 can be a service (e.g., a Windows service) that runs on local computer 802 on-board the truck. The cloud gateway service 810 is responsible for pushing local controller data from controller 814 to cloud platform 806 via the web services exposed by a cloud application. The cloud gateway service 810 can also support store-and-forward logic used when the connection between the truck and the cloud platform 806 is temporarily interrupted. In some embodiments, the data collected by the cloud gateway service 810 can be pushed to the cloud via a wireless radio 804 on-board the truck (e.g., 3G wireless radio).

In one or more embodiments, the cloud gateway service 810 can periodically read data from the controller 814 and a global positioning system (GPS, cell tower triangulation, etc.) location provider (not shown) on-board the truck and send both the controller data and the location data to the cloud application residing on cloud platform 806. The cloud gateway service 810 can also receive information from a cloud application residing on cloud platform 806 that indicates how often data should be sent to the cloud and how the gateway should handle disconnects (store and forward behavior).

The upload frequency (slow poll mode versus fast poll mode) can be controlled by the product tracking system on the cloud platform 806 on a per truck basis. For example, an object representing a given truck in the product tracking system may have a property indicating the upload mode for the given truck's cloud gateway. The cloud gateway service 810 can ping the cloud platform 806 at a pre-defined frequency (e.g., once per minute) to upload the controller data and/or to check for a change in the upload mode (fast poll mode versus slow poll mode).

Devices that send industrial, product, or transportation data to the cloud platform can determine which subsets of available data are to be sent to the cloud by reading configuration data associated with the devices' cloud interface components (e.g., cloud interface components 508 or 708). Exemplary configuration data for a cloud interface component is now described with reference to FIG. 9. Configuration data 902 resides locally on its associated cloud-capable device, and instructs the device as to which data should be collected and sent to the cloud platform, a destination cloud platform for the data, and other such specifics. Configuration data 902 comprises a number of configurable data fields 904 that allow a user to easily configure the parameters of the cloud interface component. The exemplary configuration data 902 illustrated in FIG. 9 includes fields for the System ID, the Controller ID, one or more controller tags, a cloud URL (uniform resource locator), and a maximum local storage, where the values of the respective fields can be set by the user. It is to be appreciated that the fields illustrated in FIG. 9 are only intended to be exemplary, and that configuration data 902 may include any suitable set of configuration fields without departing from the scope of this disclosure.

The System ID field can be an identifier of the control system for which the data is to be collected. For example, the System ID can identify a production area, a machine, an assembly line, or other system designation. In another example, the cloud-capable device may be used to collect data from a mobile control and/or monitoring system residing on a truck (e.g., a system health monitoring system on a cargo or service vehicle), and the System ID can be a truck identifier. In this way, data from multiple trucks comprising a fleet can be collected using respective cloud gateways on board each truck, and the source of the data can be identified by the cloud application by each cloud gateway's System ID.

The Controller ID field can identify an industrial controller from which the data is to be collected (e.g., a controller associated with the control system identified by the System ID field), and the Controller Tag fields can identify the particular controller tags holding the data. These can include both discrete controller tags containing digital data values as well as analog tags containing integer or real data values. The Cloud URL field can identify the address of the cloud platform to which the data will be sent. The maximum local storage field can be used to configure a maximum amount of local device storage space that is to be used for local data storage when communication to the cloud platform has been lost.

Returning now to FIG. 4, data received by product tracking system 402 from devices 404 is optionally filtered by filter component 416 and moved to cloud storage 426. To facilitate near real-time product tracking, product tracking system 402 can include a correlation component 406 configured to aggregate and correlate subsets of the collected data to determine a product's status within the supply chain. Correlation component 406 can leverage the data in cloud storage 426 in a number of ways to generate product tracking information. In one exemplary scenario, product units or product lots can be associated with a unique identification number so that the products can be identified at certain points within the supply chain. For example, products may be stamped with a unique two-dimensional (2D) barcode at the supply or manufacturing entity (e.g., using a pin-stamper or laser marker). As the individual product units progress through various production stages at the supply or manufacturing entities, the barcode can be read at various points using mounted or hand-held barcode readers, and production data generated for the product unit on the plant floor can be tied to the unique identifier before being sent to the cloud platform.

For instance, a machined part may pass through a leak test station at a manufacturing facility where a fluid pressure test is applied to the part to ensure that the porosity of the part will not cause undesirable fluid leaks. After the pressure readings have been taken for the part, the part may advance to a barcode reading stage at the end of the leak test station so that the part's 2D barcode can be read. The leak test data, the identifier read from the barcode, and a timestamp indicating a time when the data was measured can then be sent to the product tracking system 402 on the cloud platform, providing a record of when the part passed through the leak test station. The bundled data can be moved to the cloud using any of the exemplary techniques described above. For example, a cloud-capable industrial controller that monitors and controls the process can receive the data from the leak test equipment and barcode reader and send the data to the cloud platform using an integrated cloud interface component. In another example, the data can be sent to a cloud proxy device (e.g., a dedicated cloud proxy device, a peer industrial device as illustrated in FIG. 5, a cloud-capable firewall device or other network infrastructure device as illustrated in FIG. 6, or other such proxy device), which then sends the data to the cloud platform.

In a similar fashion, product lots can be tracked through portions of the supply chain using radio frequency identification (RFID) tags physically attached to the lots. The RFID tag for a given lot can be read at various stages of the supply chain and sent to the cloud-based product tracking system 402 together with a time-stamp to provide a record of the lot's progress through the chain. Using these or similar techniques, a product's progress through the various plant-floor processes at the supplier and manufacturing entities of the supply chain can be tracked at the cloud platform.

Additionally, cloud-based product tracking system 402 can collect data regarding a product's progress between supply chain entities as the products are being transported. For example, GPS systems embedded in a cargo vehicle can measure a current geographical location and/or speed of the vehicle, and a controller on-board the vehicle can bundle this location information with a product identifier or lot number for products loaded on the vehicle. The controller can also associate a time-stamp for the bundled data. The controller can then send this bundled data to the cloud platform for storage and analysis. Moreover, when the cargo has reached its destination (e.g., a warehouse or retail outlet), the unique product or lot identifiers can be read as the products are received (e.g., by hand-held readers), and a time-stamped record of the receipt can be sent to the cloud platform. Sales and returns of a product at a retail outlet can also be recorded by product tracking system 402. For example, sales data can be stored in a server at the retail outlet having access to the cloud platform, and the server can provide sales records to product tracking system 402 according to a defined frequency (e.g., daily, when a new record is added, etc.).

Given the diverse supply chain data maintained in cloud storage 426, correlation component 406 can identify relationships between data sets that facilitate tracking a status of a product (or group of products) through the supply chain. For example, correlation component 406 can aggregate data sets associated with a common product identifier and arrange the aggregated data into a chronological order based on time-stamps associated with the records, providing a time-series record of the product's progress through the supply chain.

Correlation component 406 may also identify correlations between data sets based in part on a data model 422 that models at least a portion of the supply chain or entities within the supply chain. An exemplary data model 422 can represent an industrial enterprise in terms of multiple hierarchical levels, where each level comprises units of the enterprise organized as instances of types and their properties. Exemplary types can include, for example, assets (e.g., pumps, extruders, tanks, fillers, welding cells, utility meters, etc.), structures (e.g., production lines, production areas, plants, enterprises, production schedules, operators, etc.), and processes (e.g., quality audit, repairs, test/inspection, batch, product parameters, shifts, etc.).

Turning briefly to FIG. 10, an exemplary organizational hierarchy that can be used as a basis for data model 422 is illustrated. In this exemplary organizational model, the hierarchical levels can include—from lowest to highest—a workcell level 1002, a line level 1004, an area level 1006, a site level 1008, and an enterprise level 1010. The type instances described above—representing units of the enterprise—can be defined for respective levels of this hierarchical structure. In one or more embodiments, the cloud-based product tracking system described herein can provide a standard set of types that allow the user to model entities of a supply chain (e.g., supplier facilities, manufacturing facilities, etc.) in terms of these standard types. The product tracking system can also allow custom types to be created, allowing users to represent their particular business or manufacturing processes using a combination of standard and user-defined types.

Data model 422 can allow devices of an automation system and data items stored therein to be described and identified in terms of these hierarchical levels, allowing a common terminology to be used across the entire enterprise to identify devices and data associated with those devices. Data model 422 can represent industrial controllers, devices, machines, or processes as data structures (e.g., type instances) within this organizational hierarchy to provide context for data generated and stored throughout the enterprise relative to the enterprise as a whole. Moreover, so that product tracking system 402 may more accurately predict estimated times of arrival for products given the products' current location in the supply chain, data model 422 can include estimated or average processing times for respective production lines or production areas. That is, for various production areas, machines, or supply chain entities, data model 422 can model an estimated or average time required for a product to be processed (e.g., machined, manufactured, transported, checked in, etc.) by the respective areas, machines, or entities.

In addition to modeling the plant facilities within a supply chain entity, data model 422 can also model the larger supply chain in order to more accurately determine a current or predicted status of a product within the supply chain. Turning briefly to FIG. 11, an exemplary supply chain that can be modeled by data model 422 is illustrated. This simplified model includes supply entities 1102, manufacturing entities 1104, warehouse entities 1106, and retail entities 1108. In one or more embodiments, data model 422 can define valid supply chain paths between the entities. For example, the single manufacturing entity of the present example may receive supplies from two suppliers—Supplier 1 and Supplier 2—and provide finished products to three warehouses—Warehouses 1-3. Warehouse 1 supplies products to Retail Outlets 1 and 2, Warehouse 2 supplies products to Retail Outlet 2 only, and Warehouse 2 supplies products to Retail Outlets 1 and 3. Some embodiments of data model 422 may model these valid supply chain paths, distances between the paths, and other relevant supply path information. Such information can be leveraged by the cloud-based product tracking system 402 to provide current and predicted status information for products within the supply chain, as will be described in more detail below.

Thus, in embodiments in which data model 422 is used, correlation component 406 can leverage data model 422 to identify correlations between subsets of data in cloud storage 426. This can include, for example, associating a subset of data for a given product with a particular path through the supply chain (e.g., one of the supply paths illustrated in FIG. 10) so that product flow analysis can be performed on the path based on the identified subset of data. In another example, correlation component 406 can correlate inventory data for a particular product received from a retail outlet with product flow data received from a particular warehouse or manufacturing entity from which the product was received.

Product tracking system 402 can include a tracking component 412 configured to analyze supply chain data stored in cloud storage 426, as well as additional correlation data generated by correlation component 406, to generate historical, current, or predicted status data for products in the supply chain. Tracking component 412 can provide such tracking data to authorized cloud-capable client devices 410 via a client interface component 408. For example, in response to a request for current status information from a client device, tracking component 412 can search the supply chain data on cloud storage 426 and identify the most recent data received for the specified product (e.g., data associated with a unique barcode number, RFID tag, etc.). Tracking component 412 can identify the current location of the product based on, for example, a location of origin for the most recent data (e.g., a particular production line within a manufacturing facility, a geographical location reported by a cargo vehicle transporting the product, invoice information indicating receipt of the product at a warehouse or retail outlet, etc.). In addition to the location, tracking component 412 may identify a current status of the product based on related production or transportation data that has been correlated with the product by correlation component 406. For example, if the most recent data received for a specified product indicates that the product is currently at a product palletizing area of a manufacturing facility, but the most recent machine status data received for a palletizing machine that stacks and wraps product for shipment indicates that the palletizing machine is in an abnormal downtime state, tracking component 412 can determine based on this information that the product is currently stalled at the palletizing area and report this status to the client device.

Like correlation component 406, tracking component 412 can reference data model 422 in connection with determining a status of products in the supply chain. For example, one of the client devices 410 may request an estimated time that a specified product or lot will arrive at a particular point in the supply chain. Tracking component 412 can reference the supply chain data in cloud storage 426 to determine a current location and status of the product. Tracking component 412 can then reference data model 422 to determine estimated processing times associated with each entity in the supply chain path between the current location and the specified destination. Based on this information, tracking component 412 can estimate the time of arrival for the product and report this estimate to the client device. Tracking component 412 may adjust such estimated arrival times based on current machine status information. For example, if tracking component 412 determines that the product is stalled at a particular production area because of a machine downtime event (e.g., the faulty palletizing machine in the example described above), tracking component 412 may apply an adjustment to the estimated arrival time to allow for the unplanned machine outage. Users of client devices 410 can compare such information with pending sales orders to facilitate order management and planning.

In addition to providing information regarding current and predicted status of products within the supply chain, tracking component 412 can also analyze historical supply chain data to identify product flow trends, potential bottlenecks, or inefficiencies in product flow through the supply chain. For example, tracking component 412 can analyze historical supply chain data over a range of time and calculate an average amount of time that products spend at respective segments of the supply chain. This can include determining an average time spent at each supply chain entity, time spent traversing supply chain path segments between entities, time spent being processed by respective production stages within a given manufacturing entity, or other such metrics. Based on these results, tracking component 412 can identify segments of the supply chain having high latencies and present these potential supply chain bottlenecks to a user (e.g., via client devices 410). In one or more embodiments, tracking component 412 can perform this latency analysis on a per-product basis, since different products may be processed differently by the various supply chain entities and production areas. Accordingly, tracking component 412 can independently assess potential latency issues for each type of product in the supply chain.

Client interface component 408 can report results of these assessments to authorized client devices 410 having access to the cloud platform. In some embodiments, tracking component 412 can also generate recommendations for eliminating identified latency issues based on these results. In an exemplary scenario, tracking component 412 may identify one or more segments of the supply chain having latencies above a defined threshold, signifying a potential bottleneck in the supply chain. Tracking component 412 can then generate a recommendation for reducing the latencies of the identified segments based in part on data model 422, which models relationships between the various segments of the supply chain. For example, based on the relationship information provided by data model 422, tracking component 412 may determine that a high latency observed at a first production area is due to a high number of machine outages at a second production area that supplies product or materials to the first production area. Accordingly, tracking component 412 may generate a recommendation that a focused maintenance effort on the unreliable machine in the second production area would increase product throughput at the first production area. In one or more embodiments, product tracking system 402 can be interfaced with a maintenance scheduling system on the plant floor and proactively schedule maintenance on the machines or devices associated with the identified bottleneck area.

Tracking component 412 can also analyze historical supply chain data to obtain metrics on supplier performance. For example, if a manufacturing facility receives materials, parts, or products from multiple suppliers, tracking component 412 can analyze subsets of the supply chain data separately for each supplier to determine metrics on the respective suppliers, such as average turn-around time between ordering and receipt of materials. This information can be used by plant personnel to identify the most reliable suppliers of a given material or part.

In another exemplary application, the collected supply chain data can be used to manage inventory. In one exemplary technique, tracking component 412 can quantify a demand for a product based on an analysis of pending sales orders and historical sales data received from one or more retail entities of the supply chain. As described in previous examples, this sales data can be received at the cloud platform from cloud-capable business servers at the respective retail entities and stored on cloud storage 426. Cloud storage 426 may also contain current warehouse inventory data for the product (received from respective cloud-capable servers at one or more warehouses). Based on an analysis of this data, tracking component 412 can determine a level of demand for the product, and determine whether current inventory levels and production rates will ensure that the demand will always be met. In making this determination, tracking component 412 may consider expected latencies at multiple segments of the supply chain and assess the demand in view of these expected latencies.

For example, tracking component 412 may determine a rate at which the product is sold at the retail entities, and assess whether present and future inventory levels will meet this demand based on current inventory level, an estimated amount of time required to transport the product from the warehouse entities to the retail entities, an estimated amount of time required to manufacture the product at the manufacturing entity and to transport the finished product to the warehouse entities, or other estimated latency values. Tracking component 412 can then generate a recommendation for altering one or more supply chain processes if it is determined that the current rates of product manufacture, product consumption, and inventory replenishment will eventually result in depletion of inventory levels and unsatisfied demand. The recommendation may be directed toward any segment of the supply chain. For example, tracking component 412 may generate a recommendation to maintain a higher warehouse inventory level calculated to ensure that the demand seen at the retail entities will be met. Additionally or alternatively, tracking component 412 may generate a recommendation to increase a rate of production at a manufacturing entity calculated to maintain suitable inventory levels at the warehouse entities, based in part on the estimated latencies calculated for the relevant production areas and transportation paths used to transport the product from the manufacturing entities to the warehouse entities. In another example, tracking component 412 may also determine that one or more supply entities must increase production of a raw material or part required by the manufacturing entity to fabricate the product in order to maintain necessary inventory levels downstream. Thus, cloud-based product tracking system can recommend modifications to processes at any portion of the supply chain to guarantee that an observed demand at a retail entity will always be met. Similar to previous examples, tracking component 412 can make these determinations based in part on supply chain interdependencies identified by correlation component 406 and/or data model 422.

One or more embodiments of product tracking system 402 may, in addition to or instead of providing recommendations, dynamically alter supply chain processes in response to detected inefficiencies or deficiencies. In such embodiments, product tracking system 402 may issue instructions to one or more devices 404 via the cloud platform to implement the necessary changes. This can include, for example, altering a shipping schedule maintained in a warehouse server to schedule more or fewer shipments of a particular part or product, altering a production schedule maintained in a plant server to increase the number of shifts during which a particular product will be manufactured, modifying a supplier order for a raw material or part used to manufacture the product, or other dynamic modifications to supply chain processes. Turning briefly to FIG. 12, an exemplary architecture for issuing supply chain management instructions from a cloud platform is illustrated. As in previous examples, a cloud platform hosts product tracking services, including a tracking component 1202 that analyzes supply chain data stored on cloud storage 1208 in view of data model 1206 (similar to data model 422) that models hierarchical, geographical, and/or temporal relationships between supply chain entities. The product tracking system can exchange data with devices in a plant facility via device interface component 1204. In the present exemplary configuration, device interface component 1204 exchanges data with control-level devices 1214 (e.g., industrial controllers, VFDs, etc.) on a plant network 1216 and business-level devices 1228 (e.g., business servers, financial systems, order management servers, etc.) on a business network 1226 via a cloud proxy device 1220 (e.g., a firewall box or other network infrastructure device that acts as a cloud proxy, as illustrated in FIG. 7). Cloud proxy device 1220 is communicatively coupled to the cloud platform via cloud interface component 1222. If tracking component 1202 determines that a modification must be made to one or more supply chain processes on the plant-floor or business-level side of the enterprise, tracking component 1202 can instruct device interface component 1204 to send supply chain management data 1212 to the cloud proxy device 1220 to be directed to the appropriate control-level or business-level device. Cloud proxy device 1220 can relay supply chain management data to the respective devices according to the particular communication protocol used by the target device. For example, cloud proxy device 1220 can send management instructions to the control-level devices 1214 using Common Industrial Protocol (CIP), and to the business-level systems using TCP/IP protocol.

Visualization of tracking information at the client devices is now discussed with reference to FIG. 4. To visualize tracking information, recommendations, and other information generated by product tracking system 402, client interface component 408 can serve predesigned interface displays 424 to any Internet-capable client devices 410 having access privileges to product tracking system 402, and render tracking data via the display screens using the client device's native display capabilities. To this end, a set of preconfigured display screens 424 can be stored on cloud storage associated with product tracking system 402, and the client interface component 408 can deliver selected display screens 424 in response to invocation by the client device 410. The display screens 424 can be developed, for example, using a development environment provided by product tracking system 402. In one or more embodiments, product tracking system 402 can provide this development environment as a cloud service, allowing a developer to remotely access a set of cloud-side interface screen development tools to facilitate design of interface screen layouts, data links, graphical animations, and navigation links between screens. In such embodiments, the interface screen development environment can allow the developer to leverage cloud resources (e.g., cloud storage and processing resources) to develop a set of display screens 424 for a given operator interface application to be run on product tracking system 402. Alternatively, some embodiments of product tracking system 402 can allow display screens developed by external display development applications to be uploaded to the cloud platform and executed by the product tracking system 402 during runtime.

Each of the display screens 424 can include display tags defining which data items are to be displayed on the respective screens, formats for the respective data items, desired graphical animations to be associated with the respective data items, graphical elements to be included on the respective display screens (e.g., externally defined graphical elements definitions), and other such configuration information. Some display screens 424 can also be configured to render alarm or informational messages in response to determinations that subsets of the supply chain data have met certain conditions (e.g., in response to a determination that a given industrial parameter has exceeded a defined setpoint, or that a defined production goal has been met). Since supply chain data can be received from multiple industrial systems and supply chain entities (possibly at diverse geographical locations), alarms, notification events, animation triggers, and the like can be defined in terms of composite data values for multiple supply chain entities, allowing the entities to be viewed and analyzed from a high-level enterprise perspective. For example, consider a scenario in which a particular product is being produced at three different facilities. Respective devices 404 can deliver production statistics to the device interface component 414, and the product tracking system 402 can aggregate these production statistics substantially in real-time to yield composite data (e.g., a total production count for all three facilities) even though the three facilities may not be communicatively networked together over a data network. One or more of the displays screens 424 can be configured to display these composite production statistics, trigger alarms or graphical animations as a function of the composite statistics, etc. Client interface component 408 can deliver these display screens to authorized client devices 410 having Internet access and suitable authorization credentials, providing owners of the client devices 410 with an enterprise-level view of the multiple industrial systems and supply chain entities monitored by product tracking system 402.

The cloud-based product tracking system 402 can support conditional display of supply chain and tracking data based on defined user roles having different levels of access privileges. Accordingly, product tracking system 402 can allow multiple user roles to be defined (e.g., operator, plant manager, finance, accounting, administrator, etc.), and customize the presentation of tracking data for the respective user roles. For example, an administrator or other user with administrative privileges can associate a given user role with a subset of display screens 424 that users belonging to that user role are allowed to access. In another example, selected data displays on the display screens 424 can be configured with visibility links that render the selected data visible only to users associated with certain authorized user roles.

One or more embodiments of the cloud-based product tracking system 402 can allow individual users to subscribe to selected real-time data feeds from one or more industrial systems or supply chain entities. For example, a maintenance engineer may be interested in monitoring a particular performance metric of a specific machine at a plant facility. Product tracking system 402 can allow the engineer to identify the machine and the performance metric (e.g., a temperature of a die cast oven) and add this data feed to one of the existing display screens 424 as a user preference. Alternatively, product tracking system 402 can create a new custom screen in response to the subscription request. In either case, the subscription information can be stored in a user profile associated with the engineer, and the client interface component 408 can render a live feed of the selected performance metric to the engineer's client device upon request.

Since the operator interface displays can be served to diverse types of client devices (e.g., desktop computers, mobile phones, tablet computers, laptop computers, HMI terminals, television monitors, etc.), the cloud-based product tracking system 402 can render a given display screen in a format suitable for display on the device invoking the screen, and in a manner that makes efficient use of the device's resources. For example, if the product tracking system 402 receives a request for a display screen from a cellular phone, client interface component 408 can deliver the requested display screen to the cellular phone in a format adapted to the display capabilities of the phone (e.g., at a display ratio and resolution suitable for display on the phone's screen).

In some embodiments, client applications 410 can run software applications designed to interact with product tracking system 402. For example, a product tracking client application can be provided that, when installed and executed on an Internet-capable client device, provides access to product tracking data residing on the cloud platform. Such client applications can include configuration menus that allow the device owner to identify the cloud platform and/or product tracking data to be accessed (e.g., a URL of the cloud platform). Once communication is established, the client application can provide pre-defined views of selected subsets of the stored product tracking data. These pre-defined views can include, for example, position charts that trace a product's path through the supply chain, graphs representing latencies of a product at respective stages of the supply chain, inventory levels of a product at respective warehouse facilities, scheduling screens showing estimated times of arrival for products, notification screens providing alerts that a current rate of flow through the supply chain is not sufficient to meet a current demand for a product, or other such pre-defined visualizations.

To accurately represent temporal relationships between supply chain events reported by diverse industrial devices, industrial and supply chain data provided by devices 404 should be time-stamped using a common synchronized time standard. Accordingly, in order to accurately determine when an event at a first supply chain entity occurred relative to an event at a second supply chain entity, the internal device clocks used by the respective devices 404 to time-stamp the data should be synchronized. To this end, data sourcing devices can include time stamp components configured to synchronize the internal clocks with a common clock maintained on the cloud platform.

FIG. 13 is a high-level overview depicting synchronization of a device clock with a cloud clock. In the present example, industrial devices 13081 and 13082 are configured to provide data to a cloud platform 1302 (e.g., over an Internet layer) for use by product tracking services 1316 residing on the cloud platform 1302. Industrial devices 13081 and 13082 can reside at different locations (Location 1 and Location 2). For example, industrial devices 13081 and 13082 may be located at different plant facilities or at different areas within the same plant facility. In some cases, industrial devices 13081 and 13082 may be located in different time zones. To ensure that data received from industrial devices 13081 and 13082 are time stamped according to a common time reference, internal device clocks 13121 and 13122 can be synchronized to global clock via an atomic clock receiver or a GPS receiver. Alternatively, internal device clocks 13121 and 13122 can be synchronized to a common cloud clock 1306 maintained by the cloud platform 1302, as illustrated in FIG. 13. Time stamp components 13101 and 13102 associated with industrial devices 13081 and 13082 can then apply time stamps to their respective data based on the times provided by synchronized device clocks 13121 and 13122. In this way, data events at each location will be accurately time stamped using a common clock standard that accurately reflects when an event at one location occurred relative to an event at the other location. Moreover, data items from both locations can be aggregated at cloud platform 1302 and arranged chronologically based on the synchronized time stamps to yield an event sequence that includes data events from both locations. Although internal device clocks 13121 and 13122 have been synchronized with a global or centralized clock, time stamps may still be viewed locally at the industrial devices 13081 and 13082 according to their respective local time zones.

One or more embodiments of the cloud-based product tracking system can also include notification services for notifying relevant personnel of a detected supply chain event. Accordingly, such embodiments of the product tracking system can include a notification component configured to deliver such notifications to selected client devices according to predefined user preferences. FIG. 14 illustrates an exemplary notification architecture according to one or more embodiments of this disclosure. Similar to previous examples, product tracking system 1404 executing on cloud platform 1402 receives industrial and/or supply chain data from devices associated with supply chain 1416 via device interface component 1412. The supply chain data is stored on cloud storage 1406, where the data can be analyzed by tracking component 1408. Tracking component 1408 can analyze the stored supply chain data in view of a data mode of the supply chain or segments thereof and/or correlations between subsets of the data identified by a correlation component (not shown).

In the present example, the cloud-based product tracking system 1404 running on the cloud platform 1402 can include a notification component 1410 configured to route notifications 1418 to appropriate plant personnel in accordance with predefined notification criteria. For example, tracking component 1408 can determine whether selected subsets of the supply chain data stored on cloud storage 1406 meet one or more predefined notification conditions. These can include such conditions as detecting that a particular process value has exceeded a defined setpoint; detecting a transition to a particular machine state; detecting an alarm condition; determining that a specified production, inventory, or sales goal has been achieved; determining that an order has been fulfilled or a product shipment has been received at a particular supply chain entity; or other such conditions that can be detected through analysis of the supply chain data. When tracking component 1408 detects a condition within the supply chain data that matches a notification criterion, tracking component 1408 can inform notification component 1410 that personnel are to be notified. In response, notification component 1410 can identify one or more specific plant employees who are to receive the notification, as well as information identifying a user notification device, phone number, or email address for each person to be notified.

In one or more embodiments, notification component 1410 can determine this notification information by cross-referencing configuration information that identifies which personnel are to be notified for a given type of condition, one or more notification methods for each identified person, and/or other relevant information. When tracking component 1408 determines that a subset of the supply chain data meets a notification condition, notification component 1410 can reference the configuration data to determine, for example, which personnel should be notified, which user devices should receive the notification, a required action to be taken by the recipient, a due date for the action, a format for the notification, and/or other relevant information. The configuration data can maintain multiple separate personnel lists respectively associated with different types of actionable situations. In some embodiments, the personnel list selected for a given notification can be at least partly a function of context data associated with the supply chain data (e.g., context information applied by transformation components 510, 604, or 710). For example, if the supply chain data indicates that a process parameter has exceeded a setpoint value, notification component 1410 can identify the list of personnel to receive the notification based on the area or workcell to which the process parameter relates.

Once notification component 1410 has determined the appropriate personnel and devices to be notified, the notification component 1410 can deliver notifications 1418 to one or more notification destinations. The notification can be sent to one or more identified Internet-capable client devices 1414, such as a phone, a tablet computer, a desktop computer, or other suitable devices. In some embodiments, a cloud application running on the cloud platform can provide a mechanism for notified personnel to communicate with one another via the cloud (e.g., establish a conference call using Voice-over-IP). In some embodiments, the notification component 1410 can be configured to send the notification 1418 periodically at a defined frequency until the user positively responds to the notification (e.g., by sending a manual acknowledgement via one of the client devices 1414). Notification component 1410 can also be configured to escalate an urgency of high-priority notifications if an acknowledgment is not received within a predetermined amount of time. This urgency escalation can entail sending the notification 1418 at a gradually increasing frequency, sending the notification to devices associated with secondary personnel if the primary personnel do not respond within a defined time period, or other such escalation measures.

FIGS. 15-16 illustrate various methodologies in accordance with one or more embodiments of the subject application. While, for purposes of simplicity of explanation, the one or more methodologies shown herein are shown and described as a series of acts, it is to be understood and appreciated that the subject innovation is not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the innovation. Furthermore, interaction diagram(s) may represent methodologies, or methods, in accordance with the subject disclosure when disparate entities enact disparate portions of the methodologies. Further yet, two or more of the disclosed example methods can be implemented in combination with each other, to accomplish one or more features or advantages described herein.

FIG. 15 illustrates an example methodology 1500 for tracking product through a supply chain using a cloud platform. Initially, at 1502, supply chain data relating to a product is collected at a cloud platform as the product traverses a supply chain. This data can include production data received from industrial devices at a supplier or manufacturing facility, location or status data received from cargo vehicles as the product is being transported between supply chain entities, sales data received from a business server at a retail outlet, shipping data received from an inventory server at a warehouse, or other such information. At 1504, the supply chain data is aggregated and correlated at the cloud platform. In some embodiments, the data can be aggregated and correlated based on contextual information appended to the data prior to being received at the cloud platform (or applied at the cloud platform). The data can also be aggregated and correlated based in part on a data model that defines relationships between supply chain entities, or between devices comprising the respective entities. At 1506, tracking information for the product is generated based on results of the aggregation and correlation of step 1504. The tracking information can include a location of the product within the supply chain, an estimated time of arrival of the product at a specified point in the supply chain, a status of the product (e.g. “in transit,” “in production,” “delayed,” etc.), or other such status information. At 1508, the tracking information is sent to a cloud-capable client device (e.g., via an Internet connection).

FIG. 16 illustrates an example methodology 1600 for identifying inefficiencies in a supply chain using a cloud platform. Initially, at 1602, supply chain data is received at a cloud platform from multiple supply chain entities (e.g., supplier facilities, manufacturing facilities, warehouses, retail outlets, transportation vehicles, etc.). At 1604, the supply chain data is aggregated and correlated at the cloud platform. At 1606, an inefficiency of the supply chain is identified based on the aggregated and correlated supply chain data. This can include, for example, analyzing historical product flow data to identify high latency areas representing potential bottlenecks, identifying areas having a high number of downtime occurrences, or other such inefficiencies that impact product flow through the supply chain. As described in previous examples, the aggregated and correlated supply chain data can be analyzed in view of a data model of the supply chain to facilitate identification of potential bottlenecks or other inefficiencies. At 1608, information regarding the identified inefficiency is delivered to a cloud-capable client device from the cloud platform.

Embodiments, systems, and components described herein, as well as industrial control systems and industrial automation environments in which various aspects set forth in the subject specification can be carried out, can include computer or network components such as servers, clients, programmable logic controllers (PLCs), automation controllers, communications modules, mobile computers, wireless components, control components and so forth which are capable of interacting across a network. Computers and servers include one or more processors—electronic integrated circuits that perform logic operations employing electric signals—configured to execute instructions stored in media such as random access memory (RAM), read only memory (ROM), a hard drives, as well as removable memory devices, which can include memory sticks, memory cards, flash drives, external hard drives, and so on.

Similarly, the term PLC or automation controller as used herein 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 cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, Input/Output (I/O) device, sensor, actuator, and human machine interface (HMI) that communicate via the network, which includes control, automation, and/or public networks. The PLC or automation controller can also communicate to and control various other devices such as I/O modules including analog, digital, programmed/intelligent I/O modules, other programmable controllers, communications modules, sensors, actuators, output devices, and the like.

The network can include public networks such as the internet, intranets, and automation networks such as control and information protocol (CIP) networks including DeviceNet, ControlNet, and Ethernet/IP. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.

In order to provide a context for the various aspects of the disclosed subject matter, FIGS. 17 and 18 as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented.

With reference to FIG. 17, an example operating environment 1710 for implementing various aspects of the aforementioned subject matter includes a computer 1712. The computer 1712 includes a processing unit 1714, a system memory 1716, and a system bus 1718. The system bus 1718 couples system components including, but not limited to, the system memory 1716 to the processing unit 1714. The processing unit 1714 can be any of various available processors. Multi-core microprocessors and other multiprocessor architectures also can be employed as the processing unit 1714.

The system bus 1718 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 8-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).

The system memory 1716 includes volatile memory 1720 and nonvolatile memory 1722. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1712, such as during start-up, is stored in nonvolatile memory 1722. By way of illustration, and not limitation, nonvolatile memory 1722 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory 1720 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

Computer 1712 also includes removable/non-removable, volatile/non-volatile computer storage media. FIG. 17 illustrates, for example a disk storage 1724. Disk storage 1724 includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memory stick. In addition, disk storage 1724 can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage 1724 to the system bus 1718, a removable or non-removable interface is typically used such as interface 1726.

It is to be appreciated that FIG. 17 describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment 1710. Such software includes an operating system 1728. Operating system 1728, which can be stored on disk storage 1724, acts to control and allocate resources of the computer 1712. System applications 1730 take advantage of the management of resources by operating system 1728 through program modules 1732 and program data 1734 stored either in system memory 1716 or on disk storage 1724. It is to be appreciated that one or more embodiments of the subject disclosure can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer 1712 through input device(s) 1736. Input devices 1736 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1714 through the system bus 1718 via interface port(s) 1738. Interface port(s) 1738 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1740 use some of the same type of ports as input device(s) 1736. Thus, for example, a USB port may be used to provide input to computer 1712, and to output information from computer 1712 to one or more output devices 1740. Output adapter 1742 is provided to illustrate that there are some output devices 1740 like monitors, speakers, and printers, among other output devices 1740, which require special adapters. The output adapters 1742 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1740 and the system bus 1718. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1744.

Computer 1712 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1744. The remote computer(s) 1744 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1712. For purposes of brevity, only a memory storage device 1746 is illustrated with remote computer(s) 1744. Remote computer(s) 1744 is logically connected to computer 1712 through a network interface 1748 and then physically connected via communication connection 1750. Network interface 1748 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s) 1750 refers to the hardware/software employed to connect the network interface 1748 to the system bus 1718. While communication connection 1750 is shown for illustrative clarity inside computer 1712, it can also be external to computer 1712. The hardware/software necessary for connection to the network interface 1748 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

FIG. 18 is a schematic block diagram of a sample-computing environment 1800 with which the disclosed subject matter can interact. The sample-computing environment 1800 includes one or more client(s) 1802. The client(s) 1802 can be hardware and/or software (e.g., threads, processes, computing devices). The sample-computing environment 1800 also includes one or more server(s) 1804. The server(s) 1804 can also be hardware and/or software (e.g., threads, processes, computing devices). The servers 1804 can house threads to perform transformations by employing one or more embodiments as described herein, for example. One possible communication between a client 1802 and a server 1804 can be in the form of a data packet adapted to be transmitted between two or more computer processes. The sample-computing environment 1800 includes a communication framework 1806 that can be employed to facilitate communications between the client(s) 1802 and the server(s) 1804. The client(s) 1802 are operably connected to one or more client data store(s) 1808 that can be employed to store information local to the client(s) 1802. Similarly, the server(s) 1804 are operably connected to one or more server data store(s) 1810 that can be employed to store information local to the servers 1804.

What has been described above includes examples of the subject innovation. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the disclosed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject innovation are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the disclosed subject matter. In this regard, it will also be recognized that the disclosed subject matter includes a system as well as a computer-readable medium having computer-executable instructions for performing the acts and/or events of the various methods of the disclosed subject matter.

In addition, while a particular feature of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” and “including” and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising.”

In this application, the word “exemplary” is used to mean serving 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, use of the word exemplary is intended to present concepts in a concrete fashion.

Various aspects or features described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ], smart cards, and flash memory devices (e.g., card, stick, key drive . . . ).

Claims

1. A product tracking system, comprising:

a memory that stores computer-executable components;
a processor operatively coupled to the memory that executes computer-executable components, including: a device interface component configured to receive supply chain data from devices of a supply chain, wherein the device interface component receives the supply chain data on a cloud platform; a correlation component configured to aggregate and correlate subsets of the supply chain data to yield correlated data; and a tracking component configured to determine a status of a product within the supply chain based on the correlated data.

2. The product tracking system of claim 1, further comprising a client interface component configured to serve a display screen to a client device and to visualize information regarding the status of the product on the display screen.

3. The product tracking system of claim 1, wherein the correlation component determines a correlation between subsets of the supply chain data based in part on a data model that models at least a portion of the supply chain.

4. The product tracking system of claim 1, wherein the tracking component is further configured to identify a product flow inefficiency associated with a portion of the supply chain based on an analysis of the correlated data over a time range.

5. The product tracking system of claim 4, wherein the tracking component is further configured to generate a recommendation for adjusting at least one supply chain process to mitigate the product flow inefficiency.

6. The product tracking system of claim 1, wherein the tracking component is further configured to predict a level of demand for the product based on an analysis of the supply chain data.

7. The product tracking system of claim 6, wherein the tracking component is further configured to generate a recommended modification to at least one supply chain process based on the level of demand.

8. The product tracking system of claim 7, wherein the recommended modification comprises a modification predicted to adjust an inventory level for the product to a level that satisfies the level of demand.

9. The product tracking system of claim 6, wherein the tracking component is further configured to generate or alter an order for materials based on the level of demand.

10. The product tracking system of claim 3, wherein the tracking component is further configured to output an estimated time of arrival for the product to reach a specified point in the supply chain based on the status and latency information modeled by the data model.

11. A method for tracking product through a supply chain, comprising:

receiving, at a cloud platform, supply chain data from a plurality of devices within a supply chain;
aggregating and correlating subsets of the supply chain data yielding correlated data; and
identifying a status of a product within the supply chain based on the correlated data.

12. The method of claim 11, further comprising:

delivering a display screen to a client device via the cloud platform; and
rendering information regarding the status on the display screen.

13. The method of claim 11, wherein the aggregating and correlating comprises determining a correlation between subsets of the supply chain data based in part on a data model of at least a portion of the supply chain.

14. The method of claim 11, further comprising identifying an inefficiency in a product flow through the supply chain based on an analysis of the correlated data over a time range.

15. The method of claim 14, further comprising outputting a recommended adjustment to at least one supply chain process predicted to mitigate the inefficiency.

16. The method of claim 11, further comprising predicting a demand level for the product based on an analysis of the supply chain data.

17. The method of claim 16, further comprising outputting a recommended adjustment to at least one supply chain process predicted to maintain an inventory level that satisfies the demand level.

18. The method of claim 16, further comprising generating or adjusting an order for materials based on the demand level.

19. The method of claim 13, further comprising outputting an estimated time at which the product will arrive at a specified point in the supply chain based on the status and latency information read from the data model.

20. A computer-readable medium having stored thereon computer-executable instructions that, in response to execution, cause a computing system to perform operations, including:

collecting, from multiple devices within a supply chain, data relating to a product in the supply chain;
storing the data in storage associated with a cloud platform;
aggregating and correlating subsets of the data at the cloud platform to yield correlated data; and
generating first output information identifying a status of the product within the supply chain.

21. The computer-readable medium of claim 20, wherein the status comprises at least one of a current location of the product within the supply chain, an estimated time of arrival of the product at a specified point within the supply chain, identification of whether the product is in production, identification of whether the product is in transit, an inventory level for the product, or a demand level for the product.

22. The computer-readable medium of claim 20, further comprising generating second output information identifying a product flow inefficiency associated with a system within the supply chain based on an analysis of the correlated data.

Patent History
Publication number: 20130211870
Type: Application
Filed: Dec 21, 2012
Publication Date: Aug 15, 2013
Applicant: Rockwell Automation Technologies, Inc. (Mayfield Heights, OH)
Inventor: Rockwell Automation Technologies, Inc.
Application Number: 13/725,543
Classifications
Current U.S. Class: Needs Based Resource Requirements Planning And Analysis (705/7.25)
International Classification: G06Q 10/06 (20120101);