US10678611B2 - Facility monitoring sensor - Google Patents

Abstract

A facility monitoring system and application receives and interprets readings from multiple sensors for determining a condition, alert or alarm and initiating appropriate notifications. Low-cost, deployed sensors detect or receive a parameter pertaining to a condition in a physical space, such as temperature, electric flow, or an open door. A channel to a remote monitoring server or application receives and reports the reading via a user accessible GUI (graphical user interface). A compound or aggregate value is computed from multiple channels based on readings from a plurality of sensors, thus allowing reporting of conclusory conditions based on several related readings, rather than a single scalar sensor value that imposes a burden on the user to deduce or investigate other related sensor readings. A GUI receives aggregation processor defining computations to be performed on readings from the multiple sensors, and alert processor defining conditions and alerts representative of issues requiring attention.

Description

BACKGROUND

For decades, homes and businesses have relied on so called “burglar alarms” and fire alarms for passive security and protection. Modern evolutions include the mandate of smoke and fire alarms, and intrusion detection has evolved to include wireless interconnections and selective access controls. Further, the proliferation of computing hardware often imposes a substantial equipment investment within a business facility. Modern businesses have outgrown conventional fire and intrusion protection. In a business with substantial computing resources, for example, water from fire sprinklers would cause greater damage than the fire they are intended to abate. Modern facility monitoring systems have evolved to collect a variety of parameters relating to a facility, including not only fire and perimeter aspects, but environmental factors such as humidity, temperature and ventilation, thus consolidating the conventional systems that define a facility infrastructure.

SUMMARY

A facility monitoring system, device and application receives and interprets readings from multiple sensors for determining a condition, alert or alarm and initiating appropriate notifications and/or responses. Low-cost, deployed sensors detect or receive a parameter pertaining to a condition in a physical facility space, such as temperature, electric flow, or an open door. A channel to a remote monitoring server or application receives and reports the reading via a user accessible GUI (graphical user interface). A compound or aggregate value is computed from multiple channels based on readings from a plurality of sensors, thus allowing reporting of computed or conclusory conditions based on several related readings, rather than a single scalar sensor value that imposes a burden on the user to deduce or investigate other related sensor readings.

In contrast to conventional approaches, where reporting applications merely pass through sensed values on a one-to-one association with a sensor channel, the disclosed approach defines relations and computations for aggregating multiple sensed values into an aggregate value, and delivers an additional channel having the aggregate value. An aggregation processor defines the computations to be performed on readings from the multiple sensors, and an alert processor defines conditions and alerts representative of issues requiring attention.

Configurations herein are based, in part, on the observation that modern facility monitoring and management systems have a variety of sensors and input devices from which to gather data about conditions in the monitored space. A universal approach to sensor deployment allows a combination of sensors limited only by the number of input connections available on a monitor base. Unfortunately, conventional approaches to facility monitoring suffer from the shortcoming that the monitoring sensors typically provide only raw, unidimensional or scalar data. There is no analysis or interpretation available to identify trends, inferences or conclusions which may be drawn based on multiple sensors. Further, modern Internet connectivity propagates these unitary data items to remote monitoring personnel, who may be compelled to make a determination and possibly an on-site visit based only on a single rogue reading.

Accordingly, the approach discussed below substantially overcomes the shortcomings of conventional facility monitoring systems by defining an aggregate sensor capability that integrates readings from multiple sensors according to aggregation logic defined and computed by the aggregation processor, and then compares the aggregate value according to alert logic before triggering an alarm or indicating an anomaly. Conventional systems merely relay an assortment of monitored sensor readings, leaving it up to the facilities manager, or perhaps a more junior “on-call” person, to draw conclusions about an underlying cause. The disclosed approach, in contrast, coalesces multiple readings to provide a conclusive problem indication, rather than a single blind reading. For example, a high HVAC delivery temperature might point to equipment overheating or even a fire. However, an HVAC health reading that computes the difference between HVAC input and output might reveal that the HVAC is not cooling effectively, narrowing the problem to HVAC efficiency rather than computing appliance overheating. The novel aggregate sensor functionality provides a compound or composite value derived from the multiple, aggregated sensors but treated as an individual sensor value for subsequent readings and alerts.

