Patent Description:
<CIT> discloses a method for alerting users to easing hazardous conditions. Once a threshold level of a hazardous condition has been realized (e.g., smoke, carbon monoxide), a hazard detector may monitor for the hazardous condition to drop below a (same or different) threshold level. Once the drop occurs an amount of time may be waited. Once a defined time period has elapsed and the hazard condition has not risen above a threshold level, an indication may be output that indicates the hazardous condition is easing. The defined time period may be based on various factors, including the type of hazard, readings from other hazard detectors, and/or a measured humidity level.

The invention is defined by the independent claims, to which reference should be made.

It should be understood at the outset that although illustrative implementations of one or more embodiments are illustrated below, the disclosed systems and methods may be implemented using any number of techniques, whether currently known or not yet in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, but may be modified within the scope of the appended claims.

The term "comprising" means including but not limited to, and should be interpreted in the manner it is typically used in the patent context;.

The phrases "in one embodiment," "according to one embodiment," and the like generally mean that the particular feature, structure, or characteristic following the phrase may be included in at least one embodiment of the present invention, and may be included in more than one embodiment of the present invention (importantly, such phrases do not necessarily refer to the same embodiment);.

If the specification describes something as "exemplary" or an "example," it should be understood that refers to a non-exclusive example;.

The terms "about" or "approximately" or the like, when used with a number, may mean that specific number, or alternatively, a range in proximity to the specific number, as understood by persons of skill in the art field (for example, ±<NUM>%); and.

Embodiments of the invention include a system and a method for remote diagnostics for flame detectors, in order to reduce processing communication latency times. In a typical work environment where there exists the possibility for fire hazards, a plurality of flame detectors may be employed. However, these flame detectors may frequently report alarms in the field because of unknown incidents occurring at a customer workplace, where diagnostics of these alarms may be provided by the operator of the flame detectors (where the operator may be separate from the customer employing the flame detectors). There is a need to provide on-field diagnostic services and remote monitoring, which will help in determining the cause of an alarm and in educating the customer in incidents that have occurred in their facility. These steps may improve in-field performance of the flame detectors, reliability and reduced false alarms, thereby encouraging trust from customers. These steps may also allow for identification of errors or problems with the flame detector that may require updates, maintenance, and/or repair.

A development team (typically not part of (e.g. with the development team part of a different organization/company than the customer, for example the company selling and/or operating/maintaining the flame detector(s) on behalf of the independent customer) and located separate and apart from the customer) may be responsible for receiving data from flame detectors, particularly with regards to alarms or alerts, and responding back to customers with a solution and/or escalating to further analysis of the data. However, within the management company, there may be a high amount of processing communication latency time (PCLT) involved in receiving and processing diagnostic information (e.g. pictures, real-time data, event logs, and radiation data).

Embodiments of the invention include a communication system with reduced PCLT and utilization of wireless communication devices to improve the response time for alarms or alerts generated by the flame detector(s). The communication system utilizes cloud-based remote diagnostics (RD) and fire replay technique (FRT) to receive and analyze data from the flame detector(s).

Industrial Internet of Things (IIOT) enabled remote diagnostics (RD) is a new monitoring and diagnostics model for flame detectors. This model benefits from cloud computing advantages and offers continuous diagnostic capabilities. It is a parallel processing model which removes layers in the process and escalating the issues further down a communication pathway. The disclosed communication system allows a development team to communicate with the flame director and/or customer directly. This may be accomplished by utilizing the wireless communication capabilities of safety communicator devices (or other such wireless devices) which may already be located near the flame detectors, as they are carried by workers in the area.

A flame detector may be configured to perform diagnostics (e.g. self-tests, communications checks, power supply diagnostics, and sensor calibrations) and communicate these via the safety communication devices to a cloud database, which may be accessed by the development team. Typically, the flame detectors do not contain cameras or microphones, and thus would not be configured to transmit video and/or audio associated with the alarm event. The flame detectors and the safety communicator devices may comprise wireless communication capabilities (such as Bluetooth, Wi-Fi, etc.) to allow them to communicate with each other and share diagnostics data with the cloud database periodically, continually, and/or on-demand. Whenever an issue is detected by the flame detector in the field, a worker carrying a safety communicator device (such as a maintenance engineer or safety manager) may upload data to the cloud database and a notification may be sent to the development team through the cloud. The development team may start processing the information immediately after receiving the notification.

Various measurements taken by the flame detector may be transmitted to the cloud database, via the safety communicator device(s), using a wireless (e.g. Wi-Fi) network. Once the data is received by the cloud database, algorithms (e.g. run by a central server) process the data and generate notifications to the development team. This is accomplished by a central server in communication with the development team. Relevant information is then shared with the development team via e-mail, local access, etc. Additionally, reports may be automatically generated for communication with the customer.

