The application pertains to systems and methods for storing and monitoring events at security devices. More particularly, the application pertains to such systems and methods which store event related information along with a time stamp.
Known security system intrusion detection devices, such as glass break detectors, and motion sensors, communicate alarm results (e.g. glass breakage events, and human movement), and other statuses (trouble status with tamper or self-test), to a common control panel via wireless or wired communications.
Although intrusion detectors are widely sold and installed, they can still experience false alarms as well as non-detects at times. In practice, it is difficult for authorities or installers to determine if a device alarmed to a false alarm event (false positive) or judged an alarm event as a false alarm (false negative) when it should have resulted in an actual alarm. In other words, it is difficult for authorities or installers to determine if a false alarm or missed alarm event is resulted from detector itself or other status changes (e.g. wires broken for wired communication; jam of wireless or wired communication; communication error; panel error and etc.) of communication between detector and control panel. These issues can result in a significant inconvenience, possibly causing confusion, and has an effect on the authorities', and/or customers', confidence in the devices performance.
In summary, known security system devices have not included event and result storage, or monitoring, and therefore cannot completely meet the requirements of user confirmation and post analysis of results to determine if an event was a missed alarm or false alarm.
While disclosed embodiments can take many different forms, specific embodiments thereof are shown in the drawings and will be described herein in detail with the understanding that the present disclosure is to be considered as an exemplification of the principles thereof as well as the best mode of practicing same, and is not intended to limit the application or claims to the specific embodiment illustrated.
To solve the problems mentioned above embodiments store monitored events for future retrieval and analysis. A method and system with event storage can improve the reliability of security system devices. The stored data can be retrieved at any time by authorities, or retrieved and sent to the device manufacturer for further analysis. The stored data may be retrieved, via wired or wireless communication methods or directly by a retrieval device, from the respective detector.
Considering the memory limits of security devices, another embodiment is also provided here which allows the glass break detector or other security device to only record the event based on the system status, armed or disarmed. By doing so, it is easier to determine actual events from false alarms, thereby making post analysis easier to perform. Furthermore, in order to avoid reaching memory limits, or, filling the allocated memory of a security device, memory space filled with events detected more than a predetermined number of days passed which have already been retrieved, or would not be used further for post analysis could be released and reused to store current event information.
When there is a glass break incident in monitored region R, the acoustic transducer module 110 senses the sound characteristics and outputs a signal that will be conditioned by the analog signal conditioning module 120. The conditioned signal will then be sampled, further processed, and the results determined by the control circuit module 130. If the module 130 determines that an event had characteristics of glass breakage, and met alarm criteria, then the event would be stored in the memory module 140. Finally, the communication module 150 sends the results to a remote, common, control panel 160 via a wired or wireless medium 170.
While only the glass break event operational process has been described, the types of events can be expanded to include tamper, environmental, or trouble events. In summary, events can be monitored and the results stored to meet the authorities/customers' needs for data to carry out post analysis.
Those of skill will understand that a variety of events, or, sensors come within the spirit and scope hereof. These include, without limitation, fault generated events, intrusion events from sensors of all types including motion, infrared, vibration, and glass break sensors, as well as environmental events, from sensors such as smoke, flame, gas, humidity, and temperature sensors.
A flow diagram 200 of a method of operating a plurality glass break detectors is illustrated in
Stored data can include incident information as well as a time stamp. Subsequently, detection results can be confirmed and used for analysis as at 250, 260.
Detector 306 includes a housing 308 which carries an acoustic transducer module 310, an analog signal conditioning module 320, a programmable processor module 330, implementable with a micro-processor unit (MPU) or alternates such as a digital signal processor (DSP) A storage, or, memory module 340, is coupled to the circuitry 330 as is a communication module 350. The detectors 306 . . .306-p can communicate with a control panel 360 via a wired or wireless medium 370.
Again, with respect to detector 306, when the sensor 310 senses the sound signal it outputs a signal to the analog signal processing module 320. Then the processed signal is sampled, further processed and the results determined by the processor module 330. If the MPU 330 determines that an event is identified as glass breakage (trouble incidents, tamper incidents or other reportable events), then the event is stored with at least timestamp information in the memory module 340. The stored events could be encoded and compressed in order to save memory. Finally, the communication module 350 sends the results to the displaced system control panel 360.
In yet another aspect, when a security system is in an armed state, if an event occurs and the detector goes into alarm or fault, the event can be recorded. Upon inspection by the authorities, if the event appears to be a false alarm, further analysis of the recording can be performed to determine that the event may have been an attempt to break in, but ended in failure.
Likewise, to determine what types of everyday occurrences may cause a false alarm, the detector may be programmed to record events during the disarmed state. These events can be time stamped in the detector by its own real time clock or via two way communication with the control panel 360 that includes a real time clock. When an event occurs, the detector 306, or any other member of the plurality can receive a time stamp back from the control panel 360 to link to the event. If the detector has its own real time clock, it would calibrate its clock periodically from the devices to which it reports such as the control panel, central monitoring station, cloud calculation center, etc.
In summary, event storage and monitoring for security system devices have been disclosed. Methods and systems for the monitoring and storage of security system device events have been provided. Those of skill in the art will understand that the present embodiments are applicable different types of environmental, or event detectors including smoke or gas detectors as well as intrusion detectors, without limitation, and can be incorporated into any security system.
In one aspect, the current embodiments can effectively identify incidents by using the design concept of event storage and recall, to meet the authorities, and/or, the customers' needs. Event information can be provided by the disclosed processing and monitoring workflow. In another aspect, the processing method of detecting, storing, and recalling events, as described above, is simple and effective, and will be helpful for failure analysis and confirming results. By recording events based on the state of the security panel, it is easier to determine actual events from false alarms, thereby making post analysis easier to perform.
The events captured locally at the respective detector(s) can be stored not only at detector(s) but also at a control panel such as panel 360. They also can be stored at central monitoring station.
The detector can synchronize its clock to the control panel periodically in order to provide a precise time stamp to the events it detects and stores. A local clock is useful when the detector can't communicate with control panel and when events are detected and event information needs to be stored on the detector side. For example the detector(s) can't send the alarm to the panel because the communication link has failed, a record is stored and available at the respective detector to forward for post-mortem analysis when the link is restored.
In one aspect, events can be captured locally at the respective detector and forwarded to a control panel. When the event has been received by the control panel, the panel will associate a time stamp with that event. The control panel can include a clock, to provide a time stamp.
Further, the event can be forwarded electronically to a central monitoring station, or other authorized personnel, to permit review and or determination that there was an actual event such as a glass break.
From the foregoing, it will be observed that numerous variations and modifications may be effected without departing from the spirit and scope hereof. It is to be understood that no limitation with respect to the specific apparatus illustrated herein is intended or should be inferred. It is, of course, intended to cover by the appended claims all such modifications as fall within the scope of the claims. Further, logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Other steps may be provided, or steps may be eliminated, from the described flows, and other components may be add to, or removed from the described embodiments.