Tools for on-premises monitoring

Abstract

A computer system for monitoring a premises, the computer system comprising: a first set of on-premises monitoring devices; a second set of on-premises monitoring devices; an on-premises server coupled to the first set of on-premises devices and the second set of on-premises devices via on-premises infrastructure, the on-premises server comprising: computer storage configured to store a set of arming profiles, each arming profile associated with a set of triggering conditions and a set of actions associated with the triggering conditions, and at least one processor configured to execute: a first monitoring service operable to communicate with the first set of on-premises devices; a second monitoring service operable to communicate with the second set of on-premises devices independently of the first control service and the first set of on-premises devices; an integration layer communicatively coupled to the first control service and the second control service to receive first and second events from the first control service and the second control service respectively; and a rules engine configured to select from the set of arming profiles responsive to a profile selection input an arming profile, continuously monitor the first events and the second events against the set of triggering conditions associated with the selected arming profile, and trigger at least one action associated with one of the triggering condition responsive to determining that the triggering condition is satisfied, the set triggering conditions dependent on the first events and the second events.

Description

TOOLS FOR ON-PREMISES MONITORINGTECHNICAL FIELD

[0001] The present disclosure relates to tools for on-premises monitoring, and method and computer programs for implementing the same. One example application considered herein is the use of such tools in physical security systems. However, a broad range of monitoring applications are also envisaged, encompassing for example safety monitoring (fire, carbon monitoring, people counting etc.), asset or appliance monitoring, environmental monitoring (temperature, humidity, vape, oxygen levels etc.) health monitoring etc.BACKGROUND

[0002] Physical security measures are important in protecting assets and personnel using components such as sensors, alarms and access control mechanisms. Such measures include, for example, the use of closed-circuit television (CCTV) cameras, door or windows sensors, motion sensors, tripwire alarms etc. for surveillance, acting as a deterrent and facilitating intruder detection. Additionally, physical security involves access control measures, ranging from simple locks to advanced biometric systems. Access control mechanisms include traditional mechanical locks or locks controlled electronically using key cards, access panels, biometric sensors and the like. Physical security measures work together to prevent unauthorized access to property and assets.

[0003] Conventional physical security solutions can be broadly divided into two categories: on-premises security systems and ‘smart’ security systems.

[0004] Physical on-premises (‘on-prem’) security systems primarily focus on protecting tangible assets such as buildings and equipment. They offer a well-defined security perimeter, with on-site monitoring and often on-site staff mitigating security risks. In such systems, all network traffic (to / from sensors, alarms, access mechanisms etc.) is routed via physical security appliances on the premises. Such systems may interface with external systems, such as an intruder alarm tiggering a call-out alert to an external security operator. On-prem systems are typically equipped with anti-tampering mechanisms to mitigate attempts by intruders to disable them (such as an intruder alarm equipped with a second power source that is activated when its primary power source is disabled).

[0005] On the other hand, so-called ‘smart’ systems tend to be lower cost systems. In so far as smart systems extend to security applications, they are more focussed on ‘soft security’. A range of low-cost ‘smart’ sensors and alarms are available, which include connected cameras and sensors (such as doorbell cameras) and connected alerts. Such components tend to have minimal set-up requirements but are reliant on a permanent (and typically wireless) connection to the Internet. They are typically controlled though smartphone applications (apps), with smart devices typically interfacing with controller apps for control and notification purposes thorough a remote cloud. Such systems have the advantage of being able to be operated and maintained remotely. However, they provide a relatively low level of security since they can be rendered ineffective by disabling their connection to the cloud. An increasingly broad range of smart systems are available, such as smart appliances, smart lighting, smart heating etc. where the focus is generally enabling users to control or monitor aspects of their home environments form their smartphones.

[0006] Conventional monitoring systems suffer from a lack of integration. This applies to both on-prem system and smart systems. Smart devices offered by different vendors are often typically disconnected, requiring a user to install and configure multiple controller apps.

[0007] On-prem monitoring systems also suffer from a lack of integration. For example, a typical on-prem setup might include an intruder detection system with one set of physical on- prem infrastructure, an CCTV system with a second, entirely independent set of physical infrastructure, and a third door access system which is independent from both. With such a setup, it is typically down to a human operator (e.g. on-prem security staff) to monitor and control both systems.SUMMARY