In a particular configuration as disclosed herein, a method of gathering sensor data from a conditioned space includes identifying a plurality of sensors for monitoring the facility environment, such that each sensor is adapted to detect and transmit a sensed value indicative of the facility environment. A series of channels provides the sensor data to a remote monitoring server (server) that handles sensor data from multiple sites. The server receives data on channels, stores data on each channel for historical reference, and for select channels, evaluates received data for certain values. Typically, key channels are monitored for values outside of a normal range, and an alert is triggered when the channel exhibits deviant or notable values. Not all channels are monitored for alerts, however, and may simply be stored.

An aggregate channel may be created for combining values from two or more channels into a new channel having an aggregate value, effectively defining an aggregate sensor. Such aggregate channels may be evaluated and logged as any other channel. Further, as disclosed in configurations herein, additional logic or computations may be associated with the aggregate channel based on the constituent channels from which the aggregate channel is defined. An aggregation processor identifies aggregate channels that are defined based on other channels, and computes or determines the aggregate values.

Any of the channels may also be evaluated for alerts. An alert is based on a value from a channel deviating from a prescribed value or range. An alert criteria specifies a channel and normal or expected values for that channel. Upon evaluation and detection of a channel value outside its expected norms, an alert is triggered. The alert may be an audible alarm, an automated call to support staff, an automated equipment instruction, such as to close a valve or unlatch a door, or other suitable remedial action. Since the channels, and not specific sensors, are evaluated for alerts, the alert processing does not need to inquire as to whether a channel carries unitary or aggregate values. Channels may even be aggregated from other aggregate channels, allowing a nesting or layering of the aggregate channels and corresponding values.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1 is a context diagram of a monitored facility environment suitable for use with configurations herein;

FIG. 2 shows an aggregation processor for sensors ofFIG. 1;

FIG. 3 shows a logic flow within the aggregation processor ofFIG. 1;

FIG. 4 shows operation of an alert processor in the monitoring server ofFIG. 1;

FIG. 5 shows computation of an aggregate value using the aggregation processor;

FIG. 6 shows definition of an aggregate sensor using an aggregate function;

FIG. 7 shows definition of an aggregate sensor using a condition rule;

FIG. 8 shows a report of aggregate values and conditions as inFIG. 7;

FIG. 9 shows definition of an alert based on values as inFIG. 8; and

FIG. 10 shows a historical report of aggregate and sensed values.

DETAILED DESCRIPTION

Configurations below depict an example implementation of a facility and facility infrastructure suitable for use with configurations herein. Alternate facility arrangements may be employed, in accordance with the principals and advantages of the disclosed approach.

Afacility environment100 may be any suitable enclosed structure such as offices, warehouses, transportation sites, apartments and residential units, and home dwellings. Often the facility environment (facility)100 is characterized by common ownership entity such as a corporation. At least portions of thefacility100 include machine rooms having computing hardware and related network appliances, with different and/or more specific monitoring and sensing needs than inhabitable conditioned spaces. Thefacility100 also often has a well-defined and continuous perimeter with discreet entry and exit portals or passages such as doors and windows.

Thefacility environment100 deploys various sensors110-A . . .110-C (110 generally) such as temperature, humidity, portal closure/entry, ventilation flow, electric/current flow, motion or any other sensor operable for responsiveness to an environmental or facility infrastructure condition. In a particular configuration, the sensors may be those operable in conjunction with the Room Alert line of products, marketed commercially by AVTECH Software of Warren, R.I.

A typical monitoring environment includes a monitored facility (facility)100, an on-site monitor130 with connections to thesensors110 in thefacility100, and a monitoring server150 in remote communication with thefacility100, as well as other facilities. In theexample facility100 ofFIG. 1, the sensors include a door110-A, ambient temperature110-B and HVAC outflow temperature110-C (110 generally).Sensors110 may also monitor other aspect, such asventilation fans104,HVAC equipment106, and other equipment and fixtures, and a typically facility may have many more sensors than the presented example. In operation, theonsite monitor130 periodically receives a reading from eachsensor110 via a respective local connection112-A . . .112-C (112 generally). Themonitor130 transmits amessage132 for each reading112 via a channel140-A . . .140-D (140 generally) assigned to acorresponding sensor110. Any number of sensor readings may be included in themessage132, depending on a polling rate of thesensor110 and a transmission rate from themonitor130. The monitoring server150 is configured to launch and execute applications for receiving parameter values from each of thechannels140, such as application programs from AVTECH as discussed above. The monitoring server150 also has a Graphical User Interface (GUI)application160 conversant with thenetwork134 for remote user interaction via a mobile device.

