JP2016021740A - Method and system for expressing sensor-related data - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently provide related information based on a sensor by monitoring and collecting data from plural sensors and managing the sensors to improve social security.SOLUTION: A system, device, and method, which are configured to monitor and manage plural sensors via a graphical user interface, receives plural pieces of sensor data, analyzes the received sensor data, and displays the received sensor data in a plain form or format to direct attention toward received sensor data that may be important.SELECTED DRAWING: Figure 3

Description

(Related application)
This application is a Joseph L. application filed May 20, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 281,896 (Attorney Docket No. 13-012-00-US) entitled “Sensor-Based Detection System” by Gallo et al.

  This application is a Joseph L. application filed May 20, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 281,901 (Attorney Docket No. 13-013-00-US) entitled “Sensor Management and Sensor Analysis System” by Gallo et al.

  This application is a Joseph L. application filed June 25, 2014, which is incorporated herein by reference. Related to US patent application Ser. No. 14 / 315,289 (Attorney Docket No. 13-015-00-US) entitled “Sensor-Related Messaging Method and System” by Gallo et al.

  This application is a Joseph L. application filed June 25, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 315,317 (Attorney Docket No. 13-016-US-US) entitled “Sensor-Based Detection System Routing” by Gallo et al.

  This application is a Joseph L. application filed June 25, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 315,320 (Attorney Docket No. 13-017-00-US) entitled “Graphical User Interface of Sensor-Based Detection System” by Gallo et al.

  This application is a Joseph L. application filed June 25, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 315,322 (Attorney Docket No. 13-018-00-US) entitled “Graphical User Interface for Sensor-Based Detection System Routing” by Gallo et al.

  This application is a Joseph L. application filed May 20, 2014, which is incorporated herein by reference. Related to US Patent Application No. 14 / 281,904 (Attorney Docket No. 13-020-00-US) entitled “Event Management System for Sensor-Based Detection Systems” by Gallo et al.

  This application is a reference to Ferdinand E., filed May 23, 2013, which is incorporated herein by reference. K. Philippine Patent Application No. 14 / 281,904 entitled “Domain Agnostic Method and System for Sensor Measurement Capture, Storage, and Analysis” by de Antoni et al. (Attorney Docket No. 13-027-00-) PH)).

  This application is a reference to Ferdinand E., filed May 21, 2014, which is incorporated herein by reference. K. Related to US patent application Ser. No. 14 / 281,904 (Attorney Docket No. 13-027-00-US) entitled “User Query and Gauge Reading Relationship” by de Antoni et al.

  As technology advances, computing technology has increased rapidly in more and more areas and prices have fallen. As a result, devices such as smartphones, laptops, GPS, etc. are prevalent in our society, thereby increasing the amount of data collected at unprecedented locations. Unfortunately, much of the information gathered is used for marketing and advertising to end users (for example, smartphone users receive nearby Starbucks coupons), while our social security bombs the Boston Marathon. It remains exposed to terrorist attacks like

JP 2009-219034

  Thus, for example, by detecting radiation and the like, a need has arisen for a solution that allows monitoring and collection of data from multiple sensors and management of multiple sensors to enhance the security of our society. Yes. Furthermore, there is a need to efficiently provide related information based on sensors to increase security.

  Embodiments can be implemented to visualize and analyze sensor data and to display sensor data and analysis in a meaningful way. Embodiments receive sensor data (eg, sensor measurements, sensor metadata, etc.) and receive sensor data (eg, sensor measurements, analyzed sensor data, a combination of sensor measurements and analyzed sensor data, etc.) Are configured to display received sensor data in an easy-to-understand format or format (eg, visually or on an external system) to direct attention to received sensor data that may be important. Embodiments implemented to filter received sensor data based on parameters, conditions, heuristics, or any combination thereof to visually enhance and report received sensor data that may be particularly important Is possible. Embodiments can determine how sensor measurements are related and sensor measurements related to reporting, thereby reporting sensor measurements that may be important as a group. It should be understood that the embodiments are described herein in the context of radiation detection and gamma ray detection for illustrative purposes only and are not intended to limit the scope.

  One embodiment is directed to a method for monitoring and managing sensors. The method includes receiving parameters defining an event and receiving data associated with the first sensor. In some embodiments, the data associated with the first sensor includes analyzed sensor data and metadata associated with the first sensor. The method includes determining whether an event has occurred based on data associated with the first sensor and displaying an indicator associated with the event in response to determining that the event has occurred. Is further included. In some embodiments, the method may further include receiving a selection of the first sensor via the graphical user interface and storing a portion of the metadata associated with the first sensor. Good. Part of the metadata may be part of the parameter.

  In some embodiments, the parameter is a radiation measurement range. In some embodiments, the parameter is selected from the group consisting of building name, floor level, room number, geospatial coordinates, distance from geographic location, and sensor device characteristics. In some embodiments, the parameter includes a distance between the first sensor and the second sensor. In some embodiments, the parameter further includes a time interval between the first sensor measurement from the first sensor and the second sensor measurement from the second sensor. The first sensor may be proximate to the second sensor. The parameter may be based on a moving speed of an object that has passed through the first sensor and the second sensor.

  Another embodiment is directed to a method for monitoring and managing sensors. The method includes receiving a plurality of parameters associated with the event and receiving data associated with the plurality of sensors. In some embodiments, the data associated with the plurality of sensors includes analyzed sensor data and metadata associated with the plurality of sensors. The method includes determining whether an event has occurred based on data associated with multiple sensors and multiple parameters associated with the event, and determining whether the event has occurred. Displaying an associated indicator. In some embodiments, the method includes receiving a selection of a set of sensors from the plurality of sensors via a graphical user interface, and converting some of the metadata associated with the set of sensors into an event. And storing as related parameters.

  In some embodiments, the plurality of parameters associated with the event includes a radiation threshold. In some embodiments, the plurality of parameters includes a distance between a first sensor and a second sensor of the plurality of sensors. In some embodiments, the plurality of parameters further includes a time interval between a first sensor measurement from the first sensor and a second sensor measurement from the second sensor. In some embodiments, the plurality of parameters includes a range of distances between a first sensor and a second sensor of the plurality of sensors. In some embodiments, the plurality of parameters associated with the event includes a moving speed of an object that has passed the first sensor and the second sensor of the plurality of sensors.

  Another embodiment is directed to a system for monitoring and managing sensors. The system includes a parameter module configured to receive conditions for defining an event and a data module configured to receive data associated with a plurality of sensors. The system includes an event determination module configured to determine whether an event has occurred based on data associated with a plurality of sensors, and a visualization configured to output an indicator based on the occurrence of the event. A module. The system may further include a messaging module configured to send an indicator associated with the event. In some embodiments, the condition associated with the event includes a set of measurements from multiple sensors that vary outside specified limits.

  These and various other features and advantages will become apparent upon reading the following detailed description.

