Patent Application
20180211176
The present invention is directed to methods and systems for performance monitoring and failure prediction. In particular, the present invention is directed to methods and systems for detecting and predicting Internet of Things device anomalous behavior or failure when a history of performance of the device may not be available.
The Internet of Things (IoT) is a global network of connected physical and virtual objects that enables these objects to collect and exchange information and control each other. With the changing scope of applications of the internet shifting towards making the physical world smarter there is no doubt that a shift is occurring in the number of connected devices. Within 5 years it is estimated that 50 billion devices will be online. PCs, laptops and smart devices which dominate the internet at present will be dwarfed in number by these physical objects. The prerequisites of Internet of Things are many, although the main components can be categorized into three categories i.e. intelligence, sensing and communication.
Broadband Internet is become more widely available, the cost of connecting is decreasing, more devices are being created with Wi-Fi capabilities and sensors built into them, technology costs are going down, and smartphone penetration is skyrocketing. All of these things are creating a “perfect storm” for the IoT. The Internet of Things refers to the connectivity and inter-connectivity of devices, objects, people and places. Many of these new “things” which never used to have any intelligence, now communicate via a network using a variety of protocols (I-P, RFID, NFC, ZigBee, etc.). In some instances these “things” also communicate with applications, people and one another.
The growth of IoT devices will have important implications for people and businesses. Homes and consumers will acquire more devices that need support. Businesses and those providing managed services/maintenance and tech support will need to have more ways to support their customers. More devices added to networks adds more convenience to daily lives but can also cause many new problems. Also, connected devices have more intelligence than ordinary objects. This means they need support, maintenance and troubleshooting. At the same time, most consumers still have a “this should work” mentality. This means competing for consumer spending on maintenance and support—is difficult, but necessary.
More connected devices bring about greater concerns over security, data and privacy. The network will become central to a business or home's safety and security because more IoT devices will depend on it to do their job. Given the lack of IoT device standards at this point, most devices do not communicate with one another. They are designed to be self contained and separate and therefore each have their own procedure and system for troubleshooting and support.
The present invention is directed to solving disadvantages of the prior art. In accordance with embodiments of the present invention, a method is provided for a device not having an available history of either failures or degraded performance. The method includes establishing, by a computer coupled to the device, an initial baseline of sensor data from the device, receiving new sensor data after establishing the initial baseline, creating an updated baseline based on the new sensor data, evaluating, by the computer, the new sensor data compared to the updated baseline based on a plurality of different time scales, and determining whether the device is indicating an increased probability of failure or degraded performance based on the evaluated sensor data.
In accordance with other embodiments of the present invention, a non-transitory computer readable storage medium is provided. The non-transitory computer readable storage medium is configured to store instructions that when executed cause a processor to perform establishing an initial baseline of sensor data from a device, receiving new sensor data after establishing the initial baseline, creating an updated baseline based on the new sensor data, evaluating, the new sensor data compared to the updated baseline based on a plurality of different time scales, and determining whether the device is indicating an increased probability of failure or degraded performance based on the evaluated sensor data. A history of either device failures or device degraded performance may not be available prior to establishing the initial baseline.
In accordance with still other embodiments of the present invention, a system is provided. The system includes a device, which includes one or more of a sensor configured to provide sensor data, and a server, coupled to the device and not having access to a history of the sensor data. The server is configured to establish an initial baseline of the sensor data, receive new sensor data after establishing the initial baseline, create an updated baseline based on the new sensor data, evaluate the new sensor data compared to the updated baseline based on a plurality of different time scales, and determine whether the device is indicating an increased probability of failure or degraded performance based on the evaluated sensor data.
One advantage of the present invention is that it provides methods for determining a higher likelihood of failure or degraded performance for an Internet of Things device where a history of failures or performance may not be available. An initial baseline of performance is established by monitoring available sensors, updated as new sensor data is received, and processed for anomalies.
Another advantage of the present invention is allows a blended health index to be determined for an IoT device based on one or more groups of sensors. Sensors may be grouped or organized based on the type of data that sensors produce, and each group of sensors may produce a unique result. A blended health index may either be determined from a group of sensors or multiple groups of sensors.
Additional features and advantages of embodiments of the present invention will become more readily apparent from the following description, particularly when taken together with the accompanying drawings. This overview is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. It may be understood that this overview is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Typical IoT devices send sensor data out on a periodic basis and receive control commands and/or other information back. Statistics of different IoT machines and devices suggests that unexpected and abrupt failures are frequent and might represent as much as 50% of all the failures observed even for well-maintained devices with scheduled inspections, part replacement, and maintenance. Unexpected failures and unscheduled maintenance is expensive and, thus, reducing their number is of great importance to the device owners and operators.
IoT sensor data contains various information about different aspects of device operation, including device health. Sensors might measure device on/off status, location, velocity, temperature, and pressure of an engine and different components, etc. Some sensors could be directly measuring how close the device is to failure. Some other sensors are able to measure some critical degradation processes inside the device such as “oil degradation” or “remaining brake pad thickness” or qualitatively measure how well an IoT device is performing its intended job (i.e. performance).
All of the above information could be used to perform an assessment of device's health and there are two general ways of doing that: with the knowledge of the device, its reliability and failure mechanisms, design, and operational requirements, and without that knowledge. The first approach relies on the knowledge of how device works and how it fails. For example, if it is known that exceeding a specific temperature or pressure leads to the device failure, it is possible to monitor IoT sensor data from device's temperature or pressure sensors and, if the pre-specified limit is exceeded, report the “failure condition” or alert the owner/operator of the device of the impending failure. The same approach could be implemented in some combination with, for example, mathematical or empirical models of this device when the sensor data is fed into the model which, in turn, makes predictions about device's remaining life or its failure risks. While the above approach could work well in many cases, it requires complete knowledge of how device works and how it fails, which may not be available.
In addition to statistical processes, machine learning processes are useful for IoT device monitoring and evaluation. Machine learning is a sub-field of Artificial Intelligence (AI) and refers to algorithms and software that gets better at its analysis and predictions with experience, e.g. with more time spent on “learning” and with more data having been analyzed. Machine learning has the ability to not only evaluate sensor data, but to discern data patterns and changes in data patterns. Patterns relate to sensor behavior over a period of time. If a pattern repeats with only minor variation it may be interpreted as reflecting normal behavior, while if a pattern repeats with major variation it may be interpreted as reflecting abnormal or anomalous behavior. Machine learning is now being relied upon heavily in Big Data Analytics and, in particular, in analytics for the IoT. Anomaly detection is a process or algorithm by which raw data points are taken in, and reports are made at the timestamps where unusual behavior in the data is observed.
Referring now to
IoT device 104 is an Internet of Things device with at least one network connection. IoT is the inter-networking of physical devices, vehicles (also referred to as “connected devices” and “smart devices”), buildings, and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data. In 2013 the Global Standards Initiative on Internet of Things (IoT-GSI) defined the IoT as “the infrastructure of the information society”. The IoT allows objects to be sensed and/or controlled remotely across existing network infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy and economic benefit in addition to reduced human intervention. When IoT is augmented with sensors and actuators, the technology becomes an instance of a more general class of cyber-physical systems, which also encompasses technologies such as smart grids, smart homes, intelligent transportation and smart cities. Each “thing” is uniquely identifiable through its embedded computing system but is able to interoperate within the existing Internet infrastructure. Experts estimate that the IoT will consist of almost 50 billion objects by 2020.
Typically, IoT is expected to offer advanced connectivity of devices, systems, and services that goes beyond machine-to-machine (M2M) communications and covers a variety of protocols, domains, and applications. The interconnection of these embedded devices (including smart objects), is expected to usher in automation in nearly all fields, while also enabling advanced applications like a smart grid, and expanding to areas such as smart cities. “Things,” in the IoT sense, can refer to a wide variety of devices such as heart monitoring implants, biochip transponders on farm animals, electric clams in coastal waters, automobiles with built-in sensors, DNA analysis devices for environmental/food/pathogen monitoring or field operation devices that assist firefighters in search and rescue operations. These devices collect useful data with the help of various existing technologies and then autonomously flow the data between other devices. Current market examples include home automation (also known as smart home devices) such as the control and automation of lighting, heating (like smart thermostat), ventilation, air conditioning (HVAC) systems, and appliances such as washer/dryers, robotic vacuums, air purifiers, ovens or refrigerators/freezers that use Wi-Fi for remote monitoring.
In addition to whatever core functionality and IoT device 104 has, in most embodiments IoT devices 104 includes one or more sensors 108. Sensors 108 monitor specific functions of IoT device 104 in order to allow an outside device (IoT health evaluation device 112) to make an independent judgment of a level of operability or health of the IoT device 104. IoT devices 104 may have many different sensors 108, each measuring a different aspect of IoT device 104 reliability or performance.
Sensor outputs 120 may be monitored in several different ways. Sensor outputs 120 may produce data on a random basis, semi-regularly, or periodically. Random sensor data may be produced at any time. Semi-regular sensor data may be produced with some regularity (for example once per day), but may not be predictably produced (for example at a random time each day). Periodic sensor data is produced with constant time differences between each data item. Sensor data may be produced as a batch of data from a sensor—so that a single sensor output 120 event may contain multiple data points. In lieu of an IoT device 104 producing sensor data on a random, semi-regular, or periodic basis, an IoT health evaluation device 112 may instead poll one or more sensor outputs 120 randomly or periodically. An IoT device 104 may also stream data to the IoT health evaluation device 112. In some embodiments, an IoT device 104 may be configured to produce sensor data at a frequency, batch, or other timed parameter to the IoT health evaluation device 112.
Sensor outputs 120 are connected to an IoT health evaluation device 112, which is generally a computer or other device able to interface with sensor outputs 120, store sensor output data, evaluate sensor output data, and determine and output sensor health status 116 for each sensor output 120. Sensor health status 116 may be provided to another computer, a user, or transmitted to one or more IoT devices 104 for various purposes. For the embodiment illustrated in
Referring now to
IoT device health evaluation system 200 includes the same components illustrated in
Referring now to
In the illustrated embodiment, IoT device 104 has three Groups 304, identified as group A 304A, group B 304B, and group C 304C. Group A 304A includes sensor 1108A, sensor 2108B, and sensor 3108C. Group B 304B includes sensor 4108D and sensor 5108E. Group C 304C includes sensor 6108F, sensor 7108G, and sensor 8108H. Each group includes at least one sensor 108.
Unlike the embodiments shown in
Referring now to
IoT health evaluation device 112 includes one or more processors 404, which execute computer-readable instructions of the present invention. Processors 404 may include x86 processors, RISC processors, embedded processors, other types of processors, FPGAs, programmable logic, or pure hardware devices.
Processor 404 interfaces with memory 408, which stores metadata 412, applications 416, and/or sensor data 420. Metadata 412 includes data structures and parameters used in the processes of the present invention. Applications 416 includes computer-readable instructions including instructions for processes of the present invention. Sensor data 420 is data from sensor outputs 120. Memory 408 may include any combination of volatile and non-volatile memory.
In some embodiments, IoT health evaluation device 112 interfaces with one or more external databases (not shown) that may provide increased storage for any of metadata 412, applications 416, or sensor data 420. In some embodiments, IoT health evaluation device 112 may utilize stateless processing or in-memory processing and not store older sensor data than the most recently received sensor data. In that case, the IoT health evaluation device 112 will need to maintain running statistics as new data is received as well as other “summary” statistics such as the number of sensor data samples received.
IoT health evaluation device 112 may optionally include one or more timers 436, a keyboard or pointing device 440, and a display 444. Timers 436 may alternatively be present within processors 404 or implemented in software within applications 416. A keyboard or pointing device 440 and display 444 are required if the IoT health evaluation device 112 directly interfaces with a user. Otherwise, they may not be required.
IoT health evaluation device 112 receives sensor outputs 120 through a sensor receiver 432. The sensor receiver 432 may be conditioned to sample sensor outputs 120 at regular intervals or operate in a batch or an event-driven basis. Once sensor outputs 120 have been received, they are stored as sensor data 420 and the memory 408 or in some other database. In some embodiments, sensor data from sensor outputs 120 is received through network transceiver 424 instead.
Finally, the IoT health evaluation device 112 may include one or more network transceivers 424, which connects to a network 428 through network connections 448. Network transceiver 424 is generally the means through which IoT health evaluation device 112 reports sensor health statuses 116 or blended health statuses 204, 308 to another computer or user. However, in some embodiments the sensor health statuses 116 and blended health indexes/statuses 204, 308 are displayed 444 in lieu of transmitting to another computer on the network 428.
Referring now to
The time 508 corresponding to a value of 0 signifies a start of a training phase 512 for each corresponding sensor 108. The training phase 512 includes a minimum of three data values 504 for each sensor 108, and there may not be a specific maximum or predetermined number of data values 504 that must be included in the training phase 512. At least three values 504 must be received during the training phase 512 in order to produce meaningful statistics for IoT device 104 health. In some embodiments, a predetermined time 508 determines the length of the training phase 512, as long as at least three samples or values 504 have been received. In other embodiments, a minimum number of values 504 must be received during the training phase 512. In general, the longer the training phase 512 is and the more values 504 received, the more accurate predictions for the IoT device 104 will be. The goal of the training phase 512 for each sensor 108 is to generate a statistical baseline for what could be considered as “normal” before initiating an operating or operational phase 516.
Once the training phase 512 criteria has been met, sensor data logging for the corresponding sensor 108 transitions to the operating phase 516. Operating phase 516 is the time period during which an IoT health evaluation device 112 generates sensor health statuses 116, blended health status 204, or group health statuses 308. In some embodiments, all sensors 108 for an IoT device 104 transition to operating phase 516 at the same time 508. In other embodiments, different sensors 108 or groups of sensors 304 of an IoT device 104 transition to operating phase 516 at different times 508.
When each sensor value 504 is received at a specific time 508, metadata 412 is stored by IoT health evaluation device 112. Therefore, in some embodiments a table in metadata 412 similar to the table shown in
An example of the result of an anomaly detection algorithm such as may be performed by one or more applications 416 of an IoT health evaluation device 112 is illustrated in
Under some conditions, the IoT health evaluation device 112 may elect to disqualify certain incoming sensor data 504. In some embodiments, disqualify means not storing the incoming data 504. In other embodiments, disqualify means not including the data 504 into either calculating a current baseline 532 or an updated baseline. In yet other embodiments, disqualify means not evaluating the disqualified data 504 against an updated baseline. Data 504 may be disqualified for many reasons, including but not limited to receiving data 504 either too soon or too late after previous data 504 or a data value 504 known to be an out of range value for a corresponding sensor 108.
Referring now to
As an example of an anomaly detection algorithm we present a basic approach from statistics. In statistics, the so-called three-sigma rule of thumb expresses a conventional heuristic that nearly all values are taken to lie within three standard deviations of the mean, i.e. that it is empirically useful to treat 99.7% probability as near certainty. The usefulness of this heuristic depends significantly on the question under consideration, and there are other conventions, e.g. in the social sciences a result may be considered “significant” if its confidence level is of the order of a two-sigma effect (95%), while in particle physics, there is a convention of a five-sigma effect (99.99994% confidence) being required to qualify as a “discovery”. The three sigma rule of thumb is related to a result also known as the three-sigma rule, which states that even for non-normally distributed variables, at least 88.8% of cases should fall within properly-calculated three-sigma intervals.
In one embodiment, namely, the embodiment recited in the immediately previous paragraph, the IoT health evaluation device 112 calculates a mean value or average 604, a Sigma value 608, a + three Sigma value 612, and a − three Sigma value 616. In the preferred embodiment, the Sigma value 608 represents a 3 Sigma standard deviation, the plus Sigma value 612 represents a +3 Sigma standard deviation, and the minus Sigma value 616 represents a −3 Sigma value 616. However, it should be understood that the Sigma 608, plus Sigma 612, and minus Sigma 616 values may be any values that produce the desired statistical analysis. The plus Sigma 612 calculation establishes an upper bound for the corresponding sensor 108, sensor group 304, or IoT device 104. The minus Sigma 616 calculation establishes a lower bound for the corresponding sensor 108, sensor group 304, or IoT device 104, as well. Data values 504 below the plus Sigma value 612 and above the minus Sigma value 616 are interpreted as being normal or “green” results 620. Data values 504 above the plus Sigma value 612 or below the minus Sigma value 616 are interpreted as being anomalous or “yellow” results. Data values 504 equal to the plus Sigma value 612 or the minus Sigma value 616 may be determined to be either normal/green or anomalous/yellow results, depending on desired interpretation. In the embodiment illustrated in
In addition to statistical anomaly detection techniques including statistical process control (SPC), other analytical techniques may be used to evaluate sensor data for anomalies. For any time scale, other statistical techniques including single variable 3*sigma outliers, use of Mahalanobis metricsdistance, Z-score/weighted Z-score, and other techniques may be used. Model-based approaches (when some sort of assumption about the data is made) include Robust covariance estimation, Subspace-based anomaly detection, Kernel-based density estimation, and other model-based techniques. Unsupervised machine learning approaches may also be used, including K-means-based approaches, dbscan (finds contiguous regions of common density), Isolation forest, One-class support vector machines, and other techniques.
Referring now to
Referring now to
There is value in using multiple time scales to evaluate IoT device 104 health. Abnormal or failure indication from sensor outputs 120 may be related to a usage pattern that is time-related an IoT device 104. For example, an IoT device 104 may be busier at some time of the day or some days of the week more than others. An IoT device 104 may fail more often during midday temperatures (12 PM to 6 PM, for example) when ambient temperatures are likely higher. In one embodiment, an IoT health evaluation device 112 evaluates data instantaneously 804, and if there is an indication of anomalous/yellow 712, 720 behavior another time scale such as the previous hour 808 is used to validate the anomalous/yellow 712, 720 behavior. This is shown in more detail with respect to
Graph B 808 of
Graph D 816 illustrates an exemplary time scale 860 based on days of the week, with no anomalous counts 848 received on Monday, no anomalous counts 848 received on Tuesday, one anomalous count 848 received on Wednesday, no anomalous counts 848 received on Thursday, no anomalous counts 848 received on Friday, and no anomalous counts 848 received on Saturday. Although monitoring for Sundays is not shown in this embodiment, in other embodiments it may be tracked as well as other weekdays. Other embodiments may be based on weekdays or weekends, include holidays, or organize days of the week 816 into other categories. The limit values shown may represent anomalous/yellow values 712, 720 or failure/red values 724.
Group E 820 illustrates an exemplary time scale 864 based on weeks of the year, with 52 weekly periods normally tracked. Group E 820 shows most anomalous counts 848 as being normal/green anomalous counts 712, 720, with one anomalous count 848 above an upper limit 612 and one data value 504 on a lower limit 616. This type of time scale 864 may be more valuable in showing relationships to seasonal or other longer-term trends. The limit values shown may represent anomalous/yellow values 712, 720 or failure/red values 724.
Referring now to
At block 904, IoT devices 104 and available sensors 108 and sensor outputs 120 are uniquely identified. Each IoT device 104 may have multiple sensors 108 and sensor outputs 120. Also, it may not be necessary to include certain sensors 108 and sensor outputs 120 into the evaluation process if it is known that those sensors 108 and sensor outputs 120 have minimal or no contribution to predicted reliability or performance degradation of the IoT device 104. Flow proceeds to block 912.
At Optional block 908, if there is a failure data or failure history available, it is usually determined at this time and incorporated into the processes of the present invention is described herein. However, this is not a requirement for the present invention although it does contribute to the quality of results obtained. For example, knowing failure data or failure history in advance may produce a more accurate prediction of upcoming failure if the data values 504 are approaching the identified failure limits. Flow proceeds to block 912.
At block 912, the type of sensor 108 evaluation performed by the IoT health evaluation device 112 is determined. Sensor outputs 120 may be evaluated individually, blended, or grouped, or in combination as described with reference to
At block 916, the time scales 808-820 to be used for evaluation are identified. Time scales 808-820 may include instantaneous 804, rolling windows 808, daily blocks of time 812, days of the week 816, weeks of the year 820, or any other time scale that may be contemplated. Different collections of time scales 808-820 may be used for different IoT devices 104, different sensor groups 304, or even different sensors 108. Flow proceeds to block 920.
At block 920, the length of the training phase 512 for each sensor 108, group 304, or IoT device 104 is defined. All training phases thus defined 512 each have the least three data values 504 in length, regardless of the length of time 508 it takes to receive the three data values 504. Some training phases 512 may be measured in a minimum number of data values 504 received by the IoT health evaluation device 112, while other training phases 512 may be measured by a minimum length of time 508. Flow ends at block 920.
Referring now to
At block 1004, the IoT health evaluation device 112 receives data 504 from sensors 108 of the IoT device 104. Flow proceeds to block 1008.
At block 1008, the IoT health evaluation device 112 stores the received data. In some embodiments, the received sensor data 420 is stored in a memory 408 of the IoT health evaluation device 112. In other embodiments, the received sensor data 420 is stored in a database part of or external to the IoT health evaluation device 112. In some embodiments, the amount of sensor data 420 able to be stored by the IoT health evaluation device 112 is limited, and in conjunction with storing the received data the oldest stored sensor data 420 is deleted. Flow proceeds to decision block 1012.
At decision block 1012, the IoT health evaluation device 112 determines if a predetermined amount of data 504 has been received. In one embodiment, the predetermined amount of data is three data values 504. In another embodiment, the predetermined amount of data is a number of data values 504 greater than three. In yet another embodiment, the predetermined amount of data is data received in a predetermined amount of time 508. If the predetermined amount of data has not been received, then flow proceeds to block 1004 to wait for new received data. If the predetermined amount of data has been received, then flow instead proceeds to block 1016.
At block 1016, a sufficient amount of data 504 has been received by the IoT health evaluation device 112 to create an initial baseline 532, and the initial baseline of anomaly counts per time scale 532 is created. In one embodiment, historical data for an anomaly detector is created by first determining the mean or average 604 and mean+/−standard deviation of the received data 504, and recording those anomalous events that occur outside of the mean+/−three sigma bounds (e.g. 712 in
At block 1020, the training phase 512 has been completed and the process transitions to the operating phase 516. The operating phase is shown in more detail in
Referring now to
At block 1104, the IoT health evaluation device 112 receives new data 504. Flow proceeds to block 1108.
At block 1108, the IoT health evaluation device 112 stores the received data 504. In some embodiments, the received sensor data 420 is stored in a memory 408 of the IoT health evaluation device 112. In other embodiments, the received sensor data 420 is stored in a database part of or external to the IoT health evaluation device 112. In some embodiments, the amount of sensor data 420 able to be stored by the IoT health evaluation device 112 is limited, and in conjunction with storing the received data 504 the oldest stored sensor data 420 is deleted. Flow proceeds to block 1112.
At block 1112, the relevant time scales 808-820 and time periods 836 for the new data 504 are identified. The new data 504 has an associated time stamp 508 identifying when the IoT health evaluation device 112 received the new data 504. Time scales 808-820 and time periods 836 are selected which include the time stamp 508 of the new data 504. For example, new data 504 having a time stamp 508 of 2 PM on a Thursday on May 23rd would have specific time periods 836 identified for each of time scales 812, 816, and 820. Flow proceeds to decision block 1116.
At decision block 1116, the IoT health evaluation device 112 determines if there are any known failure limits 704, 708 exceeded. Known failure limits 704, 708 are defined by failure data or failure history identified in optional block 908. Failure data or failure history may not be known for the IoT device 104 being monitored, or for some IoT devices 104 and not other IoT devices 104. If any known failure limits 704, 708 have been exceeded then flow proceeds to block 1120. If any known failure limits 704, 708 have not been exceeded, then flow instead proceeds to block 1124.
At block 1120, the current status 116 for the sensor 108 or IoT device 104 being monitored is failure/red 724. Identifying the current status as failure/red 724 alerts personnel that the corresponding sensor 108 or IoT device 104 is producing a sensor output 120 reflecting a known failure condition, and maintenance or replacement should be addressed as soon as possible. Flow proceeds to block 1104 to await new data 504.
At block 1124, known failure limits 704, 708 have not been exceeded, and statistically significant differences in the anomaly counts are evaluated for the time scales 808-820 identified in block 916. Therefore, since failure limits 704, 708 have not been exceeded the health status for the corresponding sensor 108 or IoT device 104 is either normal/green 716 or anomalous/yellow 712, 720. Updated anomaly count 848 limits are determined as the updated baseline. Flow proceeds to block 1128.
At block 1128, anomalies are detected in the raw data 504, using the +/−sigma technique detailed herein and updated in block 1124, or any of the other techniques mentioned previously. In the aforementioned embodiment, the number of raw data points occurring outside the +/−three sigma region 612, 616 from the mean 604 are recorded as anomalies and are used to update the baseline. Flow proceeds to decision block 1132.
At decision block 1132, the IoT health evaluation device 112 determines if there are anomalies found in the raw data 504. If there are anomalies found in the raw data 504 (i.e. anomaly counts 848 either at or above high limit 612 or at or below low limit 616), then flow proceeds to block 1140. If there are not anomalies found in the raw data 504, then flow instead proceeds to block 1136.
At block 1136, anomalies have not been found in the raw data 504, and the current status is normal or Green 716. Flow proceeds to block 1104 to wait for new data 504.
At block 1140, anomalies have been found in the raw data 504, and the IoT health evaluation device 112 evaluates statistically significant differences in anomaly counts for the time scales identified in block 916. The evaluation process for block 1140 is shown in more detail in
Referring now to
At block 1204, the evaluation process selects an initial time scale 808-820 to update. Flow proceeds to block 1208.
At block 1208, the evaluation process compares anomaly counts 848 to the updated baseline for the current time scale and time period 836. Flow proceeds to decision block 1212.
At decision block 1212, the IoT health evaluation device 112 determines whether the anomaly count 848 for the current time period 836 is statistically significant from the historical distribution of anomaly counts 848. In the example illustrated in
If the received data value 504 is the same as or greater than either the +3 Sigma value 612 or the −3 Sigma value 616, this event increments the anomaly count 848, and with a sufficient number of such events may be interpreted as an anomalous/yellow 712, 720 result. If there is not a statistically significant difference in the number of anomalies for the selected time scale 808-820, then flow proceeds to block 1216. If there is a statistically significance in the number of anomalies for the selected time scale 808-820, then flow instead proceeds to decision block 1220.
At block 1216, the IoT health evaluation device 112 identifies the current status as normal/Green 716. Flow proceeds to block 1104 to receive new data 504 and to decision block 1304 to begin determination of a blended health index.
At decision block 1220, the IoT health evaluation device 112 determines if there are more time scales 808-820 to update. If there are more time scales 808-820 to update, then flow proceeds to block 1224. If there are not more time scales 808-820 to update, then flow instead proceeds to block 1228.
At block 1224, the IoT health evaluation device 112 has determined there are more time scales 808-820 to update, and selects a next time scale 808-820. Flow proceeds to block 1208 to compare anomaly counts 848 for the selected time scale 808-820.
At block 1228, the IoT health evaluation device 112 determines the anomaly counts 848 for the various sets of time scales 808-820 are statistically different from observed historical data and status anomalous/Yellow 712, 720 is reported. Flow proceeds to block 1104 to receive new data 504 and to decision block 1304 to begin determination of a blended health index.
Referring now to
At decision block 1304, the IoT health evaluation device 112 determines if all sensors 108 have been evaluated. If all sensors 108 have not been evaluated, then flow proceeds back to decision block 1304 until all sensors 108 have been evaluated. If all sensors 108 have been evaluated, then flow instead proceeds to decision block 1308.
At decision block 1308, the IoT health evaluation device 112 determines if the sensors 108 are in multiple groups 304. If the sensors 108 are in multiple groups 304, then flow proceeds to block 1332. If the sensors 108 are not in multiple groups 304 then either the sensors 108 are being evaluated individually as shown in
At decision block 1312, the IoT health evaluation device 112 determines if any of the sensors 108 have a failed/red status. If any of the sensors 108 have a failed/red status 724, then flow proceeds to block 1316. If none of the sensors 108 have a failed/red status 724, then flow instead proceeds to decision block 1320.
At block 1316, the IoT device 104 status is failed/red 724. Identifying the current status as failed/red 724 alerts personnel that the corresponding sensor 108 and device 104 is producing a sensor output 120 reflecting a known failure condition, and maintenance or replacement should be addressed as soon as possible. Flow ends at block 1316 or proceeds to block 1104 to await new sensor data 504.
At decision block 1320, the IoT health evaluation device 112 determines if any of the sensors 108 or the IoT device 104 has an anomalous/yellow status 712, 720. If any of the sensors 108 or the IoT device 104 has an anomalous/yellow status 712, 720, then flow proceeds to block 1324. If any the sensors 108 do not have an anomalous/yellow status 712, 720, then flow instead proceeds to block 1328.
At block 1324, the IoT device 104 status is anomalous/yellow 712, 724. Flow ends at block 1324 or proceeds to block 1104 to await new sensor data 504.
At block 1328, the IoT device 104 status is normal/green 716. Flow ends at block 1328 or proceeds to block 1104 to await new sensor data 504.
At block 1332, sensors 108 in multiple groups 304 have been identified, and a first group 304 is selected. Flow proceeds to decision block 1336.
At decision block 1336, the IoT health evaluation device 112 determines if any of the sensors 108 in the selected group 304 have a failed/red status 724. If any of the sensors 108 in the selected group 304 have a failed/red status 724, then flow proceeds to block 1340. If none of the sensors 108 in the selected group 304 have a failed/red status 724, then flow instead proceeds to decision block 1348.
At block 1340, at least one sensor 108 in the selected group 304 has a failed/red status 724, and the corresponding group health status 308 is identified as failed/red 724. Flow proceeds to block 1344.
At block 1344, a next group 304 is selected. Flow proceeds to decision block 1336.
At decision block 1348, the IoT health evaluation device 112 determines if any the sensors 108 in the selected group 304 have an anomalous/yellow status 712, 720. If any of the sensors 108 in the selected group 304 have an anomalous/yellow status 712, 720, then flow proceeds to block 1352. If none of the sensors 108 in the selected group 304 have an anomalous/yellow status 712, 720, then flow instead proceeds to block 1356.
At block 1352, at least one sensor 108 in the selected group 304 has an anomalous/yellow status 712, 720, and the corresponding group health status 308 is identified as anomalous/yellow 712, 720. Flow proceeds to decision block 1360.
At block 1356, no sensors 108 in the selected group 304 have an anomalous/yellow status 712, 720, and the corresponding group health status 308 is therefore identified as normal/green 716. Flow proceeds to decision block 1360.
At decision block 1360, the IoT health evaluation device 112 determines if there are more groups 304 to evaluate. If there are not more groups 304 to evaluate, then flow either ends or proceeds to block 1104 to wait for next receive data 504. If there are more groups 304 to evaluate, then flow proceeds to block 1364.
At block 1364, the IoT health evaluation device 112 selects a next group 304 to evaluate. Flow proceeds to decision block 1336.
The functional block diagrams, operational scenarios and sequences, and flow diagrams provided in the Figures are representative of exemplary systems, environments, and methodologies for performing novel aspects of the disclosure. While, for purposes of simplicity of explanation, methods included herein may be in the form of a functional diagram, operational scenario or sequence, or flow diagram, and may be described as a series of acts, it is to be understood and appreciated that the methods are 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 method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel embodiment.
The descriptions and figures included herein depict specific embodiments to teach those skilled in the art how to make and use the best option. For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these embodiments that fall within the scope of the invention. Those skilled in the art will also appreciate that the features described above can be combined in various ways to form multiple embodiments. As a result, the invention is not limited to the specific embodiments described above, but only by the claims and their equivalents.
Finally, those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for carrying out the same purposes of the present invention without departing from the spirit and scope of the invention as defined by the appended claims.
This application claims priority to earlier filed provisional application No. 62/448,801 filed Jan. 20, 2017 and entitled “TOT HEALTH MONITORING USING BLENDED HEALTH INDEX”, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62448801 | Jan 2017 | US |