Uponmessage132 arrival at the monitoring server150, amessage parser210 parses themessage132 into values with timestamps and determines channels140-A,140-B and140-C (140 generally) corresponding to therespective sensor110. Since thesensors110 may have different cycles for reading values, themessage132 may have any number of values corresponding to thechannels140. An ID in the message denotes the sensor and channel.

In the server150, anaggregation processor220 identifies and computes the aggregate channels, and analert processor240 performs comparisons of the channels with conditions deemed to warrant further action. The values from each of the channels are also stored in a repository defined by apersistent storage medium230 for historical reports, statistics and trending. Aggregate channels populated by theaggregation processor220 appear as any other channel to thealert processor240. Thealert processor240 only maintains channels and criteria indicative of significant deviations, and need not distinguish whether a channel carries a sensed or derived (aggregate) value.

Theaggregation processor220 includesaggregation logic162 indicative ofchannels140 used in determination of aggregate channels, discussed further below inFIG. 2. While theaggregation processor220 receives and may examine allchannels140′-A . . .140′-C, based on counterparts140-A . . .140-C, it will only retrieve those included in computation of an aggregate channel. For channels that contribute to an aggregate computation (140′-B,140′-C), theaggregation logic162 defines anaggregate rule225. Other channels that carry only sensor values (140′-A) may be ignored222 by theaggregation processor220. Theaggregation processor220 computes and provides channel140-D, which progresses to thealert processor240 andstorage medium230 with other channels140-A . . .140-C.

Alerts may be configured for any channel value. An alert refers to an indication and action resulting from a channel having a value triggering an alert criteria, typically a value outside normal, expected operation ranges. An alert criteria is configurable via theGUI160, discussed further below. An alert is an optional set of instructions associated with achannel140 for proactive response to values on that channel. In the example shown, channel140-D has analert rule245 configured. Thealert processor240 filters input channels based on a list of configured alerts and decides whether anyalert rule245 is met on a given channel value at a given time. Not all channels need contribute to alert processing, as they may be merely stored for historical queries and reference. All input channels with no alerts configured242 will be ignored by thealert processor240. Once analert rule245 for a specific channel140-D is met, the alert processor performs alert actions configured for the alert. Alert actions can be a variety of actions taken by thealert processor240 once the alert rule evaluate true, such as sending an email246-A to a manager, sending a text message246-B via phone, or sending an http post message to a web API, discussed further below.

Polling and reading are typically handled by the on-site monitor130. For each of the configuredsensors110, achannel140 is defined for receiving the sensed value from themonitor130. At the periodic interval, the monitoring server150 receives, from themonitor130 at the facility, readings from each configuredsensor110 at thefacility100. It should be noted that the monitoring server150 is typically coupled to a plurality ofindividual monitors130 on-site at various facilities under the oversight of the monitoring server150.

FIG. 2 is an illustration of a more detailed configuration of theaggregation processor220. Referring toFIGS. 1 and 2, theaggregation processor220 may contain any suitable number of aggregate rules225-A . . .225-B (225 generally). Each rule is comprised of one or more inputs and typically one output. The inputs can include sensed readings or readings calculated from other rules. In this example, the aggregate rule225-A takes values of channels140-B and140-C as input and after applying theaggregate logic162, it produces an output value for channel140-D. Aggregate rule225-B takes the new channel140-D and received channel140-X values as its inputs and calculates the channel value for140-E. In this example,Input data222 by channel140-A, are ignored by theaggregation processor220 as there are no aggregate rules using that input data at this time. Both values140-D, and140-E, alongside original values140-A,140-B,140-C and140-X will be persisted instorage medium230, as well as being processed by thealert processor240. It should be noted that channel140-D illustrates a calculated channel being used as input for another calculated channel resulting in channel140-E. The output from theaggregation processor220 merges with the stream of channels emerging from theparser210 such that thealert processor240 andstorage medium230 require no modifications as they seamlessly continue to process channels.