[0008] A first aspect herein is directed to a computer system for monitoring a premises, the computer system comprising:• a first set of on-premises monitoring devices;• a second set of on-premises monitoring devices;• an on-premises server coupled to the first set of on-premises devices and the second set of on-premises devices via on-premises infrastructure, the on-premises server comprising:o computer storage configured to store a set of arming profiles, each arming profile associated with a set of triggering conditions and a set of actions associated with the triggering conditions, o and at least one processor configured to execute:■ a first monitoring service operable to communicate with the first set of on-premises devices;■ a second monitoring service operable to communicate with the second set of on-premises devices independently of the first control service and the first set of on-premises devices;■ an integration layer communicatively coupled to the first control service and the second control service to receive first and second events from the first control service and the second control service respectively; and■ a rules engine configured to select from the set of arming profiles responsive to a profile selection input an arming profile, continuously monitor the first events and the second events against the set of triggering conditions associated with the selected arming profile, and trigger at least one action associated with one of the triggering condition responsive to determining that the triggering condition is satisfied, the set triggering conditions dependent on the first events and the second events.

[0009] The system herein provides open integration to multiple subsystems, facilitating (among other things) a multi-vendor solution as well as ‘swap-ability’ of subsystems. Using the open integration mechanisms taught herein, a bespoke modular system can be built and modified with ease, e.g. using multi-vendor technology that is not interoperable ‘out of the box’.

[0010] The system enables extensible combining of events and / or conditions from subsystems in an on-prem rules engine to drive granular alarms, actions and / or other outputs, through appropriate definition of the arming profiles and their associated rules / conditions.

[0011] In embodiments, the triggering condition may be dependent on a first event received from the first control service via the integration layer, and a second event received from the second control service via the integration layer.

[0012] The computer storge may embody an integration database containing entity identifiers, each entity identifier associated with one or more on-premises monitoring devices, wherein at least one entity identifier is associated with: a first device identifier of a first device within the first set of on-premises monitoring devices, and a second device identifier of a second device within the second set of on-premises monitoring devices.

[0013] The ability to compose real-world entities from devices from more than one subsystem in an open manner is a powerful integration tool.

[0014] For example, devices from different systems may be modelled into real world entities (e.g., a ‘door’ entity, being part Access system and part Intruder Sensor).

[0015] The triggering condition or the at least one action associated with the triggering conditions may be dependent on the entity identifier.

[0016] The at least one action may comprise triggering a notification based on the entity identifier. For example, the notification may be dependent on a status of the first monitoring device associated with the entity identifier and a status of the second monitoring device associated with the entity identifier.

[0017] The computer system may comprise a user interface (e.g. graphical user interface) configured to receive the profile selection input

[0018] The on-premises server may be communicatively-coupled to a remote server.

[0019] The on-premises server may be configured to receive the profile selection input via the remote server.

[0020] The set of triggering conditions and the set of actions associated with the triggering conditions for each of the stored arming profiles may be received via the remote server.

[0021] The remote server may be hosted in a cloud computing infrastructure.

[0022] The integration layer may be configured to store the first and second events in an event database.

[0023] The computer system may further comprise a user interface configured to receive the profile selection input.

[0024] According to a second aspect of the disclosure there is provided a computer- implemented method for monitoring a premises, the method implemented at an on-premises server and comprising: storing a set of arming profiles, each arming profile associated with a set of triggering conditions and a set of actions associated with the triggering conditions, communicating with a first set of on-premises devices; communicating with a second set of on-premises devices independently of the first set of on-premises devices; receiving first and second events from the first set of on-premises devices and the second set of on-premises devices respectively; selecting from the set of arming profiles responsive to a profile selection input an arming profile; monitoring the first events and the second events against the set of triggering conditions associated with the selected arming profile; and triggering at least one action associated with one of the triggering condition responsive to determining that the triggering condition is satisfied, the set of triggering conditions dependent on the first events and the second events.

[0025] In embodiments, an entity identifier is associated with one or more on-premises monitoring devices, wherein at least one entity identifier is associated with: a first device identifier of a first device within the first set of on-premises monitoring devices, and a second device identifier of a second device within the second set of on-premises monitoring devices.

[0026] The triggering condition or the at least one action associated with the triggering conditions may be dependent on the entity identifier.

[0027] The at least one action may comprise triggering a notification based on the entity identifier.

[0028] The notification may be dependent on a status of the first monitoring device associated with the entity identifier and a status of the second monitoring device associated with the entity identifier.