The embodiments are described by way of illustration and not limitation in the figures of the accompanying drawings in which like reference numerals refer to like elements.
FIG. 1 illustrates an exemplary operating environment of an exemplary sensor-based detection system according to one embodiment. FIG. 2 shows an exemplary data flow diagram according to one embodiment. FIG. 3 shows an exemplary flow diagram of a process for representing data from a sensor, according to one embodiment. FIG. 4 shows an exemplary flow diagram of a process for representing data from multiple sensors, according to one embodiment. FIG. 5 illustrates a block diagram of an exemplary graphical user interface configured to display sensor related information having its respective geographic background, according to one embodiment. FIG. 6 illustrates a block diagram of an exemplary graphical user interface configured to create an event, according to one embodiment. FIG. 7 shows a block diagram of an exemplary graphical user interface configured to display alert information, according to one embodiment. FIG. 8 illustrates a block diagram of an exemplary graphical user interface operable to configure an event, according to one embodiment. FIG. 9 illustrates a block diagram of an exemplary graphical user interface configured to view event details according to one embodiment. FIG. 10 illustrates a block diagram of an exemplary graphical user interface operable to view an event activity log, according to one embodiment. FIG. 11 illustrates a block diagram of an exemplary graphical user interface operable to view sensor details associated with an event, according to one embodiment. FIG. 12 shows a block diagram of an exemplary graphical user interface configured to add event reservations, according to one embodiment. FIG. 13 shows a block diagram of an exemplary graphical user interface operable to configure an event reservation, according to one embodiment. FIG. 14 shows a block diagram of an exemplary graphical user interface configured to manage event reservations, according to one embodiment. FIG. 15 shows a block diagram of an exemplary graphical user interface configured to list event packages, according to one embodiment. FIG. 16 illustrates a block diagram of an exemplary graphical user interface configured to manage event packages, according to one embodiment. FIG. 17 shows a block diagram of an exemplary graphical user interface configured to send an event package, according to one embodiment. FIG. 18A shows a block diagram of an exemplary graphical user interface displaying event package communications, according to one embodiment. FIG. 18B shows a block diagram of an exemplary graphical user interface configured to display details of an event package, according to one embodiment. FIG. 19 illustrates a block diagram of an exemplary graphical user interface configured to view an activity log, according to one embodiment. FIG. 20 illustrates a block diagram of an exemplary graphical user interface including an exemplary event log entry, according to one embodiment. FIG. 21 shows a block diagram of an exemplary computer system according to one embodiment. FIG. 22 shows a block diagram of another exemplary computer system, according to one embodiment.

  Reference will now be made in detail to various embodiments, examples of which are illustrated in the accompanying drawings. While the claimed embodiments are described in connection with various embodiments, it will be understood that these various embodiments are not intended to limit the scope of the embodiments. On the contrary, the claimed embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the scope of the claims. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the claimed embodiments. However, it will be apparent to one skilled in the art that the claimed embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure aspects of the claimed embodiments.

  Some portions of the detailed descriptions that follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In this application, procedures, logic blocks, processes, etc. are considered to be a consistent sequence of operations or steps or instructions that lead to a desired result. An operation or step utilizes a physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system or computing device. Take. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as transactions, bits, values, elements, symbols, characters, samples, pixels, or the like.

  It should be borne in mind, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. As will be apparent from the following description, unless otherwise specified, throughout this disclosure, "receive", "convert", "transmit", "store", "determine", "send", "inquire" ”,“ Provide ”,“ access ”,“ associate ”,“ configure ”,“ activate ”,“ customize ”,“ map ”,“ change ”,“ analyze ”,“ display ” It should be understood that descriptions utilizing terms such as “update”, “reconfigure”, “resume”, etc. refer to the operations and processes of a computer system or similar electronic computing device or processing device. A computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities in computer system memory, registers or other such information storage, transmission or display devices.

  It should be understood that the present system and method can be implemented in a variety of architectures and configurations. For example, the present systems and methods can be implemented as part of a distributed computing environment, a cloud computing environment, a client server environment, etc. The embodiments described herein are generally referred to as computer-executable instructions on some form of computer-readable storage media, such as program modules, that are executed on one or more computers, computing devices, or other devices. Will be described. For example, but not limited to this example, computer-readable storage media may include computer storage media and communication media. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules can be combined or distributed as required in various embodiments.

  Computer storage media is non-transitory, volatile and non-volatile removable and non-volatile implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. Removable media can be included. Computer storage media include random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disc (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any that can be used to store and retrieve the desired information Other media may be included, but is not limited to this.

  Communication media can embody computer-executable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example, but not limited to this example, communication media can include wired media such as a wired network or direct-wired connection, and acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above can also be included within the scope of computer-readable storage media.

  Thus, there is a need for a solution that allows monitoring and collection of data from multiple sensors and management of multiple sensors to enhance the security of our society, for example, by detecting radiation, biohazards, etc. Has occurred. Furthermore, there is a need to efficiently provide related information based on sensors to increase security.

  Embodiments can be implemented to visualize and analyze sensor data and to display sensor data and analysis in a meaningful way. Embodiments receive sensor data (eg, sensor measurements, sensor metadata, etc.) and receive sensor data (eg, sensor measurements, analyzed sensor data, a combination of sensor measurements and analyzed sensor data, etc.) Are configured to display received sensor data in an easy-to-understand format or format (eg, visually or on an external system) to direct attention to received sensor data that may be important. Embodiments implemented to filter received sensor data based on parameters, conditions, heuristics, or any combination thereof to visually enhance and report received sensor data that may be particularly important Is possible. Embodiments can determine how sensor measurements are related and sensor measurements related to reporting, thereby reporting sensor measurements that may be important as a group. It should be understood that the embodiments are described herein in the context of radiation detection and gamma ray detection for illustrative purposes only and are not intended to limit the scope.

  FIG. 1 illustrates an exemplary operating environment according to one embodiment. Exemplary operating environment 100 includes a sensor-based detection system 102, a network 104, a network 106, a messaging system 108, and sensors 110-120. Sensor based detection system 102 and messaging system 108 are coupled to network 104. Sensor-based detection system 102 and messaging system 108 are communicatively coupled via network 104. Sensor based detection system 102 and sensors 110-120 are coupled to network 106. Sensor-based detection system 102 and sensors 110-120 are communicatively coupled via network 106. The networks 104, 106 may include two or more networks (eg, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), etc.) and are combinations of one or more networks including the Internet. Also good. In some embodiments, network 104 and network 106 may be a single network.

  Sensors 110-120 detect measurements associated therewith (eg, gamma radiation, vibrations, etc.) and communicate the information to sensor-based detection system 102 for analysis. The sensor-based detection system 102 uses the received information to determine whether a potentially dangerous event has occurred and uses it as a threshold (eg, past value, user selected value, etc.). Can be compared. Depending on the decision, the sensor-based detection system 102 may take appropriate action (e.g., send e-mail to appropriate personnel, sound an alarm, tweet an alarm, report to a police station, report to the Department of Homeland Security, etc. ) Can be communicated to the messaging system 108. Therefore, appropriate measures can be taken to avoid danger.

  The sensors 110 to 120 include thermal sensors (for example, temperature, heat, etc.), electromagnetic sensors (for example, metal detectors, optical sensors, particle sensors, Geiger counters, charge coupled devices (CCD), etc.), mechanical sensors (for example, It may be any of a variety of sensors, including tachometers, odometers, etc.), complementary metal oxide semiconductors (CMOS), biological / chemical sensors (eg, toxins, nutrients, etc.). The sensors 110 to 120 are further equipped with acoustic, sound, vibration, automobile / transport equipment, chemistry, electricity, magnetism, wireless, environment, weather, moisture, humidity, flow rate, flow velocity, ionization, atoms, nuclei, navigation, position, angle, Displacement, distance, velocity, acceleration, light, optical imaging, photon, pressure, force, density, level, thermal type, heat, temperature, proximity, presence, radiation, Geiger counter, crystal portal, biochemical, pressure, air It may be any or a combination of various sensors including, but not limited to, quality, water quality, fire, flood, intrusion detection, motion detection, particle count, water level, surveillance camera sensor, and the like. Sensors 110-120 may be video cameras (eg, internet protocol (IP) video cameras, network-coupled cameras, etc.) or dedicated sensors.

  The sensors 110 to 120 are fixed at a certain place (for example, a surveillance camera, a sensor, a camera, etc.) or semi-fixed (for example, on a mobile phone base station that is moved or fixed to another semi-moving body) Sensor) or mobile (eg, part of a mobile device, smart phone, etc.). Sensors 110-120 can provide data to sensor-based detection system 102 depending on the type of sensor 110-120. For example, the sensors 110-120 may be CMOS sensors configured for gamma radiation detection. The gamma radiation can, for example, illuminate the pixels, and the radiation is converted into an electrical signal and transmitted to the sensor-based detection system 102.

  The sensor based detection system 102 is configured to receive data and manage the sensors 110-120. The sensor-based detection system 102 is configured to assist a user in monitoring and tracking sensor measurements or levels at one or more locations. A sensor-based detection system 102 allows for easy deployment of new sensors (eg, by an administrator, operator, etc.) at a location, as well as sensors for detecting events based on user selection, rules of thumb, etc. It can have various components that allow monitoring. The event is further used by the messaging system 108 for appropriate personnel to take action (eg, sensor readings above a threshold for one sensor, two sensors within a certain proximity above the threshold). A sensor-based alarm can be generated (based on sensor measurements, etc.). The sensor-based detection system 102 can receive any data and manage any number of sensors that may be located in different geographical locations. In some embodiments, the sensors 110-120 and components of the sensor-based detection system 102 may be distributed across multiple systems (eg, physical computers, virtual machines, combinations thereof, etc.) and a large geographic area. it can.

  The sensor-based detection system 102 tracks and stores location information (eg, conference room B, floor 2, terminal A, etc.) and global positioning system (GPS) coordinates (eg, latitude, longitude, etc.) for each sensor or group of sensors. be able to. The sensor-based detection system 102 determines whether a prescribed event has occurred (eg, whether the detected radiation level exceeds a certain threshold, whether the detected biohazard level exceeds a certain threshold, etc.). Can be configured to monitor the sensor and track the sensor value, so that the sensor-based detection system 102 can detect the route or A route can be determined. For example, the path of travel of radioactive material relative to the stationary sensor can be determined and displayed via a graphical user interface. It should be understood that the path of travel of radioactive material for a mobile sensor (eg, smart phone, sensing device, etc.) or a mixture of stationary and mobile sensors can be similarly determined and displayed via a graphical user interface. It should be understood that the analysis and / or detection values can be displayed in real time or stored for later retrieval.

  The sensor-based detection system 102 can display a graphical user interface (GUI) for monitoring and managing the sensors 110-120. The GUI can be configured to indicate sensor measurements, sensor status, sensor placement on the map, and the like. The sensor-based detection system 102 can review past sensor measurements and the movement of the substance or condition detected by the sensor based on the stored sensor value stop, playback, pause, fast forward, and rewind functions Can be. The sensor-based detection system 102 also allows viewing of images or video images (eg, still images or videos) corresponding to sensors that have sensor measurements above a threshold (eg, based on a predetermined value or surrounding sensor measurements). Can be. For example, the sensor can be selected in the GUI and the video image associated with the area within the sensor's detection range can be displayed, allowing the user to see an individual or person transporting dangerous goods Become. According to some embodiments, the video is displayed in response to a user selection or automatically in response to a specific event (eg, a sensor measurement associated with a sensor or group of sensors having characteristics above a predetermined threshold). May be displayed automatically.

  In some embodiments, sensor readings of one or more sensors can be displayed in a graph or chart for easy viewing. A visual map-based display representing the sensor can be displayed with a sensor representation and / or an indicator that may include color coding, shape, icon, blink rate, etc. depending on the sensor measurements and specific events. For example, gray is associated with a calibration sensor; green is associated with a normal measurement from the sensor; yellow is associated with an elevated sensor measurement; orange is associated with a potentially dangerous sensor measurement; It may be related to hazard alarm sensor measurements.

  The sensor-based detection system 102 determines an alarm or sensor measurement that exceeds a specified threshold (e.g., predetermined, dynamic, or environmental) or based on a rule of thumb, and displays the alarm in a graphical user interface (GUI). ) Can be displayed. The sensor-based detection system 102 can allow a user (eg, operator, administrator, etc.) to group multiple sensors to create events related to multiple alerts from multiple sensors. For example, a red code event can be created when more than two sensors within 20 feet of each other and in the same physical space have sensor readings that are at least 40% greater than past values. In some embodiments, the sensor-based detection system 102 can automatically group the sensors based on the geographical proximity of the sensors (eg, gates 1, 2, 2 in terminal A at LAX airport). The three sensors can be grouped by their proximity to each other (eg, physical proximity in the same physical space), whereas sensors at different terminals differ in their location Therefore, it cannot be grouped. However, in certain situations, sensors within the same airport can be grouped to monitor events at the airport rather than at a more detailed level of terminals, gates, etc.

  The sensor-based detection system 102 can send information to the messaging system 108 based on a determination of an event created from information collected from the sensors 110-120. The messaging system 108 is a database (eg, messaging, SQL, or other database), a short message service (SMS), a multimedia message service (MMS), an instant message service, Twitter available on Twitter, San Francisco, California. One or more messaging systems, which may include trademark, extensible markup language (XML) based message service (eg, for communication with a fusion center), Javascript Object Notation (JSON) message service, etc. Or it can include a platform. For example, messaging that corresponds to the National Information Exchange Model (NIEM) is a government agency (eg, local, state, or federal government) that reports suspicious activity reports (SARs) in defense of chemical, biological, radioactive materials, and nuclear weapons (CBRN). Can be used to report to.

  FIG. 2 shows an exemplary data flow diagram according to one embodiment. Diagram 200 represents a flow of data (eg, sensor measurements, raw sensor data, analyzed sensor data, etc.) associated with a sensor-based detection system (eg, sensor-based detection system 102). The diagram 200 includes sensors 250 to 260, a sensor analysis process 202, a sensor process management unit 204, a data store 206, a state change management unit 208, and a sensor data expression module 210. In some embodiments, the sensor analysis process 202, sensor process manager 204, state change manager 208, and sensor data representation module 210 are one or more computing systems (eg, virtual or physical computing systems). Can be run on. The data store 206 may be part of the data warehouse or stored in the data warehouse.

  Sensors 250-260 may be substantially similar to sensors 110-120 and may be any of the various sensors described above. Sensors 250-260 may provide data to sensor analysis process 202 (eg, as camera stream data, video stream data, etc.).

  The sensor process manager 204 is configured to activate or initiate the sensor analysis process 202. The sensor process manager 204 can operate to configure each instance or process of the sensor analysis process 202 based on configuration parameters (eg, preset and configured by a user or the like). In some embodiments, the sensor analysis process 202 organizes sensor measurements over a specific time interval (eg, 30 seconds, 1 minute, 1 hour, 1 day, 1 week, 1 year) by the sensor process manager 204. Can be configured to. It should be understood that specific time intervals may be preset or user configurable. It should further be appreciated that certain time intervals may change dynamically (eg, during runtime) or statically. In some embodiments, the sensor analysis process 202 process may be performed for each time interval. The sensor process manager 204 may also be configured to access or receive metadata associated with the sensors 250-260 (eg, geospatial coordinates, network settings, user input information, etc.).

  The sensor process management unit 204 receives the analyzed sensor data from the sensor analysis process 202. The sensor process manager 204 can send the analyzed sensor data to the data store 206 for storage. The sensor process manager 204 can further transmit metadata associated with the sensors 250-260 for storage in the data store 206 along with associated analyzed sensor data. In some embodiments, the sensor process manager 204 can send the analyzed sensor data and metadata to the sensor data representation module 210. In some embodiments, the sensor process manager 204 sends the analyzed sensor data and metadata associated with the sensors 250-260 to the sensor data representation module 210. It should be understood that the information communicated from the sensor process manager 204 to the sensor data representation module 210 may be in a message-based format.

  In some embodiments, the sensor analysis process 202 can be sent to the data store 206 to store the analyzed sensor data. The sensor analysis process 202 can further transmit metadata associated with the sensors 250-260 for storage in the data store 206 along with associated analyzed sensor data.

  The state change manager 208 can access or receive the analyzed sensor data and associated metadata from the data store 206. The state change manager 208 can be configured to analyze sensor measurements for possible changes in the state of the sensor. In one embodiment, the state change manager 208 may receive the analyzed sensor data and / or associated metadata directly from the sensor analysis process 202 without having to retrieve information from the data store 206 (not shown). Please understand that you can.

  The state change management unit 208 can determine whether the state of the sensor has changed based on the current sensor data and the previous sensor data. Sensor changes based on sensor measurements that exceed a threshold inside or outside the range can be sent to the sensor data representation module 210 (eg, on a per sensor, per sensor group basis, etc.). For example, the state change of the sensor 252 is based on the sensor 252 changing from a previous normal measurement value to a rise measurement value (eg, above a certain threshold, within the rise measurement value, within the danger measurement value, etc.). Can be determined. In another example, the state of the sensor 250 can be determined not to change based on the sensor 252 having a rising measurement in the same range as the previous sensor measurement. In some embodiments, various sensor conditions and associated alarms can be configured by the sensor process manager 204. For example, the sensor process manager 204 can be used to configure thresholds, ranges, etc. that can be compared to sensor measurements to determine whether an alarm should be generated. For example, sensors 250-260 can have five possible states: calibration, normal, elevated, latent, warning, and dangerous. It should be understood that the configuration of the sensor process management unit 204 may be responsive to user input. For example, the user can set thresholds, ranges, etc. and conditions that match to generate an alarm. In some embodiments, a color can be associated with each state. For example, dark gray may be associated with a calibration condition, green may be associated with a normal condition, yellow may be associated with an elevated condition, orange may be associated with a latent condition, and red may be associated with an alarm condition. Light gray may be used to represent sensors that are offline or not functioning.

  In some embodiments, the state change manager 208 is configured to generate an alarm or alarm signal when there is a change in the state of the sensor to a new state. For example, an alarm can be generated for a sensor that goes from a normal state to a rising or latent state. In some embodiments, the state change manager 208 includes an active state table. The active state table can be used to store the current and / or previous state, whereby the active state table is maintained to determine sensor state changes. Therefore, the state change management unit 208 can provide real-time detection information based on the sensor state change.

  In some embodiments, the state change manager 208 determines whether sensor readings have exceeded normal sensor readings from surrounding sources or if there has been a change in sensor state and generates an alarm. be able to. For example, for gamma radiation, the state change management unit 208 may cause the gamma radiation sensor measurement to rise from a natural source (eg, the sun, another celestial body, etc.) or other natural environment source based on the standard sensor state, Whether from radioactive material being transported within range of the sensor can be determined based on potential, warning, or hazardous sensor conditions. In one exemplary embodiment, it is determined whether the gamma radiation measurement is within a safe range based on a standard sensor condition or out of a safe range based on an elevated, latent, warning, or dangerous sensor condition.

  In some embodiments, individual alerts can be sent to an external system (eg, messaging system 108). For example, one or more alerts that occurred in a particular building within a one minute, two minute, or ten minute time period can be sent to the messaging system. It should be understood that the time period during which the alarm is transmitted may be preset or selected by the system operator. In one embodiment, the time period during which the alarm is communicated can be set dynamically (eg, in real time) or statically.

  Sensor data representation module 210 can access or receive analyzed sensor data and associated metadata from sensor process manager 204 or data store 206. The sensor data representation module 210 can further receive an alarm (eg, on a sensor-by-sensor basis, a location-by-location basis, etc.) based on the sensor state change determined by the state change management unit 208.

  The sensor data representation module 210 is operable to display a graphical user interface representing sensors, sensor status, alarms, sensor measurements, and the like. When the sensor measurement value visually satisfies a specific condition on the map, for example, when the sensor measurement value exceeds the threshold, or when the sensor measurement value falls within a certain range, the sensor data expression module 210 sets the certain threshold. One or more alarms can be displayed that occur when the number falls below. Accordingly, the sensor data representation module 210 indicates that the sensor has met certain conditions, for example, that a biologically dangerous substance has been detected, high gamma radiation has been detected, etc. For example, an operator, a manager, etc.) can be notified visually or audibly. The user examines various data (eg, mSv value, biohazard indication level value, etc.) generated by the sensor analysis process 202 and data (eg, raw stream data) of the original sensor analysis process 202 that triggered the alarm. An opportunity to generate an appropriate event case file including converted stream data, pre-processed sensor data, etc.). The sensor data representation module 210 is used to obtain an awareness of any material moving within the monitored area (eg, radioactive material, biological hazardous material, etc.) or other situations occurring within the monitored area (eg, operator, Or by the administrator).

  In some embodiments, the sensor data representation module 210 includes a location function that can be used to geographically indicate sensors, alerts, and events. The location function can be used to draw various sensors at each location on a map in a graphical user interface (GUI). The GUI can allow a rich visual map with detailed floor plans at various zoom levels and the like. The sensor data representation module 210 can send sensor data, alerts, and events to a messaging system (eg, messaging system 108) for distribution (eg, other users, safety authorities, etc.).

  Alerts from one or more sensors can be grouped, aggregated, represented and / or displayed as an event. Thus, an event can be associated with one or more alerts from one or more sensors. An event can be determined based on conditions, rules, parameters, or heuristics applied to one or more alerts. For example, a single alarm can be a sensor measurement fluke or blip. However, if multiple alarms occur, it is likely that something more important has happened. For example, multiple alarms that occur within the same area or within a certain vicinity of each other or within a facility may indicate that dangerous goods are present in that area. In another example, five alarms that occurred within the last minute within the same building and on the same floor can be aggregated into one event. Events can be sent to an external system or highlighted on a graphical user interface.

  In some embodiments, an operator can mark an alarm or series of alarms as an “event”. The sensor data representation module 210 allows a user (eg, operator, administrator, etc.) to create, for example, a text block field, a mouse selection, a drop-down menu to create events related to multiple alerts from the selected sensor group. Etc., a plurality of sensors can be grouped. For example, a red code event can be created when more than two sensors within 20 feet of each other and in the same physical space have sensor readings that are at least 40% greater than past values. In some embodiments, the sensor-based detection system 102 can automatically group the sensors based on the geographical proximity of the sensors (eg, gates 1, 2, 2 in terminal A at LAX airport). The three sensors can be grouped by their proximity to each other (eg, physical proximity in the same physical space), whereas sensors at different terminals differ in their location Therefore, it is not grouped. However, in certain situations, sensors within the same airport can be grouped to monitor events at the airport rather than at a more detailed level of terminals, gates, etc. Other criteria may be used to group sensors and events, such as sensor type, sensor measurements, sensor proximity to other sensors, sensor location, common path of structures past sensors, etc. Should be further understood.

  Sensor representations (eg, icons, images, shapes, rows, cells, etc.) may be displayed on a map, and selections associated with events may be available. For example, five alarms can be displayed for five related sensors in a particular nearby range, and the operator can select five sensors (eg, via lasso tool selection, click and drag selection, click selection, etc. ) Select (eg, highlight, click, etc.) to group the sensors as an event. Alarms from five sensors can be displayed or transmitted as one event. 5 so that one event is triggered based on one or more sensors in a group of five sensors meeting a condition (eg, reaching a specific radiation level, exceeding a range of radiation measurements, etc.) A condition can also be applied to a group of two sensors.

  In some embodiments, the sensor data representation module 210 can automatically select a sensor associated with an event. For example, sensors within a 10 meter radius of each other in the same building can be automatically grouped so that alarms from the sensors are shown as one event.

  The sensor data representation module 210 provides one input via a graphical user interface as input that can be used by an operator, for example, to configure the sensor process manager 204 / state change manager 208 in determining an event. These conditions, parameters, or heuristics can be accessed or received. One or more conditions, parameters, or heuristics may be received via the graphical user interface of sensor data representation module 210, sensor process manager 204, state change manager 208. The sensor data representation module 210 determines whether an event has occurred based on the analyzed sensor data, sensor metadata, and one or more conditions, parameters, or heuristic evaluations (eg, comparisons, algorithms, etc.). be able to. For example, a sensor on a particular floor of a building can be selected as an event based on the sensor's associated location metadata.

  In another example, a parameter, condition, or heuristic may be used if the sensor metadata has a substantially similar value or is within a certain value range and / or the sensor is in a certain temporary time zone (eg, The sensor data may be associated within minutes or hours of analysis. Exemplary parameters include, but are not limited to, building name, floor level, room number, geospatial coordinates within a predetermined range (eg, distance between sensors, sensor proximity, etc.), sensor vendor, sensor type, sensor Characteristics, sensor configuration, and the like.

  The heuristic may include a geographic range (e.g., a sensor within a 20-30 meter range, a wider range, etc.) or may be based on travel time or distance between specific sensors. For example, if it usually takes 30 minutes for a person to pass through a checkpoint and any sensor in the checkpoint has an alarm condition at 1-minute or 30-minute intervals, heuristic-based events may be reported. it can. A 30 minute rise or alarm sensor condition may correspond to a particularly high radiation level that may deserve further investigation.

  The heuristic may further include the distance between the sensors and the proximity of the sensors. That is, heuristics may be based on sensor time, distance, and proximity. For example, two adjacent sensors can be separated from each other so that radioactive material does not actuate both sensors and a person moving through the sensors will take at least 10 minutes to walk beside both sensors. When far enough away, an associated event occurs when an alarm based on both sensors is generated in a specific order within 10 minutes.

  Events and associated parameters, conditions, etc. may be based on the geographical proximity of the sensor. Thus, an event can allow a user (eg, operator, administrator, etc.) to focus attention on a particular sensor in a particular area. Metadata associated with the sensor, including location etc., can be used for event determination. For example, a single sensor-based alarm can be caused by anomalies, background radiation, etc., whereas alarms from three, five, or seven sensors within 10 meters of each other are further analyzed Or it can indicate a dangerous condition (eg, dangerous goods, dangerous clouds, etc.) to which attention should be directed.

  An indicator can be output by the sensor data representation module 210 based on the determination that an event has occurred. In some embodiments, the indicator can be output visually, audibly, or via a signal to another system (eg, messaging system 108).

  In some embodiments, the event can be configured with parameters that specify where the event indicator should be sent. For example, the event indicator may be displayed in the GUI or sent to an external system (eg, messaging system 108).

  The indicator may be based on one or more alerts from one or more sensors, or an event based on alerts from multiple sensors. The event can be selected manually (eg, via a GUI, command line interface, etc.) or automatically (eg, based on an automatic grouping determined by the sensor-based detection system 102), or a heuristic It may be based. In some embodiments, indicators (eg, alerts, events, messages, etc.) can be output to a messaging system (eg, messaging system 108 or messaging module 214). For example, the indicator can be output to notify a person (eg, operator, administrator, sheriff, etc.) or group of people (eg, security department, police station, fire department, homeland security, etc.).

  The sensor data representation module 210 can have various tools to “play” after an event has occurred. The sensor data representation module 210 may further allow an operator to configure the sensor data representation module 210 to send an alarm to an external entity. For example, an operator can configure an XML interface to forward alerts and events to a local fusion center (eg, federal government, another government office, etc.). The operator can further configure an SMS gateway or even a Twitter account to send alerts or events.

  In some embodiments, the functionality of a sensor-based detection system (eg, sensor-based detection system 102) can be invoked in response to an event determination. For example, a message may be sent when determining the path of movement of a dangerous substance or condition, displaying a video related to sensor measurements, signaling an alarm, etc.

  FIG. 3 shows an exemplary flow diagram of a process for representing data from a sensor, according to one embodiment. FIG. 3 represents a process for determining an event based on parameters and data associated with a sensor.

  At block 302, parameters associated with the event are received. Parameters associated with the event can include one or more conditions, heuristics, etc. for evaluating one or more sensor alerts to determine whether the event has occurred. It should be understood that the parameters can be received via a graphical user interface and in response to user input. It should be further understood that in some embodiments, the parameters can be automatically received based on sensor information, eg, sensor type and model, sensor location, sensor range, sensor metadata, etc.

  At block 304, data associated with the sensor is received. The received data may be sensor data (eg, raw sensor data), analyzed sensor data, and / or sensor state change information (eg, alarm) as described above. As described above, metadata associated with the sensor can further be received (eg, from a data store, data warehouse, etc.).

  At block 306, it is determined whether an event has occurred. Whether an event has occurred can be determined based on receiving sensor-related data at block 304 and comparing the sensor-related data with the parameters received at block 302. For example, the parameter may be a checkpoint location in the airport, or an acceptable radiation indication threshold. An event can be determined to occur when an airport checkpoint sensor changes to a warning or dangerous state, eg, exceeds an acceptable radiation indication threshold or range.

  At block 310, a representation of data associated with the sensor is displayed. The representation can be related to the state of the sensor. For example, the icon representing a sensor can be updated from green associated with a standard sensor measurement to yellow associated with an elevation sensor measurement.

  At block 320, an indicator associated with the event is displayed. In some embodiments, an event-related indicator can be displayed as a pop-up window, such as a flashing or blinking sensor icon, in the status bar. The indicator may further be displayed in an alarm area (eg, alarm area 550 of FIG. 5) that displays information related to the alarm (eg, sensor data, analyzed data, and / or sensor metadata). In one embodiment, a representation of data associated with the sensor (eg, sensor measurements, raw sensor data, etc.) is displayed in an indicator associated with the event at block 320 regardless of the occurrence of the event (not shown). Can be displayed.

  At block 322, information related to the event is stored. In some embodiments, information related to the event is stored on a non-transitory medium. In some embodiments, a record of events may be created and stored that may include time information, sensor location information, sensor data, analyzed sensor data, sensor metadata, or any combination thereof.

  In optional block 330, a sensor selection is received. In some embodiments, the sensor can be selected via a representation (eg, icon) of the sensor in a graphical user interface. For example, a sensor can be selected at block 330 and the user is prompted to enter information to create an event associated with the selected sensor at block 302.

  In optional block 332, a portion of the metadata associated with the sensor is stored as a parameter associated with the event. For example, a sensor at an airport checkpoint can be selected and metadata associated with the sensor, including location (eg, longitude and latitude), can be stored as parameters associated with the event. The position parameter can be used to determine whether other sensors in a particular proximity of the selected sensor have entered an alarm state before reporting the event.

  FIG. 4 shows an exemplary flow diagram of a process for representing data from multiple sensors, according to one embodiment. FIG. 4 represents a process for determining an event based on a plurality of parameters and data associated with a plurality of sensors.

  At block 402, a plurality of parameters associated with the event are received. The plurality of parameters associated with the event can include one or more conditions, heuristics, etc. for evaluating one or more sensor alerts to determine whether the event has occurred, as described above. . It should be understood that multiple parameters can be received via a graphical user interface and in response to user input. It should be further appreciated that in some embodiments, the plurality of parameters can be automatically received based on sensor information, eg, sensor type and model, sensor location, sensor range, sensor metadata, and the like.

  At block 404, data associated with a plurality of sensors is received. The received data may be sensor data (eg, raw sensor data), analyzed sensor data, and / or sensor state change information (eg, alarm) as described above. As described above, metadata associated with multiple sensors can be further received (eg, from a data store, data warehouse, etc.).

  At block 406, it is determined whether an event has occurred. Whether an event has occurred may be determined based on receiving data associated with the plurality of sensors at block 404 and comparing the data associated with the plurality of sensors with the plurality of parameters received at block 402. . For example, the plurality of parameters may be checkpoint locations and distance ranges within the airport. An event is determined to occur when multiple sensors at airport checkpoints within a predetermined distance range change to an alarm state, eg, exceed acceptable radiation indication thresholds, ranges, etc.

  At block 410, one or more representations of data associated with the plurality of sensors are displayed. A representation can be associated with multiple sensor states. For example, icons representing multiple sensors can be updated from green associated with standard sensor measurements to yellow associated with elevated sensor measurements.

  At block 420, an indicator associated with the event is displayed. In some embodiments, an event-related indicator can be displayed as a pop-up window, such as a flashing or blinking sensor icon, in the status bar. The indicator may further be displayed in an alarm area (eg, alarm area 550 of FIG. 5) that displays information related to the alarm (eg, sensor data, analyzed data, and / or sensor metadata). In one embodiment, a representation of data associated with the sensor (eg, sensor measurements, raw sensor data, etc.) is displayed in an indicator associated with the event at block 420 regardless of the occurrence of the event (not shown). Can be displayed.

  At block 422, information related to the event is stored. In some embodiments, information related to the event is stored on a non-transitory medium. In some embodiments, a record of events may be created and stored that may include time information, sensor location information, sensor data, analyzed sensor data, sensor metadata, or any combination thereof.

  In optional block 430, a selection of a set of sensors from the plurality of sensors is received. In some embodiments, the set of sensors can be selected via a representation (eg, icon) of the sensors in the graphical user interface. For example, at block 430, a sensor can be selected by drawing a box around the sensor, and the user is prompted to enter information to create an event associated with the selected sensor at block 402. .

  In optional block 432, a portion of the metadata associated with the set of sensors is stored as a plurality of parameters associated with the event. For example, multiple sensors at an airport checkpoint can be selected, and any metadata associated with the sensor can be stored as parameters associated with the event, including location (eg, longitude and latitude). The position parameter can be used to determine whether other sensors within a particular proximity or distance range of the selected sensor have entered an alarm state before reporting the event.

  FIG. 5 illustrates a block diagram of an exemplary graphical user interface configured to display sensor related information having its respective geographic background, according to one embodiment. The exemplary graphical user interface (GUI) 500 includes a recognition button 502, an event menu 504, a management menu 506, a user icon 508, a location area 510, a geographic background area 538, and an alert area 550. .

  The recognition button 502 may operate to invoke a graphical user interface display that may include a location area 510, a geographic background area 538, and an alert area 550. The event menu 504 can be used to invoke an event related graphical user interface (eg, FIGS. 8-19). The management menu 506 can be used to invoke access to management functions for configuring visualization of sensor data and graphical user interface configuration. User icon 508 is configured to access user-related functions (eg, logout, preferences, etc.). In some embodiments, the user icon 508 can include a username (eg, an email address).

  The location area 510 can be used to select, search, and save locations. The location area 510 may include a location search area 520, a sensor list-up area 530, a saved location search area 540, a saved location button 542, a saved location selection button 544, and a saved location delete button 546.

  The location search area 520 allows for searching for locations within a sensor-based detection system (eg, sensor-based detection system 102). Locations may be created and configured via the management component of the sensor-based detection system, and each may have one or more sensors.

  The sensor listing area 530 can display a hierarchical diagram of locations, sensors, and time intervals associated with the sensors. The sensor listing area 530 can further include a sensor status indicator that indicates a sensor status based on sensor measurements (eg, as described above). The sensor list-up area 530 can list each location in an organization, for example, an office building, a warehouse, an airport, or a manufacturing site.

  The saved location search area 540 may allow selection of a location that was just selected and saved (eg, a drop-down menu or other graphical user interface element). The location can be saved for quick or direct access by an operator to categorize the location. In some embodiments, the user can select any number of locations and give the selected location a unique name that can be used for filtering. In some embodiments, a user may be able to add or delete locations via a drag and drop function on a map displayed on a graphical user interface.

  The save location button 542 can save the location to be saved in a save location list (eg, accessible via the save location area 540). The save position selection button 544 can be used to select a save position to be displayed in the position list area 530. The save position delete button 546 can be used to delete a save position from the save position area 540.

  The geographic background area 538 can be used to display one or more sensors in a geographic background (eg, a map, satellite image, combinations thereof, etc.). Geographic background area 538 includes sensor icons 514-518 and legend 548. Each of the sensor icons 514-518 can represent a sensor, and can be visually represented in a color based on the sensor state (eg, as described above). The sensor icons 514 to 518 can represent the aggregate number of sensors. For example, sensor 514 may be an aggregation of five different sensors, but can be represented as one by a zoom-out function on the map. Sensor icons 514-518 can be selected and, depending on the selection, additional sensors including sensor measurements (eg, in mSV), time intervals, sensor status based on time intervals, metadata associated with the sensor, etc. Information can be displayed.

  Legend 548 can be used to represent the color coding used for sensor icons 514-518. In some embodiments, each entry in the legend may be selectable to remove a particular alarm condition sensor from the map. For example, a user (eg, operator, administrator, etc.) can remove a sensor that is in an inactive state (eg, light gray).

  Alarm area 550 can be used to display alarm information. In some embodiments, the alert information includes the alert location (eg, gate and terminal), time interval, and timestamp.

  FIG. 6 illustrates a block diagram of an exemplary graphical user interface configured to create an event, according to one embodiment. FIG. 6 represents an exemplary graphical user interface (GUI) for creating an event, configuring parameters associated with the event, and selecting sensors associated with the event. An exemplary graphical user interface (GUI) 600 includes an event name area 602, an event save button 604, an event delete button 606, a cancel button 608, a parameter type column 610, a parameter property column 612, and a management column 614. And an exemplary parameter 620, a parameter addition button 622, a sensor list area 630, a sensor addition button 634, a sensor deletion button 636, and a selected sensor area 640. In some embodiments, the exemplary graphical user interface 600 can be displayed in response to selection of an event creation menu item in the event menu 504.

  The event name area 602 can be used for entry and editing of names assigned to events (eg, displayed as name labels 1024, stored in a data store, etc.). The save event button 604 can be used to invoke a function that saves events and associated event data. In some embodiments, the event data can include parameters related to the event and selected sensors as configured via the graphical user interface 600.

  The delete event button 606 can be used to delete an event and / or delete an event via the graphical user interface 600, partially or fully. A cancel button 608 can be used to cancel the configuration of the event via the graphical user interface 600. In some embodiments, another graphical user interface (eg, graphical user interface 900, graphical user interface 500, etc.) may be displayed in response to activation of cancel button 608.

  Exemplary parameters 620 can be displayed by a parameter type column 610, a parameter characteristics column 612, and a management column 614. Parameter type column 610 is configured to display various types of parameters that may include conditions, rules, heuristics, and the like. In some embodiments, parameter types include, but are not limited to, range, value, or proximity or distance. The parameter characteristic column 612 is configured to display parameter characteristics that can define parameters related to the event based on an evaluation on sensor data (eg, raw sensor data, analyzed sensor data, sensor metadata, etc.). . For example, exemplary parameter characteristics of range parameters may include a range of 300 mSv to 900 mSv. In another example, an exemplary parameter characteristic of the value parameter may be 1 Sv (or 1000 mSv) or higher. In another example, exemplary parameter characteristics of proximity parameters may be sensors within 50 meters, sensors in the same location, etc. It should be understood that the embodiments are described herein in the context of radiation detection and gamma ray detection for illustrative purposes only and are not intended to limit the scope.

  The management column 614 can be used to display buttons or other elements for managing parameters and parameter characteristics. In some embodiments, the management column 614 includes an edit button 624 and a delete button 626. The edit button 624 is configured to allow the user to edit the event's parameter type and parameter characteristics (eg, configure range, value, and proximity characteristics). Delete button 626 is configured to allow the user to delete a parameter from the event.

  The add parameter button 622 is configured to add a parameter to the event. The sensor list area 630 is configured to display a list of one or more sensors. The selected sensor area 640 can be used to display a list of one or more sensors selected in the sensor area 630 and added to the selected sensor area 640 via the add sensor button 634. The add sensor button 634 is configured to allow the addition of one or more sensors to the event, and the sensor is displayed in the selected sensor area 640 accordingly. The delete sensor button 636 is configured to allow deletion of one or more sensors from the event and selected sensor area 640.

  Elements of the exemplary graphical user interface 600 having the same reference numbers as the exemplary graphical user interface 500 perform functions substantially similar to those described herein with respect to the exemplary graphical user interface 500. Can do.

  FIG. 7 shows a block diagram of an exemplary graphical user interface configured to display alert information, according to one embodiment. The exemplary graphical user interface (GUI) 700 represents an alert 712 selected from an alert area (eg, alert area 550). The example GUI 700 can include an alert log area 702 and a selected alert area 720.

  The alarm log area 702 can be used to display alarm information (eg, by a red alarm icon). In some embodiments, the alert information includes the alert location (eg, gate and terminal), time interval, and timestamp. Thus, the alarm log area 702 can provide an overview of the displayed alarm (eg, on a map, satellite image, etc.). Each of the alarms in the alarm log area 702 may be selectable.

  The selected alarm area 720 can include alarm information displayed in the alarm log area 702 along with three icons 724, 734 and 736. The first icon 724 can create an event based on the selected alert in the selected alert area 720. The second icon 734 can visually represent an alert (eg, on the geographic background area 738). The third icon 736 can delete an alarm from the alarm log area 702. Embodiments can assist in creating an event based on a selection of multiple alerts.

  FIG. 8 illustrates a block diagram of an exemplary graphical user interface operable to configure an event, according to one embodiment. An exemplary graphical user interface (GUI) 800 includes a start time area 802, an end time area 812, a record number per page selector 822, a search area 834, a select all button 836, a deselect all button 838, A location column 842, a sensor name column 848, a previous button 858, an existing event addition button 866, and a new event creation button 868 are included.

  The start time area 802 can be used to configure the start time of an event (eg, when the event becomes active). The end time area 812 can be used to configure the end time of the event.

  In some embodiments, the end time area 812 and the end time of the event may be arbitrary. An event without an end date / time may be unrestricted and the user can add further alerts to the event when the alert occurs.

  The record number per page selector 822 is configured to set the number of records to be displayed per page. In some embodiments, each record can be associated with a sensor or alert. Search area 834 is configured to invoke a search for sensors to display and can be used for selection. In some embodiments, a sensor with an alarm can be searched.

  Select all button 836 can be used to select each of the sensors displayed via location column 842 and sensor name column 848. Deselect all button 838 can be used to deselect each of the sensors displayed via location column 842 and sensor name column 848. Location column 842 can be used to display a location associated with the sensor displayed in sensor name column 848. The sensor name column 848 can be used to display a name associated with the sensor. In some embodiments, the sensor name column 848 is labeled as an RST name or a radiation sensor terminal name.

  The previous button 860 can be used to access the previous set of sensors based on the records per page selector 822. Next button 858 can be used to access the next set of sensors based on record number per page selector 822. Add Existing Event button 866 can be used to add the selected sensor to an existing event. The create new event button 868 can be used to invoke creation of an event, and the event can view all event menu items via the event menu 504.

  FIG. 9 illustrates a block diagram of an exemplary graphical user interface configured to view event details according to one embodiment. FIG. 9 represents a graphical user interface (GUI) for viewing an event ticket associated with an event. An event ticket is an object associated with an event that has a life cycle and has characteristics that include a status. Event tickets can be used to track events and to assign events to one or more organizational units (eg, provinces or people). The exemplary GUI 900 includes an event ticket label 912, a new event 918, a record number per page selector 914, a key column 921, a name column 922, a status column 923, a creation column 924, an update column 925, It includes a close column 926, a start time column 927, an end time column 928, an action column 929, a next button 930, and a previous button 932.

  The event ticket label 912 can be used to indicate that one or more event tickets are being displayed. New event button 918 can be used to create a new event ticket. The record number per page selector 914 can be used to set the number of event tickets displayed per page. Key column 921 can be used to display a key or unique identifier associated with the event ticket. The name column 922 can be used to display the name of the event ticket (eg, the name of the event). The status column 923 can be used to display the status of the event ticket. In some embodiments, the status can be set to open, closed, pending, or in progress. Creation column 924 can be used to display the date / time that the event ticket was created. Update column 925 can be used to display the date / time the event ticket was most recently updated.

  Close column 926 can be used to display the date / time that the event ticket was closed. The start time column 927 can be used to display the start time of the event associated with the event ticket. The end time column 928 can be used to display the end time of the event associated with the event ticket. The action column 929 can be used to display actions (eg, buttons, drop-down items, etc.) associated with the event ticket. In some embodiments, the action column includes a log display button that can be used to invoke the display of the event log, and an indication of the event, for example, sensor measurements leading to the occurrence of the event and the rewind of each analyzed data. And a rewind button that can be used to call.

  The previous button 932 can be used to access the previous page of the event ticket based on the record number per page selector 914. The Next button 930 can be used to access the next page of the sensor's event set based on the record number per page selector 822.

  Elements of the exemplary graphical user interface 900 having the same reference numbers as the exemplary graphical user interface 500 perform functions substantially similar to those described herein with respect to the exemplary graphical user interface 500. Can do.

  FIG. 10 illustrates a block diagram of an exemplary graphical user interface operable to view an activity log, according to one embodiment. An exemplary graphical user interface (GUI) 1000 includes an event label 1001, a name label 1024, a description area 1012, an activity log button 1002, a package button 1004, a sensor time segment button 1006, and an alarm event reservation button 1008. A status area 1010, a record number per page selector 1022, an add log button 1028, a search area 1038, a date column 1032, a user column 1034, a comment column 1036, a previous button 1046, and a next button 1048 including.

  The event label 1001 can be used to indicate an event displayed by the exemplary GUI 1000 and the key or other identifier of the associated log entry. The name label 1024 can be used to indicate the name of the event for which the associated log entry is being displayed. The description area 1012 can be used to display a description of the event. Activity log button 1002 can be used to invoke the display of activity log entries associated with the event (eg, as shown in FIG. 9). Package button 1004 can be used to invoke the display of a GUI (eg, FIG. 15) associated with the event package. The sensor time segment button 1006 can be used to invoke a display of a graphical user interface (eg, FIG. 11) associated with the sensor time segment. The alarm event reservation button 1008 can be used to invoke a display of a GUI (eg, FIG. 12) associated with an event reservation. The status area 1010 can be used to display the status information of the event ticket. In some embodiments, the status area 1010 includes event ticket status, event ticket creation date / time, event update date / time, event start date / time, event end date / time, and event ticket closure. And a close button that can be used.

  The record number per page selector 1022 is configured to set the number of event log records to be displayed per page. In some embodiments, each event log record is associated with an activity (eg, creation, configuration, update) associated with the event. The add log button 1028 can be used to add a log entry or record (eg, see FIGS. 19-20) associated with the event. For example, the user can enter a custom log entry with or without a custom comment message. Search area 1038 can be used to search for log records associated with the event.

  Date column 1032 can be used to display the date of the log record associated with the event. User column 1034 can be used to display users associated with the event ticket activity. For example, a user can be assigned to an event ticket, while other users can perform activities related to the event ticket, such as changing the event ticket status, adding custom messages, and the like. Comment column 1036 can be used to display comments or notes associated with the event ticket. The previous button 1046 can be used to access the previous set of event log records on the number of records per page selector 1022. Next button 1048 may be used to access the next set of event log records based on the record number per page selector 1022.

  Elements of the exemplary graphical user interface 900 having the same reference numbers as the exemplary graphical user interface 500 perform functions substantially similar to those described herein with respect to the exemplary graphical user interface 500. Can do.

  FIG. 11 illustrates a block diagram of an exemplary graphical user interface operable to view sensor details associated with an event, according to one embodiment. An exemplary graphical user interface (GUI) 1100 represents a GUI for displaying time segments associated with an event ticket. The exemplary graphical user interface 1100 includes a records per page selector 1122, a search area 1118, a sensor column 1132, a start column 1124, an end column 1125, an adder column 1126, an additional date column 1127, an action It includes a column 1128, a time segment row 1102, a delete button 1138, a previous button 1146 and a next button 1148. An event can include multiple sensor time segments. A time segment is the length of time during which sensor data (eg, raw sensor data, analyzed sensor data, sensor metadata, etc.) is stored or associated with an event. For example, an event may have two time segments, one time segment associated with a pre-event sensor and the other time segment associated with a post-event sensor. The time segment can be selected by the user. In some embodiments, the operator can add or delete time segments as desired. In some embodiments, the time segment end date / time may be arbitrary, and events without end date / time are considered unlimited.

  The record number per page selector 1122 is configured to set the number of time segment records to display per page. Search area 1118 can be used to search for sensor time segments associated with the event ticket. The sensor column 1132 can be used to display a sensor identifier (eg, name, MAC address, etc.). The start column 1124 can be used to display the start time of the sensor time segment associated with the event ticket. The end column 1125 can be used to display the end time of the sensor time segment associated with the event ticket.

  The adder column 1126 can be used to display users who have added time segments to the event ticket. Added date column 1127 can be used to display the date / time that the time segment was added to the event ticket. The action column 1128 can be used to display actions associated with the event time segment. Time segment row 1102 includes data corresponding to columns 1124-1132. In some embodiments, the time segment row 1102 can include a delete button 1138 that can be used to delete a time segment from an event (eg, or event ticket, other event tracking object, etc.). The previous button 1146 can be used to access the previous set of time segments associated with the event ticket based on the records per page selector 1122. Next button 1148 can be used to access the next set of time segments associated with the event ticket based on the records per page selector 1122.

  Elements of exemplary graphical user interface 1100 that have the same reference numbers as exemplary graphical user interface 500 and exemplary graphical user interface 1000 are described herein with respect to exemplary graphical user interface 500 and exemplary graphical user interface 1000. Functions similar to those described in the document can be performed.

  FIG. 12 shows a block diagram of an exemplary graphical user interface configured to add event reservations, according to one embodiment. An exemplary graphical user interface (GUI) 1200 represents a GUI for display of alarm event reservations. In some embodiments, additional time segments can be added (eg, automatically, dynamically, etc.) through an alarm event reservation. The exemplary GUI 1200 includes an add reservation button 1228, the number of records per page 1222, a search area 1218, a rule column 1232, a start column 1224, an end column 1225, a creator column 1226, and a creation date column 1227. , Action column 1238, previous button 1246, and next button 1248.

  The reservation addition button 1228 can be used to call up a display of a GUI for adding a new reservation (for example, FIG. 13). The number of records per page selector 1222 is configured to set the number of alarm event reservations to display per page. Search area 1218 can be used to search for alarm event reservations. The rule column 1232 can be used to display one or more rules associated with the alarm event reservation. The start column 1224 can be used to display the start date and time associated with the alarm event reservation. The end column 1225 can be used to display the end date / time associated with the alarm event reservation. Creator column 1226 can be used to display the user or entity that created the alert event reservation. Creation date column 1227 can be used to display the date / time that the alarm event reservation was created. The action column 1238 can be used to display the action (eg, delete) that will be performed on the displayed alarm event reservation. The previous button 1246 can be used to access a previous set of alert event reservations associated with an event ticket based on the records per page selector 1222. Next button 1248 can be used to access the next set of alert event reservations associated with the event ticket based on the records per page selector 1222.

  Elements of exemplary graphical user interface 1200 having the same reference numbers as exemplary graphical user interface 500 and exemplary graphical user interface 1000 are described herein with respect to exemplary graphical user interface 500 and exemplary graphical user interface 1000. Functions similar to those described in the document can be performed.

  FIG. 13 shows a block diagram of an exemplary graphical user interface operable to configure an event reservation, according to one embodiment. An exemplary graphical user interface (GUI) 1300 represents a GUI for configuring event reservations. The exemplary GUI 1300 includes a start date area 1302, an end date area 1312, a reservation rule area 1322, a cancel button 1326, and a save button 1328.

  The start date area 1302 can be used to set the start date and / or time of the alarm event reservation. The end date area 1312 can be used to set the end date and / or time of the alarm event reservation. The end date and / or time of the alarm event reservation may be arbitrary. The reservation rule area 1322 can be used to select rules related to events and associated alarm event reservations. In some embodiments, the reservation rule area 1322 includes a rule selector area 1324. In some embodiments, a rule listing area 1338 may be displayed in response to selection of the rule selector area 1324. The rule listing area 1338 may display a list of rules 1358 and may include a search area 1348 that can be used to search for rules. Cancel button 1326 can be used to invoke the display of an alarm event reservation. Save button 1328 can be used to save a rule reservation for an event ticket.

  FIG. 14 shows a block diagram of an exemplary graphical user interface configured to manage event reservations, according to one embodiment. An exemplary graphical user interface (GUI) 1400 represents the GUI after creation of an alarm event reservation (eg, via FIG. 13). The exemplary GUI 1400 includes an alert event reservation line 1402 and a delete button 1404.

  The alarm event reservation line 1402 can be used to display the characteristics of the alarm event reservation. As shown, the alert event reservation row 1402 includes the values of the delete button 1404 in the rule column 1232, the start column 1224, the creator column 1226, the creation date column 1227, and the action column 1238. As described above, the end column 1225 is indicated by a blank value because there is no limit for alarm event reservation. The delete button 1404 can be used to call a function for deleting an alarm event reservation in the alarm event reservation line 1402.

  The elements of the exemplary graphical user interface 1400 having the same reference numbers as the exemplary graphical user interface 500, the exemplary graphical user interface 1000, and the exemplary graphical user interface 1200 are the exemplary graphical user interface 500, Functions similar to those described herein with respect to the exemplary graphical user interface 1000 and the exemplary graphical user interface 1200 may be performed.

  FIG. 15 shows a block diagram of an exemplary graphical user interface configured to list event packages, according to one embodiment. An exemplary graphical user interface (GUI) 1500 represents a GUI for browsing information related to event packages. Packages can be created for each event. The package can be used for decision purposes and contains raw sensor data from each sensor time segment. The exemplary GUI 1500 includes a create package button 1508, a record number per page selector 1522, a search area 1518, a file column 1523, a start column 1524, an end column 1526, a status column 1527, an action column 1538, A previous button 1546 and a next button 1548 are included.

  A package creation button 1508 can be used to call a function for creating an event package or a determination package. In some embodiments, this functionality may include the ability to communicate to a sensor process manager (eg, sensor process manager 204) to collect raw sensor data related to the time segment of the event. The sensor process manager can collect, package, and create data available for download or access. A package is a collection of any combination of sensor-based system information for a purpose. Objectives can include later searches, lessons, decisions, criminal prosecution, litigation, and the like.

  The record number per page selector 1522 is configured to set the number of event package entries to display per page. Search area 1518 can be used to search for event packages. File column 1523 can be used to display one or more file names associated with the event package. The start column 1524 can be used to display the start date / time of the event package (eg, the start of sensor-based information related to events in the event package).

  The end column 1526 can be used to display the end date / time of the event package (eg, the end of sensor-based information associated with the event in the event package). Status column 1527 can be used to display the status of the event package. In some embodiments, the status column 1527 may have a status value “package” for a substantially completed event package or a status value “in progress” for an event package that is in progress.

  Action column 1538 may be used to display options associated with the package. In some embodiments, the options may include viewing event package details or sending the event package (eg, via email, file transfer, etc.). The previous button 1546 can be used to access a previous set of event packages associated with an event ticket based on the records per page selector 1522. Next button 1548 can be used to access the next set of event packages associated with the event ticket based on the records per page selector 1522.

  Elements of exemplary graphical user interface 1500 having the same reference numbers as exemplary graphical user interface 500 and exemplary graphical user interface 1000 are described herein with respect to exemplary graphical user interface 500 and exemplary graphical user interface 1000. Functions similar to those described in the document can be performed.

  FIG. 16 illustrates a block diagram of an exemplary graphical user interface configured to manage event packages, according to one embodiment. An exemplary graphical user interface (GUI) 1600 represents the exemplary GUI after creation of the event package. The exemplary GUI 1600 includes an event package row 1602 and an action button 1648.

  Event package row 1602 can be used to display the characteristics of the event package. As shown, event package row 1602 includes values for file column 1522, start column 1524, end column 1526, status column 1527, and action column 1538. The action column 1538 includes a function for viewing event package details and a button 1648 for initiating other actions.

  Exemplary graphical user interface 500, exemplary graphical user interface 1000, and elements of exemplary graphical user interface 1600 having the same reference numbers as exemplary graphical user interface 1500 include exemplary graphical user interface 500, exemplary Functions similar to those described herein with respect to the exemplary graphical user interface 1000 and the exemplary graphical user interface 1500 may be performed.

  FIG. 17 shows a block diagram of an exemplary graphical user interface configured to send an event package, according to one embodiment. An exemplary graphical user interface (GUI) 1700 represents further actions including sending an event package. The exemplary GUI 1700 includes a send package option 1748 and a send package window 1750.

  A part of the action button 1648 can be selected, and a package transmission menu item 1748 is displayed. A send package menu item 1748 can be used to invoke display of the package window 1750. The send package window 1750 can be used to invoke sending an event package to an email address or some other destination / location (eg, file server, archive system, etc.). Package send window 1750 includes an email address area 1758, a cancel button 1766, and a save button 1768. The email address area 1758 can be used to enter and edit email addresses. Save button 1768 can be used to invoke the sending of the event package to the location entered in email address area 1758. A cancel button 1766 can be used to invoke display of an event package GUI (eg, FIG. 16). It should be understood that sending event packages via email is exemplary and non-limiting. For example, an event package can send faxes, print, display, etc.

  FIG. 18A shows a block diagram of an exemplary graphical user interface displaying event package communications, according to one embodiment. An exemplary graphical user interface (GUI) 1800 represents an email with an event package link. The exemplary GUI 1800 includes an email subject 1802, sender and recipient information 1804, and a message 1806. Email subject 1802 may include a key or other identifier associated with the event. Sender and recipient information 1804 can indicate the sender and recipient of the email. The message 1806 can include an event name and a link to the event package (eg, a hyperlink, a file transfer protocol (FTP) link), which allows the recipient to download the event package.

  FIG. 18B shows a block diagram of an exemplary graphical user interface configured to display details of an event package, according to one embodiment. An exemplary graphical user interface (GUI) 1830 represents package details including the person to whom the package was sent. In some embodiments, the exemplary GUI 1830 may be displayed in response to selection of a detail display option in the action column 1438. The exemplary GUI 1830 includes a package detail 1838, a record number per page selector 1822, a search area 1818, a send date column 1852, a sender column 1854, a destination column 1856, a previous button 1846, and a next button 1848. And a close button 1878.

  Package details 1838 include package status (eg, sent, not sent, in progress, etc.), package filename, event package start date / time, event package end date / time, creation date / time, creator (Eg, user name, email address, etc.), last update date / time, and updater (eg, username, email address, etc.).

  The record number per page selector 1822 is configured to set the number of event package transmission records to be displayed per page. A search area 1818 can be used to search for event package details.

  The sent date column 1852 can be used to display the date / time the event package was sent. The sender column 1854 can be used to display the sender (eg, user name, email address, etc.) who sent the event package. The destination column 1856 can be used to display the destination (eg, user name, email address, etc.) to which the event package or pointer to the event package (eg, link) was sent.

  The previous button 1846 can be used to access the previous set of event package details based on the records per page selector 1822. Next button 1848 can be used to access the next set of event package details based on the records per page selector 1822. A close button 1878 can be used to close the exemplary graphical user interface 1830.

  FIG. 19 illustrates a block diagram of an exemplary graphical user interface configured to view an activity log, according to one embodiment. An exemplary graphical user interface (GUI) 1900 can be displayed in response to the selection of an add log button 1028 that allows a user to add a custom log message.

  The exemplary GUI 1900 includes a new event log window 1950. New event log window 1950 includes a custom message area 1958, a cancel button 1966, and a save button 1968. Custom message area 1958 can be used to enter and edit text or other information to be added to the event log. The save button 1968 can be used to invoke saving data in the custom message area 1958 to the activity log associated with the event. A cancel button 1966 can be used to close the new event log window 1950.

  Elements of exemplary graphical user interface 1800 that have the same reference numbers as exemplary graphical user interface 500 and exemplary graphical user interface 1000 are described herein with respect to exemplary graphical user interface 500 and exemplary graphical user interface 1000. Functions similar to those described in the document can be performed.

  FIG. 20 illustrates a block diagram of an exemplary graphical user interface including an exemplary event log entry, according to one embodiment. FIG. 19 illustrates an exemplary event log that can include automatic event log entries (eg, generated by the sensor-based detection system 102) and custom log entries (eg, created via the new event log window 1950). Represents an entry. The exemplary graphical user interface (GUI) 2000 includes a date column 1032, a user column 1034, a comment column 1036, and exemplary log entries 2002-2012.

  The example log entry 2002 shows an example custom message log entry (eg, created via the new event log window 2050). The example log entry 2004 shows an example status change log entry (eg, event status change from open to decision). The example log entry 2006 shows an example package send log entry (eg, sent via the example graphical user interface 1700). The example log entry 2008 shows an example package creation log entry (eg, created via the package creation button 1508). The example log entry 2010 shows an event occurrence log entry (eg, when one or more alerts meet an event parameter, condition, rule, or heuristic). The example log entry 2012 shows an example event creation log entry (eg, created via the example graphical user interface 800).

  Elements of the exemplary graphical user interface 2000 having the same reference numbers as the exemplary graphical user interface 900 perform functions substantially similar to those described herein with respect to the exemplary graphical user interface 900. Can do.

  Referring to FIG. 21, a block diagram of an exemplary computer system according to one embodiment is shown. With reference to FIG. 21, exemplary system modules for implementing the above embodiments, eg, the embodiments described in FIGS. In some embodiments, the system includes a general purpose computing system environment, eg, computing system environment 2100. The computing system environment 2100 includes, but is not limited to, servers, desktop computers, laptops, tablets, mobile devices, and smartphones. In its most basic configuration, the computing system environment 2100 generally includes at least one processing unit 2102 and a computer readable storage medium 2104. Depending on the exact configuration and type of the computing system environment, the computer-readable storage medium 2104 may be volatile (eg, RAM), non-volatile (eg, ROM, flash memory, etc.) or some combination of the two. At runtime, portions of computer readable storage medium 2104 facilitate monitoring and management of sensors and sensor analysis processes (eg, processes 300-400) according to the above embodiments.

  Further, in various embodiments, the computing system environment 2100 may have other features / functions. For example, the computing system environment 2100 may include additional storage devices (removable and / or non-removable), including but not limited to magnetic or optical disks or tapes. Such additional storage devices are illustrated by removable storage 2108 and non-removable storage 2110. Computer storage media includes volatile and non-volatile removable and non-removable media implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. Computer readable media 2104, removable storage 2108 and non-removable storage 2110 are all examples of computer storage media. Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, extended memory (eg, USB stick, compact flash card, SD card), CD-ROM, digital versatile disc (DVD) Or any other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other medium that can be used to store desired information and that is accessible by the computing system environment 2100 However, it is not limited to this. Any type of computer storage media can be part of the computing system environment 2100.

  In some embodiments, the computing system environment 2100 can further include a communication connection 2112 that can cause it to communicate with other devices. Communication connection 2112 is an example of a communication medium. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and acoustic, radio frequency (RF), infrared, and other wireless media. The term computer readable media as used herein includes both storage media and communication media.

  Communication connection 2112 includes Fiber Channel, Small Computer System Interface (SCSI), Bluetooth (registered trademark) (Bluetooth), Ethernet (registered trademark), Wi-Fi (Wi-Fi), Infrared Communication Association Standard (IrDA), local area network ( LAN, wireless local area network (WLAN), wide area network (WAN) such as the Internet, serial, and universal serial bus (USB) to communicate the computing system environment 2100 over a variety of network types be able to. The various network types to which the communication connection 2112 connects are: Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), Real Time Transport Protocol (RTP), Real Time Transport Control Protocol (RTCP), It should be understood that a number of network protocols can be implemented, including but not limited to File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP).

  In further embodiments, the computing system environment 2100 includes a keyboard, mouse, terminal or terminal emulator (all directly connected or remotely accessible via Telnet, SSH, HTTP, SSL, etc.), pen It can also have an input device 2114 such as a voice input device, a touch input device, a remote control and the like. Also included are output devices 2116 such as displays, terminals or terminal emulators (all directly connected or remotely accessible via telnet, SSH, HTTP, SSL, etc.), speakers, LEDs, etc.

  In one embodiment, computer readable storage medium 2104 includes a sensor based detection module 2120. The sensor based detection module 2120 is configured for monitoring and managing a plurality of sensors and associated analysis (eg, sensor based detection system 102). The sensor base detection module 2120 includes a sensor measurement value expression module 2122. The sensor measurement value representation module 2122 is configured to manage the collection, reporting, and display of sensor measurement values.

  The sensor measurement representation module 2122 includes a parameter module 2124, a data module 2126, an event determination module 2128, a visualization module 2130, and a messaging module 2132. The parameter module 2124 is configured to receive one or more conditions, rules, parameters, and heuristics to define an event as described above. The condition associated with the event may include a set of measurements from multiple sensors that vary outside specified limits. Data module 2126 is configured to receive data associated with a plurality of sensors. The event determination module 2128 is configured to determine whether an event has occurred based on data related to the plurality of sensors and conditions related to the event, as described above. The visualization module 2130 is configured to output an indicator based on the occurrence of an event. The messaging module 2132 is configured to send an indicator associated with the event (eg, to the messaging system 108).

  Referring now to FIG. 22, a block diagram of another exemplary computer system according to some embodiments is shown. FIG. 22 represents a block diagram of a computer system 2200 suitable for implementing the invention. The computer system 2200 includes a central processing unit 2214, a system memory 2216 (generally RAM, but also including ROM, flash RAM, etc.), main subsystems of the computer system 2200 such as an input / output controller 2218, and an audio output interface 2222. An external audio device such as a speaker system 2220 via a display adapter, a display screen 2224 via a display adapter 2226, serial ports 2228 and 2230, a keyboard 2232 (interfaced with the keyboard controller 2233), a storage interface 2234, and a floppy disk 2238. A floppy disk unit 2236 that functions to accept and a home that functions to connect to the Fiber Channel network 2260. A bus adapter (HBA) interface card 2235A, a host bus adapter (HBA) interface card 2235B that functions to connect to a small computer system interface (SCSI) bus 2236, an optical disk drive 2240 that functions to accept an optical disk 2242, etc. A bus 2212 connected to an external device is included. Also, mouse 2227 (or other point and click device coupled to bus 2212 via serial port 2228), modem 2246 (coupled to bus 2212 via serial port 2230), and network interface 2248 (bus 2212). Directly coupled to).

  It should be understood that the network interface 2248 includes, but is not limited to, one or more Ethernet ports, a wireless local area network (WLAN) interface, and the like. The system memory 2216 includes a sensor measurement representation module 2250 configured to manage the collection of sensor measurements, the reporting of sensor measurements, and the display of sensor measurements. According to one embodiment, the sensor measurement representation module 2250 can include other modules (eg, the modules of FIG. 21) for performing various tasks. It should be understood that the sensor measurement representation module 2250 may be located anywhere in the system and is not limited to the system memory 2216. Thus, being in system memory 2216 is merely illustrative and is not intended to limit the scope of the embodiments. For example, each part of the sensor measurement value representation module 2250 may be in the central processing unit 2414 and / or the network interface 2248, but is not limited thereto.

  Bus 2212 includes central processing unit 2214 and, as described above, system memory 2216 which may include read only memory (ROM) or flash memory (both not shown) and random access memory (RAM) (not shown). Enables data communication with the. The RAM is generally a main memory into which an operating system and application programs are loaded. ROM or flash memory can include a basic input / output system (BIOS) that controls basic hardware operations, such as interaction with peripheral components, among other codes. Applications resident in computer system 2200 are typically stored on a computer readable medium, such as a hard disk drive (eg, fixed disk 2244), optical drive (eg, optical drive 2240), floppy disk unit 2236, or other storage medium. Accessed through it. Further, the application may be in the form of an electronic signal that is modulated according to the application and data communication techniques when accessed via the network modem 2246 or the network interface 2248.

  The storage interface 2234 can be connected to a standard computer readable medium for storing and / or retrieving information, such as a fixed disk device 2244, similar to other storage interfaces of the computer system 2200. Fixed disk device 2244 may be part of computer system 2200, and may be separate and accessed through other interface systems. The network interface 2248 can provide a composite connection with a network device. Furthermore, the modem 2246 can provide a direct connection to a remote server via a telephone link or to the Internet via an Internet Service Provider (ISP). Network interface 2248 provides one or more connections to a data network that may include any number of other network connection devices. Network interface 2248 may provide such connections using wireless technologies including digital mobile telephone connections, cellular digital packet data (CPDP) connections, digital satellite data connections, and the like.

  Many other devices or subsystems (not shown) can be connected in a similar manner (eg, document scanners, digital cameras, etc.). Conversely, not all of the apparatus shown in FIG. 22 need be present to implement the present invention. Devices and subsystems can be interconnected in different ways than shown in FIG. Code for implementing the invention may be stored on one or more of computer readable storage media, such as system memory 2216, fixed disk 2244, optical disk 2242, or floppy disk 2238. The operating system provided on the computer system 2200 is MS-DOS (registered trademark), MS-WINDOWS (registered trademark), OS / 2 (registered trademark), UNIX (registered trademark), Linux (registered trademark), or others. Operating system.

  Further, with respect to the signals described herein, the signal can be transmitted directly from the first block to the second block, or the signal can be modified between blocks (eg, amplified, attenuated, delayed, latched, buffered). Will be understood by those skilled in the art. While the signals of the above-described embodiments are depicted as being transmitted from one block to the next, other embodiments of the present invention are as long as the information and / or functional aspects of the signal are communicated between the blocks. , May include a modified signal instead of such a directly transmitted signal. To some extent, the signal input at the second block is due to physical limitations of the circuits involved (eg, there will necessarily be some attenuation and delay), so the first signal from the first block. It can be conceptualized as a second signal obtained from the output. Thus, as used herein, the second signal derived from the first signal is subject to circuit constraints or other circuit elements that do not change the information and / or final functional aspects of the first signal. It includes the first signal or any modification to the first signal, whether for the passage through.

  The foregoing description has been described with reference to specific embodiments for illustrative purposes. However, the illustrative description above is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching.