Within theaggregation processor220, theaggregation logic162 stores rules that define the aggregate channels and the computations used to derive them. For aggregation processing, theaggregation processor220 maintains a set or list of the channels received by theparser210 that are included in aggregation rules. For eachchannel140′ received, theaggregation processor220 determines if it is employed in an aggregate channel computation. If so, the channel value is retained along withothers140′ for computing the aggregate channel. When a new aggregate channel is computed, such as140-D, it is further evaluated to determine if it is invoked in an aggregation rules, such as225-B. In this manner, theaggregation processor220 evaluateschannels140 to determine if they contribute to any of the aggregate rules225-A . . .225-N, and are ignored222 if unused. This logic is formalized inFIG. 3 below.

FIG. 3 consolidates the logic flow within theaggregation processor220. Referring toFIGS. 1 and 3, when amessage132 is received by the monitoring server150 as illustrated inFIG. 1, theaggregation processor220 receives a list of all channels that have new sensed data from thefacility100, as depicted at step302. Theaggregation processor220 then searches for all aggregate rules225-N that are associated with the incoming channel readings, as shown atstep304. Instep306, if the search did not find any aggregate rules, the logic flow ends. Otherwise, control passes to step308 where new readings are calculated based on the aggregate rules found instep304. A list of channels with the new readings is then prepared instep310 and control passes back to step304. The logic flow repeats until there are no aggregate rules associated with the last set of newly calculated readings. After theaggregation processor220 logic flow has ended, all the newly created channel readings fromstep308 are passed on to thestorage medium230 and thealert processor240.

Aggregate rules provided in theaggregation processor220 include three types of rules:

Aggregate Functions.

Condition.

Custom Formula.

The aggregate function type allows a user input indicative of an aggregate function to apply to all input values as a list, such as average, sum, min or max. With the condition type, the user input may specify a value comparison test for each input. (>, <, =). The user will also specify which Boolean operations should be used to combine the results into a single Boolean value. The condition type will always produce a Boolean output value. For the custom formula type, user input is received for generating a custom mathematical formula to describe the aggregate rule for the channel. When evaluated, the aggregate rule will apply the input values to the custom formula to produce the new output value. Further details about generation and formation of user input is discussed below with reference to the GUI. Other suitable arrangements for deriving aggregate channels may be performed by identifying a range of output values and a manner of determination based on a plurality of channels.

FIG. 4 illustrates an example scenario of thealert processor240. Referring toFIGS. 1 and 4, thealert processor240 may have any number of alert rules. Each alert rule accepts at least one channel reading as input, and one or more actions to perform. Thealert processor240 searches for alert rules that define conditions based on currently received channel values. Once matches are found, alert rule245-A processes channel140-B values and if conditions specified in the alert are met it sends an email246-A and a text message246-B. Similarly, alert rule245-B receives channel140-D's value and if the condition holds true, it fires an http post action246-C accordingly. In this example there are no alerts configured for140-A or140-C, so the values are ignored242 byalert processor240.

Thealert processor240 evaluates allchannels140 for which alerts have been configured, and does not discriminate between aggregate and single-sensed values. In many instances, alerts may not be configured for channels if the values contained on those channels are for diagnostic or informational purposes, and would not represent an exigent situation even at an extreme value. Generally, alerts look to a value of a single channel and a condition specifying an alert criteria. If multiple values contribute to an alert criteria, the individual channels concerned are first defined as an aggregate channel, and the alert criteria specified in terms of the values on the aggregate channel. Any suitable response action may be specified. Email, text, and post commands are employed as examples of notification, but invocation of apps or other entity could also be performed.

FIG. 5 shows an example computation of a time-differentiated sequence of aggregate values using theaggregation processor220. Referring toFIGS. 1 and 5, history logs510-1 . . .510-3 (510 generally) reside on thestorage medium230 and, for each of 3channels140, store a sequence of times and parameter values. Logs510-1 and510-2 are sensed values from themonitor130, whileaggregation processor220 computes the stream of aggregate values for log510-3.

