SECURITY SYSTEM AND METHOD
BACKGROUND OF THE INVENTION
THIS invention relates to a security system which is installable at a particular site/premises, such as a house or office. It extends the role played by conventional systems that typically activate a siren and/or notify a security company when activity is detected in an area being secured while the system is active.
Conventional property security systems generally require manual activation when authorized occupants exit the secured area, and manual deactivation when they enter the area being secured in order to prevent the alarm triggering while they are in the secured area. In other words they offer little or no protection when authorized people are present in the secured area. They rely on activity sensing technology to detect unauthorized entry while they are active and cannot distinguish between different causes of detected activity, responding to all detected activity as if it was an unauthorized intrusion. For control convenience, when activated most such systems simultaneously secure a group of physically connected but distinct activity detection areas, such as an entire work premises or private home.
Conventional security systems also commonly evaluate signals from discrete sensors as representing discrete activity, whereas multiple sensors might be signalling detection of the same activity. In addition, environmental conditions may cause some sensors to detect activity that is not a security risk and should not elicit any security response, for example the movement of birds, or plant movement due to high winds in a garden.
The Inventors wish to address at least some of the problems identified above.
SUMMARY OF THE INVENTION
In accordance with an aspect of the invention there is provided a security system which is installable at a premises, wherein the system includes: at least one activity detection device which is configured to detect a particular activity at/within a particular zone/location in/at the premises, when in use, and to send activity information to a processing arrangement when the particular activity has been detected;
a tracking arrangement which is configured to identify one or more assets which are associated/registered with the system and which are located at the premises and to determine/estimate the location of the assets(s) within the premises, when in use; a data base on which is stored certain predefined activity criteria/rules with/against which activity information received from the at least one activity detection device can be compared; and a processing arrangement which is configured to determine/calculate a security response by using/utilising the activity information received from the at least one activity detection device, the criteria/rules stored on the data base; and the location of the asset(s) estimated/determined by the tracking arrangement.
The term "asset" refers to users (i.e. humans), animals and other movable assets.
The term "premises" should be interpreted to include a house, building, or piece of land which needs to be monitored for security purposes, irrespective of its intended use. In other words, it can be for personal or business use.
In one embodiment, the asset may refer specifically to users (e.g. employees, or family members).
The processing arrangement may be configured to determine/calculate a security response which either requires an actionable activity/procedure, whereby an appropriate security alert procedure is implemented by the processing arrangement, or does not require an actionable activity/procedure.
The processing arrangement may be configured to also take into account previously determined/calculated security responses in order to determine/calculate an appropriate security response, e.g. for elevating the threat/suspicion level of a configured zone within the premises, to indicate a suspicion of intrusion that might be confirmed by information received later.
The data base may be a long-term data store in the form of a relational database, in which configuration, state and transaction information of a specific installation of the system is stored, including the assets, zones, rules, schedules, and identities of various input and output devices described previously.
The processing arrangement may be configured to also take into account previous/historic activity information received previously from the at least one activity detection device in order to determine/calculate an appropriate security response.
The system may include at least one detection inhibition device which is operatively/communicatively connected to the processing arrangement and which is configured to inform the processing arrangement when certain conditions are present which can negatively affect the accurate detection of a particular activity at/within a particular zone of the premises, and wherein the processing arrangement is therefore configured to also take into account information received from the at least one detection inhibition device in order to determine/calculate an appropriate security response.
The premises may, in use, be divided into a plurality of zones, and the system may include at least one activity detection device for each zone. The activity detection device may be a motion detector/sensor. More specifically, the activity detection device may be a motion detector/sensor, a smoke detector/sensor, a glass-break detector/sensor, a security beam or any other device which can be used to detect the presence of a human/animal, e.g. an intruder. The motion detector may be an infrared motion detector.
The tracking arrangement may be operatively/communicatively connected to the processing arrangement. Alternatively, the tracking arrangement and processing arrangement may be implemented by a single module (i.e. the processing of both arrangements may be implemented centrally). The processing arrangement and/or tracking arrangement may be configured, by way of software, to perform at least some of their functions mentioned above.
The tracking arrangement may include at least one asset detection device which is configured to receive/retrieve asset identification information wirelessly from assets which are located at the premises.
The tracking arrangement may include at least two or more asset detection devices which are located at the premises and a positioning module which is configured to determine/estimate the position of an asset based on information received from the two or more asset detection devices.
The tracking arrangement may include at least one asset detection device for each zone and the positioning module is configured to determine in which zone of the premises a particular asset, which is associated/registered with the system, is located.
The positioning module may include an artificial neural network which is trained/configured to interpret information received from the asset detection device(s) and determine/estimate the position of a particular asset within the premises.
The asset detection devices may be configured to receive a wireless signal which is sent from an identification device/tag which is associated with a particular asset, wherein the signal includes information on the identity of the associated asset. The asset detection device(s) may be wireless transceivers.
The asset detection device(s) may be RF (radio frequency) transceivers which are configured to send and receive information to and from an identification device/tag which is associated with a particular asset.
The security alert procedure may include:
activating an alarm; sending a message/instruction to a security control panel, sending an instruction to a video recorder to record video; sending an alarm signal to a security company; and/or sending a notification/communication to an entity/person which is associated with the premises in order to inform the entity/person of the security alert.
The system may include a server of which the processing arrangement forms part of.
In accordance with another aspect of the invention there is provided a method of operating a security system which is installable at a premises, wherein the method includes: receiving activity information from at least one activity detection device which is configured to detect a particular activity at/within a particular zone/location in/at the premises; identifying, by using a processor, one or more assets which are associated/registered with the system and which are located at the premises, and determining/estimating, by using a tracking arrangement, the location of the asset(s) within the premises; and determining/calculating, by using a processor, a security response based on predefined activity criteria/rules which are saved on a data base, wherein the criteria/rules relates to criteria/rules with/against which activity information received from the at least one activity detection device can be compared, the activity information received from the at least one activity detection input device, and the estimated/determined location of the user(s).
The step of determining/calculating a security response may also include determining/calculating, by using a processor, a security response which either requires an actionable activity/procedure, whereby an appropriate security alert procedure is implemented by a processor, or does not require an actionable activity/procedure.
The step of determining/calculating a security response may include also basing the determination/calculation on previously determined/calculated security responses in order to determine/calculate an appropriate security response.
The step of determining/calculating a security response may include also basing the determination/calculation on previous/historic activity information received previously from the at least one activity detection device in order to determine/calculate an appropriate security response.
The method may include detecting an activity by utilising at least one activity detection device.
The identification of one or more assets may include: receiving identification information from an asset by utilising at least one asset detection device; and querying a database/memory on which asset identification information of associated/registered assets are stored in order to determine if the detected asset is in fact an associated/registered asset.
The method may include receiving information from at least one detection inhibition device which is configured to detect certain conditions which can negatively affect the accurate detection of a particular activity at/within a particular zone of the premises.
The detection inhibition device may be configured to assess at least one environmental condition which can negatively affect the accurate detection of a particular activity at/with the particular zone of the premises.
The method may include one or more of the following steps, if it is determined that the security alert procedure/instruction should be implemented: activating an alarm; sending a message/instruction to the security control panel; sending an instruction to a video recorder to record video; sending an alarm signal to a security company; and/or sending a notification/communication to an entity/person which is associated with the premises in order to inform the entity/person of the security alert.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will now be described, by way of example, with reference to the accompanying diagrammatic drawings.
In the drawings:
Figure 1 shows a schematic layout of various high-level components of a system in accordance with the invention;
Figure 2 shows a schematic layout and illustration of the security system of Figure 1 installed at a household;
Figure 3 shows a schematic overview of at least some of the hardware infrastructure of the system of Figure 1 ;
Figure 4 shows a schematic overview of at least a portion of a software component infrastructure of the system of Figure 1 , which is mapped to a hardware infrastructure thereof;
Figure 5 shows a simplified entity relationship diagram of a data structure of the system, which is fulfilled by relational database tables in a preferred embodiment of the invention;
Figure 6 shows a simplified flow diagram of how the system of Figure 1 acquires information for training an artificial neural net, which is used by the system to determine asset position;
Figure 7 shows a simplified flow diagram of how the system of Figure 1 trains an artificial neural net, which is used by the system to determine asset position; Figure 8 shows a simplified flow diagram of how the system of Figure 1 locates and identifies registered assets when required;
Figure 9 shows a simplified flow diagram of how the system of Figure 1
input into a common format from heterogeneous input devices;
Figure 10 shows a simplified flow diagram of how the system of Figure 1 de-normalizes output from a common format to the device specific signals of heterogeneous output devices;
Figure 11 shows a simplified flow diagram of how the system of Figure 1 determines whether assets have left or re-entered the premises secured by the system;
Figure 12 shows a simplified flow diagram of how the system of Figure 1 validates asset tags that require validation before they can facilitate authorized activity in the secured property;
Figures 13-15 show a detailed flow diagram of how the system of Figure 1 evaluates input according to rules in order to determine if actionable activity has been detected;
Figures 16-18 show a detailed flow diagram of how the system of Figure 1 evaluates actionable activity according to rules, seeks additional information if required by said rules and determines an appropriate response;
Figures 19-22 show a detailed flow diagram of how the system of Figure 1 evaluates a schedule in order to determine whether the current time is within a scheduled period for a given action performed by the system
DESCRIPTION OF PREFERRED EMBODIMENTS
In the drawings, reference 10 refers generally to a security system in accordance with the invention.
Reference is now specifically made to Figures 1 and 2. The system 10 is typically installed at a particular premises/property 100. The property 100 is typically divided into a number of security zones which are generally indicated by reference numerals 102.1-102.12 (collectively referred to as 102).
The system 10 includes: one or more activity detection devices 16 which include motion sensors 18.1-18.12 (collectively referred to as 18), smoke detectors, beam sensors as well as any other devices which can be used to detect the presence of a person or an animal of a particular size; one or more inhibition devices, including a wind speed sensor 26.1, which may be used to determine if environmental conditions hinder the accurate detection of activity by the activity detection devices 18; one or more asset validation devices 24, are typically used to validate specific asset tags 30 (described below) where required; one or more output devices 54 which includes an alarm panel 56 and a siren 58, and are used to execute a security response to unauthorised activity or intrusion, where required; messaging software 57 which is used to send electronic messages such as emails and SMS's; a data store 40, which is used to store zone definitions and states 102, asset definitions and states 23, and various rules for detecting activity 25 and executing appropriate responses 27; a tracking arrangement 20 (also referred to as "Asset Tracking" in Figure 1) which is configured to identify assets which are associated/registered with the system 10 (described in more detail below) and which are located at the property 100 and to determine/estimate the location of the assets within the property 100 (i.e. thereby effectively acting as a type of positioning module). a central server 12, which hosts a rule processor 14, which is configured to determine/calculate a security response based on certain predefined activity criteria/rules.
The rule processor 22 receives a constant stream of security inputs 19 from security input devices 11 (which includes the activity detection devices 16) and other software which is in communication with the server 12. The security inputs 19 can be evaluated by the processing software according to specific predefined rules which are configured for a particular property 100 (i.e. it is a site-specific installation system). The security devices 11 include validation devices 24, activity detection devices 16, inhibition devices 26, as well as external software.
The rule processor 22 constantly cycles through a set of activity detection rules 25 which are configured for the specific site/property 100, each comprising a set of conditions and parameters describing the desired response to those conditions, and checks if the incoming inputs from the security inputs 19 match the conditions defined for each rule. Where such conditions are met, the rule processor 14 records actionable activity events (i.e. appropriate security responses).
Where such actionable activity events are raised, the rule processor 14 further cycles through a set of security response rules 27, which further evaluate the identified activity in combination with asset states and zone states to determine an appropriate security response.
Where necessitated by a security response rule and/or built-in program logic, the rule processor 14 attempts to establish the locations of known assets within the property 100, by sending a request to the tracking arrangement 20, which, in turn, provides the rule processor 22 with the current location and identity of known assets within the property 100. On receipt of this information, the rule processor 14 cycles through a set of security response rules 27, checking if certain conditions are met, and if so, executes a security response (this is described in greater detail below).
The rule processor 22 also maintains and considers zone 102 and asset tag 30 states, which may vary, in the evaluation of security response rules. For example, an asset tag 30 (described below) that requires validation will become invalid when it leaves the property 100 and will therefore be in an invalid state if it re-enters the property 100 without a validation input being received (this is described in more detail below). Similarly, monitoring of a particular zone 102 may be suspended at certain scheduled times. The data store 40 may be a database hosted by an RDMS (relational database management system) hosted on the server 12. The data store 40 stores site/property-specific configuration data, such as the predefined zones 102, identification information of assets 200 which are registered with the system 10 and the rules for evaluating 25 and responding 27 to security inputs 19.
The tracking arrangement 20 includes an RF asset tag 30 for each of its registered assets and an array 50 (also see Figure 3) of RF transceivers/relay devices 52 (also referred to as "the relay network") which are configured to send requests to the RF asset tags 30 and receive identification information and signal strength information from the RF asset tags 30. The assets may be users 200, 202, animals (e.g. household pets), as well as other movable objects (e.g. vehicles and televisions) that the owner of the property 100 wishes to identify and track.
The tracking arrangement 20 also includes an artificial neural network 44, to which the array 50 sends the identification information received from the asset tags 30 and information describing the received signal strength at each relay 52 of the data packet which communicates that identity. The said artificial neural network 44 is trained to interpret this information in order to determine the position of identified assets, when requested by the rule processor 14.
The rule processor 14 is configured to raise security events that may have one or more security response outputs 53. A security response 53 may consist of a signal sent to a security output device 54, such as an alarm panel 56 or siren 58, or a software communication 57, such as an email or SMS, which is sent to a particular recipient.
Reference is now specifically made to Figure 3 which illustrates the so-called hardware components of the system 10 which are installed at the property 100 and how they are connected to each other.
The server 12 is a server computer that hosts the rule processor 14. The server 12 is connected to a LAN (local area network) 540 via a TCP/IP Ethernet router (generally indicated by reference numeral 544). All the security inputs 19 can collectively be referred to as an array 77 of heterogeneous input devices which are configured to detect activity, are connectable to a computer, and which are connected to the server 12 by means appropriate to each device 16. Each device 16, 24, 26 in the array 77 can include software and/or hardware (i.e. have a physical presence). Examples include programmable microcontrollers which run a variety of programs, the motion sensors 18, beam detectors 79, panic buttons and security panels 56. Examples of connection devices for each of the input devices typically include multiplexers, conventional alarm panels and specialized cards installed on the server 12 with hardware ports for the particular devices.
The security outputs 53 are connected to the server 12 by appropriate means. The devices which form part of the security outputs may be collectively referred to as an array 81 of heterogeneous output devices. Each device in the array 81 can include software and/or hardware (i.e. have a physical presence). Examples include alarm/security panels 83 employed by security companies which are associated with the system 10, sirens 58, electronic locks and video recorders 87. Examples of connection devices for each of the output devices typically include multiplexers, conventional alarm panels and specialized cards installed on the server 12 with hardware ports for the particular devices.
The RF asset tags 30 are programmable microcontrollers with RF transmission and reception capability. RF tags 30 are attached to, or carried by, assets that the system 10 is required to identify. As each property 100 has a different number of assets that must be tracked, the number of asset tags 30 employed is variable. When a request is received by an RF asset tag 30 from the network 50 of RF relays 52 (e.g. sent by the server 12), the RF asset tag 30 sends identification information to the network 50, which is used to locate the tags 30 within the property 10.
These tags 30 should be carried by the people who are registered/associated with the system 10 at all times that the system 10 is operational, or kept near their person. A range of options can be supplied so that the tags 30 may be easily worn (wristbands, pendants) or attached to commonly carried objects like key-rings. For pets and moveable assets, the asset tag 30 can be attached in some other way to the pet or object. For example, it may be attached to a pet's collar. The RF relays 52 are programmable microcontrollers with RF transmission and reception capability and specifically, the ability to use the TCP/IP protocol used by most wireless network cards in modern computers. An array of programmable RF relays 52 are installed around the property 100 and is used to communicate requests to, and receive responses from, the RF asset tags 30. Each RF relay 52 hosts a networking program that allows it to route information about itself, and responses received from specific RF asset tags 30, to the server 12 via wireless TCP/IP communication. The server may receive these requests directly through a wireless network card or indirectly through multiple network routers on the same local area network, and the server 12 can send identification requests through the network to any RF asset tags 30 on the property 10 by the same means.
Reference is now specifically made to Figure 4 which describes the so-called software components of the system 10, which are generally hosted in the hardware components/infrastructure described above.
The inputs of the server 12 are generally indicated by reference numeral 111 , while the outputs of the server 12 are generally indicated by reference numeral 113.
An input normalization software layer 115 uses a common software pattern known as an extensibility pattern (a plugin-based architecture) to convert electronic information from various input sources/devices 19 into a single, common format (see also reference numeral 119). The layer 115 itself is a software host for software plugins, which follow a common plugin specification. An individual plugin is supplied for each type of input 19 and output 53 that the server 12 can communicate with and new plugins can be developed at a later stage (e.g. to allow new devices to be employed to detect activity).
The packets sent to the rule processor 14 by the input normalization layer 115, when input signals are received, take the form of a list of key/value pairs describing a uniquely identified source and a set of parameters appropriate to the source. The count of parameters and value range of each parameter may vary depending on the input source. The rule processor 14 is able to evaluate these lists in a generic manner by examining configured rules that specify source, a parameter key, an associated parameter value and a comparison operator as criteria.
The output denormalization layer 117 also uses the extensibility pattern to convert data packets from the rule processor 14 in a standard output format into signals to various outputs 53 (see also reference numeral 121). Similar to the input normalization layer 115, it acts as a host to plugins that are specific to each output device 54. The packets received from the rule processor 22 indicate the destination the output is intended for and a list of key/value pairs appropriate to the destination, describing parameters of the message to be sent to the destination. The appropriate plugin to process the packet is selected based on the destination identified in each packet. The selected plugin then sends the message to that destination in an electronic protocol employed by the destination, through the hardware or software port that the destination is connected to.
The rule processor 14 receives inputs from the input normalization layer 115, evaluates them against activity detection rules in a state and rule database 40, and determines whether actionable activity has taken place (e.g. whether a certain security response is required, based on the activity detection rules). Where it determines that actionable activity has taken place, it records the determination as activity detection from a virtual activity detection device, comprised of the various inputs used to make the determination.
Where the rule processor 14 determines actionable activity in the manner described above, it initiates a further process that examines security response rules in the state and rule database 40. Where the security response rules indicate that the activity is zone-specific and identification is required, the rule processor 14 broadcasts/sends an identification request through the RF relay network 50 and waits a limited amount of time for identification and location information. Appropriate security responses are raised based on the response received from the network 50, if necessary. The security rules may also require a response where no identification is necessary, for example where the input is a panic button being pressed. The security response rules may also take into account previous (i.e. historic, e.g. of a few seconds ago) actionable activities/security responses, when determining a particular security response. In other words, a previously detected/determined event may have an impact on a particular security response (e.g. for elevating the threat/suspicion level of a configured zone within the premises, to indicate a suspicion of intrusion that might be confirmed by information received later.).
The database/data store 40 hosts all property-specific configuration data employed by the system 10, in a conventional RDMS (Relational Database Management System). The database 40 is used to store and retrieve both configuration data for the property 100 and persistent state data (see reference numeral 137). An asset identifier 49 is a software component that identifies and locates a single asset within the property 10. It is hosted on an asset tag 30 and responds to requests sent from the network 50, which can also be referred to as the positioning array 123. Each asset identifier 49 is configured with a unique identifier (asset key) that matches an asset key of an asset tag 30 in the database 40.
The positioning array 123 includes software on the RF relays 52 in the network 50. The software receives broadcasted requests for asset identification and location from the rule processor 22 (see reference numeral 25) and solicits requests from the asset identification software hosted on the RF asset tags 30 that are in range. Upon receiving a signal from an RF asset tag 30, which includes identification data/information, the relay(s) 52 forward the identification data, a signal strength of the signal received by the relay(s) 52 and a unique identifier (e.g. a code or number) of the relay(s) 52 that read the signal strength, back to the neural network layer 44 (see reference numeral 127).
The neural network layer 44 is a software layer that contains a supervised, feed-forward back-propagation artificial neural network (ANN). In the system 10, the ANN is trained to interpret signal strength data as received by different relays in the RF relay network 50 from an asset identifier 49 to determine/estimate the location of an asset within the property 10 on request from the rule processor 14. This information (see reference numeral 129), in turn, is returned/sent to the rule processor 14, so that it can identify whether or not a detected activity within a zone 102 is authorized, and to raise appropriate security responses, if necessary.
Such ANN's are generally well known and are in essence learning algorithms that mimic the learning behavior of networks of neurons in animal brains and can be trained to find continuous functions that transform input values into matching, expected output values or close approximations thereof. The ANN comprises a virtual circuit of interconnected nodes which can each receive inputs from other nodes or some external source and produce corresponding outputs to other nodes it is connected to, where the outputs may either inhibit or activate further output by those nodes. Some of the nodes described are input nodes that are activated by external software and some are output nodes that are read by external software. This arrangement constitutes a virtual circuit for transforming input values to output values by some function described by the circuit of a particular ANN. The ANN is trained by training software, which provides the input from a training data set, evaluates the outputs against the output values expected for the input values supplied and adjusts the connections within the virtual circuit based on how close the output for a given set of inputs is to the corresponding desired output in the training data set, so that after multiple iterations the virtual circuit gradually learns to produce the desired outputs from the given inputs.
The ANN employed by the neural network layer 44 takes, as input, the received signal strengths reported by various RF relays 52 for a signal containing identification data from a single asset tag 30 and provides as output a value representing the unique identifier of a zone 102.
Since artificial neural networks are software algorithms that learn from repetitive training, a training interface 131 is implemented, which is a software interface required to train the neural network layer 44 to infer the positions of assets based on signal data received from the positioning array 123. See also reference numerals 133 and 135 which refer to a training interface and a database for the training interface 131 , respectively.
The system 10 includes a configuration interface 139 which is an end-user software interface that enables the rules and associated data entities used by the rule processor 22 to be configured for an installation of the system 10 at a specific property/site 100.
The way in which the system 10 is installed at a particular property 100, and the way it operates in practice, will now be described. Persistent data described below is stored in the state and rule database 40.
In the following descriptions reference is made to Figure 5, which shows the data structure of the database 40. References 702-732 refer to tables in the database that store the entities shown in the diagram, as structured. Where a many-to-many relationship is described by a Figure 5, the existence of a join table that is not shown, to facilitate the relationship, is implied.
Configuration Zones, Assets and Devices On installation of the system 10 at the property 100, the installer typically consults with and advises the users to determine how they would like to divide up the property into logical zones 102 and which assets they wish to track.
During the same consultation process, the installer establishes which input devices 11 are required, including where activity detection devices 16 and inhibition devices 26 are required to detect activity within the zones 102; and where asset validation devices 24 are required for validation of asset tags 30 that require validation. The devices must then be registered with the system, which involves capturing a user-friendly name for the device, selecting the hardware/software port through which they communicate with the server 12 and capturing the identity of the device that is communicating via that port, and the device type represented by a reference to the appropriate driver plugin registered with the input normalization software layer 115. This process creates the linking information required to map the signals received from input devices to associated device records in the database, which are referenced in activity detection rules. The resulting device record is stored in the device table 706.
During the same consultation process, the installer establishes which output devices 54 are required, including but not limited to sirens, alarm panels, light switches, LEDs, buzzers and video recorders. The devices 54 must then be registered with the system 12, which involves capturing a user-friendly name for the device, selecting the hardware/software port through which they communicate with the server 12 and capturing the identity of the device that is communicating via that port, and the device type represented by a reference to the appropriate driver plugin registered with the output normalization software layer 117.
The zones 102 are captured into the system 10. For each zone 102 the following may be captured: the name of the zone and a schedule of times when the system 10 will respond to activity in that particular zone 102, and whether identity monitoring is enabled for the zone 102. The enablement of the identity monitoring typically dictates whether the system 10 automatically evaluates detected activity as an intrusion detection or attempts to evaluate whether it is caused by an identifiable asset. The name of the zone and identity monitoring flag are stored in the zone table 710. The schedule of times when the system will respond is stored in the schedule table 712. Information on the assets 200 are also captured into the system 10. For each asset 200 the following may be captured: the name of the asset 200, which zones 102 they are authorized to be in and a schedule of times they are allowed to be in those zones 102. Asset information, excluding the zone schedules described, is stored in the asset table 728. The schedules of times when an asset is allowed to be in various zones are stored in the schedule table 712, and the information linking specific asset/zone combinations to a particular schedule are stored in the zone authorization table 730.
One or more asset tag 30 records are captured in the system 10 for each of the assets 200 and saved on the database 40, in addition to whether the associated tag 30 requires validation. If validation is required, then the relevant validation rule is also captured in the system 10 (i.e. stored on the database 40). The asset tag information, including a flag specifying whether validation is required, is stored in the tag table 726. If validation is required, the validation rule input is stored in the same tables as activity detection rule devices (detection rule input 708) and their associated conditions (detection rule input condition 702), because validation involves examining whether the system has had input that meets certain conditions from an input device - for example a code punched into a keypad.
Validation rules are specified as a device identity from which input must be recorded (stored in the detection rule input table 708), and a list of conditions that must be met for validation of an invalid tag to occur (stored in the detection rule input condition table 702), where each condition consists of a named parameter expected from the device, a value to compare to the value received for that parameter from the device and a comparison operator specifying the desired relationship of the value received from the device to the value specified in the condition. In a typical scenario where a security keypad is used as a validation device, authorization codes for users of tags that must be validated on entry will be configured on the keypad itself and the input normalization layer will receive as a parameter only the information that a valid code has been entered, so the associated validation rule would have a single condition testing whether that parameter has been supplied.
An asset tag 30 is issued for each identified asset 200 and is encoded with information linking it to the corresponding asset record described above. Users are able to reconfigure zones 102, and assets at any point in time, e.g. by using the alarm panel 56 or a computer which is connected to the server 12 via the LAN 520. They may also capture changes to the input device configuration at any time, although such changes may necessitate re-training the neural network layer 44 of the asset tracking arrangement 20. Configuring Detection Rules and Security Response Rules
On installation of the system 10 at a property 100, the installer will typically conduct tests, consult with and advise the users in order to determine what activity detection rules and security response rules are necessary.
The activity detection rules effectively define virtual activity detection devices, where the determinations of the rule are treated by internal processes as the outputs of a single activity detection device in a particular zone 102, where the virtual device is uniquely identified by the unique key associated with the rule in the database 40. The rules that are possible are dependent on the available input and output devices described above.
A set of activity detection rules are then captured into the system 10 where they are stored in the tables described below in the database 40. Each rule describes/includes:
• The name of the rule and zone 102 for which it detects activity, stored in the activity detection rule table 710.
• The devices (e.g. security inputs 19) employed in determining whether the criteria is met, stored in the detection rule input table 708
• For each device, a combination of input criteria which will be tested against input from the specified device, received from the input normalization layer 115, to determine if actionable activity has taken place (also referred to as trigger conditions). Each criterion is stored in the detection rule input table 702 and describes: o A named parameter that will be received from the input normalization layer 115 to be examined. o A value to compare the received value for the given parameter against. o A comparison operator describing how the values are compared. For example "equal to" means that the value received for the parameter named must be equal to the value specified in the criterion. • For each device, whether the device elicits or inhibits activity detection (stored in the detection rule input table 708. In the latter case, when the criteria linked to the device are all met, the rule the device is linked to will not record actionable activity, even if the criteria for devices that elicit detection and are linked to the same rule are met.
• A schedule of times when the rule is active, stored in the schedule table 712.
Evaluation of the above rules and automatic program logic, as described below, may raise a range of different security events, which are stored in the security event table 714. For each of these events, a security response rule is captured into the system 10 (and stored in the tables described below), detailing the following:
• The event type the rule will determine a response for and a parameter specifying a time period after a response rule has produced a response, during which time events that meet the criteria of the rule, will be ignored (similar to an event suppression period). This is to ensure, for example, that the system does not continually send messages for a siren to be activated while the siren is already sounding. This information is stored in the security event response rule table 718.
• The zones 102, if any, and assets 200, if any, that must be associated with the event being examined for the rule under examination to be applicable, as stored in the zone table 720 and asset table 728 respectively, and linked to the security response rule record by a join table.
• A set of actions to take if the above conditions are met. In this regard, the following is captured into the system 10 for each action: an action type, including enabling or disabling zone monitoring, validating or invalidating asset tags 30, sending a signal to an output device 53, or sending a notification in the form of an SMS or email to a user. The security responses are stored in the response rule action table 716.
• Where an output device, SMS or email is specified as the action type, parameters appropriate to the output device or messaging technology must be captured. For example, the parameters for a particular buzzer to sound may require capturing the pitch and volume, while the parameters for an email will comprise recipient address, heading and body of the email.
Training the Neural Network (See Figures 6 and 7)
When the system 10 is deployed the ANN 44 should be trained to infer/determine the position of asset tags 30 accurately within the property 10 (i.e. in which zone 102 the tag 30 is located) from signal data received by the RF relay network 50.
This process entails two distinct stages: First acquiring training data that describes example inputs and the desired outputs required for each example, then using the training set thus acquired in a subsequent ANN training process:
Acquiring the training data (see Figure 6) entails the following steps:
■ A training person is equipped with a training RF asset tag carried on their person and a portable computer running software that does the following: o Facilitates the capture of a position in the property 10 represented by a previously configured zone.
■ When a position is captured, broadcasts a request for response to the positioning array 123 which, in turn, requests a response from the training tag and then returns the signal strengths of the response to different relays 52 from the training tag. The signal strength with which each relay 52 receives a response is then stored and linked to the captured position that initiated this process.
• The training person then moves around the property 10 in an ordered pattern, stopping at regularly spaced intervals and capturing their position and recording signal strengths as described above, ensuring that they do so a significant number of times within each configured zone 102 so that there is sufficient data to train the ANN 44.
Once the training data is thus captured, the ANN is trained in the manner described by Figure 7 and entailing the following steps: • The training data gathered in the process described above is supplied to the neural network layer 44 in order to train the ANN.
• The neural network layer 44 is provided with a desired accuracy (e.g. by the trainer)
• The neural network layer 44 determines the number of unique relay devices 52 providing signal strength input positioning, creates an ANN with the same number of inputs and an output representing the predicted position (zone), represented as a numeric key
• The network layer 44 begins training the ANN, which entails: o supplying the ANN with a training dataset representing the positions captured and for each position, the associated signal strengths gathered in the acquisition stage described above. The ANN is then iteratively trained until it predicts the known position for any given set of signal strengths with an accuracy equal to or greater than the desired accuracy supplied above; and o may take up to several hours. If the training person decides that the training process is taking too long and is unlikely to yield the desired accuracy, the training process may be interrupted and additional data may be gathered for training as described above.
Determining Asset Positions (see Figure 8)
When the rule processor 22 needs to determine asset positions in order to raise appropriate security events based on detected activity, it sends a request for identification and position via the positioning array 123.
The positioning array 123, in turn, broadcasts the request to asset identifiers 49 of the asset tags 30 located in the property 100 through its corresponding RF relay network 50. The asset identifiers 49 of the asset tags 30 that are in range then responds by sending their respective identities.
The positioning array 123 forwards the following information to the neural network layer 44 for each tag 30 identified:
• the identity of the asset tag 30; and • the signal strengths of the response signal of the asset identifier received by each RF relay 52.
The neural network layer 44 feeds the returned signal strengths of each asset tag 30 that responded into the trained ANN, which returns an inferred/determined zone for each asset tag 30.
The identity of each asset tag and the inferred zone the tag is in, is then forwarded from the neural network layer 44 back to the rule processor 12
Normalising Input (See Figure 9)
Various heterogeneous input devices 77 send signals to the server 12 across a variety of hardware ports and in a variety of forms, as appropriate to the kind of device. Software plugins hosted by the input normalization layer 115 for each type of input device monitor their respective ports for input from the devices 77 of the type that they monitor. On receipt of a signal from an input device 77, the corresponding plugin for that device type converts it into a common input format data packet comprising the device type, a unique device identifier and a list of parameters that the input signal represents supplied as key/value pairs. The common input format data packet is then forwarded to the rule processor 14 for evaluation.
Denormalising Output (See Figure 10)
When the rule processor 14 determines that a signal must be sent to an output device 81 , it forwards the instruction to the output denormalization layer 117 in a common output format data packet, comprising a device type, a unique device identifier and a list of parameters that the output signal must contain supplied as key/value pairs. The output denormalization layer 117 hosts software plugins for each output device type. It forwards the packet received from the rule processor 14 to the appropriate plugin for the device type specified in the packet.
The plugin converts the packet to a signal format understood by the output device 81 and sends it to the device 81 matching the unique device identifier specified in the packet, across the appropriate port for that device 81.
Identifying Lost and Found Asset Tags (See Figure 11)
At routine intervals, the rule processor 22 seeks information on the positions of all asset tags 30 within the property 100 by invoking the process illustrated in Figure 11. The rule processor 14 then compares the identities of the asset tags 30 that responded with all asset tag records configured and saved in the state and rule database 40. For each asset tag 30 that was last recorded as being within the property 100 and does not respond, their corresponding record is flagged as lost and a security event is raised, e.g. of the type "Tag Lost". If the tag 30 has been configured as requiring validation, the tag 30 is also flagged as being invalid until a validation process takes place. For each asset tag 30 that was last recorded as being lost and responds, their corresponding record is flagged as found and another security event is raised, e.g. of the type "Tag Found".
Validating Invalidated Asset Tags (See Figures 12)
The rule processor 14 is configured to review, at routine and frequent intervals, all asset tag records flagged as invalid (e.g. lost) and evaluate whether the conditions have been met for the rule that validates the tag again, as described above. If the conditions are met (e.g. an input representing a user entering a security code on a keypad was received), the rule processor 22 initiates the process described above that the tag 30 has been found (within the property 100). If the tag 30 is found, its corresponding record is flagged as valid again (as described above).
Detecting Activity (see Figures 13, 14 & 15)
The rule processor 14 is configured to cycle continuously through the detection rules, evaluating each one. For each rule evaluated, the schedule of the rule is checked to determine whether the rule is active at the present time. If so, recent input data from the input normalization layer 115 is examined to see if any inputs meet the trigger conditions defined for the rule. If so, recent input data from the input normalization layer is further examined to see if any inputs meet the inhibition conditions defined for the rule.
If the inhibition conditions are met then the rule processor 22 raises an "activity detection inhibited" security event, supplying the zone 102, if any is configured for the rule, as an event parameter. The rule processor 12 then proceeds to evaluate the next rule.
If the trigger conditions for the rule are met and no inhibition conditions are met, then the rule processor 22 raises an "activity detected" security event, supplying the zone, if any is configured for the rule, as an event parameter, along with the input data and associated parameters that triggered the event. If the rule specifies a zone 102, it indicates that activity has taken place in that particular zone 102, and the rule processor 22 proceeds to the process described below under the heading "Evaluating Zone Activity".
Responding to Security Events (See Figures 16, 17 and 18)
Parameterized security events are raised by various processes described above with the parameters supplied as key/value pairs.
Whenever a security event is raised the rule processor 14 retrieves all of the response rules configured for that event (as described above). For each response rule, if the rule includes filters for particular zones 102, assets or other event parameters configured, the rule processor 14 checks whether corresponding parameters are supplied with the event. If not, then the response rule is ignored. If the response rule does not include filters then the rule processor 14 retrieves actions for the response rule and executes them. The following types of actions can be configured for a response rule:
• Notification - the rule processor 14 sends an SMS or email to a specified address or number, providing a description of the event type and its parameters.
• Enable/disable zone monitoring - the rule processor 14 enables or disables monitoring of a zone 102 that is configured for the action.
• Validate/Invalidate asset tag - the rule processor 14 flags an asset tag 30 that is configured for the action as valid or invalid.
• Output to Device - the rule processor sends parameters that are configured for the action to an output device 53 that is configured for the action, via the output denormalization layer 117, which relays the message as described above. The system 10 maintains a readable database (e.g. database 40) of all events processed by the system 10, so that, if necessary, at some later date, activities connected to an incident being investigated can be reviewed, and the location of every asset on the property at the time of the incident can be determined, or so that trends can be evaluated.
The system 10 is in effect always active, and permits authorised users to move freely around the secured property in which the system 10 is installed, without triggering security responses, while still detecting and responding appropriately to intrusions in areas within the property where there are no users, without requiring the users to actively enable or disable the system 10 or any part of the system 10.
Schedule Checking (See Figures 19. 20. 21 and 22)
As described above, schedules may be attached to rules, tags and zones and are checked whenever the system 10 needs to determine whether the current time falls within scheduled time periods. Schedules are stored in the schedule table 712 of the database 40.
The schedule checking process evaluates the appropriate schedule and returns either a true or a false value, indicating whether the current time is within the periods defined by the schedule or not.
When a behaviour of the system must only occur within the times specified by a given schedule, the appropriate schedule is retrieved from the database 40.
The schedule may simply specify "always" as the scheduled period, in which case the schedule checking process returns true.
If the schedule is flagged as "once off' then it will be defined by a single period with a start date/time and an end/date time. If the current time is within the said period, the schedule checking process returns true, otherwise it returns false.
If the schedule is flagged as "recurring", then the schedule will have an effective period defined by a start date/time and either an end date/time, or no end date/time, where the schedule is flagged as "endless" In the former case the recurring periods of the schedule (described below) will only be in effect during the period specified above and outside of that period the schedule will no longer be in effect. In the latter case, the recurring periods will be in effect after the start date/time.
The recurring unit of measure (UOM) is then evaluated to determine whether the recurring periods are daily, weekly or monthly.
If recurring UOM is daily, the daily schedule type is evaluated. If the daily schedule type is "one time", it indicates that the schedule will be in effect during one period every day, defined by a start and end time. If the current time is within that period, the schedule checking process returns true. If not, it returns false. If the daily schedule type is "recurring", the schedule checking process determines whether the current time is within one of the specified periods, which may occur every specified number of seconds, every specified number of minutes, or every specified number of hours and are equal in duration to the value specified by active period. If the current time falls within such a period the schedule checking process returns true, otherwise it returns false.
If recurring UOM is weekly, the days of the week specified in the schedule are evaluated. If the current time falls on one of those days, the daily schedule is further evaluated, as described above, to determine if the current time is within the daily schedule. If so, the schedule checking process returns true, otherwise it returns false.
If the recurring UOM is monthly, the monthly schedule type is further evaluated.
If the monthly schedule type is "month day", the current day is evaluated to see whether it is the specified day of the month. If so, the daily schedule is further evaluated, as described above, to determine if the current time is within the daily schedule. If so, the schedule checking process returns true, otherwise it returns false.
If the monthly schedule type is "Weekday" then the week of month and weekday of week are evaluated in combination to determine which day of which week of the month the schedule is in effect (e.g. "First Monday", "Last Saturday"). The current day is evaluated to see whether it is the specified day of the month. If so, the daily schedule is further evaluated, as described above, to determine if the current time is within the daily schedule. If so, the schedule checking process returns true, otherwise it returns false. The Inventors believe that the system fulfils the role played by conventional electronic intrusion detection and alarm systems, but with significant enhancements and/or improvements that remove the need for users to intervene routinely and manually in order to activate and deactivate alarms and other automated electronic responses. Under normal operating conditions, the system 10 does not require manual intervention to temporarily disable or enable alarm zones, as is the case with traditional intrusion detection and alarm systems mentioned in the background of the invention, when a user enters the property 10.
The system 10 also provides an open-ended, configurable framework that allows a large variety of activity detection devices and security response devices to be used in evaluating activity and responding appropriately, based on site-specific rule-based processing. It achieves this by combining conventional electronic activity detection/security response devices with an electronic asset-tracking arrangement/system and a server computer that hosts rule-processing software which evaluates where activity is detected, what known assets (people, pets and moveable objects) are in the location of the activity and how to respond based on rules that are configured for the specific site/property where it is installed.
The system 10 allows activity to be detected anywhere on the property, not just at entry/exit points.
The system 10 allows authorized users, guests, pets and other movable assets, equipped with small electronic asset tags, to move freely within the property 100, without triggering electronic security responses, while at the same time, raising appropriate security responses when unauthorized, invalid or unknown activity is detected. In addition, the system 10 also allows a user to determine where activity has been detected and the sequence of detection if multiple detections have been made.
The Inventors believe that the invention improves the reliability of sensor detection, so that the resulting system allows for the configuration of "virtual" activity sensors which evaluate the signals of multiple sensors, historical data, and other inputs such as significant environmental influences to produce a determination of activity. The system continuously monitors and reacts to activity in secured areas, requires no manual intervention to activate on departure from or deactivate on entry into the secured area and can automatically differentiate between unauthorized, authorized and unknown sources of activity within different detection areas and respond appropriately. In other words a system that is always armed and offers some protection even when authorized occupants are present.
To this end the inventors developed a configurable, rule-based security software method and an asset/user tracking system which, in conjunction with some changes to the communicative arrangement of the devices used in the conventional property security system described above, receives all of the security inputs such as signals from activity detection devices and other sensors, evaluates them according to rules pre-configured by the user/installer and produces security responses configured by the user or installer based on that evaluation.