Referring now to <FIG>, a communication system <NUM> is shown. The communication system <NUM> may comprise one or more flame detectors <NUM> configured to detect electromagnetic radiation, where each of the flame detectors <NUM> may be associated with (and employed by) a customer <NUM>. The communication system <NUM> may also comprise one or more safety communicator devices <NUM> carried by one or more workers within the area of the flame detectors <NUM>.

In a typical situation, a communication system <NUM> may comprise one or more of a sales/marketing system <NUM>, a product support team <NUM>, an engineering management system <NUM>, and a development team <NUM>, where the data collected by each of the flame detectors <NUM> may be gathered and communicated by this flow of information. It may be important for a development team <NUM> to access specific data from flame detectors <NUM> to provide improvements, adjustments, and/or corrections to the customers <NUM> and their flame detectors <NUM>. However, the information flow may be delayed by the many steps or systems between the customer <NUM> and the development team <NUM>. Additionally, false alarms given by the flame detectors <NUM> may not be quickly identified by the development team <NUM> because of the long communication time/lag. In some embodiments, errors or problems with the flame detectors <NUM> that may require updates, maintenance, and/or repair may also be identified and communicated.

The communication system <NUM> shown in <FIG> may utilize the safety communicator device(s) <NUM> that are carried by workers in proximity to the flame detectors <NUM> to relay data (e.g., detected by sensor(s) within the flame detector) from the flame detectors <NUM> and upload it to a cloud database <NUM>. A central server <NUM> (managed by the development team <NUM>, for example) pulls data sets from the cloud database <NUM> to analyze and produce feedback for a customer <NUM> (or another monitoring service) based on the analyzed data.

The processing of the data (which may be completed by the flame detector <NUM>, the safety communicator device <NUM>, the cloud database <NUM>, and/or the central server <NUM>) comprises converting the data using an analog to digital converter (ADC). Additionally, the data is processed using a Fire Replay Technique (FRT) to simulate or replay the collected ADC data to establish actual fire scenario remotely, by means of providing collected ADC values as input.

In some embodiments, the development team <NUM> may use the diagnostics data from the flame detector <NUM> to reproduce or replicate the exact scenario remotely, using the FRT, where the development team <NUM> may simulate or replay back the collected diagnostic data from the flame detector <NUM> to establish an actual fire scenario remotely. In some embodiments, the data may be processed by analyzing the short and long band infrared spectrum (within the data from the flame detectors <NUM>) to determine the type of fire (or other alarm event) that occurred. Additionally, customer explanations may be input by the customer <NUM> (e.g. using the safety communicator device <NUM>) and associated with the received data, and the processing of the data may comprise cross analyzing whether the customers' explanation makes sense (such as a customer asserting that the smoke was caused by arc welding instead of a hydrocarbon fire). In some embodiments, the safety communicator <NUM> may receive the data from the flame detector <NUM>, which may automatically trigger a response by the safety communicator <NUM> (e.g., forwarding the data and/or presenting a notification to the user). When a notification is presented to the user by the safety communicator <NUM>, the notification may also comprise a request for the user to input information about the surroundings in the environment of the flame detector <NUM>. For example, the notification may provide an opportunity for the worker to input an explanation for an alarm, alert, and/or error communicated by the flame detector <NUM>.

In some embodiments, the central server <NUM> (e.g., with a processor) may be configured to pull specific scripts in response to analysis triggers (based on the analysis described above) and self-generate a report that is understandable for relay to a customer representative. These reports can also be compiled and used to provide recommendations for changing and/or updating the software/firmware used in the flame detectors <NUM>.

Typical flame detectors <NUM> that are IR sensor based may not provide a way to identify an event as a nuisance alarm or false alarm. A nuisance alarm is the detector response to a friendly fire, such as a known or non-hazardous fire. A false alarm is the detector response to a non-fire event, such as modulated heated surface or the sun. If any such false alarm or nuisance alarm event occurs at the customer end, a worker (such as a maintenance engineer) may report the event by manually sending the diagnostic data of the flame detector <NUM> to the cloud database <NUM>. When this type of event is reported by the customer <NUM>, it may be considered a service support request by the development team to analyze what went wrong. The development team <NUM> may pull diagnostic data from the cloud database <NUM> (possibly via a central server <NUM>), and replicate the actual scenario remotely using the fire replay technique described above to determine what went wrong.

The FRT may be accomplished using "Fire Pic" data. The Fire Pic data may comprise a collected set of flame detector (sensor behavioral) data at the instant of time (and perhaps in some instances from a period of time in proximity to the event, such as immediately preceding and/or immediately after the event) when an event has occurred. The FRT considers this Fire Pic data as input to simulate all the fire scenarios (a piece of software code written on a machine) and generate an analysis document as output. The analysis report may be pushed to the cloud database <NUM> from the development team <NUM> with a notification to the customer <NUM> that the report is available. Typically, the Fire Pic data does not include video or audio (since for example, the flame detector(s) typically would not include camera or microphone elements), and typically the FRT or other analysis would not use any video or audio information (although in other embodiments, video and/or audio might be used to assist in the analysis (in which instance the flame detector might include a camera and/or microphone)).