FIG. 6 shows definition of an aggregate sensor using an aggregate function for defining theaggregation logic162 in theaggregation processor220. Referring toFIGS. 1 and 6, ascreen180 on a rendering device receives, via theGUI160, an operation and one or more parameter values for employed in computation of the aggregate value. Definition of the aggregate value therefore includes receiving, from a GUI (Graphical User Interface), commands for defining the aggregation processor for each of the aggregate values, such that the commands include an indication of the sensor readings and channels used for computing the aggregate value, and operations to be performed on the sensor readings (e.g. average, sum, difference, etc.). Theaggregation processor220 defines a new channel for the result to be returned as the aggregate sensor value. Thenew channel140 is therefore defined as the result of application of the aggregation processor using the sensed values defining the selected parameter values.

Aname602 defines a mnemonic label, such as “temp delta.” Aselection bullet604 indicates aggregate rule type selection, “Aggregate” in the example shown. Afunction606 defines the operation to be performed on thechannels140, and a pulldown608 specifies the existingchannels140 to be used for the selected operation. Thefunction606 andchannels608 may vary with the other aggregate rule types. An aggregate rule, such as min, max, average and sum, accepts an arbitrary number of input channels and applies thefunction606 specified. A condition type (FIG. 7, below) returns a Boolean true or false result, and requires binary values (two channels or a channel and a constant) and a binary operator (<, >, =, !=). A computation type employs mathematical operations for computing a numerical result. Other suitable approaches may be employed for defining the aggregate channel output based on input channels. Anoutput type610 specifies the new channel, for both reporting and usage in other aggregate rules. A numeric temperature value is shown; other channels may carry Boolean or other numeric types.

FIG. 7 shows definition of an aggregate sensor using a condition rule. A condition rule defines a comparison of values for generating a Boolean value that may be evaluated for an alert, discussed below. Aname field704 receives a mnemonic designator for the aggregate sensor value. Thebullet list604 is selectable for a “condition” definition for this aggregate sensor. Acondition702 defines logical comparisons, and may include any suitable condition expression, which may be expressed as a sequence of conjunctive and/or disjunctive associations. The result is a new aggregate sensor that provides a value of true or false which may be subsequently evaluated by thealert processor240.

Thebullet list604 may include various options for defining an aggregate sensor. The computation selection allows mathematical operations to be performed on channel values for rendering the aggregate sensor channel. Other suitable approaches may be employed for aggregating the channels, such as a script, launchable app., or other instructions for computing an aggregate value based on a plurality of the sensor readings received from the channels.

FIG. 8 shows a report of aggregate values and conditions as inFIG. 7.FIG. 8 reflects the aggregate values defined inFIGS. 6 and 7 as a sensor and channel that may be employed for conditions and alerts. Aline item802 denotes an aggregate sensor as reflecting an average temperature, as defined inrendering screen180.Line item804 denotes the “High temp AC failed” channel defined inscreen182.

FIG. 9. shows definition of an alert rule. In this example, the alert is based on the aggregate sensor defined in the example ofFIG. 7. InFIG. 9, the alert indicates a responsive action to take. Referring toFIGS. 1, 7 and 9, the sensor selection pulldown fields902 reflect the sensor to be used as input for the alert rule. Acondition field904 defines the condition or threshold that will trigger the alert. In this example, the condition “Closed” indicates that the threshold value for the input sensor “High Temp AC Has Failed” is “true”. For numeric conditions (e.g. equalities and range comparisons) additional drop downs are provided. The responsive action fields906 receives entry ofresponsive steps246, such as emailing a manager or staff member on-call to address the situation. Multiple and/or alternative responsive actions may by incurred, such as calling or texting the on-call party.

FIG. 10 shows a historical report of aggregate and sensed values. As indicated above, the monitoring server150 stores parameter values for both sensed values and aggregate values. The graphs ofFIG. 10 plot the sensed and aggregate parameter values together.Graph line1002 renders a sensed value from the rear of a networking unit.Graph line1006 renders a sensed value from the front of a networking unit. The aggregate value computed from theaggregation processor220 above defines the average temperature, shown asgraph line1004. Visual inspection for this computation yields an expected average running between the two contributing sensed values.

