Cloud based drive monitoring solution
Summary by NHIP
Cloud Agent Reconfiguration
The system monitors industrial devices using a local data historian and a facility-based cloud agent. The agent collects data from a SQL server database according to a manifest that defines collection targets, send frequencies, and priorities, then dynamically reconfigures itself without interrupting data transmission.
Claim Score by NHIP
Abstract
A cloud-based remote monitoring system and method monitor one or more industrial devices of an industrial facility, including a local data historian located to monitor one or more parameters from the industrial devices, and store parameters in a local storage associated with the data historian, as well as a cloud agent located at the industrial facility to collect data indicative of a past and/or a present state of the industrial devices from the data historian local storage according a manifest specific to the industrial facility. The cloud agent sends the collected data to a remote cloud platform according to the manifest, and dynamically reconfigures the cloud agent without interrupting the collecting and the sending.

Term
6.5 yearsleft in the term
Expires 13 March 2033.
- Priority
- Filed
- Granted
- Today
- Expires
20 claims: 2 independent, 18 dependent
- 1Broadest claimClaim Score 62, broad(NHIP)A cloud-based remote monitoring system for monitoring industrial devices of an industrial facility, comprising:a data historian located at the industrial facility and configured to monitor one or more parameters in parameters archives received from the industrial devices, and store parameters in a local storage associated with the data historian;anda cloud agent located at the industrial facility and configured to, by at least one processor:collect data indicative of a past and/or a present state of the industrial devices from the local storage associated with the data historian according a manifest specific to the industrial facility,send the collected data to a remote cloud platform according to the manifest, anddynamically reconfigure the cloud agent without interrupting the collecting and the sending.
- 12A cloud-based remote monitoring for monitoring industrial devices of an industrial facility, the method comprising:by a data historian located at the industrial facility:monitoring one or more parameters in parameters archives received from the industrial devices, andstoring parameters in a local storage associated with the data historian;andby at least one processor located at the industrial facility:collecting data indicative of a past and/or a present state of the industrial devices from the local storage associated with the data historian according a manifest specific to the industrial facility,collecting data indicative of a past and/or a present state of the industrial devices according a manifest specific to the industrial facility,sending the collected data to a remote cloud platform according to the manifest, anddynamically reconfiguring the at least one processor without interrupting the collecting and the sending.
Independent claims2
90 paragraphs in 5 sections, as filed
RELATED APPLICATIONS
This application is a continuation of U.S. patent application Ser. No. 13/798,430, filed Mar. 13, 2013, now U.S. Pat. No. 9,647,906, issued May 9, 2017, entitled CLOUD BASED DRIVE MONITORING SOLUTION, which claims priority to and the benefit of U.S. Provisional Patent Application No. 61/721,859, filed Nov. 2, 2012, the entirety of which applications are hereby incorporated by reference.
BACKGROUND INFORMATION
The present exemplary embodiments relate to remote monitoring. They find particular application in conjunction with industrial devices, such as the POWERFLEX 7000, and will be described with particular reference thereto. However, it is to be appreciated that the present exemplary embodiments are also amenable to other like applications.
Maintaining stability and integrity of industrial devices is a high priority. Industrial devices include, for example, motor drives, such as the POWERFLEX 7000. Motor drives are used to generate and provide alternating current (AC) output power to a motor. Failure to maintain the stability and integrity of industrial devices can affect production and prove costly to entities employing the industrial devices. Further, maintaining the stability and integrity of industrial devices can prove dangerous to those relying upon industrial equipment to, for example, generate power or pump gas to generate heat.
To maintain stability and integrity of industrial devices, industrial devices can be locally or remotely monitored for anomalies and/or patterns indicative of failure. Traditionally, industrial devices have been locally monitored. However, industrial equipment may not always be easily accessed. Further, those with the technical know how to identify anomalies and/or patterns indicative of failure may not be on-site. Sending maintenance and/or repair personnel to a field installation is costly. Remote monitoring provides a solution to these challenges.
Previous remote monitoring implementations involved customized software and infrastructure configurations, which are cumbersome to maintain and update. Further, on-premise data collection required by such remote monitoring systems consumes large amounts of data storage. Moreover, since potentially sensitive plant data is to be transmitted to a remote viewer, secure data transmission channels are required.
The present application provides a new and improved system and method which overcome the above-referenced problems and others.
BRIEF DESCRIPTION
In accordance with one aspect of the present disclosure, a cloud-based remote monitoring system for monitoring an industrial facility is provided. The industrial facility includes one or more industrial devices. The system includes a cloud-based remote monitoring system and method monitor one or more industrial devices of an industrial facility, including a local data historian located to monitor one or more parameters from the industrial devices, and store parameters in a local storage associated with the data historian, as well as a cloud agent located at the industrial facility to collect data indicative of a past and/or a present state of the industrial devices from the data historian local storage according a manifest specific to the industrial facility. The cloud agent sends the collected data to a remote cloud platform according to the manifest, and dynamically reconfigures the cloud agent without interrupting the collecting and the sending.
In accordance with another aspect of the present disclosure, a cloud-based remote monitoring method for monitoring an industrial facility is provided. The industrial facility includes one or more industrial devices. By at least one processor located at the industrial facility, data indicative of a past and/or a present state of the industrial devices is collected according a manifest specific to the industrial facility. Further, the collected data is sent to a remote cloud platform according to the manifest and the at least one processor is dynamically reconfigured without interrupting the collecting and the sending.
In accordance with another aspect of the present disclosure, a cloud-based remote monitoring system for monitoring an industrial facility is provided. The industrial facility includes one or more industrial devices. The system includes a cloud agent located at the industrial facility and configured to, by at least one processor, collect data indicative of a past and/or a present state of the industrial devices according a manifest specific to the industrial facility. The cloud agent is further configured to send the collected data to a remote cloud platform according to the manifest. The collected data is sent to corresponding queues of the cloud platform based on data type. The cloud agent is further configured to dynamically reconfigure the cloud agent without interrupting the collecting and the sending. The cloud platform processes the sent data from the queues to facilitate remote monitoring of the industrial devices, data in each queue processed differently.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention.
<figref idref="DRAWINGS">FIG. 1</figref> illustrates a cloud-based remote monitoring system;
<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example memory layout of an industrial device;
<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example bit layout of a status parameter of an industrial device;
<figref idref="DRAWINGS">FIG. 4</figref> illustrates part of an example manifest listing motor drives to monitor;
<figref idref="DRAWINGS">FIG. 5</figref> illustrates part of an example manifest listing parameters to monitor for motor drives;
<figref idref="DRAWINGS">FIG. 6</figref> illustrates a detailed embodiment of the cloud-based remote monitoring system of <figref idref="DRAWINGS">FIG. 1</figref>;
<figref idref="DRAWINGS">FIG. 7</figref> illustrates more detail of the cloud agent of <figref idref="DRAWINGS">FIG. 6</figref>;
<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example data packet;
<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example status webpage for a motor drive that can be viewed by a web client;
<figref idref="DRAWINGS">FIG. 10</figref> illustrates an example historical alarms webpage for a motor drive that can be viewed by a web client;
<figref idref="DRAWINGS">FIG. 11</figref> illustrates an example motor speed webpage for a motor drive that can be viewed by a web client;
<figref idref="DRAWINGS">FIG. 12</figref> illustrates an example computing environment; and
<figref idref="DRAWINGS">FIG. 13</figref> illustrates an example networking environment.
DETAILED DESCRIPTION
Various aspects of this disclosure are 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 of one or more aspects. It should be understood, however, that certain aspects of this disclosure may be practiced without these specific details, or with other methods, components, materials, etc. In other instances, well-known structures and devices are shown in block diagram form to facilitate describing one or more aspects.
With reference to <figref idref="DRAWINGS">FIG. 1</figref>, a cloud-based remote monitoring system <b>10</b> including one or more industrial facilities <b>12</b>, <b>14</b> is provided. Each industrial facility <b>12</b>, <b>14</b> corresponds to an industrial enterprise. For example, a first industrial facility can correspond to a first industrial enterprise, and a second industrial facility can correspond to a second industrial enterprise. As another example, the first and second industrial facilities can correspond to a common industrial enterprise. The industrial facilities <b>12</b>, <b>14</b> can be fixed (e.g., a plant facility) and/or mobile (e.g., a system contained in a truck or other service vehicle).
Each industrial facility <b>12</b>, <b>14</b> includes one or more industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>. The industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> can include one or more of: industrial controllers (e.g., programmable logic controllers or other types of programmable automation controllers); field devices (e.g., sensors and meters); motor drives (e.g., the POWERFLEX 7000); operator interfaces (e.g., human-machine interfaces, industrial monitors, graphic terminals, message displays, etc.); industrial robots, barcode markers and readers; vision system devices (e.g., vision cameras); smart welders; and other such industrial devices.
Each of the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> includes one or more memories. The memories include externally readable data (external to the industrial device) indicative of the present and/or past state of the industrial device. For example, the memories can include one or more of: 1) one or more configurable parameters controlling the operation of the industrial device; 2) one or more parameters indicating the status of the industrial device; 3) one or more warning, fault or alarm parameters indicating one or more of warnings, faults and alarms, respectively, with the industrial device; and 4) one or more queues, each with one or more of warnings, faults and alarms with the industrial device. Referring to <figref idref="DRAWINGS">FIG. 2</figref>, an example memory layout of an industrial device is illustrated. Referring to <figref idref="DRAWINGS">FIG. 3</figref>, an example table illustrating the bit layout of a status parameter of an industrial device is illustrated.
The industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> make up one or more automation systems operating within the respective facilities. Exemplary automation systems can include one or more of: 1) batch control systems (e.g., mixing systems); 2) continuous control systems (e.g., proportional-integral-derivative (PID) control systems); and 3) discrete control systems. Exemplary automation systems can include one or more industrial controllers that facilitate monitoring and control of respective processes. The controllers exchange data with field devices using native hardwired input/output (I/O) and/or using industrial facility networks (e.g., Ethernet/Internet Protocol (IP), Data Highway Plus, ControlNet, Devicenet, etc.).
A given controller typically receives any combination of digital and 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.
Each industrial facility <b>12</b>, <b>14</b> includes an on-premise data collection system <b>28</b>, <b>30</b> communicatively coupled to the respective industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> using one or more associated network connections and any suitable protocol. In some embodiments, control interface protocol (CIP) and/or distributed protocol interface (DPI) may be used for communication between the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> and the data collection system <b>28</b>, <b>30</b>. Using CIP and/or DPI, the data collection system <b>28</b>, <b>30</b> is configurable to monitor controlled processes and device status through receipt of information related to the monitored devices and/or associated processes.
The data collection system <b>28</b>, <b>30</b> includes a cloud agent <b>32</b>, <b>34</b> configured to collect live data (e.g., status parameter values) and/or historical data (e.g., alarm history, fault history, warning history, status history, trend data, etc.) from the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>, directly and/or indirectly by, for example, accessing an optional data historian <b>36</b>, <b>38</b> of the data collection system <b>28</b>, <b>30</b>. The data historian <b>36</b>, <b>38</b> monitors one or more industrial devices and stores data in local storage associated with the data historian. This data can include historical data and/or live data read from the monitored devices. It's advantageous to use the data historian <b>36</b>, <b>38</b> as the data source when there are a large number of data points to monitor.
The cloud agent <b>32</b>, <b>34</b> is further configured to transmit the collected data to a cloud platform <b>40</b> of the cloud-based remote monitoring system <b>10</b>. The data can be prioritized before transmission to the cloud platform <b>40</b>. Further, the data can be transmitted with priorities indicating the order with which the cloud platform <b>40</b> processes the data. The cloud agent <b>32</b>, <b>34</b> can further specify how transmitted data is to be processed, for example, to allow additional data types to be processed by the cloud platform <b>40</b>. If an industrial device becomes disconnected, powered off or otherwise unavailable, an alarm is sent to the cloud platform <b>40</b>. The cloud agent <b>32</b>, <b>34</b> can be, for example, a Windows service that periodically collects and transmits serialized and compressed data into the cloud platform <b>40</b> using standard web services over hypertext transfer protocol secure (HTTPS)/secure sockets layer (SSL).
The cloud agent <b>32</b>, <b>34</b> is configured by a site-specific manifest <b>42</b>, <b>44</b>. The manifest <b>42</b>, <b>44</b> can include a plurality of files and is typically in extensible markup language (XML). The manifest <b>42</b>, <b>44</b> can identify the frequencies with which data should be collected from the respective industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>. Typically, the frequencies are specific to the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> and/or types of data (e.g., alarms, faults, warnings, status parameters, configurable parameters, historical data, live data, etc.). Even more, the manifest <b>42</b>, <b>44</b> can identify how the data transmitted to the cloud platform <b>40</b> is processed by the cloud platform <b>40</b>. Also, the manifest <b>42</b>, <b>44</b> can specify the priority with which data is processed by the cloud platform <b>40</b>.
Further, the manifest <b>42</b>, <b>44</b> identifies which of the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> to collect live data and/or historical data for, and what data to collect from the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>. The data to collect is suitably specified for each industrial device <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> or individual type of device by identifying one or more parameters in the memories of industrial devices and/or by identifying alarms, faults and/or warnings to collect from the memories of industrial devices. For example, the manifest <b>42</b>, <b>44</b> can indicate the ready bit (see <figref idref="DRAWINGS">FIG. 3</figref>) is to be monitored for an industrial device. As another example, the manifest can indicate the five most recent alarms in an alarm queue of an industrial device are to be collected. <figref idref="DRAWINGS">FIG. 4</figref> illustrates part of an example manifest listing POWERFLEX 7000 drives to monitor. <figref idref="DRAWINGS">FIG. 5</figref> illustrates part of an example manifest listing parameters to monitor for POWERFLEX 7000 drives.
Moreover, the manifest <b>42</b>, <b>44</b> can identify the priorities and/or upload rates of the different types of data transmitted to the cloud platform <b>40</b>. For instance, historical data may be transmitted to the cloud platform <b>40</b> for off-site monitoring at a low priority and a low rate, whereas other data can be transmitted at a higher priority and a higher rate. The manifest <b>42</b>, <b>44</b> can also specify that certain data is characterized as “live data”, which may be used by an off-site monitoring facility for process monitoring or other monitoring purposes. In such a case, the manifest <b>42</b>, <b>44</b> may define such “live data” as being of high priority (e.g., lower priority than alarm data, but higher priority than historical data), and may specify a corresponding high upload rate for such “live data”.
The cloud agent <b>32</b>, <b>34</b> is dynamically configurable to allow changes to be made to the respective manifest <b>42</b>, <b>44</b> during runtime. For example, the number and type of monitored devices can be changed at any time. As another example, the cloud agent <b>32</b>, <b>34</b> allows the priority and upload rate settings for a given type of data to be dynamically set. This, in turn, allows a remote monitor to adjust the upload rate and/or priority for a given device, for example, to facilitate troubleshooting from a remote location. Such adjustments, moreover, may be advantageous in process monitoring applications, for instance, in which a remote user desires higher granularity data with respect to a controlled process at the customer site, and can employ dynamic adjustments to the rate and/or priority settings of the manifest <b>42</b>, <b>44</b> to adjust the speed of data monitoring.
Further, the cloud agent <b>32</b>, <b>34</b> can include multi-threading capabilities to facilitate scalability and to prevent failed industrial devices from blocking data collection from other industrial devices. Upon detecting a failed industrial device, the cloud agent <b>32</b>, <b>34</b> can also generate an alarm to the cloud platform <b>40</b> indicative of the failure.
In some embodiments, the cloud agent <b>32</b>, <b>34</b> includes a collection service and a queue processing service. The collection service stores the collected data (e.g., to a working directory), typically in a compressed state. A priority indicating the priority by which the cloud platform processes the data can also be added according to the manifest <b>42</b>, <b>44</b>. The queue processing service then creates a data packet from the stored data and uploads the data packet to a temporary storage in the cloud platform <b>40</b>. The order with which the data packet is uploaded relative to other data packets can be controlled by a priority of the data packet.
Further, in some embodiments, the cloud agent is configured by the manifest <b>42</b>, <b>44</b> to, for each industrial device <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>, read the list of parameters that have been configured for the device and upload data to the cloud platform <b>40</b>. Further, if there is a fault queue and/or a warning queue, the cloud agent <b>32</b>, <b>34</b>, for each industrial device <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b>, reads the status to determine if there is a fault and/or a warning. If there is a fault, the most recent fault is read from the fault queue and uploaded to the cloud platform <b>40</b>. Similarly, if there is a warning, the most recent warning is read from the warning queue and uploaded to the cloud platform <b>40</b>.
The cloud platform <b>40</b> can be any infrastructure that allows computing services <b>46</b> to be accessed and utilized by cloud-capable devices. For example, the cloud platform <b>40</b> can be MICROSOFT's AZURE cloud platform. The cloud platform <b>40</b> can be a public cloud accessible via the Internet by devices having Internet connectivity and appropriate authorizations to utilize the services. In some scenarios, the cloud platform <b>40</b> can be provided by a cloud provider as a platform-as-a-service (PaaS), and the services <b>46</b> can reside and execute on the cloud platform <b>40</b> as a cloud-based service. In some such configurations, access to the cloud platform <b>40</b> and the services <b>46</b> can be provided to customers as a subscription service by an owner of the services. For example, the services can be provided using a software-as-a-service (SaaS) service model. Alternatively, the cloud platform <b>40</b> can be a private cloud operated internally by an industrial enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud services <b>46</b> and residing on a corporate network protected by a firewall.
The cloud services <b>46</b> can include one or more of data storage, data analysis, control applications (e.g., applications that can generate and deliver control instructions to industrial devices based on analysis of real-time system data or other factors), visualization applications (e.g., a cloud-based operator interface system), reporting applications, enterprise resource planning (ERP) applications, notification services, and other such applications. In some embodiments, the cloud services <b>46</b> include a diagnostic service monitoring the health of respective automation systems or their associated industrial devices across an entire industrial facility, or across multiple industrial facilities that make up an industrial enterprise. Further, in some embodiments, the cloud services <b>46</b> include a control application 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.). Even more, in some embodiments, the cloud services <b>46</b> include an application monitoring for the unavailability of an industrial facility (e.g., due to a power outage) and generating an alert or notification (e.g., an email notification) in response to such an event.
The industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> suitably interact with the cloud services <b>46</b> through the cloud agent <b>32</b>, <b>34</b>. Advantageously, this allows the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> to be used with the cloud platform <b>40</b> without modification. However, direct interaction between the cloud services <b>46</b> and at least some of the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> is also contemplated. For example, industrial devices having smart configuration capability can be configured to automatically detect and communicate with the cloud platform <b>40</b> upon installation at any facility, simplifying integration with existing cloud-based data storage, analysis, or reporting applications used by the industrial enterprise.
Upon receiving data from the cloud agent <b>32</b>, <b>34</b>, the cloud platform <b>40</b> processes the data using the cloud services <b>46</b>. This can include adding the data in temporary storage for subsequent processing. The order with which the data packet is subsequently processed can be governed by a priority accompanying the data. The processing typically includes: 1) analyzing the data and storing the results of the analysis in permanent storage; and/or 2) storing the data in permanent storage. The results and/or the data can, in turn, be used to generate notifications (e.g., email notifications of potential problems with industrial devices) to users of the cloud platform <b>40</b>, reports, and/or visualizations. Reports, visualizations, and other service outputs are typically stored in permanent storage.
Once the cloud platform <b>40</b> has processed received data, the received data and/or data derived from the received data are made available to one or more clients <b>48</b> of the cloud platform <b>40</b> for viewing. The clients <b>48</b> can also be employed to remotely update the manifest <b>42</b>, <b>44</b> of an industrial facility. For example, a client can initiate selective adjustment to a manifest to change upload speeds, priorities or add monitored devices. The clients <b>48</b> can include web clients communicating with the cloud platform <b>40</b> using, for example, hypertext transfer protocol (HTTP) or HTTPS. The clients <b>48</b> can also include clients using specialized software to communicate with the cloud platform <b>40</b>. Advantageously, the clients <b>48</b> allow remote monitoring of the industrial devices <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> without being on-site. Further, problems can advantageously be more easily diagnosed by those with the requisite skill to do so.
In some embodiments, the clients <b>16</b>, <b>18</b>, <b>20</b>, <b>22</b>, <b>24</b>, <b>26</b> include a monitoring center. The monitoring center can be managed by an industrial enterprise to monitor its industrial facilities. Alternatively, the monitoring center can be managed by a third party to monitor the industrial facilities of one or more industrial enterprises. In this case, the third party can charge the industrial enterprises a fee for the monitoring.
Providing industrial devices with cloud capability can offer a number of advantages particular to industrial automation. The cloud platform <b>40</b> can be easily scaled to accommodate differing amounts of data storage and processing. Further, the cloud platform <b>40</b> can be easily extended to increase functionality. For example, the cloud platform <b>40</b> can be extended to provide a motor control center (MCC).
The cloud platform <b>40</b> also provides a cost effective solution for industrial enterprises to monitor industrial devices. Industrial enterprises do not have to maintain a data center infrastructure or patch software running in the data center infrastructure. Further, the cloud platform <b>40</b> does away with high upfront costs and defers costs over a period of time when using a PaaS or SaaS service model. Even more, monitoring and diagnosis are also improved since on-site visits by those with requisite skill to identify future issues and/or diagnosis issues are not required. Moreover, multiple industrial facilities 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.
With reference to <figref idref="DRAWINGS">FIG. 6</figref>, a detailed embodiment of the cloud-based remote monitoring system <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref> is provided. This embodiment leverages the cloud platform <b>40</b> to provide remote monitoring services to an industrial enterprise (i.e., a customer) using, for example, a SaaS service model.
As illustrated, a plant facility <b>50</b> includes an on-premise data historian <b>52</b> collecting live and/or historical data from industrial devices (e.g., data <b>54</b> generated by one or more industrial controllers) at the plant facility <b>50</b>. For example, the data historian <b>52</b> monitors one or more parameters in parameters archives <b>56</b> received from the industrial devices and stores data in local storage <b>58</b> associated with the data historian <b>52</b> (e.g., a structured query language (SQL) server database). This can include both historical data (e.g., alarm history, warning history, fault history, status history, trend data, etc.), as well as live data values read from the industrial devices.
An on-premise cloud agent <b>60</b> at the plant facility <b>50</b> is configured to collect live and/or historical data from the industrial devices, either directly (e.g., from one or more variable frequency drives <b>62</b>) or indirectly (e.g., by accessing the data historian <b>52</b>). The process of collecting the data involves intelligent sorting and organizing based on time of occurrence and user-defined priorities. The cloud agent <b>60</b> can be, for example, a Windows service that periodically collects and transmits serialized and compressed data to the cloud platform using standard web services over HTTPS/SSL. As illustrated, the data historian <b>52</b> is a data source for the cloud agent <b>60</b>. The use of a data historian is advantageous when there are a large number of data points to monitor. However, the cloud agent <b>60</b> can additionally or alternatively collect data directly from the industrial devices (e.g., through a OP link), as illustrated with respect to the variable frequency drives <b>62</b>, or through middleware applications (e.g., open productivity and connectivity (OPC) clients).
With reference to <figref idref="DRAWINGS">FIG. 7</figref>, a more detailed illustration of the cloud agent <b>60</b> is provided. The cloud agent <b>60</b> includes a collection service <b>64</b> that collects data directly from the industrial devices (e.g., the variable frequency drives <b>62</b>), and/or indirectly from the industrial devices (e.g., by way of the data historian <b>52</b>), via a CIP link or other suitable communication protocol. The collection service <b>64</b> is controlled by a site-specific manifest, which can specify one or more of what data to be collected, how often to collect the data, how to retrieve data from the industrial devices, and so on. For example, the manifest can specify that the following should be collected for a specific type of motor drive: motor speed; motor power; motor voltage; motor current; drive status; last warning; and last fault. The collection service <b>64</b> stores the collected data in a data file <b>66</b>, typically a compressed data file. In addition, reference to the stored data file <b>66</b> is added to a queue <b>68</b> (e.g., a MICROSOFT Message Queue Server (MSMQ) database). The queue <b>68</b> can be prioritized based on priorities specified in the manifest. These priorities can be specific to different parameters, different types of data, different industrial devices, different types of industrial devices, etc.
A queue processing service <b>70</b> of the cloud agent <b>60</b> reads the data file <b>66</b> in the order it appears in the queue <b>68</b>. Based on the manifest, the queue processing service <b>70</b> packages the data file <b>66</b> into a data packet <b>72</b> and pushes the data packet <b>72</b> to the cloud platform <b>40</b>. The data packet <b>72</b> includes a header which can include customer-specific data read from the manifest. This customer-specific data can include, for example, a behavioral assembly ID and/or priority for processing the data of the data packet. As discussed hereafter, behavior assemblies implement customer-site capabilities to process monitored data and are typically specific to different types of data. Alternatively, instead of including the customer-specific data wholly within the header, this customer-specific data can at least partially be included in an event data notification, which is generated and pushed to the cloud platform <b>40</b> concurrently with the data packet <b>72</b> and in accordance with the manifest. The queue processing service <b>70</b> can also encrypt and send storage account keys to the cloud platform <b>40</b> for user verification.
An exemplary data packet is illustrated in <figref idref="DRAWINGS">FIG. 8</figref>. In addition to a data file, the data packet includes a header, which includes one or more of a unique customer identifier (ID), a site ID representing a particular industrial facility, a virtual support engineer ID, a data priority for the data in the data file, a message type, and a process ID. Packaging the data in this way allows data from diverse data sources to be packaged together using a uniform, generic data packaging schema so that the data can be moved to the cloud infrastructure.
The manifest can include one or more of subscription information for the cloud platform <b>40</b>, how to push data to the cloud platform <b>40</b>, firewall settings that allow the cloud agent <b>60</b> to communicate with the cloud platform <b>40</b>, and so on. The manifest may can also include associations between data and behavioral assemblies, thus allowing easy scaling to add more customized associations, and dynamic reconfiguration of associations for cloud-side parsing of received data packets.
A configuration interface of the cloud agent <b>60</b> allows modifications to be made to the manifest of the cloud agent <b>60</b>. For example, users can assign priorities to respective data parameters or parameter groups at the customer site. Accordingly, when the queue processing service <b>70</b> packages the collected data to be moved to the cloud platform <b>40</b>, the collected data items can be packaged into data packets according to priority (as defined in the manifest), and the respective data packet headers, or respective event data notification packets, can be populated with the appropriate priority level.
Advantageously, if access to the cloud platform <b>40</b> is disconnected, data will continue to be collected by the collection service <b>64</b> and stored locally at local storage associated with the collections service <b>64</b>. When communication to the cloud platform <b>40</b> is restored, the stored data is forwarded to the cloud platform <b>40</b>. Hence, data is not lost due to a lapse in connectivity with the cloud platform <b>40</b>.
Returning back to <figref idref="DRAWINGS">FIG. 6</figref>, upon receiving a data packet <b>72</b>, data in the received data packet <b>72</b> is intelligently stored in temporary storage <b>74</b> (e.g., in cloud blob storage). The infrastructure can use cloud agent reasoning and collective bargaining to determine a data storage locale. Further, based on the corresponding customer-specific data, a record linking to the stored data is created in a selected one of one or more message queues <b>76</b> of the cloud platform. The record suitably includes at least some of the customer-specific data, and the selected queue can be prioritized using a priority of the customer-specific data. The customer-specific data can be received as part of the data packet, a corresponding event data notification, or a combination of the two. Further, the customer-specific data can include or be accompanied by a selection of the one of the message queues <b>76</b>. The message queues define how the data is processed in the cloud platform <b>40</b>. In the present example, separate queues have been defined for alarms <b>78</b>, live data <b>80</b>, historical data <b>82</b>, and motor drive data <b>84</b>. The historical data queue <b>82</b> relates to time-series records accessed through, for example, an SQL application programming interface (API). The live data queue <b>80</b> relates to substantially real-time monitored data, such as current temperatures, current pressures, etc. The live data values can also be accessed through SQL API. The motor drives queue <b>84</b> is specific to motor drive data accessed through a DPI protocol to the respective drives. The motor drive data can relate to alarming and uploading of drive parameter data via a connector that uses the DPI protocol via, for example, a .NET class provided by the drives group.
The alarms queue <b>78</b> relates to abnormal situations, where the alarm data can also be accessed through SQL API. This alarms queue <b>78</b> can comprise multiple queues associated with different priorities to allow for different alarms having different levels of criticality. In some embodiments, servers, controllers, switches, etc., can be monitored using a number of protocols, and at a certain point (e.g., at the end of a monitoring cycle) alarms are queued up and the cloud agent <b>60</b> sends the alarms to the cloud platform <b>40</b>. Alarms can be reactive (e.g., alarm when a motor fails, when a central processing unit (CPU) crashes, when an interlock is tripped, etc.) or proactive (e.g., track consumables on a machine and alarm when time to reorder, monitor cycle counts on a machine and determine when to schedule preventative maintenance, alarm when temperatures go out of defined bandwidths, send notification when a computer's memory is 80% full, etc.).
Through a configuration interface provided by the cloud agent <b>60</b>, users at the plant facility <b>50</b> can dynamically configure these message queues <b>76</b>. Namely, the cloud agent <b>60</b> allows the user to define these queues <b>76</b> from the on-site location and to define how data in each queue is handled. For example, the user can define, for each queue, an upload frequency to the queue, a priority level (e.g., which data queues should take processing priority over other data queues), which cloud partitions or databases data from the respective queues should be placed in, and other such information. The configuration of the message queues <b>76</b> is suitably stored in the manifest and provided to the cloud platform <b>40</b>, for example, upon initialization.
In an exemplary scenario, the live data queue <b>80</b> may be defined to process live data values that are to be used by a remote operator interface application to view substantially real-time data from the plant facility <b>50</b>, while the historical data queue <b>82</b> may be used to process historical data for archival storage in a historical database <b>86</b> in cloud storage <b>88</b>. Accordingly, the live data queue <b>80</b> may be assigned a higher priority relative to the historical data queue <b>82</b>, since data in the live data queue <b>80</b> is more time-critical than data in the historical queue <b>82</b>.
On the output of the message queues <b>76</b>, a worker role <b>90</b> processes data referenced in the respective queues <b>76</b> according to predefined processing definitions and according to the priorities of the data. The worker role <b>90</b> determines how data is to be processed and stored based on a manifest <b>92</b>, typically a client-specific manifest, stored in the cloud storage <b>88</b>. The manifest <b>92</b> references behavior assemblies <b>94</b> (e.g., a dynamic-link library (DLL)) stored in the cloud storage <b>88</b>. The behavior assemblies <b>94</b> implement customer-site capabilities to process monitored data. The behavior assemblies <b>94</b> can be dynamically uploaded by a user at the plant facility <b>50</b> through the cloud agent <b>60</b>, which facilitates dynamic extension of the cloud platform <b>40</b>. Additional roles can be dynamically added as needed.
For example, if new data points are to be added to the cloud-based remote monitoring system <b>10</b> that require creation of a new message queue, the user can interact with the cloud agent <b>60</b> to configure a new behavior assembly for the new queue that defines such aspects as a processing priority for the data, an upload frequency for the data, where the data is to be stored within cloud storage, and other such information. The cloud agent <b>60</b> can then upload the new behavior assembly together with the data (or independently of the data). The new behavior assembly is then added to the customer's manifest <b>92</b> with the other behavior assemblies defined for the customer, so that the worker role <b>90</b> can leverage the new behavior assembly to determine how data in the new queue is to be processed. This new behavior assembly need only be uploaded to the cloud platform once.
Thereafter, data placed in the new message queue of the message queues will be processed by the worker role according to the new behavior assembly stored in the customer's manifest <b>92</b>. For example, the manifest <b>92</b> may define where the data is to be stored within the cloud storage <b>94</b> (e.g., in the historical database <b>86</b> or in an alarms and live data database <b>96</b>), and whether processing of the new data queue is to take priority over other data queues. In some embodiments, the manifest <b>92</b> may only accept a new behavior assembly if the behavior assembly is accompanied by a unique key associated with the client.
Once the cloud platform <b>40</b> has processed and stored the data provided by the cloud agent <b>60</b> according to the techniques described above, the data can be made accessible to one or more clients <b>98</b> for viewing. For example, data analysis on the cloud platform <b>40</b> can provide a set of web-based and browser enabled technologies for retrieving, directing, and uncompressing the data from the cloud platform to web clients. To this end, reporting services <b>100</b> can deliver data in the cloud storage <b>88</b> (e.g., from the alarm and live data database <b>96</b> or the historical database <b>86</b>) to the clients <b>98</b> in a defined format. For example, the reporting services <b>100</b> can leverage monitored data stored in the cloud storage <b>88</b> to provide remote operator interfaces to the clients <b>98</b> over the Internet.
<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example status webpage for a motor drive that can be viewed by a web client of the cloud platform <b>40</b>. <figref idref="DRAWINGS">FIG. 10</figref> illustrates an example historical alarms webpage for a motor drive that can be viewed by a web client of the cloud platform <b>40</b>. <figref idref="DRAWINGS">FIG. 11</figref> illustrates an example motor speed webpage for a motor drive that can be viewed by a web client of the cloud platform <b>40</b>.
Using the cloud agent <b>60</b> described above, users can organize the cloud computing infrastructure at the plant facility <b>50</b> through the cloud agent <b>60</b> without the need to redevelop, recompile, test, and re-upload services. The cloud agent <b>60</b> provides a mechanism to integrate industrial devices with the cloud platform <b>40</b>, where data from the industrial devices can be leveraged by the cloud services <b>46</b>. By offering users the ability to create and upload behavior assemblies for respective data types, the cloud agent <b>60</b> can facilitate dynamic allocation of cloud computing data storage and computing resources for plant data.
Embodiments, systems, and components described herein (e.g., the industrial devices, the cloud platform, the data collection system, etc.) can include, and/or be embodied by, computer or network components (e.g., servers, clients, programmable logic controllers (PLCs), 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 (i.e., electronic integrated circuits that perform logic operations employing electric signals) configured to execute instructions stored in media (e.g., random access memory (RAM), read only memory (ROM), hard drives, etc.), as well as removable memory devices (e.g., memory sticks, memory cards, flash drives, external hard drives, etc.).
Similarly, the term PLC as used herein can include functionality that can be shared across multiple components, systems, and/or networks. As an example, one or more PLCs can communicate and cooperate with various network devices across the network. This can include substantially any type of controller, communications module, computer, 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 can also communicate to and control various other devices (e.g., I/O devices, including analog, digital, and/or programmed/intelligent I/O devices, other programmable controllers, communications modules, sensors, actuators, output devices, and the like).
The network can include public networks (e.g., the Internet), intranets, and automation networks (e.g., OP networks, including DeviceNet, ControlNet, and Ethernet/IP). Other networks include Ethernet, Data Highway (DH), Data Highway Plus (DH+), Remote I/O, Fieldbus, Modbus, Profibus, controller area network (CAN), wireless networks, serial protocols, and so forth. In addition, the network devices can include various possibilities of hardware and/or software components. These include components such as switches with virtual local area network (VLAN) capability, local area networks (LANs), wide area networks (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, <figref idref="DRAWINGS">FIGS. 11 and 12</figref>, as well as the following discussion, 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 <figref idref="DRAWINGS">FIG. 11</figref>, an example operating environment <b>200</b> for implementing various aspects of the aforementioned subject matter includes a computer <b>202</b>. The computer <b>202</b> includes a processing unit <b>204</b>, a system memory <b>206</b>, and a system bus <b>208</b>. The system bus <b>208</b> couples system components including, but not limited to, the system memory <b>206</b> to the processing unit <b>204</b>. The processing unit <b>204</b> can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit <b>204</b>.
The system bus <b>208</b> can be any of several types of bus structure(s) including a 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 <b>206</b> includes volatile memory <b>210</b> and nonvolatile memory <b>212</b>. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer <b>202</b> (e.g., during start-up), is stored in the nonvolatile memory <b>212</b>. By way of illustration, and not limitation, the nonvolatile memory <b>212</b> can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. The volatile memory <b>210</b> 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).
The computer <b>202</b> also includes removable/non-removable, volatile/nonvolatile computer storage media. <figref idref="DRAWINGS">FIG. 11</figref> illustrates, for example, disk storage <b>214</b>. The disk storage <b>214</b> can include a magnetic disk drive, a floppy disk drive, a tape drive, a Jaz drive, a Zip drive, a LS-100 drive, a flash memory card, a memory stick, or a like device. In addition, the disk storage <b>214</b> can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive (e.g., a compact disk (CD) ROM (CD-ROM) drive, a CD recordable (CD-R) drive, a CD rewritable (CD-RW) drive or a digital versatile disk ROM (DVD-ROM) drive). To facilitate connection of the disk storage <b>214</b> to the system bus <b>208</b>, a removable or non-removable interface is typically used (e.g., an interface <b>216</b>).
It is to be appreciated that <figref idref="DRAWINGS">FIG. 11</figref> describes software that acts as an intermediary between users and the basic computer resources described in the operating environment <b>200</b>. Such software includes an operating system <b>218</b>, which can be stored on the disk storage <b>214</b>, acts to control and allocate resources of the computer <b>202</b>. System applications <b>220</b> (e.g., the cloud agent, in some embodiments) take advantage of the management of resources by the operating system <b>218</b> through program modules <b>222</b> and program data <b>224</b> stored either in the system memory <b>206</b> or on the disk storage <b>214</b>. 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 <b>202</b> through one or more input devices <b>226</b>. The input devices <b>226</b> 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, television (TV) tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit <b>204</b> through the system bus <b>208</b> via one or more interface ports <b>228</b>. The interface ports <b>228</b> include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). One or more output devices <b>230</b> use some of the same type of ports as the input devices <b>226</b>. Thus, for example, a USB port may be used to provide input to the computer <b>202</b> and to output information from the computer <b>202</b> to an output device <b>230</b>. Output adapters <b>232</b> are provided to illustrate that there are some output devices (e.g., monitors, speakers, and printers) which require special adapters. The output adapters <b>232</b> include, by way of illustration and not limitation, video and sound cards that provide a means of connection between these output devices and the system bus <b>208</b>. It should be noted that other devices and/or systems of devices provide both input and output capabilities (e.g., one or more remote computers <b>234</b>).
The computer <b>202</b> can operate in a networked environment using logical connections to the remote computers <b>234</b>. The remote computers <b>234</b> can include one or more of a personal computer (PC), 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 the computer. For purposes of brevity, only a memory storage device <b>236</b> is illustrated with the remote computers <b>234</b>. The remote computers <b>234</b> are logically connected to the computer <b>202</b> through a network interface <b>238</b> and then physically connected via one or more communication connections <b>240</b>. The network interface <b>238</b> encompasses communication networks (e.g., LANs and WANs). 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).
The communication connections <b>240</b> refer to the hardware and/or software employed to connect the network interface <b>238</b> to the system bus <b>208</b>. While the communication connections <b>240</b> are shown for illustrative clarity inside the computer <b>202</b>, the communication connections <b>240</b> can also be external to the computer <b>202</b>. The hardware and/or software necessary for connection to the network interface <b>238</b> includes, for exemplary purposes only, internal and external technologies (e.g., modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards).
<figref idref="DRAWINGS">FIG. 12</figref> is a schematic block diagram of an example computing environment <b>250</b> with which the disclosed subject matter can interact. The computing environment <b>250</b> includes one or more clients <b>252</b>. The clients <b>252</b> can be hardware and/or software (e.g., threads, processes, computing devices, etc.). The computing environment <b>250</b> also includes one or more servers <b>254</b>. The servers <b>254</b> can also be hardware and/or software (e.g., threads, processes, computing devices, etc.). The servers <b>254</b> can house threads to perform transformations by employing one or more embodiments as described herein, for example. One possible communication between a client and a server can be in the form of a data packet adapted to be transmitted between two or more computer processes. The computing environment <b>250</b> includes a communication framework <b>256</b> that can be employed to facilitate communications between the clients <b>252</b> and the servers <b>254</b>. The clients <b>252</b> are operably connected to one or more client data stores <b>258</b> that can be employed to store information local to the clients <b>252</b>. Similarly, the servers <b>254</b> are operably connected to one or more server data stores <b>260</b> that can be employed to store information local to the servers <b>254</b>.
What has been described above includes examples of the subject innovation. It is 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 . . . ).
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 removable 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.
In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
Contents5
14 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14
Every citation, both waysCites: the store holds 37 of 38
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US11533589B2 | Cited by | United States of America | Applicant |
| US11312392B2 | Cited by | United States of America | Search report |
| EP1672535A1 | Cites | European Patent Office (EPO) | Applicant |
| US2005108453A1 | Cites | United States of America | Applicant |
| US2008081579A1 | Cites | United States of America | Applicant |
| US2008125877A1 | Cites | United States of America | Applicant |
| US2008140356A1 | Cites | United States of America | Applicant |
| US2008291918A1 | Cites | United States of America | Applicant |
| US2009017145A1 | Cites | United States of America | Applicant |
| US2009210071A1 | Cites | United States of America | Applicant |
| US2010211928A1 | Cites | United States of America | Applicant |
| US2010256795A1 | Cites | United States of America | Applicant |
| US2010278086A1 | Cites | United States of America | Applicant |
| US2010333116A1 | Cites | United States of America | Applicant |
| US2012320928A1 | Cites | United States of America | Applicant |
| US2013211546A1 | Cites | United States of America | Applicant |
| US2013211559A1 | Cites | United States of America | Applicant |
| US2013268357A1 | Cites | United States of America | Applicant |
| US2014026179A1 | Cites | United States of America | Search report |
| CN202267864U | Cites | China | Applicant |
| US7463935B1 | Cites | United States of America | Applicant |
| US8819701B2 | Cites | United States of America | Search report |
| US20050108453A1 | Cites | United States of America | Applicant |
| US20080081579A1 | Cites | United States of America | Applicant |
| US20080125877A1 | Cites | United States of America | Applicant |
| US20080140356A1 | Cites | United States of America | Applicant |
| US20080291918A1 | Cites | United States of America | Applicant |
| US20090017145A1 | Cites | United States of America | Applicant |
| US20090210071A1 | Cites | United States of America | Applicant |
| US20100211928A1 | Cites | United States of America | Applicant |
| US20100256795A1 | Cites | United States of America | Applicant |
| US20100278086A1 | Cites | United States of America | Applicant |
| US20100333116A1 | Cites | United States of America | Applicant |
| US20120320928A1 | Cites | United States of America | Applicant |
| US20130211546A1 | Cites | United States of America | Applicant |
| US20130211559A1 | Cites | United States of America | Applicant |
| US20130268357A1 | Cites | United States of America | Applicant |
| US20140026179A1 | Cites | United States of America | Search report |
| CN202267864 | Cites | China | Applicant |
12 members in 4 offices
Priority claims8
| Document | Office | Kind | Date |
|---|---|---|---|
| 201261721859 | United States of America | P | |
| 201313798430 | United States of America | A | |
| 201715478761 | United States of America | A | |
| 13798430 | – | – | – |
| 61721859 | – | – | – |
| US201261721859P | – | – | – |
| US201313798430 | – | – | – |
| US201715478761 | – | – | – |
Members12
| Document | Office | Kind | |
|---|---|---|---|
| EP2728428A1 | European Patent Office (EPO) | A1 | |
| US2014129688A1 | United States of America | A1 | |
| CN103957228A | China | A | |
| BR102013028304A2 | Brazil | A2 | |
| US9647906B2 | United States of America | B2 | |
| CN103957228B | China | B | |
| US2017214575A1 | United States of America | A1 | |
| US9929905B2This record | United States of America | B2 | |
| US2018205606A1 | United States of America | A1 | |
| EP2728428B1 | European Patent Office (EPO) | B1 | |
| US10250438B2 | United States of America | B2 | |
| BR102013028304B1 | Brazil | B1 |
44 transactions on the USPTO file
Allowed without a rejection on record.
- Non-final rejections
- 0
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Post Issue Communication - Certificate of CorrectionN423 | N423 | |
| Post Issue Communication - Certificate of CorrectionN423 | N423 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Email NotificationEML_NTR | EML_NTR | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Email NotificationEML_NTR | EML_NTR | |
| Application Is Now CompleteCOMP | COMP | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Sent to Classification ContractorPGPC | PGPC | |
| FITF set to NO - revise initial settingFTFI | FTFI | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Additional Application Filing FeesADDFLFEE | ADDFLFEE | |
| Applicant has submitted new drawings to correct Corrected Papers problemsCORRDRW | CORRDRW | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Email NotificationEML_NTR | EML_NTR | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| Corrected PaperCPAP | CPAP | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Cleared by OIPE CSRL194 | L194 | |
| Preliminary AmendmentA.PE | A.PE | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| PTO/SB/69-Authorize EPO Access to Search ResultsSREXR141 | SREXR141 | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Entity status set to undiscounted (initial default setting or status change)BIG. | BIG. | |
| Initial Exam Team nnIEXX | IEXX |
4 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Certificate of correctionCC | CC | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 09929905
- Publication, DOCDB
- 9929905
- Publication, EPODOC
- US9929905
- Application
- 15478761
- Application, DOCDB
- 201715478761
- Application, EPODOC
- US201715478761
Titles
- English
- Cloud based drive monitoring solution
Classification
- CPC, 13
- H04L41/0813
- G05B19/048
- H04L41/046
- G05B23/0297
- H04L43/04
- G05B2223/06
- H04L43/0817
- G06F16/21
- G05B19/4185
- G05B2219/31151
- G06F17/30289
- Y02P90/80
- G05B2219/13
- IPC, 5
- G06F15 173
- H04L12 24
- H04L12 26
- G06F17 30
- G05B19 418
- USPC, 2
- 719314000
- 001001000