Embodiments described herein generally relate to computer network and related operations. More particularly, embodiments described herein relate to providing methods and devices for determining, generating, and issuing a contextual alert message regarding an alert condition of a process system
The Internet of Things (IOT) has been a rapidly adopted technology over the last few years and has become especially important and critical in industrial applications, so much so that the term IIOT has emerged to refer to “Industrial IOT”. Generally speaking, IOT refers to devices, mechanical and/or electronic machines that are capable of at least some computation and associated system of software and networks that are able to transfer data over a network without requiring regular human interaction. Typically, IOT devices comprise a sensor, a microprocessor, and a connectivity module. The connectivity module connects the IOT device with a network, and may be “wireless” (using, e.g., WiFi, Bluetooth, Bluetooth Low Energy, RF, Zigbee, LoRa, cellular, 2G cellular, 3G cellular, 4G cellular, 5G cellular, and the like) or “wired” (using Ethernet, USB, serial, RS232, RS485, and the like).
In the early part of 2020, the COVID-19 pandemic forced many companies to shut down for extended periods of time, increasing the need for and reliance on IOT technologies to enable remote monitoring of companies' operations and facilities. Even after companies started opening up, they were still being run with fewer staff, with only essential staff being permitted on site and/or with limited on-site access, or with staggered staffing, all in an attempt to enforce social distancing. Industries that rely on in-person activity have been particularly hard hit, such as manufacturing, restaurants, retail shopping, grocery stores, hospitals, clinics, pharmacies, biotech companies, pharmaceutical companies, materials science companies, chemical companies, petrochemical companies, contract research organizations, research labs, research and development (R&D) labs, and the like.
One of the ways that IOT has been able to help is by monitoring critical assets and facilities that cannot be easily or regularly monitored in-person. Examples of such assets and facilities include, but are not limited to: Environmentally-controlled machines and instruments such as refrigerators, freezers, ovens, hotplates, incubators, and/or vending machines, etc.; Environmentally-controlled spaces such as walk-in freezers, walk-in cold rooms, cleanrooms and clean areas (including those specified by the ISO 14644 family of standard and the ISO 14698 family of standard), vivariums, saunas, greenhouses, and/or server rooms and data centers, etc.; Machinery including motors, turbines, and/or centrifuges etc.; analytical instrumentation including nuclear magnetic resonance (NMR) spectroscopy machines, magnetic resonance imaging (MRI) machines, mass spectrometers, and/or high performance liquid chromatography (HPLC) machines and systems, etc. among many others.
Such assets and facilities, and the processes which are associated and/or dependent on them, may be collectively called “Process Systems”. A common scenario is for these Process Systems to be monitored via an IOT device comprising a sensor that is responsive to at least one variable or parameter that is appropriate for the application. Non-limiting examples of variables or parameters include: temperature; intensity of electromagnetic radiation at at-least one frequency, including visible spectrum, infrared spectrum, ultraviolet spectrum, RF frequencies, etc; light; concentration of gas (e.g. CO2, O2); concentration of dissolved gas; pH; motion, including acceleration, velocity, and speed; intensity of sound at at-least one frequency; air pressure; absolute humidity and relative humidity; air quality (e.g. particle count, VOC); power consumption (e.g. voltage, AC current, DC current, or combinations thereof). It should be appreciated that other variable or parameters may be monitored by an IOT device that comprises a sensor that is responsive to that particular variable or parameter.
The variables listed above can be monitored for a variety of applications, systems and/or devices including, but not limited to: monitoring temperature in refrigerators, freezers, walk-in cold rooms, vivariums, manufacturing environments, ovens, etc.; monitoring temperature, humidity, and/or gas concentrations such as carbon dioxide and oxygen in cell-culture incubators; monitoring the power usage of machines and instruments like centrifuges, MRI machines, NMR machines, ovens, heaters, heating, ventilation, and air conditioning (HVAC) systems; monitoring air quality including VOC levels (volatile organic compounds), and/or particulate count in cleanrooms, office spaces, homes, and environments; monitoring vibration and/or motion of machines including generators, motors, die presses, turbines, robots, conveyer belts, and generally machines that have moving parts; monitoring one or more variable inside controlled environments, such as freezers, refrigerators, incubators, ovens, rooms, greenhouses, animal housings, vivariums, warehouses, shipping containers, shipping vehicles such as cars, vans, trucks, trains, airplanes, ships.
There are many sensors and instruments that can readily measure these and other variables of interest as a function of time. Exemplary sensors and instruments include, but are not limited to: thermocouple, thermistor, resistance temperature detector (RTD) for temperature, such as those supplied by Omega Engineering Inc.; photodiodes, photosensors, charge-coupled device (CCD) cameras for optical wavelengths of the EM spectrum including visible, infrared, and ultraviolet spectra; optical and electrochemical sensors for gas concentrations, such as those supplied by Alpha Sense and City Technology Ltd.; dissolved gas sensors; pH meters such as those supplied by Hanna Instruments, Omega Engineering Inc., and Cole-Parmer; motion sensors such as accelerometers supplied by Analog Devices, Omega Engineering Inc., STMicroelectronics; sound sensors such as those supplied by Vesper Mems; air pressure sensors; and/or humidity sensors.
Sensors like the ones above may be used to monitor different Process Systems to ensure proper operation and/or compliance with regulations. For example, a freezer may be deemed to be in proper operation when the temperature is within a certain range such as between −85C to −75C, or an incubator may be deemed to be operating properly if the humidity is between 95% and 100% or its carbon dioxide concentration is between 4% and 6%, or a vivarium housing animals may be deemed to be operating in a compliant manner if the temperature is between 23C and 27C and the humidity is between 30% and 60%. It should be appreciated that proper operation and/or compliance with regulations may be uniquely defined for each Process System without departing from the scope of the invention.
A notification or message may be issued when a Process System is deemed not to be operating in a desirable manner (e.g. not operating properly or not operating in a compliant manner). In such situations, the Process System can be said to be in an “alert” state. Proper operation of Process Systems can thus be determined by monitoring one or more than one variable of interest over time and checking to see if the variable is within a range of values, is above a threshold, is below a threshold, or is outside of a range of values for some defined period of time. The aforementioned ranges, thresholds, and time periods may be predefined or may be defined dynamically based on historical data. For example in: (a) an implementation, a method of determining if a Process System is in an alert state is if one or more values of a sensor or group of sensors is outside of a given range for a minimum period of time; and/or (b) in another implementation, a method of determining if a Process System is in an alert state is if at least one sensor reading satisfies at least one pre-determined condition, wherein the predetermined condition may be: an absolute condition; a relative condition; and/or a time-varying condition.
Once it has been determined that a Process System is in an alert state, a notification or message may be issued in many ways, including: sending an email; sending a text or SMS message; utilizing the native alert mechanism on a smart phone (e.g. Apple iPhone or Android phone); sending an electronic message or signal to a computing device (computer, tablet, smart phone, smart watch, etc.); and/or initiating a visual and/or audible alert, such as lighting up a light source or sounding an audible alarm, whether locally or at a remote monitoring location.
Furthermore, the message may comprise recommendations for actions that the user can take. Non-limiting examples include: scheduling calibration or maintenance; and/or suggesting that a user use a different machine, asset, or instrument for a particular task, for example: the incubator that has your cells may be damaged—it is recommended that you move your cells to a different incubator; and/or “the freezer where you store your samples experiences a lot of door opening events and therefore is our of temperature rage frequently—consider moving your samples.”
In a non-limiting example, when a freezer's temperature is above a threshold (for example, −70C) for some predefined period of time (for example, 10 minutes), that Process System is in an alert state. In this case, a temperature sensor is monitoring the freezer's temperature, and once the temperature has been above −70C for at least 10 minutes, an alert message is sent to a user via a text message, email, and/or phone call.
Many alerting and monitoring system on the market today operate in this manner, including systems from Monnit, Rees Scientific, and XiltriX. The problem with this current way of issuing notifications is that there is no context as to why the system entered into an alert state. Notifications are generally issued to inform the recipient that a system is currently in an alert state, but there is no information provided as to why the alert state came to be or if the situation is improving or worsening. This is especially true in the present working conditions caused by the COVID-19 pandemic (in 2020) whereby staff and employees are much more working from home and are not present on site in their company's facilities to inspect and check on why the alert state may have occurred. Further, access to facilities resources may be extremely limited, so context is increasingly important in order to deploy the correct resources to address the root of the problem rather than simply reacting the alert state.
Accordingly, there is a strong need to provide context regarding alerts and/or to indicate potential root cause(s) as to why a system entered into an alert state and optionally information as to the current status of the system.
In a first embodiment, the present invention provides a method for determining, generating, and issuing a contextual alert message to a user regarding an alert condition of a process system. The method includes the steps of:
In a second embodiment, the present invention provides a method for determining and generating a contextual alert message regarding an alert condition of a process system. The method comprising the steps of:
In a third embodiment, the present invention provides apparatuses for determining and generating and/or issuing a predictive contextual alert message to a user regarding a predicted alert condition of a process system. The apparatuses comprise programmed circuitry having instructions for performing the steps of any of the methods described herein and optionally a server component comprising instructions for performing server associated steps of the described methods.
The present invention provides solutions to the above-described problems in the art. Described herein are methods, systems, and/or computer readable media and/or instructions for determining and/or providing context regarding alerts and/or to indicate potential root cause(s) as to why a system entered an alert state and optionally information as to the current status of the system.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed concepts. As part of this description, some of this disclosure's drawings represent structures and devices in block diagram form in order to avoid obscuring the novel aspects of the disclosed concepts. In the interest of clarity, not all features of an actual implementation are described. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in this disclosure to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosed subject matter, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment. One skilled in the art will understand that there a numerous alternative variations that fall within the scope of the following disclosure. Reference to one embodiment or another embodiment is understood to be within the context of the disclosure and reference or embodiments may be combined in any fashion to arrive at a combination of separately disclosed features and that any of these combinations fall within the present disclosure.
A “process system” as used herein is not limited and can include any system or process where monitoring and/or tracking thereof is desired or required. Non-limiting examples includes devices or equipment such as freezers, refrigerators, ovens, incubators and/or other laboratory and/or manufacturing facility equipment. In other embodiments, a process system may be a combination of devices or equipment described above and/or a series of steps or subroutine performed using any of these types of devices. Unless the context is specifically limiting the such process systems can include an analytical instrument, measurement instrument, laboratory instrument, process instrument, manufacturing instrument, analytical equipment, measurement equipment, laboratory equipment, process equipment, manufacturing equipment, testing instrument/equipment, medical instrument/equipment, and facility management instrument/equipment, etc. These instruments and equipment are well known in the art and are not particularly limited herein.
The phrase Internet of Things (IoT) refers to physical objects, devices or “things” embedded with electronics, software and the ability to connect to the Internet or other top level server system etc. The connectivity permits the implementation of systems that monitor and control an activity. By way of example, multiple sensors in a manufacturing plant or laboratory may be controlled (turned on/off or throttled) based on a number of factors such as the desired power level, temperature, and the operation of devices within the loop. Thus, not only can single sensors (e.g. a light or temperature sensor) or actuators (e.g. a switch) be controlled in this way. Collections of sensors and actuators may be designed to function as a unit, where inter-device communication is operationally beneficial or necessary.
In one embodiment, the present invention provides a method for determining, generating, and issuing a contextual alert message to a user regarding an alert condition of a process system. The method comprising the following steps, which include:
In a further embodiment, the present invention provides a method for determining and generating a contextual alert message regarding an alert condition of a process system. In this embodiment, the method includes at least the following steps of:
In preferred embodiments, the contextual alert information comprises the alert condition and contextual information about the alert condition. The contextual information can be for example information such as why/when/how the alert condition was/will be reached; the root cause/timing of the alert condition; whether the process system is currently in/out of the alert condition; the current variable data of sensor measurement; the trajectory of the variable data; and data or information received or interpreted from other sensors. In alternative embodiments, the contextual alert information can include information such as a root cause message based on classification of primary root causes of process systems alerts and current process conditions which then are subsequently combined.
The variable data is preferably received and used by the server from a first sensor and optionally one or more additional sensors in developing the alert classification model and in determining the contextual information about the alert condition. The sensors are not particularly limited herein and can include sensors and/or sensor units coupled with or in communication with a sensor control unit which are either or both programmed with logic or instructions to receive and/or transfer sensor data to the application service and/or data storage device. In preferred embodiments, the sensor and/or sensor unit measures environmental data selected from the group consisting of temperature, humidity, light intensity, light wavelengths, vibration, gas concentration, air pressure, volatile organic compounds (VOC) concentration, particulate level, air pollution level, calibration information, user information, and equipment use information.
The sensor is preferably associated with the process system and is preferably an environmental variable sensor positioned to determine variable environmental data about or within the process system. Several different environmental factors can be measured using the various embodiments described herein. The word ‘Environment’ can be for example: the area where an instrument (lab or manufacturing equipment where measurement or other related data is obtained from); a laboratory or part of a laboratory space, a cold room, an animal house, a manufacturing floor, a greenhouse, a weather station; the area surrounding a chemical or ingredient being measured, or involved in the preparation of samples being measured, such as a reagent bottle (as measured by a miniaturized sensor or array of sensors, a ‘smart lid’ etc.), any storage container (grain silo, fermentation tank, refrigerator, freezer, etc.). The environmental factors (e.g. measured environmental parameters) can be, for example any of the following: temperature, humidity, atmospheric pressure, gas composition (overall, or specific to certain components of interest such as Volatile Organic Compounds (VOCs), ammonia, carbon monoxide, carbon dioxide, oxygen, or any other molecule for which sensors are available) light intensity (overall, or specific to a window of wavelengths—red, green, blue, or otherwise filtered to be sensitive only to a range of frequencies useful to the application, such as blue-UV for light-sensitive chemistry, or near infra-red, red and blue for plant growth) sound intensity (overall, or specific to a window of frequencies), motion, changes in magnetic strength or orientation etc. Another environment factor related to the instrument measurement data that can be measured by environmental sensing units is “whom took the measurement” and/or the “Time of measurement” from the laboratory/manufacturing facility equipment or “duration of a process step”. Such a measured factor can give a measure of the environment representative of conditions such as when using the instrument and/or inside a reagent container immediately before use. Further such a measured factor can give duration data (i.e. difference between times of measurements of other process steps) and this can also be determined from measured and recorded time points. This factor can be determined by any known methods of determining time or duration of time. In the alternative this factor can be determined by: a change of state in measuring equipment (e.g. change in weight recorded by a balance, motion detected by motion sensor (such as an accelerometer, gyroscope, software-based gyroscope) fitted to portable equipment or reagent containers etc.). In the alternative it simply can be determined and input by the operator of the equipment.
The choice of what environmental factor(s) to measure can be guided by relevance to the measurement (known or suspected by instrument manufacturer, research and supervisory staff) and availability of sensors (both commercially and the subset installed by an institution). The location of sensors needs to be adequate to represent the local environment but this may not mean close spatially; for example, atmospheric pressure across an entire floor of a building may be equal if there are no positive-pressure areas like clean rooms or negative-pressure areas like biohazard containment areas, and so an atmospheric pressure sensor somewhere on that floor can often be used to supply environmental pressure data relevant to the entire floor. In contrast, storage humidity may require a far more local sensor within a reagent container. Handling humidity may be recorded by a nearby humidity environmental sensor, but if there are no sources of water vapour addition (humidifiers, hot water baths etc.) or extraction (dehumidifiers, areas of water condensation) a more remote humidity sensor can be used; however, relative humidity varies with temperature and so corrections may be needed for temperature differences, using dew point or water vapour pressure as a constant point for correction.
The contextual alert message provides an indication as to why/how/when etc. the alert was generated and can contain any or all of the sensor data described above. In preferred embodiments, the alert message is a predictive contextual alert message. Such message will preferably contain prediction information regarding a future alert condition of the process system or that the process system is on a trajectory to achieve and/or is approaching a future alert condition.
To increase utility, the process system can be located in a facility selected from the group consisting of: a laboratory, medical facility, and a manufacturing facility.
In further embodiments the present invention provides apparatuses (such IoT devices or IoT systems etc. optionally coupled with a top level or cloud server components) for determining and generating and/or issuing a predictive contextual alert message to a user regarding a predicted alert condition of a process system. The apparatuses include programmed circuitry (such as computing and/or computer and/or electronic infrastructure, communication devices, relays etc.) including instructions for performing the steps of any of the methods described herein. For example the apparatus of the present invention may include local IoT device or infrastructure in communication with a processing system such as web server and/or application server via the internet through a local router or wireless network. The processing system comprising logic and /or other computer readable instructions to perform the process steps described herein and to provide contextual alerts as described etc.
The following non-limiting examples are provided to illustrate concepts and embodiments of the principles of the invention.
In this non-limiting example, temperature monitoring of a freezer is considered. In freezer monitoring (and in general for controlled environment monitoring) it is possible for a notification, message, or alert to be generated and sent when the temperature crosses a threshold and remains there for a set period of time. Some systems also inform the user once the temperature has returned back to the desired range and remains there for some period of time. This is useful since the user is notified that the excursion is no longer an issue.
Whilst this type of notification system is useful and helpful for initial alerting, there may be many different reasons or root causes as to why the temperature may have crossed the threshold. Furthermore, such a basic system cannot inform the user if the temperature may be returning back towards the desired range (and only informs the user after it has returned). This basic system provides no insight or explanation as to why the temperature variation may have occurred. Thus, it is useful to have a system that can also inform the user of potential root causes for the initial excursion, the current state of the Process System during the excursion event, and an indication that the excursion event is over if the system returns back to its desired normal operating range.
Table 1 below lists some common root causes for the temperature of a freezer to have an excursion and increase above a predefined threshold and associated status. Red dotted lines in the Figures indicate the time at which an alert is triggered. Green dotted lines in the Figures indicate the time at which the alert is cleared (i.e., when the temperature of the freezer has returned back below the threshold). The table below shows that for each root cause that triggered an alert, there may be more than one state that the freezer is in (current freezer status) when the alert or notification message is sent to the user.
These Figures show examples of how different root causes can cause the temperature of the freezer to increase above a predefined threshold. As can be seen, it is useful to also know and understand these root causes when an alert message is received so that the user understands the context around the alert. Furthermore, in this example, there are two notification messages that are sent: the first one is when the temperature increases above the alert threshold (shown in red in
In the embodiments described herein, methods and apparatuses are described for providing contextual information related to an alert condition. As described above, an alert condition is a condition where a Process System is in a state that is deemed to be in a state that warrants a notification to be generated and/or sent to a recipient, such as a user or a computing device. The embodiments relate inter alia to any and all of the following scenarios: Providing contextual information when an alert condition is reached; Providing contextual information after an alert condition is reached; Providing contextual information during the time in which a Process System is in an alert state; Providing contextual information when a Process System has exited an alert state; Providing contextual information after a Process System has exited an alert state; Providing contextual information before a Process system has entered an alert state. Such a scenario is possible when conditions are monitored and analyzed at regular or irregular time intervals, continuously, semi-continuously, periodically, or generally at predefined intervals (which can be either fixed duration intervals or intervals of different durations) during times when a Process System is not in an alert state. In this manner, conditions that indicate that an alert state may occur within a future time period can be used to provide predictive notifications with the associated contextual information to a user or computing device. In one non-limiting example, such a contextual alerting system may be measuring the temperature of a freezer and identify a period of time where a characteristic temperature oscillation caused by a compressor may cease to exist. In such a case, a notification or message can be sent to a user indicating that the compressor may have stopped working and that a temperature increase (and the associated temperature alert) is likely to occur within the next few hours.
The embodiments herein described allow for inter alia determining, generating, and improving contextual notifications. Contextual notifications are messages which comprise associated information related to potential root causes of an alert, current state of a Process System, and/or recommendation for action to be taken in addition to simply indicating that an alert state is imminent, has been reached, or has been exited.
In certain embodiments, in order to provide the context related to an alert state, a classification model needs to be constructed. In order to build a classification model, the root cause states in Table 1 can be distilled into classes for classification and/or prediction. It would be inefficient to build a classification model for each root cause state. Instead, the root cause states can consist of a combination of classes. For example, in the last example in Table 1 above, the root cause state of “Door open multiple times. Compressor on, but struggling to lower temperature” is not a viable class for training because it is comprised of several more fundamental root causes. However, this composite root cause can be broken down into four primary root cause classes, where each primary class can be determined to be true or false: 1. “door open multiple times”=TRUE; 2. “compressor on”=TRUE; 3. “temperature normal”=FALSE; 4. “temperature decreasing”=TRUE.
Then each primary class can be predicted separately and combined as appropriate into a single contextual alert message. A preferred model will consist of the least number of primary classes as this will be the most accurate and efficient. Therefore, the goal is to reduce the entire root cause space into a matrix of primary classes. The first step is to identify the common and useful output status messages for a given Process System. It is preferable to identify most of the common and useful output status messages; it is more preferable to identify all of the possible output status messages. In this way, a composite model may be crated that is comprised of at least one primary model.
One non-limiting example of how to determine useful and common output status messages is to consider a list of questions that an end user would like answered by a status message. One ordinary skilled in the art will recognize that a user will likely have more questions during an alert state, but also that there may be instances where the user would want contextual notifications even when the Process System is not in an alert state (such as prior to an alert state when an alert state is predicted to occur, or during a period of normal operation where a user would like to receive periodic notifications informing him or her that the Process System is running correctly). Non-limiting examples of questions that a user may have for the non-limiting example of monitoring a freezer, refrigerator, or cold-storage apparatus are: Is the temperature ok?'; Is the compressor on?; Is the power out or freezer unplugged?; Is the compressor behaving abnormally?; Is the door currently open?; How many times has the door been opened recently?; Is the temperature currently increasing (getting worse) or decreasing (getting better) or stable (no change)? (i.e. what is the short-term temperature trend?); Has the temperature been increasing (getting worse) or decreasing (getting better) or stable (no change)? (i.e. what is the long term temperature trend?); Is the freezer currently being defrosted?
In this non-limiting example, a preferred goal of a contextual notification would be to answer all of the above questions, either explicitly or implicitly, at any given time. For instance, a message of “the freezer is operating normally” suggests the temp is ok, the compressor is on, the power is not out, the compressor is behaving normally, the door hasn't been opened excessively, the temperature is stable and we are not defrosting.
One ordinary skilled in the art will recognize that providing answers to at least one of the above questions would still be beneficial to the user. Furthermore, in the case where none of the questions above could be answered confidently, it would still be beneficial to inform the user that in fact none of questions can be confidently answered. This is because such a message would allow the user to conclude that a new, unknown root cause may be manifesting. Table 2 below shows examples of seven root cause class groups, and the corresponding class labels.
In this example, by considering each class group separately and creating models for each class group, the number of models is kept to a smaller number. The “Door Open History” model would only require 2 classes to be predicted (if the labels were to be “typical” and “atypical”) or 3 classes to be predicted (if the labels were “none”, “one extended”, and “many”). Similarly, the “Current Door Open Status” model would require only two classes to be predicted (“closed” or “open”). In total there are 7 class groups, which suggests 7 different models will need to be trained, one for each class group. In this non-limiting example, however, each model has at most 3 output class labels (plus the default unknown class label), which will lower the training time, keep the models small, and hopefully allow for ample training samples for each class. If however, one model was created to combine all of the above class groups and labels, there would be over 400 classes to predict, one for each combination of all classes for each class group. Realistically this may be unfeasible for practical applications where the size of a training set may be limited.
Thus, according to further embodiments the present invention provides methods of creating composite root cause messages based on classification of primary root causes which then are subsequently combined together.
One ordinary skilled in the art will recognize that there are many different approaches to building classification models. This is well known in the fields of artificial intelligence and machine learning (often referred to as AI/ML). There are generally two broad methods of constructing models in the field of AI/ML: supervised learning models and unsupervised learning models.
One ordinary skilled in the art will recognize that there are several methods of AI/ML including but not limited to the following:
In this non-limiting example, a freezer status algorithm will be developed using a weak supervision framework. In weak supervision, rules are handcrafted by domain experts which are used to label training data instead of manual inspection. Each rule labels a training example with a class or abstains from labeling. For example: “if temperature >20C for past 1 hr then defrosting=yes; else no”; and/or “if temperature is decreasing then compressor=cycling; else abstain”.
These rules can be noisy by nature and can contradict each other. Multiple rules are written for each class group until every example has at least one label (i.e. at least one rule does not abstain for each example). Next, the hand-crafted rules are weighted based on a likelihood function, which ultimately gives higher weight to rules that tend to agree with other rules. The re-weighted rules are then used to give a final class label to each example. These weighted labels are then used to train a machine learning model. This method drastically reduces the need for hand labeled data, increasing development speed and thereby reducing effort, cost, and time.
A small development training/test data set is necessary. The training set is used to help craft the rules, the test set is used to validate the final model. The model building and testing process is done completely independently of the hand labeled data.
To show the feasibility of using programmed rules for this application, a single freezer was investigated. Five rules were initially crafted to classify whether the compressor was on or off based on the temperature readings over a period of time. After running the rules over a data set at one hour intervals, three of the rules had values that had discriminating value. These three rules are as follows: 1. If the temperature range <10 degrees then compressor is on (+1), compressor is off (−1); 2. Split the time series data into 5 windows of equal size. If the resonant frequency of the most recent split is >double the median, then the compressor is off (−1), else compressor is on (+1); and/or 3. Split the time series data into 5 windows of equal size. If the resonant frequency of the most recent split is >double the minimum, then the compressor is off (−1), else compressor is on (+1)
Rule 1. identifies positive events, i.e. compressor is cycling. Rules 2 and 3 identify negative events i.e. compressor is not cycling.
It is clear from these three rules taken independently that there is a significant number of false positives. As can be seen from the raw data of
When the three rules are combined into a composite rule, the performance of the model can be improved. One ordinary skilled in the art will recognize that there are many methods of combining the models, including but not limited to averaging the values of each rule's output or using logistic regression. In this example, logistic regression was used. The red dots in
In this example, the combined model's output can be interpreted as follows: a value >0 suggests that the compressor is on; the higher the model's output, the higher the confidence that the compressor is off; and/or a value <=0 suggests that the compressor is off; the lower the model's output the higher the confidence that the compressor is off
It is clear that the label noise is improving. There are still several false positives (red dots above 0 during the period where the compressor is off), but these false positives are likely due to door opening events that were not accounted for in these rules. However, the important output is that the long band of no compressor activity is clearly tagged with many negative results. Thus, one can trigger a notification based on the composite rule outputting values <=0 to inform a user that the compressor may not be on or functioning properly.
As described above, it is often the case that to provide an explanation for why a Process System is in an alert state (or might be approaching an alert state), there may be several factors that contribute to the cause. In such a situation, it is convenient to create a composite root cause comprised of at least one primary root cause. In this manner, the combination of several primary root causes into a composite root cause can be mapped to an external message that is suitable for a human user, or even another machine, to understand.
In
Incorporated herein by reference are U.S. Prov. Application Ser. No. 62/739,427 filed on Oct. 1, 2018; U.S. application Ser. Nos. 16/589,347 and 16/589,713 filed on Oct. 1, 2019; and PCT Application Serial Nos. PCT/2019/53941 and PCT/2019/53977 filed on Oct. 1, 2019; US Prov. Applications entitled (1) “Method and Apparatus for Local Sensing” which was filed on Oct. 1, 2018 and received U.S. Provisional Application Ser. No. 62/739,419 and its related PCT application Ser. No. PCT/US19/54020; (2) “Method and Apparatus for Process Optimization” which was filed on Oct. 1, 2018 and received U.S. Provisional Application Ser. No. 62/739,441 and “Method and Apparatus for Process Optimization” which was filed on Feb. 4, 2019 and received U.S. Provisional Application Ser. No. 62/800,900 and their related US and PCT applications (U.S. Ser. No. 16/589,713 and PCT/US19/53977). These applications are incorporated in their entireties herein by reference for all purposes.
Any external reference mentioned herein, including for example websites, articles, reference books, textbooks, granted patents, and patent applications are incorporated in their entireties herein by reference for all purposes.
Reference throughout the specification to “one embodiment,” “another embodiment,” “an embodiment,” “some embodiments,” and so forth, means that a particular element (e.g., feature, structure, property, and/or characteristic) described in connection with the embodiment is included in at least one embodiment described herein, and may or may not be present in other embodiments. In addition, it is to be understood that the described element(s) may be combined in any suitable manner in the various embodiments.
Numerical values in the specification and claims of this application reflect average values for a composition. Furthermore, unless indicated to the contrary, the numerical values should be understood to include numerical values which are the same when reduced to the same number of significant figures and numerical values which differ from the stated value by less than the experimental error of conventional measurement technique of the type described in the present application to determine the value.
This application claims the benefit of U.S. Prov. App. Ser. No. 63/081,033 filed on Sep. 21, 2020, which is incorporated herein by reference for all purposes.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2021/051098 | 9/20/2021 | WO |
Number | Date | Country | |
---|---|---|---|
63081033 | Sep 2020 | US |