[0029] According to a third aspect of the disclosure there is provided a computer program comprising executable instructions configured, when executed on one or more hardware processors, to implement the method defined in the second aspect.

[0030] The remote server may be configured to receive user input to select the profile selection input.

[0031] The optional features defined above in relation to the third aspect may be combined in any combination. Accordingly, each sentence in the optional features defined above can be read as if it is a dependent claim referring to the features of any preceding sentence.

[0032] Furthermore, the optional features of the first, second and third aspect may be combined in any combination.BRIEF DESCRIPTION OF FIGURES

[0033] For a better understanding of the present subject matter, certain embodiments will now be described by way of example only with reference to the following figures, in which:

[0034] FIG.l shows a schematic block diagram of an example monitoring system;

[0035] FIG.2 shows a schematic block diagram of an example on-prem server;

[0036] FIG.3 shows a schematic block diagram of example arming profiles;

[0037] FIG.s 4A-4D shows various views rendered in a graphical user interface.

[0038] In the drawings, corresponding reference characters indicate corresponding components. The skilled person will appreciate that elements in the figures are illustrated for simplicity and clarity. Also, common but well-understood elements that are useful in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various example embodiments.DETAILED DESCRIPTION

[0039] Herein, an on-prem monitoring system is provided, with greatly improved integration and scalability. In certain embodiments, the on-prem system is additionally equipped with an interface to a remote (e.g. cloud-based) service, facilitating a greater range of remote monitoring and control operations, but without the drawbacks of conventional smart systems.

[0040] FIG. 1 shows on the left-hand side a schematic block diagram of an on-prem monitoring system, which in turn is shown to comprise a central on-prem server 100. The on-prem monitoring system (including the on-prem server 100) is located local to a premises being monitored.

[0041] A premises could for example be a building or collection of buildings, a vessel, aircraft etc.

[0042] FIG. 1 shows multiple on-prem devices connected to the on-prem server 100, which may for example include a combination of sensors 110 (typically with different types of sensor), alarms 115 and access mechanisms 120. Sensors 110 may, for example, include one or more cameras, such as CCTV cameras and / or NVRs (network video recorders).

[0043] The on-prem server 100 includes a processor 102 (such as a CPU) equipped with memory (or multiple such processors) and is coupled to computer storage 104 (such as solid state or magnetic storage). Computer-readable instructions (code) are loaded into the memory for execution on the processor(s) 102 and, upon execution cause the processor(s) 102 to carry out the functions of the on-prem server 100 described below. At least one database is embodied in the memory or computer storage 104 (or a combination of both) to enable the collection, storage and access of structured data.

[0044] Communication between the on-prem server 100 and the on-prem devices is facilitated by local network infrastructure (such as on-prem routers, switches etc.) and is not reliant on any external connection to the Internet. The premises boundary is defined by the connectivity range of the local network infrastructure (whether wired or wireless), and the on- prem devices and on-prem server 100 sit within this premises boundary.

[0045] On the right hand side, a remote monitoring and control service is shown (referred to as the cloud service for brevity), which is executed on a remote server 150 (or servers). Communication between the on-prem server 100 and the remote server 150 is conducted via an external Internet connection, meaning the remote server 150 sits outside of the premises boundary. For example, the remote monitoring and control service may be executed within a cloud computing infrastructure 155.

[0046] As described in more detail below, the on-prem server 100 facilitates a complete, integrated on-prem monitoring solution that is not reliant on the external connection to the Internet, and which is fully functional without requiring a persistent connection to the remote server 150.

[0047] A first on-prem device 130 is shown connected to the on-prem server 100. The on- prem device 130 has direct connectivity to the on-prem network infrastructure, and therefore also sits within the perimeter boundary.

[0048] A second off-prem device 160 is shown in communication with the remote monitoring and control service. An additional layer of remote monitoring and control functions are provided to the second device 160 by the remote monitoring and control service.

[0049] Note, the on-prem device 130 may also be capable of interfacing with the remote monitoring and control service, enabling both on-prem and off-prem functions to be accessed from the same device.

[0050] FIG. 2 shows a schematic function block diagram of the on-prem server 100, with further details of the on-prem infrastructure supported by the on-prem server 100.

[0051] The on-prem server is configured to support multiple independent monitoring subsystems. First 202, second 204 and third 206 subsystems are shown purely by way of example, however, the following description applies equally to any number of subsystems. In a commercial setting, such subsystems would typically be provided by different vendors or manufactures, and in a conventional set-up would operate in a ‘closed’ manner.