In another example, environmental sensors and perimeter sensors may be combined. An open door and a nearby temperature sensor may result in the nearby sensor reading significantly lower than other sensors. A condition for a “delivery state” may compute an average temperature across all temperature sensors, but then perform a min/max operation to identify if a sole sensor is bringing down the average. An alert would only trigger if the average is low and an open door was not shown, based on reasoning that the open door would cause the temperature to temporarily drop. Alternate configurations may inject temporal and historical aspects to consider previous event windows.

Another example correlates temperature and humidity. Opening a door allows an exchange of outside air affecting both temperature and humidity. In the case of a humidity sensitive ware such as salt, humidity causes degradation of the salt stock. An open door allows a temperature fluctuation which is quickly remedied by the building HVAC, yet the humidity tends to persist in the region of the open door. An aggregate reading based on the temperature, humidity and door closure could detect excess humidity entering through the open door that are not shown or expected merely from temperature monitoring.

Those skilled in the art should readily appreciate that electronic logic and instructions as disclosed herein are open to implementation in many forms, including but not limited to a) information permanently stored on non-writeable storage media such as ROM devices, b) information alterably stored on writeable non-transitory storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media, or c) information conveyed to a computer through communication media, as in an electronic network such as the Internet or telephone modem lines. The operations and methods may be implemented in a software executable object or as a set of encoded instructions for execution by a processor responsive to the instructions. Alternatively, the operations and methods disclosed herein may be embodied in whole or in part using hardware components, such as Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), state machines, controllers or other hardware components or devices, or a combination of hardware, software, and firmware components.

While the system and methods defined herein have been particularly shown and described with references to embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims (18)

What is claimed is:

1. In a facility environment having a plurality of sensors deployed around a facility defined by a perimeter and an area for sensing environmental and ingress/egress conditions, a method of gathering sensor data, comprising:

associating, at a monitoring server, a channel with each of the sensors in the facility environment, each channel configured to transport and store a value for the associated sensor;

receiving, from a GUI, a selection of an aggregation function and a selection of one or more channels employed in computation of an aggregate value;

receiving, from each of a plurality channels in the facility environment, a sensor reading indicative of a physical condition or occurrence in the facility environment;

combining readings from the selected channels into a new channel having a value computed from the combined readings based on computing the aggregate value by retrieving the values from the selected channels and performing the aggregation function for computing a value for the new channel; and

storing the computed value in a history file with the readings from the other channels, the history file responsive to chronological inquires based on the channels.

2. The method ofclaim 1 further comprising receiving a message from a monitor, the monitor deployed at the facility and coupled to each of the sensors at the facility, the received message including at least one sensed value from the plurality of sensors, and an identity of the channel associated with the sensor.

3. The method ofclaim 1 further comprising:

monitoring at least one of the channels associated with the facility environment by periodically receiving or computing the value from the channel;

periodically gathering each of the values in the monitored channels for comparison with operating parameters indicative of abnormal operation; and

invoking an alert processor for comparison of the channel values with the operating parameter based on the alert criteria.

4. The method ofclaim 3 further comprising receiving, from a GUI, an alert criteria including:

a operating parameter indicative of operational limits of the facility environment;

a channel having a value based on readings from the facility environment; and

a comparison for determining operation outside the limits.

5. The method ofclaim 4 further comprising:

determining if a channel value triggers the alert criteria; and

invoking a notification defined for the alert criteria.

6. The method ofclaim 1 further comprising:

assigning a channel to each of the sensors in the facility environment;

periodically receiving a message indicative of a value from each of the assigned channels, the message based on a polling interval for reading each of the sensors in the facility environment.

7. The method ofclaim 1 further comprising computing the aggregate value following network transmission of the channels in the facility environment used to compute the aggregate value.

8. The method ofclaim 1 wherein the aggregate channel originates at a network destination of the message including the sensor reading based on the sensors in the facility environment.

9. In a facility environment having a plurality of sensors deployed around a facility defined by a perimeter and an area, the facility associated with operating parameters defining environmental and ingress/egress conditions, a method of gathering data regarding a facility environment, comprising:

associating, at a monitoring server, a channel with each of the operating parameters for the facility environment, the channel configured to store received sensor readings;

receiving, from each of a plurality of sensors deployed in the facility environment, the sensor reading indicative of a physical condition or occurrence in the facility environment;

invoking an aggregation processor for computing an aggregate value based on a plurality of the sensor readings;

determining, based on aggregation logic in the aggregation processor, the channels used for computing the aggregate value;

computing the aggregate value from the determined channels;

defining a new channel for storing the computed aggregate value;

storing the aggregate value in the new channel;

comparing the aggregate value with an alert criteria, the alert criteria indicative of whether the aggregate value denotes a notable condition in the facility environment; and

based on the comparison, performing at least one of storing or reporting the compared aggregate value.

10. The method ofclaim 9 further comprising receiving an identity of each of the plurality of sensors configured in the facility environment, the sensors deployed in locations around the facility environment for detecting physical parameters indicative of environmental and perimeter attributes pertinent to integrity of the facility environment.

11. The method ofclaim 9 further comprising:

monitoring a plurality of parameter values associated with the facility environment, the parameter values defined by values carried on channels based on conditions in the facility environment;

periodically gathering each of the monitored parameter values for comparison with operating parameters indicative of expected operating conditions;

computing the aggregate value based on the aggregation logic defined for the aggregate value, and invoking an alert processor for comparison of the aggregate value with an operating parameter based on an alert criteria.

12. The method ofclaim 9 further comprising:

receiving, from a GUI, a selection of an aggregation function and one or more channels employed in computation of an aggregate value; and

computing the aggregate value by retrieving the values from the selected channels and applying the aggregation function.

13. The method ofclaim 9 further comprising receiving, from a GUI (Graphical User Interface), commands for defining the aggregation function for the aggregate value, the commands including:

i an indication of the channels used for computing the aggregate value;

ii operations to be performed on the values from the channels; and

iii the result to be returned as the aggregate value.

14. The method ofclaim 9 further comprising receiving, from a GUI, the alert criteria specifying:

a operating parameter defined based on normal operational limits of the facility environment;

a channel value based on readings from the facility environment; and

a comparison for determining operation outside the normal operation limits based on the channel value.

15. A facility monitoring server device responsive to a facility environment having a plurality of sensors deployed around a facility defined by a perimeter and an area, the facility associated with operating parameters defining normal environmental and ingress/egress conditions, comprising:

an interface for receiving, for each of a plurality of sensors deployed in the facility environment, a channel associated with each of the sensors in the facility environment, each channel configured to transport and store a parameter value for the associated sensor;

a graphical user interface (GUI) for receiving a selection of an aggregation function and a selection of two or more channels employed in computation of an aggregate value;

an aggregation processor configured to compute an aggregate value based on combined readings from the selected channels into a new channel having a value computed from the combined readings, including computing the aggregate value by retrieving the values from the selected channels and performing the aggregation function for computing a value for the new channel;

a storage interface to a repository for storing the aggregate value in a history file with the readings from the other channels, the history file responsive to chronological inquires based on the channels; and

an alert processor configured to compare, based on an operating parameter and an alert criteria, whether the aggregate value is indicative of a notable occurrence in the facility environment.

16. The device ofclaim 15 wherein the interface to the facility is configured to receive a message from a monitor, the monitor deployed at the facility and coupled to each of the sensors at the facility, the received message including at least one sensed value from the plurality of sensors, and an identity of the channel associated with the sensor.

17. The method ofclaim 15 wherein:

the GUI is for receiving, a selection of an aggregation function and one or more channels employed in computation of an aggregate value; and

the aggregation processor is for computing the aggregate value by retrieving the values from the selected channels and performing the aggregation function for computing a value for the new channel.

18. The device ofclaim 15 wherein the alert processor is configured to:

monitor at least one of the channels associated with the facility environment by periodically receiving or computing the value from the channel;

periodically gather each of the values in the monitored channels for comparison with operating parameters indicative of expected operation; and

invoke an alert processor for comparison of the channel values with the operating parameter based on the alert criteria.

Images