Claims (20)

Receiving a parameter defining the event;
Receiving data associated with the first sensor;
Determining whether the event has occurred based on data associated with the first sensor;
Displaying an indicator associated with the event in response to determining that the event has occurred.   The method of claim 1, wherein the parameter is a radiation measurement range.   The method of claim 1, wherein the data associated with the first sensor includes analyzed sensor data and metadata associated with the first sensor. Receiving a selection of the first sensor via a graphical user interface;
The method of claim 1, further comprising storing a portion of metadata associated with the first sensor, wherein the portion of metadata is part of the parameter.   The method of claim 1, wherein the parameter is selected from the group consisting of building name, floor level, room number, geospatial coordinates, distance from geographic location, and sensor device characteristics.   The method of claim 1, wherein the parameter includes a distance between the first sensor and a second sensor.   The method of claim 6, wherein the parameter further comprises a time interval between a first sensor measurement from the first sensor and a second sensor measurement from the second sensor.   The method of claim 7, wherein the first sensor is proximate to the second sensor.   9. The method of claim 8, wherein the parameter is based on a moving speed of an object that has passed the first sensor and the second sensor. Receiving a plurality of parameters associated with the event;
Receiving data relating to a plurality of sensors;
Determining whether the event has occurred based on data associated with the plurality of sensors and the plurality of parameters associated with the event;
Displaying an indicator associated with the event in response to determining that the event has occurred.   The method of claim 10, wherein the data associated with the plurality of sensors includes analyzed sensor data and metadata associated with the plurality of sensors. Receiving a selection of a set of sensors of the plurality of sensors via a graphical user interface;
11. The method of claim 10, further comprising storing a portion of metadata associated with the set of sensors as the parameters associated with the event.   The method of claim 10, wherein the plurality of parameters associated with the event includes a radiation threshold.   The method of claim 10, wherein the plurality of parameters includes a distance between the first sensor and a second sensor of the plurality of sensors.   The method of claim 14, wherein the plurality of parameters further includes a time interval between a first sensor measurement from the first sensor and a second sensor measurement from the second sensor. .   The method of claim 10, wherein the plurality of parameters includes a distance range between a first sensor and a second sensor of the plurality of sensors.   The method of claim 10, wherein the plurality of parameters associated with the event include a moving speed of an object that has passed through a first sensor and a second sensor of the plurality of sensors. A parameter module configured to receive a condition for defining an event;
A data module configured to receive data associated with a plurality of sensors;
An event determination module configured to determine whether the event has occurred based on the data associated with the plurality of sensors;
A visualization module configured to output an indicator based on the occurrence of the event.   The system of claim 18, wherein the condition associated with the event includes a set of measurements from the plurality of sensors that vary outside specified limits.   The system of claim 18, further comprising a messaging module configured to transmit an indicator associated with the event.

Images