[0052] However, in the present system, the on-prem server 100 includes an integration layer 210 which provides much improved integration between the different subsystems.

[0053] The first 202, second 204 and third subsystems 206 are shown to comprise first 212, second 214 and third 216 monitoring and control services. The first 212, second 214 and third 216 monitoring and control services are implemented as applications executed on the on-prem server 100. Whilst these operate as mutually-independent software services, each exposes an application programming interface (API) 222, 224, 226 via which the integration layer 210 can communicate with each of them.

[0054] Each sub-system comprises a subset of the on-prem devices, which interface with that sub-system’s monitoring and control service, also referred to as control service herein.Hence, in this example, the first subsystem 202 comprises a first subset of on-prem devices that interface with the first control service 212, the second subsystem 204 comprises a second subset of on-prem devices that interface with the second control service 214 etc.

[0055] Among other things, the integration layer 210 receives incoming events from the different control services, and stores those events in an event database 215 (or databases). Events received from a given control service are incoming messages pertaining to the subsetof on-prem devices under its control. Such event may communicate the status of sensors (e.g. when a sensor has been activated), alarms (e.g. when an alarm has been triggered), or has stopped functioning, access mechanisms (e.g. when a door ow window has been unlocked) and the like. Events may also indicate status changes such a device developing a fault, or communication to a device being lost. The storing of events by the integration layer 210 may involve additional processing, such as restructuring or otherwise modifying event data to facilitate downstream processing.

[0056] An important aspect function provided by the on-prem server 100 is the ability to define and set different “arming profiles” 250A-D. Multiple arming profiles may be defined, and any one of these can be selected at a given time. The arming profile may be selected manually, or automatically in response to a profile change event (e.g. according to a predetermined schedule).

[0057] A rules engine 260 is executed on the on-prem server 100. The rules engine 260 continuously monitors events stored in the event database(s) 215 and triggers defined actions when associated triggering conditions are satisfied by the monitored events.

[0058] As depicted in FIG. 3, each arming profile defines a set of actions and a set of associated triggering conditions applied within the rules engine. A triggering condition may be associated with one or more actions. Hence, different actions and triggering conditions may be set by changing the selected arming profile.

[0059] Remote actions can be triggered at an off-prem device 160 via the cloud service 155.

[0060] Actions can be customized at any desired level of granularity. For example, under one arming profile, a particular triggering condition (such as opening a door to an area when a ‘privacy’ profile is set) might simply trigger a text-based notification at an on-prem device 130 and / or off-prem device 160. However, when another arming profile is set, the same triggering condition might trigger an audible alarm on-prem and / or off-prem (e.g. when the same door is opened and an ’away’ profile is set).

[0061] Note that the rules engine 260 is able to trigger actions the different subsystems 202, 204, 206. Moreover, and event or events from one subsystem (e.g. a sensor being activated in the first subsystem) might result in an action being triggered in another system (e.g. activating an alarm in the second subsystem). The rules engine 260 is coupled to the integration layer 210 to enable actions to be coordinated across the different subsystems.Triggering conditions can also be dependent on events from multiple subsystems. For example, a particular action might only be triggered when a first sensor in the first system 202 is activated and a second sensor in the second subsystem 204 is also triggered.