Additionally, errors or problems with the flame detectors <NUM> may be identified (e.g., by the flame detector, safety communicator, and/or central server <NUM>), where the errors may require updates, maintenance, and/or repair. The central server <NUM> is configured to identify a problem or error with a flame detector <NUM> (in response to the FRT analysis), and generates (corresponding) instructions for correction. The instructions may also be for update, maintenance, and/or repair. The central server <NUM> generates instructions that are communicated to the flame detector <NUM> and the flame detector <NUM> automatically implements, applies, or otherwise follows the instructions (where correction or repair can be made by software updates). Specifically, the instructions comprise a sensor adjustment or a field-of-view adjustment.

The described communication system <NUM> using a cloud-based approach to communicating between a customer <NUM> (and their flame detector(s) <NUM>) and the operator (and development team <NUM>) of the flame detector <NUM> offers a method for reducing the frequency of issues and false alarms, and decreasing the communication times between the customer <NUM> and the development team <NUM>. Additionally, a data bank of flame detector data that is communicated via
the cloud database <NUM> may be stored and accessed for future reference for the customer <NUM> and development team <NUM> (e.g., during FRT, the system might reference similar events by profile comparison, leading to recommended selections drawn from past similar events).

<FIG> illustrates an exemplary method <NUM> for collecting, processing, and communicating data from a flame detector. At step <NUM>, the flame detector may monitor the available field of view. At step <NUM>, the flame detector may determine if a fire event has been detected. If no fire event is detected, the method may continue from step <NUM>. If a fire event is detected (e.g., by one or more sensor(s) and/or a processor of the flame detector assessing the sensor data), at step <NUM> the flame detector may capture the sensor data, diagnostic data, Fire Pics, event logs, and other pertinent information related to the fire event and at the time of the fire event. At step <NUM>, a safety communicator device may access the captured data from the flame detector (which may occur at a time different than the fire event). This access may be accomplished in many ways, where the safety communicator device may request the data, and/or the flame detector may push the data to the safety communicator device (e.g. wirelessly, for example using Bluetooth or some other such short range communication means). At step <NUM>, the safety communicator device may push (e.g. wirelessly, typically using a longer range means of communication such as Wi-Fi) the captured data from the flame detector to a cloud database (and may send a notification to a development team for the flame detector). Alternatively, the flame detector could comprise a longer range (wireless) communication means and directly push the captured data to a cloud database (although the Applicant believes that using a safety communicator device offers advantages regarding cost and/or the ability of the workers to provide/include context/comments along with the captured data). At step <NUM>, the development team may access the data from the cloud database, and may process the data (for example, after receiving notification of the fire event and/or pushed out captured data). This processing comprises using a fire replay technique (on a computer, i.e., a central server). At step <NUM>, the development team may generate an analysis report for the specific fire event using the processing of the data (using the fire replay technique). The analysis report may be generated manually (e.g. by the development team using their computer(s) to process the data and/or generate a report), or it may be generated automatically by a central server controlled by the development team. At step <NUM>, the analysis report may be communicated (pushed) to the cloud database, and may be accessed by the customer. Optionally, a notification may also be sent to the customer directly, notifying them of the analysis report related to the fire event.

<FIG> illustrates an exemplary diagram of a flame detector <NUM> (as described above) wherein the flame detector <NUM> may comprise one or more sensors <NUM> i.e., an IR sensor). As described above, the flame detector <NUM> may comprise a wireless module <NUM> configured to allow the flame detector <NUM> to wirelessly communicate with other devices (e.g., the safety communicator and/or cloud server). The flame detector <NUM> may comprise a processor <NUM> and a memory <NUM> configured to store and execute applications and processes as described above.

Claim 1:
A communication system (<NUM>) comprising:
a central server (<NUM>) configured to:
access fire event data from a cloud database (<NUM>), wherein the fire event data comprises a set of data detected in a field of view of an infrared sensor of a flame detector (<NUM>) at the time of a fire event; and
an analog to digital converter, ADC, configured to convert the set of data,
wherein the central server (<NUM>) is further configured to:
analyze the converted set of data using a fire replay technique, wherein the fire replay technique is a piece of software code that, when executed by the central server (<NUM>), takes the converted set of data as input and simulates all fire scenarios that trigger an alarm to identify an error associated with the flame detector (<NUM>); and
generate and communicate instructions to the flame detector (<NUM>) to automatically correct the error with the flame detector (<NUM>),
wherein the instructions comprise a sensor adjustment or a field-of-view adjustment.