[0062] To simplify the coordination of event and actions across systems, an integration database 270 is also provided. The integration database 270 is used to store association between devices and “assets” or other entities, identified by asset / entity identifiers 272 (IDs). An asset may correspond to a physical asset (such as a door or a particular area within the premises). However, more generally, an asset ID 272 is an identifier used to link different on-prem devices (identified by device IDs, where a device ID 274 identifies a device and the subsystem to which the device belongs. On-prem devices belonging to different systems may be associated with same asset ID 272. For example, a door within the premises might be secure with a door sensor within the first subsystem 202 (activated when the door is opened) and a door access mechanism within the second system 204 (to lock or unlock the door). The relationship between the door sensor and door access mechanism is recorded in the integration database 270, by associating their respective device IDS 274 which a common asset ID 272. This, in turn, allows triggering conditions and actions to be defined within the rules engine 260 in terms assets. For example, for reporting purposes, it becomes possible to indicate a detailed status of a given asset (e.g., marking the door as both locked and closed). As another example, a particular action might be triggered in dependence on an asset status (e.g. if a door is reported as being both locked and open, and that might indicate the door has been forced open, or a fault in one of the associated on-prem devices).

[0063] An interface layer 240 is provided within the on-prem server 100, which facilitates communication with the on-prem device 242 and the remote cloud service 244. Among other things, this enables a user to manually select a desired arming profile 250, locally or remotely.

[0064] As another example, exit / entry routes could be defined by different sequences of door identifiers, and linked to different arming profiles. Thus, when one arming profile is set, a particular route might be ‘opened’ by automatically disabling door alarms in an alarm subsystem (meaning those door sensors do not trigger an intruder alarm) and unlocking the doors in an access control system. Elsewhere in the premises, the triggering conditions might set to trigger intruder alarms for doors outside of the approved route. When a different alarm profile is set, associated with a different door sequence, those systems are configuredautomatically to implement the new profile settings via the integration layer 210. As another example, one subsystem might provide a specific security function (such as drone detection in the vicinity of a premises), which is integrated with other security sub system(s) (such as intruder alert, access control etc.). A panic alarm system could also be integrated in the other way with other systems such as security or medical monitoring systems.

[0065] The integration layer 230, flexible rules engine 260 and configurable arming profiles enable a wide range of integration possibilities. For example, medical monitoring of a person from one subsystem could be integrated with environmental monitoring from another subsystem (such as environmental temperature, oxygen levels, humidity etc.) via the integration layer 210 of the on-prem server supported by the cloud service 150. The described architecture can accommodate a wide range of integration applications supported by continuous monitoring across otherwise independent systems and granular actions and triggering conditions that can be flexibly defined in configurable arming profiles.

[0066] In the present context, an arming profile defines a set of ongoing monitoring conditions and associated actions. The system generally operated with an arming profile set at all times, although an arming profile might be set to perform only ‘soft’ actions, such as generating text-based notifications.

[0067] FIG. 4A shows an example user interface which enables a user to remotely select and set an arming profile for a premises.

[0068] On the left-hand side of the figure, layouts 405 of a building being monitored is shown. Each layout of each level shows multiple rooms, a corridor joining the rooms and doors into and out of the corridor and the rooms. On the layout of each level, locations of CCTV cameras are labelled with pictures of small cameras, for example the camera denoted by reference numeral 407. Although cameras are shown in the figure, other types of monitoring device may be presented on the layout 405, e.g., a motion sensor.

[0069] At the bottom of the figure, video panes 412A-D show video footage captured by cameras 414A-D. The cameras 414A-D are chosen by the user from a drop down list. The drop down list contains cameras that correspond to those cameras shown in the layouts 405 of the levels of the building. For example, video pane 412C shows the footage captured by camera 414C, as chosen by the user. The camera 414C may correspond to the camera denoted by reference numeral 407, as shown on the layouts 405 of the building levels.

[0070] The right-hand side of the figure shows a user selecting an arming profile 416. In the example shown in the figure, the arming profile 416 is selected by a user from a drop down list. The arming profiles shown in the drop down list have predetermined triggering conditions. For example, the ‘Night’ arming profile shown in the drop down list may trigger a notification if a door is opened, as no one is expected to be in the building at night. In contrast, the ‘Day’ arming profile shown in the drop down list would not have such a triggering condition as people are expected to be in the building and therefore opening doors during the day.

[0071] A door profile 415 is also selected from a drop down list by a user. In embodiments, the door profile is a list of doors and a statement for each door in the list of doors as to whether they are to be locked or unlocked. A door profile can be applied as a means of setting the state of many door locks in one go.

[0072] The right-hand side of the figure also shows a list of the cameras 418 shown in the building layouts 405. The list 418 shows the name of the camera, or monitoring device, an ID of the camera and the status of the camera. This enables the user to see which cameras are faulty, and therefore not working properly. If a notification is therefore triggered, as defined in the selected arming profile 416, by a camera that is identified as faulty in the list 418, the user can investigate further. The list 418 also shows the last activity of the cameras or monitoring devices. The last activity gives a clue to the health of the device and / or the frequency of the events.

[0073] FIG. 4B shows an example user interface 420 which enables a user to investigate a premises which has triggered a notification as defined by an arming profile 416.

[0074] The left-hand side of the user interface 420 shows a list of sites, or premises, 422 being monitored. The list 422 contains the names of the sites being monitored, an indication of the health of the site and an indication of whether a triggering condition according to an arming profile has been met.

[0075] The indication of the health of the site is a summary of how many faults it has and how critical those faults are. For example, if a site is “offline” it is unreachable. The indication of the health of the site is denoted by reference numerals 435, 436 and 437 where 435 is “healthy”, 436 is “medium risk” and 437 is “high risk”. The indication of whether atriggering condition has been met may be shown by an alarm symbol. For example, the alarm symbol denoted by reference numeral 428.

[0076] The user interface 420 shows a map 424. The map 424 contains pins showing the locations of the sites named in the list 422. The pins also show whether the site at that location is online or offline. For example, pin 430 shows that the site at that location is offline as it contains a cross symbol.

[0077] Pin 432 on the map 424 does not contain a cross indicating that the site at that location is online.

[0078] The right-hand side of the user interface 426 shows the number of sites and devices being monitored. In the example shown in the figure, 11 sites are listed with 9 online and 2 offline. In the 11 sites, 474 devices are being used to monitor the sites. The user interface also shows the number of devices which are healthy or faulty. Again, this information can be used by the user to determine whether to further investigate a site where an alarm or notification has been triggered according to a selected arming profile.

[0079] Below the number of sites and devices, a list of faults 434 shows the health of the devices on the sites. For example, an entry in the list corresponds to a camera going offline.

[0080] FIG.4C shows an example user interface 440 displaying a list of faults 442 that have been detected on devices used to monitor sites, or premises, remotely. The list of faults 442 may be used to identify and prioritise devices with faults that are to be fixed.

[0081] Each entry in the list of faults 442 contains a fault date 444, a site ID 446, a name of the site which contains the faulty device 448, an indication of the site health 450, a device ID 452, a device engineer name 454, a device friendly name 456, a criticality indication 458, a manufacturer 460, a model 462, a fault status 464 and a fault description 466.

[0082] Fault date 444 entries display the date and time in which a fault on a device was detected. The site ID 446 is a unique identification number assigned to the site, for example the premises at the locations previously shown in FIG.4B. The site 450 entries are the names of the premises in which the devices are located. The site health 452 for each entry provides an indication as to the overall (fault count & severity driven) health of the site which hosts this particular fault item. The device ID 452, as described previously with reference to FIG.s 2 and 3, is a unique identifier for the device that has a fault. The device engineer name 454entries correspond to a name of the device given to an engineer to fix the fault in the device, e.g., the engineer name may refer to a design document or map. The device friendly name 456 entries correspond to a name that is meaningful to end users. For example, a camera may be “Hik-120-PTZ” for an engineer but would be “Front Door Cam” for an end user.

[0083] An indication of the criticality 458 device is provided for each entry in the list 442. In embodiments, the indication of the criticality 458 is used to prioritise fixing faults in the devices. For example, the faults identified as minor are fixed after the faults identified as major. The criticality indication of a device (and thus its faults) therefore informs a support organization of the importance of it to a system. The device manufacturer 460 and model 462 entries of the list 442 can be used by an engineer to determine how to fix the faulty device. The fault status 464 indicates that the device is faulty and the fault description 466 describes the nature of the fault.

[0084] FIG. 4D shows an alternative example user interface which enables a user to remotely select and set an arming profile for a premises. In this example, the layout 485 shows a boat that is being monitored according to the methods presented herein. The components of the user interface described with reference to FIG. 4A apply correspondingly to FIG.4D. In the layout 485, multiple types of monitoring devices are shown. Each symbol in the layout show the type of the device (fixed camera, pan-tilt- zoom camera, door, PIR sensor etc). The colour red 486 or green 487 broadly indicates if something is secure or not: A unlocked or open door indicates insecure for example. Additionally in the layout 485, warning signs are shown to denote locations of devices which are offline, in-fault or temporarily isolated.

[0085] The list 498 shows the name of the monitoring device, an ID of the monitoring device and the status of the monitoring device. This enables the user to see which devices are faulty, and therefore not working properly. If a notification is therefore triggered, as defined in an arming profile 496, by a device that is identified as faulty in the list 498, the user can investigate further. The list 498 also shows the last activity of the monitoring devices. The last activity date-time provides an indication as to the health and security of the device as the date-time may not be as expected by the user.

[0086] The examples of the user interfaces described with reference to FIG.s 4A-4D may be rendered on the on-prem server local to the premises which is being monitored. Alternatively, the user interfaces may be rendered on a remote server hosted remotely on a cloud service, asdescribed with reference to FIG. 1. The terms “site” and “premises” may be used interchangeably throughout the embodiments presented herein.

Claims

Claims1. A computer system for monitoring a premises, the computer system comprising: a first set of on-premises monitoring devices; a second set of on-premises monitoring devices; an on-premises server coupled to the first set of on-premises devices and the second set of on-premises devices via on-premises infrastructure, the on-premises server comprising: computer storage configured to store a set of arming profiles, each arming profile associated with a set of triggering conditions and a set of actions associated with the triggering conditions, and at least one processor configured to execute: a first monitoring service operable to communicate with the first set of on-premises devices; a second monitoring service operable to communicate with the second set of on-premises devices independently of the first control service and the first set of on-premises devices; an integration layer communicatively coupled to the first control service and the second control service to receive first and second events from the first control service and the second control service respectively; and a rules engine configured to select from the set of arming profiles responsive to a profile selection input an arming profile, continuously monitor the first events and the second events against the set of triggering conditions associated with the selected arming profile, and trigger at least one action associated with one of the triggering condition responsive to determining that the triggering condition is satisfied, the set triggering conditions dependent on the first events and the second events.

2. The computer system of claim 1, wherein the triggering condition is dependent on a first event received from the first control service via the integration layer, and a second event received from the second control service via the integration layer.

3. The computer system of claims 1 or 2, wherein the computer storge is an integration database containing entity identifiers, each entity identifier associated with one or more onpremises monitoring devices, wherein at least one entity identifier is associated with: a first device identifier of a first device within the first set of on-premises monitoring devices, and a second device identifier of a second device within the second set of on-premises monitoring devices.

4. The computer system of claim 3, wherein the triggering condition or the at least one action associated with the triggering conditions is dependent on the entity identifier.

5. The computer system of claims 3 or 4, wherein the at least one action comprises triggering a notification based on the entity identifier.

6. The computer system of claim 4, wherein the notification is dependent on a status of the first monitoring device associated with the entity identifier and a status of the second monitoring device associated with the entity identifier.

7. The computer system of any preceding claim, wherein the on-premises server is communicatively-coupled to a remote server.

8. The computer system of claim 7, wherein the on-premises server is configured to receive the profile selection input via the remote server.

9. The computer system of claims 7 or 8, wherein the set of triggering conditions and the set of actions associated with the triggering conditions for each of the stored arming profiles are received via the remote server.

10. The computer system of any of claims 7 to 9, wherein the remote server is hosted in a cloud computing infrastructure.

11. The computer system of any preceding claim, wherein the integration layer is configured to store the first and second events in an event database.

12. The computer system of any of claims 1 to 7, wherein the computer system further comprises a user interface configured to receive the profile selection input.

13. A computer-implemented method for monitoring a premises, the method implemented at an on-premises server and comprising: storing a set of arming profiles, each arming profile associated with a set of triggering conditions and a set of actions associated with the triggering conditions, communicating with a first set of on-premises devices; communicating with a second set of on-premises devices independently of the first set of on-premises devices; receiving first and second events from the first set of on-premises devices and the second set of on-premises devices respectively; selecting from the set of arming profiles responsive to a profile selection input an arming profile; monitoring the first events and the second events against the set of triggering conditions associated with the selected arming profile; andtriggering at least one action associated with one of the triggering condition responsive to determining that the triggering condition is satisfied, the set of triggering conditions dependent on the first events and the second events.

14. The method of claim 13, wherein an entity identifier is associated with one or more on-premises monitoring devices, wherein at least one entity identifier is associated with: a first device identifier of a first device within the first set of on-premises monitoring devices, and a second device identifier of a second device within the second set of on-premises monitoring devices.

15. The method of claim 14, wherein the triggering condition or the at least one action associated with the triggering conditions is dependent on the entity identifier.

16. The method of claims 14 or 15, wherein the at least one action comprises triggering a notification based on the entity identifier.

17. The method of claim 16, wherein the notification is dependent on a status of the first monitoring device associated with the entity identifier and a status of the second monitoring device associated with the entity identifier.

18. A computer program comprising executable instructions configured, when executed on one or more hardware processors, to implement the method of any of claims 10 - 17.

19. The computer system of claim 8 comprising the remote server, wherein the remote server is configured to receive user input to select the profile selection input.

Images