GB2409320A - Alarm system having computerized processing means - Google Patents

Abstract

An alarm system includes first processing means 1 which implement a software alarm object 10, a plurality of sensors 4 connected to a control unit 51, and an interface 6 connecting the control unit to second processing means 2 which implement a control application 20. The control application and alarm object are linked via first communication means 23, and the alarm object and a response application 30 are linked via second communication means 33. The response application 30 is implemented by a third processing means 3. The control unit responds to a signal from one of the sensors, and sends an alarm signal 61 via the interface to the control application, which then sends a control message to the alarm object via the first communication means. The control message sets the state of the alarm object according to the data from the original sensor, and the alarm object then sends a corresponding alarm message (an event) to the response application which then carries out a pre-programmed response. The processing means may be provided in a personal computer or server, and control and/or alarm messages may be sent in http format.

Description

ALARM SYSTEM

Field of the Invention

The present invention relates to alarm systems, and in particular, although not exclusively, to alarm systems incorporating a number of separate sensor systems, each having a respective control unit.

Background to the Invention

It is common for buildings, especially commercial properties, to contain a number of sensor systems, with corresponding control units. For example, a building may contain a fire alarm system, with alarm sensors for manual activation and smoke detectors, an intruder alarm system, with a number of movement sensors, and a building management system, with sensors arranged to indicate various building parameters, such as temperature at a variety of locations.

Most manufacturers of various building systems, including Fire, Security, CCTV, Access Control and Building Management Systems (BMS) provide some means of networking their systems together. These networked systems usually utilise manufacturer-specific communications protocols and only allow for the connection of the specific manufacturers equipment.

Each sensor system, and indeed the combination of the sensor systems, can be regarded as an alarm system, in the sense that it responds in some way to an activation, or other change of state, of the sensors The response may be to bring the sensor activation to the attention of someone, and/or to control a piece of equipment accordingly.

If a client has multiple buildings within the same site, these separate buildings may contain control equipment from different manufacturers. Connecting these systems together to provide a common interface where management and reporting tasks can be easily carried out has, in the past, been a complex operation requiring special interface units from the various manufacturers.

Accordingly, it is an aim of certain embodiments of the invention to provide a less complex integrated alarm system, and alarm systems which can easily be adapted to incorporate various sensor systems, for example from different manufacturers.

Embodiments also aim to provide alarm systems which facilitate interconnection of sensor systems in different locations, and/or alarm systems which can easily be expanded to accommodate further sensor systems and alarm-responsive applications.

Summary of the Invention

According to the present invention there is provided an alarm system comprising: first processing means arranged to implement a software alarm object, the alarm object having a state defined by at least one variable; a plurality of sensors connected to a control unit; an interface connecting the control unit to second processing means, the second processing means being arranged to implement a control application (i.e. a first software application, or control software), first communication means arranged to provide communication between the control application and the alarm object; third processing means arranged to implement a response application (i.e. a second software application, or response software); second communication means arranged to provide communication between the alarm object and the response application, the control unit being responsive to a signal originating from one of the sensors to send a corresponding alarm signal indicative of an identity of the originating sensor via the interface to the control application, the control application being responsive to said alarm signal to send a corresponding control message (which may also be described as an alarm initiation message) indicative of said identity to the alarm object via the first communication means, the control message setting the state (i.e. setting at least one state variable) of the alarm object according to said identity and the alarm object being responsive to the control message to send a corresponding alarm message via the second communication means to the response application, the response application being responsive to the alarm message to carry out a pre- programmed response.

The alarm message may also be referred to as an event. Thus, the control application is able to set, or trigger, an event, the alarm object then sending the event to the response application to cause it to carry out a programmed action.

It will be appreciated that the configuration of an alarm system embodying the invention provides the advantage that different sensor systems, with their respective control units, may be easily accommodated by suitable coding of the control application, i.e. to accommodate different hardware only a software modification is required. A change in the sensor system, or indeed the addition of another sensor array and control unit, does not require any modification of the alarm object or the response application; the changed or additional sensor system simply requires a modified control application, interfaced to receive signals in the format provided by the sensor system, which "converts" these hardware- specific signals into the single format required by the alarm object.

Thus, the system may be expanded to include a variety of different sensor systems, each interfaced to a control application programmed to convert its signals into the common format for controlling the alarm object.

Similarly, the system can easily be expanded to include a number of different response applications, each coded to respond in the appropriate manner to messages in a common format from the alarm object.

In certain preferred embodiments, the response application is responsive to the alarm message to inspect the state of the alarm object (i.e. to inspect at least one state variable) and carry out a pre-programmed response according to that state.

Preferably, the alarm message includes at least one state variable (i.e. as a parameter or parameters to the message) and the response application carries a pre- programmed response according to the included state variable(s). In such instances, the response application need not inspect the alarm object.

Advantageously, the alarm object may be configured to send a plurality of alarm messages (i.e. different alarm messages), the control message determining which alarm message is sent, according to the signal from the originating sensor.

In certain preferred embodiments the system comprises a plurality of response applications, each being implemented on respective third processing means and communicating with the alarm object via respective second communication means.

The alarm object is then configured to send (i.e. is triggerable to send) a plurality of alarm messages, and each response application is configured to respond to at least one of these alarm messages.

Preferably, at least one of the response applications is configured to respond to a plurality of the alarm messages by carrying out respective pre-programmed responses. In other words, the response application can carry out different operations or processes according to which message it received from the alarm object.

Typically, the control message from the control application determines which of the plurality of alarm messages is sent. The control application may be adapted to control the alarm object to send a selected alarm message according to the signal from the originating sensor.

Thus, which alarm message is sent is determined by the control message received by the alarm object. A control application interfacing with a plurality of sensors may be arranged to trigger a number of different alarm messages from the alarm object, depending on the signal from the originating signal, for example, depending on whether the sensor is sending an alarm signal or a fault signal. In embodiments where a number of different control applications can trigger the alarm object, each control application being interfaced to a respective set of sensors, the triggered alarm message may be dependent on the type of sensor system originating the alarm, e.g. whether it is from a set of fire alarm sensors, movement sensors, or a system of building management sensors.

In certain preferred embodiments the alarm system comprises a plurality of control units, each connected to a respective plurality of sensors; and a plurality of interfaces, each connecting a respective control unit to a respective second processing means arranged to implement a respective control application communicating with the alarm object via respective first communication means, each control application being configured to send respective control messages to the alarm object.

The control units of the various sensor sets may provide alarm signals in different formats to the respective control applications. However, all of the control applications are arranged to "convert" these alarm signals into control messages having the same, common format for setting and triggering the alarm object.

Preferably, the alarm object is configured to send a plurality of alarm different messages and each control application is configured to send a respective control message to cause the alarm object to send at least one of the plurality of alarm messages.

In certain embodiments, at least one of the control applications is configured to send a respective control message to cause the alarm object to send a selected one of a plurality of the available alarm messages.

Thus, each control application may be able to trigger the sending of at least one alarm message. Preferably, at least one of the control applications can trigger the alarm object to send a number of the different alarm massages, and at least one of the control applications may be able to trigger the alarm object to send any one of the alarm messages.

Advantageously, the control and/or alarm messages are sent in the wellknown http format.

It will be appreciated that the first, second, and third processing means may be provided in a single device (e.g. personal computer or server). However, in certain preferred embodiments, at least two of said first, second, and third processing means are located in separate devices.

Sending the control and alarm messages in http format facilitates communication between control applications, response applications, and alarm objects located on different processing machines, and enables the alarm system to be distributed.

In preferred embodiments the first communication means may comprises at least one of: a LAN connection; a WAN connection; and an internet connection.

Thus, the first and second processing means may be provided by different machines on the same LAN (local area network) or WAN (wide area network), or on different LANs or WANs connected via the internet. Similarly, the second communication means may comprise at least one of: a LAN connection; a WAN connection; and an internet connection. The second and third processing means may be provided by different machines on the same or different LANs or WANs.

Preferably, the alarm system further comprises fourth processing means arranged to implement a database application (which may also be referred to as database software), the control application(s) being arranged to send a database signal via fourth communication means to the database application in response to the signal from the originating sensor, the database signal being indicative of the identity of the originating sensor, and the database application being arranged to log the database signals.

At least one response application may then be arranged to interrogate the database application in response to an alarm message from the alarm object. For example, the response application may be a reporting application adapted to provide an indication, to a user, of part of the alarm event history of the system.

Certain preferred embodiments include a response application that is responsive to all of the different types of alarm message from the alarm object, and arranged to update a database in response to each message to create a log.

Embodiments of the invention may, for example, include response applications of the following types: Graphical Display Interfaces (controlling a display device to display an image, such as a map showing the location of the originating sensor, in response to the alarm message); event logging and/or reporting applications; paging system interfaces (controlling the sending of a pager signal in response to the appropriate alarm message, the pager signal optionally including information on the identity/location of the originating sensor); SMS software applications for sending SMS signals; Email applications for sending email messages; printing and fax applications generating and sending information; applications for sending signals to the emergency services; and control equipment interfaces controlling some equipment in response to the appropriate alarm message (for example, a control equipment application arranged to operate a sprinkler system).

Other applications will be apparent to those skilled in the relevant art. Thus, various applications may send out signals, messages, or produce outputs in response to appropriate alarm messages being received from the alarm object, and those signals/messages/outputs may contain information indicative of the identity of the originating sensor.

Embodiments of the invention may, for example, include control applications of the following types: fire alarm applications; building security applications; CCTV applications; access control applications; and building management system applications.

The alarm object may, for example, be configured to send one or more alarm messages of the following types: Alarm; Pre Alarm; Fault; Fire; Common Fault; Fault; High Level Alarm; Low Level Alarm; Critical Alarm; Intruder Alarm; Silence; Reset; Isolated; Restored; General Fault; and System.

Preferably, the at least one variable defining the alarm object state comprises a variable indicative of the identity of the originating sensor.

In certain embodiments the alarm object state is defined by a plurality of variables. These may include at least one variable indicative of a state of the originating sensor (i.e. of an alarm condition), and/or at least one variable indicative of a location of the originating sensor.

It will thus be apparent that certain embodiments of the invention incorporate a distributed software application which allows the integration, reporting and management of a building's various types of control systems.

The control applications may comprise software control objects, and the response applications may comprise software response objects.

Thus, certain embodiments of the invention integrate different types of sensor systems by utilising remote objects communicating with each other, or control and response applications communicating with an alarm object, over a standard protocol such as HTTP.

Brief Description of the Drawings

Embodiments of the invention will now be described with reference to the accompanying drawings, of which: Fig. 1 is a schematic representation of an alarm system embodying the invention, with the various software applications and the software alarm object running on a single PC; Fig. 2 is a schematic representation of another alarm system embodying the invention; Fig.3 is a schematic representation of another alarm system embodying the invention; Fig.4 is a schematic representation of another alarm system embodying the invention, in which the control and response application and the alarm object are implemented on separate machines in a LAN; Fig. 5 is a schematic representation of part of another alarm system embodying the invention; and Fig. 6 is a schematic representation of another part of the alarm system from fig.5.

Detailed Description of the Embodiments

Referring now to fig. 1, this is a block diagram showing an embodiment of the invention and how its various software elements fit together on a stand-alone PC. The PC is running a Microsoft.NET framework, and provides first processing means 1 implementing an alarm object 10, second processing means 2 implementing a control application 20 (which may also be referred to as a control object), and third processing means 3 implementing a response application 30 (which may also be described as a response object). The software alarm object l O has a state l l defined by a plurality of variables 111, 112, l 13, and also defines a plurality of events 12 which it can implement. These events are a plurality of different types of alarm message 121, 122, 123, 124, 125 which can be sent out. The alarm system also comprises a plurality of sets of alarm sensors 4 arranged on loops L1, L2, connected to control panels 5 which are themselves connected together on a control panel LAN 51. For clarity, only two sets of sensors, connected directly to one of the panels 5, are shown. One of the control panels 5 is connected via an interface 6 to the second processing means 2 implementing the control application 20. In response to a signal from one of the sensors 4, the control panel sends a corresponding alarm signal 61 to the control application 20. The arrangement is such that this alarm signal is indicative of the identity of the originating sensor (i.e. the triggered sensor). In this embodiment the signal from the sensor is also indicative of the state of the sensor, and may be an alarm signal, a fault signal, or a pre-alarm signal. In this example, the interface 6 comprises an RS232 communication port on the PC. The control object 20 is connected to the alarm object 10 by first communication means 23. According to the received alarm signal 61, the control object (which in this example is a fire alarm application and may also be described as a control connection object) composes a control message which it sends to the alarm object via the communication means 23.

The control message comprises a first part 21 and a second part 22. The first part 21 sets the state of the alarm object. In other words, it sets the properties (i.e. state variables) of the alarm object according to the initial signal from the originating sensor. The second part 22 causes the alarm object to perform one, or more, of its methods, i.e. it triggers the alarm object to send out a selected one of its alarm massages 12, again according to the initial signal from the originating sensor. Thus, in response to the control signal, the alarm object state is set according to the identity of the originating sensor. In this example, the control message is an http communication to the IF address localhost.

The response application, or object, 30 is connected to the alarm object via a second communication means 33. The alarm object 10 responds to the control signal component 22 by sending selected alarm message 123 to the response object 30 via this second communication means. This alarm message is also an http format communication to IP address local host, and may be described as a "respond to event" signal. The same alarm message 123 is also sent to the control application via the first communication means In this example, the object property l l l corresponds to alarm condition (i.e alarm, fault, or pre-alarm), property 112 is an identification variable (i.e. corresponding to the identity of the originating sensor), and property 113 is an alarm description (i.e. a description of the location of the originating sensor). The alarm object messages/events 121 to 125 correspond respectively to alarm, fault, pre- alarm, reset, and silence. The signal from the originating sensor has resulted in the alarm signal 61 being indicative of the pre-alarm condition. This in turn has determined the control message component 22, which then has triggered the alarm object to send alarm message 123, i.e. the corresponding pre-alarm message, to the response application. The response application (a report connection object) in this example is a graphical display software application, and is programmed to respond to the pre-alarm signal to cause a map to be displayed on the PC's monitor 31, showing the location of the originating sensor and also displaying the pre-alarm status of the sensor. The alarm message 123 has been sent to the response application 30 with properties 111, 112, 113 as parameters, so the response application does not need to inspect the state of the alarm object to provide the necessary display.

In this example, the control application 20 is only responsive to some of the alarm messages (in fact just to the reset and silence messages) and does not respond to the pre-alarm signal 123. If reset or silence messages were sent, the control application is arranged then to send corresponding signals 62 to the control panel and sensor system.

The alarm system of fig. 2 includes a plurality of distributed software objects.

The figure shows how the graphical display software 30 connects to the rest of the distributed elements, the combination of those elements being denoted by reference number 100. Features in common with the alarm system of fig. l are given the same reference numbers, and their operation and interaction will be understood from the preceding description. In addition to the control object 20, alarm object 10, and response object 30, the distributed software also comprises a database application and a web server. The database may be an SQL server, for example, and may be implemented on the same processing means as one or more of the other applications, or on separate processing means. Similarly, the web server may be on a common, or different machine. The control object 20 is a fire alarm application, and responds to an alarm signal 61 by sending a message 28 via communication means 27 to update the database. This sets an image field in the database corresponding to the identity of the originating sensor. The control object has also sent an appropriate control message 21,22 to the alarm object, triggering it to send out alarm message 124. The graphical display software responds by communicating with the webserver 32, causing the webserver to read the database 7 via communication means 29 and to display a page indicative of the database's current contents (i.e. its current state). The response application 30 is arranged such that whenever an alarm message 12 is sent from the alarm object, it in turn causes the webserver to refresh, so that the page displayed remains up-to-date with the alarm events. A plurality of internet web browsers 40 are connected via respective internet connections to the server, so the alarm system state can be accessed remotely.

Fig.3 shows an alarm system with two sensor system LANs, LANa and LANb (the individual sensors connected to each control unit 5 are not shown in the figure). LANa is a network of building security sensors and control units, and LANb is a network of fire alarm sensors and control units. Again, features in common with the previously described alarm systems are given the same reference numbers, and their operation and interaction will be already understood. This practice will be followed for subsequent figures. Respective interfaces 6a, 6b connect the external electronic equipment of the sensor/control unit LANs to respective control objects, i.e. to security application 20a and fire alarm application 20b. The control objects are able to send control signals 21a, 21b, 22a, 22b to set the alarm object variables 111,112,113 and to set the events in motion, i.e. to trigger the alarm object to issue appropriate alarm messages. Both control objects are configured to respond to reset and silence messages 124, 125. They can both trigger the alarm message, but set the alarm object state differently. For example, the security application would set the alarm condition variable 111 to "INTRUDER,, when raising the alarm event, whereas the fire application would set alarm condition to "FIRE". The system includes a plurality of response objects, a graphical display software object 30a, a second graphical display object 30b, database management software 30c, and a paging application 30d. When each response object receives the alarm message "ALARM" 121 from the alarm object, it inspects the state variables ofthe object via the communication means 33, and then responds accordingly (i.e. it is sensitive not just to being told that there is an alarm condition, but also to the nature of the sensor originating the alarm). The pager application, for example, responds by sending a signal 302 to a pager transmitter 303, via an interface 301.

Figure 4 shows an alarm system embodying the invention and incorporating software elements running on different PCs on a standard LAN comprising a hub 232 and spurs 233. An alarm object 10 is implemented on a personal computer 921 running Microsoft.NET framework and having a network address 192.168.92.1. This computer is connected to other computers on the LAN via a network card 231. Thus, control messages 21,22 are received, and alarm messages 121-125 are sent via communication means which comprise the network cards and the network connections therebetween. The system incorporates three sensor systems a, b, c, comprising sensors connected to respective control panel LANs. Each control panel LAN is interfaced to a corresponding control object 20. Control objects 20a, 20b, and 20c are implemented on separate personal computers 926, 925, 924 (running Microsoft.NET framework) having addresses 192.168.92.6, 192.168.92.5 and 192.168.92.4 respectively. Two response objects 30a and 30b are implemented on separate PCs 922, 923 having addresses 192.168.92.2 and 192.168.92.3 respectively.

Any of the sensor systems can trigger an alarm event, by simply sending a signal to one of its associated control units. The control unit sends an alarm signal 61 to its control application 20, which then sends an appropriate control message 21,22 to the alarm object over the PC LAN. The control message is in HTTP format, addressed to the PC hosting the alarm object (i.e. to address 192.168.92.1 in this example).

Similarly, via the PC LAN, the alarm object can send out alarm messages, e.g. 124, to any and all responsive applications. It is a relatively simple matter to extend the system to include additional sensor sets and responsive devices. Each one simply requires an associated software object able to translate signals into the appropriate format used and understood by the alarm object.

In the above examples, the control applications 20, in addition to triggering alarm object messages, are able to respond to at least some of the alarm messages.

Hence they can be considered to be response applications/objects as well.

Figs. 5 and 6 together illustrate a further embodiment (the separate parts of the system connect at point X) which is similar to that shown in fig. 4. However, rather than the alarm object being implemented on a PC on the same PC LAN as the control and response objects, its PC is at a remote location, connected to the other components via the internet 235 and routers 234. Conveniently, messages are exchanged between the applications and the alarm object using the HTTP protocol, and appropriate LAN and WAN addresses.

The distributed alarm system may comprise more than one alarm object. For example, additional alarm objects may be implemented on remote PCs connected via the internet and routers to points Z and Y on figure 6.

Further examples and features of alarm systems embodying the invention will now be described, with general reference to the accompanying figures.

The basic operation of certain embodiments is achieved by hosting a remote software ALARM type object and a standard Database on a personal computer or server computer that implements a common language runtime environment. This remote Alarm object may be encapsulated, for example, in a standard PC application, a Network Server Service or a Web Server Service. The Alarm object contains properties (variables) for alarm condition, alarm identification and alarm description.

The object also defines events for common alarm conditions such as Fire, Fault, Pre Alarm, Overload, Intruder etc. The database application contains any amount of tables that may be required to perform advancedreporting tasks but should always contain a table that includes fields to match the remote Alarm objects properties. Separate software applications running on a common language runtime device such as a PC or a handheld PC connect to the remote object via a common protocol such as HTTP.

This connection could be made on the same machine, across an Ethernet type local area network, or across a wide area network such as the luternet. Each separate application may be defined as a Control Connection Application (control application), Report Connection Application (report application) or both.

A Control Connection Application connects to an external control system such as a fire alarm system or Security System via a common interface such as an RS232 port, a USB port or a Parallel port.

A Report Connection Application would be capable of displaying various alarm conditions and / or generating reports on various alarm conditions.

Any number of Control Connection Applications or Report Connection Applications may utilise the Remote Alarm Object Component at the same time, thus any number of control systems and any number of reporting systems may be connected to any number of control and / or reporting systems.

An example of a Control Connection Application is as follows. When an application that is connected to a control system receives an alarm condition (i.e. an alarm signal) from its interface, it converts the relevant message into the predetermined properties of the remote object. For example, if a Fire condition is received on the RS232 serial port from Panel No. 1 on Loop No. 1 by device No. 1 that has a description of "Main Building", the software application would parse the data received and would create an arbitrary reference such as POOlLOOlDOO1.

The application would set the remote object properties: - alarm condition=Fire, alarm identification = POOlLOOlD001, alarm description = "Main Building" and would then raise the Alarm event (i.e. send a control message to trigger the alarm message) on the remote object.

The property information above would also be added to the remote database table via an SQL connection or other remote connection to allow for subsequent querying by a reporting application.

A Report Connection Application would connect to the remote Alarm object and would subscribe to any events that it may wish to implement.

When an event is raised by a Control Connection Application the Report Connection Application would read the associated properties of the remote Alarm Object. If the Report Connection Application is programmed to respond to the Alarm Identification property, the associated actions would be carried out. These actions could include but are not limited to: Querying the Database to display a log of all events received to date Displaying a graphical representation of the area in alarm Transmitting an encoded message to a Paging system.

Transmitting an encoded message to a SMS system.

Transmitting an encoded message to a Facsimile machine.

Printing graphical images of the area in alarm.

Displaying a CCTV image of the area in alarm Furthermore, since a Report Connection Application can also be a Control Connection Application, it may also encode and transmit the event to a connected system via a standard interface such as RS232 or other.

The Report Connection Application would also be capable of connecting to the remote database through common connections such as SQL and would therefore be capable of producing any required reports or adding any new fields to the associated event record.

In certain embodiments, the remote Alarm Object is an object orientated component running under a Common Language Runtime environment such as Microsoft's.NET framework. Being able to execute under such an environment allows the component to run on any device supported by such a runtime environment.

These include but are not restricted to Desktop PC's, Network Servers, Web Servers, Portable Devices, Pocket PCs. The component would be able to run as an application, a network service or a web service and would create a communications channel over a common protocol such as HTTP on a given network port.

Running over a common network service allows the remote object to pass through common network devices and security devices such as Routers and Firewalls without the need for any special configuration.

The remote Alarm object may define common alarm type events that can be set or responded to by any other application that implements the remote Alarm object.

These may include but are not limited to: Alarm Pre Alarm Fault Fire Common Fault High Level Alarm Low Level Alarm Critical Alarm Intruder Alarm Silence Reset Isolated Restored General Fault System The remote Alarm object could also define a number of properties that may include but are not limited to: Alarm Condition Alarm identification

Alarm description

Any application that implements the remote object can set these properties to any value it may see fit. These properties can then be used as parameters to any of the above events. Any second application that needs to use these parameters only has to be programmed to respond to what has been set by the first application. By using this method, simple communications can be implemented between different control systems.

For example, a software application No. 1 may implement the remote object and be connected to a fire alarm system No. 1. When a fire is received from that system, application No. I may set the remote object parameters to "FIRE", "ANYIDENTIFICATION", "ALARMLOCATION" and then raise an ALARM event. A software application No.2 may also implement the remote object and be connected to a fire alarm No.2. It also subscribes to the ALARM event and is programmed to transmit a fire alarm condition to fire alarm No.2 via a RS232 port when the remote objects identification property is set to "ANYIDENTIFICATION".

As soon as application No. 1 receives a fire condition from fire alarm No. I it will set the remote object properties and raise the ALARM event. As soon as the ALARM event is raised, application No.2 will either read the identification parameter of the event or read the identification property of the remote object and then subsequently transmit the fire condition to fire alarm No.2 thus setting that system into fire too.

Details of certain Control Connection Applications will be better understood from the following. Most building control systems utilise a technique where any "points" connected to the system have a unique identification number, usually called an Address. In a Fire Alarm System for example each smoke detector, heat detector or call point is connected to a wiring loop and is given a unique number. The unique identification number or Address of this point would be LOOP NUMBER, POINT NUMBER. IE. If a Fire Alarm control panel has eight loops and each loop as ten smoke detectors connected each numbered 1 to 10, the unique point identification would be LOOP l DEVICE 1, LOOP 1 DEVICE 2, LOOP 1 DEVICE 3 LOOP 8 DEVICE 1, LOOP 8 DEVICE 2, LOOP 8 DEVICE 3.... and so on.

The Address information is usually associated to a device description, in the above example, LOOP l DEVICE 2 might be associated to a description of MAIN RECEPTION. When an alarm condition occurs on a particular device, the unique point identification and description is usually presented to the user in some form.

In certain embodiments, a control connection application, when started, would connect to the Remote Alarm Object, at the IP address of the computer that the object is running on, to the predetermined port. It would utilise the same protocol that the Remote Alarm Object has used, e. g. HTTP.

The control connection application could also connect to a database system either remotely to a database server such as an SQL server or locally either through a local SQL connection or an ODBC connection. It could further create a connection to a table within this Database that may be called "EventTable" for example and contain fields for Date, Time, Alarm Condition, Alarm Identification and Alarm Description.

It should be noted that since the purpose of the Database is solely to keep a record of the events for each system, the Database could also be updated by implementing a separate Report Connection Application that subscribes to ALL events and updates a local Database.

It is the job of a Control Connection Application to capture the above control equipment information, create a unique reference, and record the device description along with the alarm condition.

Some manufacturers provide a means of outputting this information via a dedicated hardware interface unit that connects to their system and outputs the data via a RS232 link or other link. Manufacturers that do not provide an interface unit usually provide at the very least a RS232 or serial TTL Printer connection. Some manufacturers do not provide any form of data output.

In the instance where a data output unit is available, the software could capture this data through the relevant communications port and fill the properties of the Remote Alarm Object. In the example above the application would fill the "Alarm Condition" property with the text string "FIRE", the "Alarm Identification" property with an arbitrary text reference that represents the unique address number such as "L001D002" and the "Alarm Description" property with the text description associated to that address, in the above example it would be the text string "MAIN RECEPTION".

In the instance where only a printer connection is available, a typical print output may look like: FIRE Address 2 Loop 1

MAIN BUILDING RECEPTION

This print output would be captured by the relevant port of a computer and parsed by the Control Connection Application to enable the remote Alarm Object properties to be completed as above.

In the instance where no output data is present, a custom hardware interface could be supplied that connects to the computers RS232 port. This hardware interface would be microprocessor controlled and would have sufficient inputs to allow interfacing to the control equipments reporting circuit, such as an LCD display or LED Display. The relevant display signals could then be decoded converted to RS232 and transmitted to the Control Connection Application via the RS232 link. The encoding from this interface would have to create all necessary reference details.

The above interface could also be implemented for control systems that do not provide address information such has conventional Fire Alarm Control Panels.

Which ever method is used, after all the relevant properties have been set, the Control Connection Application would raise the relevant Remote Alarm Object event and create a new record in the Database system with the same details.

Details of preferred report connection applications may be better understood from the following. A report connection apphcation, when run would also implement a copy of the remote Alarm object by connecting to the IP address of the machine running the component, through the designated port. Communications would be established over the designated channel, such as HTTP.

Typically, a report connection application will maintain a list of Alarm Identifications it wishes to carry out some action on.

A report connection application would then subscribe to any events that are available from the remote Alarm object. Once any of these events are triggered from a Control connection application, the report connection application would read the Alarm Identification property, either from the event parameters or from the remote Alarm object properties.

If the Alarm Identification property of the remote Alarm object matches a property held by the report connection application, a pre-programmed response will be carried out.

Various applications can be created that can be classified as a report connection application. These may include, but are not limited to: Graphical Display Interfaces Event logging and reporting Paging system interfaces SMS software applications Email applications Printing and Fax printing Control equipment interface Since the main function of a report connection application would be to present the gathered data from different systems in some form to a user, the most commonly used application would be a graphical user interface.

Graphical User Interface Background is as follows. Most manufacturers already provide some means of connecting a graphical user interface to their control systems.

Graphical user interfaces, commonly called graphics systems, usually comprise of a software application that connects to the manufacturers control equipment and receives various alarm conditions. Upon receipt of a valid alarm condition, a graphical map of the area in alarm is presented to the user. These maps usually start by displaying an overview image of the main site and contain sufficient links, that when clicked, allow the user to zoom into the area in alarm.

Since embodiments of the invention can be used to link to multiple systems, it would be pointless to use a specific manufacturers graphics system, since only one specific manufacturers system could be displayed on any existing graphics system.

Report Connection Graphics Application details are as follows. Since a report connection application can subscribe to any events from the remote Alarm object, and since the events of the remote Alarm object can be triggered by any Control connection application, all the data required from any connected system is present for the report connection application to display.

Since multiple systems can be located in different buildings, the graphics system would need to be accessible from any of these locations. The simplest way of carrying this out is for the report connection application to connect to standard web site.

The web site would typically contain dynamic pages that each contains an image of the area in alarm or a part thereof that will display various zoom levels. The dynamic pages would be scripted in a standard language such as ASP or ASP.NET.

A database may be created with a number of tables. The first table might be called "LINKS" and would contain a field called ID and any number of subsequent fields called linkl, link2, links.... which are relevant to the number of zoom levels required within the graphics system. The ID field would contain a text string that would correspond to the Alarm Identification property set by a control connection application. The link fields would contain an arbitrary reference to a unique link number such as A1, A2, AS and so on.

Each subsequent link would extend the previous link in a hierarchical way.

This allows for different screens to contain different links to each alarm point.

Example Database Table (allows for 5 zoom levels) I D Link1 Link2 _ Link3 Link4 Links L001 D001 A1 A1A AIM A1MB A1MBA L001 D002 A2 A2A A2M A2AAA A2AAAB L001 D003 A3 A3B A3BA A3BM A3BMB In the above example, alarm address point LOOlDOO1 would be on web page A1 AABA.

To display this page from the main site overview, the user would have to click on the link A1 which would subsequently load a web page called A1. The user would then have to click on link A1A which would subsequently load a web page called A1A.

The user would then have to click on link A1 AA which would subsequently load a web page called A1AA and so on.

These links would be followed in this way until the user is presented with a web page called A l AABA. This page would then display an image of the area in alarm with the device identified by LOOlDOO1 present.

A second table would also be created that may be called "ALARMPOINTS" for example. This table would contain fields that would include: 1. ID 2. X coordinate 3. Y coordinate 4. Screen name S. Link 6. Image 7. State Field number 1 (ID) would again contain a text string that would correspond to the Alarm Identification property of the remote Alarm object. It would also contain the same reference for each link as defined in the relevant link fields in table 1. IE a record for link Al, a record for link A1A, a record for link A1AA and so on.

Fields 2 & 3 hold a value that corresponds to the X,Y co-ordinate of the current image that an image link should be placed at.

Field 4 contains the web page name that an image link should be displayed on.

Field 5 contains an URL to a web page that would be loaded when the link is clicked.

Field 6 contains the filename of an image to be displayed that would represent either the point that is in alarm or the link that is in alarm.

Field 7 would be set to a predetermined value that would represent the alarm state of the point in alarm KG. FIRE.

Table 2 Example

X Screen Link I rnage State coord coord A1 10 10 Oview A1.asp Norm.gif Normal A1 A 10 15 A1 A1 A.asp Norm.gif Normal A1 M 15 100 A1 A A1 M. asp Norm.gif Normal A1 MB 120 200 A1 M A1 MB.asp Norm.gif Normal A1 MBA 300 450 A1 MB A1 MBA.asp Norm.gif Normal L001 D001 450 150 A1MBA L001 D001.asp Norm.gif Normal From the above table, it can be shown that when screen Oview is loaded, it contains a link called A1 that uses an image called Norm.gif that is placed at co-ordinates 10,10 and is an hyperlink to a web page called Al.asp.

When the web page Al.asp is loaded, it contains a link called A1A that uses an image called Norm.gif that is placed at co-ordinates 10,15 and is an hyperlink to a web page called AlA.asp.

This continues to the final record of LOOI DOO1 which can be shown that when the web page A1AABA is loaded it contains a link called LOOlDOO1 that uses an image called Norm.gif that is placed at co-ordinates 450,150 and is a link to a web page called LOOlD001.asp.

Each of the web pages above would contain an image of the relevant area. EG the oview page would contain an image of the entire site. The Al.asp page would contain a zoomed image of the overview image. The Al A.asp page would contain a zoomed image of the Al image.... This is continued until the final screen AlAABA.asp is displayed, this would usually contain an image of the area in alarm EG the Main Reception.

The fields of these two database tables can be read and / or modified by any control connection application or any report connection application via a SQL Server or an ODBC connection.

Example Operation - controlled by a Report Connection Application 1. Remote Alarm object is run a computer with TP address 192.168.92.1 a. A channel is created using the HTTP protocol listening on port 8080 2. A Control Connection Application is run on a computer with IP address 192.168.92.2 a. This implements the Remote Alarm object by connecting to port 8080 of the computer at IP address 192.168.92.1 communicating over HTTP.

b. It also starts starts communications with a fire alarm system connected to it's RS232 port.

3. A Report Connection Application is run on a computer with IP address 192.168.92.3 a. This also implements the Remote Alarm Object by connecting to port 8080 of the computer at IP address 192.168.92.1 communicating over

HTTP

b. It then subscribes to the ALARM event.

4. A Fire alarm is received by the RS232 port of the Control Connection Application (item 2) 5. The Control Connection Application formats the unique alarm address into a text string of LOOlD001 6. The Control Connection Application sets the properties of the Remote Alarm Object.

a. Alarm Condition property is set to FIRE b. Alarm Identification property is set to L001 D001 c. Alarm Description property is set to Main Reception 7. The Control Connection Application then raises the FIRE event of the Remote Alarm Object, passing the above properties as parameters.

8. The Report Connection Application is triggered by the FIRE event of the Remote Alarm Object.

9. The Report Connection Applications FIRE event handler: a. Searches Table number 1 for a record that has an ID field of the Alarm Identification property- LOOlD001 b. Retrieves a list of each link name held in fields Linkl.... LinkN c. Searches Table number 2 for the Alarm Identification property LOOlD001 and changes the IMAGE field contents to FIRE.GIF and

the status field to FIRE

d. Searches Table number 2 for each link retrieved in 9b e. Changes the IMAGE field of each record found to FIRE.GIF and the

status field to FIRE

The above step by step procedure would receive a fire from an external control system and change various database entries.

A standard web browser could now connect to a web site that utilises server side scripts to read the database and add images to a web page. E. G. A web page is created called oview.asp. This page contains a GIF image of the overall site plan of a site. The page also contains a server side asp script that connects to the Database, filters Table 2 for all records where the screen name corresponds to OVIEW and then adds an image where the filename corresponds to the contents of field IMAGE at the coordinates given by the X & Y fields. It would then set the link reference of this image

to those given in the LINK field.

The result would be a web page that shows an overview of the entire site. It would be populated with images that depict a link. Any links that are not in alarm would use the Normal.gif image and any links that are in alarm would use the FIRE.gif image. The hyperlink attributes of these images would link to the next web page that would again query the database and display any relevant images.

By utilising server side scripting within the web pages, and a dynamically generated database under the control of a report connection application, any standard web browser can be used to view the graphical user interface without the need for any special applets or activeX controls to be embedded within the web site.

The disadvantage of using server side controls is that if a web browser is currently viewing a page on the web site, and subsequently an alarm event is received, there is no way of instructing the web browser to refresh the page to re-read the database and hence update any links to a fire image.

The report connection application however provides the perfect solution. Since a report connection application can be run on any computer across a standard network, it is capable of receiving any of the events triggered by the remote Alarm object.

If a report connection application were to implement a browser control, such as that of Microsofl's Internet Explorer, it is possible to create a custom browser that will work the same as a standard browser, but will respond to any event triggered by the remote Alarm object.

All that is required is to create a report connection application that connects to and subscribes to all the events generated by the remote Alarm object. The application implements the Microsoft web browser object which allows connection to any web site as normal. When the report connection application receives an event from the remote Alarm object, it simply refreshes the browser page, thus re-reading the database and displaying the current alarm information.

The final link in the example above LOOlDOOl.asp could be used to open a web page that reads the Event Table from the database connected to by the control connection application and could then display the event log history for that particular device.

In summary, embodiments of the invention may comprise a distributed application for connecting different control systems, that is, an application made of numerous objects or components that act as one application, setting properties and passing events between different system components.

The main benefit of distributed applications is the ability to easily expand the application without the need for re-writing any existing code. Additional control equipment can be added at any time by simply creating and running a component that connects to the control system and also connects to and shares other parts of the distributed application.

Separate components can act in a multitude of different ways, whilst not affecting any other part of the application. Control systems can be made to respond to certain events or no events, and can set any type of property they wish.

Any or All data gathered can be seen visually through standard web sites or special applications. Data can be manipulated and added to through standard database connections.

Applications can be updated and modified by third parties or end users, simply by adding a component or modifying a web page.

CCTV images can be linked, simply by adding an URL to a web page that points to a stored camera image.

Paging systems can be linked by adding a component to respond to events and subsequently transmit any or all parameters through a RS232 port to a paging transmitter.

Remote operatives can be informed of system events by email simply by adding mailto links or server side scripting to new or existing web pages.

Detailed reports of false alarms, engineer call outs or other user specified criteria can be generated simply by querying the existing databases or adding additional information to additional tables.

Claims (1)

1. Claims 1. An alarm system comprising: first processing means arranged to

   implement a software alarm object, the alarm object having a state defined by at least one variable; a plurality of sensors connected to a control unit; an interface connecting the control unit to second processing means, the second processing means being arranged to implement a control application; first communication means arranged to provide communication between the control application and the alarm object; third processing means arranged to implement a response application; second communication means arranged to provide communication between the alarm object and the response application, the control unit being responsive to a signal originating from one of the sensors to send a corresponding alarm signal indicative of an identity of the originating sensor via the interface to the control application, the control application being responsive to said alarm signal to send a corresponding control message indicative of said identity to the alarm object via the first communication means, the control message setting the state of the alarm object according to said identity and the alarm object being responsive to the control message to send a corresponding alarm message via the second communication means to the response application, the response application being responsive to the alarm message to carry out a pre- programrned response.

   2. An alarm system in accordance with claim 1, wherein the response application is responsive to the alarm message to inspect the state of the alarm object and carry out said pre-programmed response according to said state.

   3. An alarm system in accordance with claim I or claim 2, wherein the alarm message includes at least one said state variable and the response application carries out said pre-programmed response according to said at least one included state variable.

   4. An alarm system in accordance with any preceding claim, wherein the alarm object is configured to send a plurality of alarm messages, the control message determining which alarm message is sent, according to the signal from the originating sensor.

   5. An alarm system in accordance with any preceding claim, comprising a plurality of said response applications, each being implemented on respective third processing means and communicating with the alarm object via respective second communication means, wherein the alarm object is configured to send a plurality of alarm messages, and wherein each response application is configured to respond to at least one of said alarm messages.

   6. An alarm system in accordance with claim 5, wherein at least one of the response applications is configured to respond to a plurality of said alarm messages by carrying out respective pre-programmed responses.

   7. An alarm system in accordance with claim 5 or claim 6, wherein the control message from the control application determines which of the plurality of alarm messages is sent.

   8. An alarm system in accordance with claim 7, wherein the control application is adapted to control the alarm object to send a selected alarm message according to the signal from the originating sensor.

   9. An alarm system in accordance with any preceding claim, comprising: a plurality of said control units, each connected to a respective plurality of sensors; and a plurality of said interfaces, each connecting a respective control unit to a respective second processing means arranged to implement a respective control application communicating with the alarm object via respective first communication means, each control application being configured to send respective said control messages to the alarm object.

   10. An alarm system in accordance with claim 9, wherein the alarm object is configured to send a plurality of alarm messages and each control application is configured to send a respective control message to cause the alarm object to send at least one of said plurality of alarm messages.

   1 1. An alarm system in accordance with claim 10, wherein at least one of the control applications is configured to send a respective control message to cause the alarm object to send a selected one of a plurality of said alarm messages.

   12. An alarm system in accordance with any preceding claim wherein said control and alarm messages are sent in XML format.

   13. An alarm system in accordance with any preceding claim wherein at least two of said first, second, and third processing means are located in separate devices.

   14. An alarm system in accordance with any preceding claim wherein said first communication means comprises at least one of: a LAN connection; a WAN connection; and an internet connection 15. An alarm system in accordance with any preceding claim wherein said second communication means comprises at least one of: a LAN connection; a WAN connection; and an internet connection.

   16. An alarm system in accordance with any preceding claim, further comprising fourth processing means arranged to implement a database application, the or each control application being arranged to send a database signal via fourth communication means to the database application in response to the signal from the originating sensor, the database signal being indicative of the identity of the originating sensor, and the database application being arranged to log the database signals.

   17. An alarm system in accordance with claim 16, comprising at least one said response application arranged to interrogate the database application in response to an alarm message from the alarm object.

   18. An alarm system in accordance with any preceding claim, comprising a said response application responsive to all alarm messages from the alarm object and arranged to update a database in response to each message to create a log.

   20. An alarm system in accordance with any preceding claim, wherein the or each response application is selected from a list comprising: Graphical Display Interfaces; event logging and/or reporting applications; paging system; SMS software applications; Email applications; printing and fax applications; applications for sending signals to the emergency services; and control equipment interfaces.

   21. An alarm system in accordance with any preceding claim, wherein the or each control application is selected from a list comprising: a fire alarm application; a building security application; a CCTV application; an access control application; and a building management system application.

   22. An alarm system in accordance with any preceding claim, wherein the alarm object is configured to send one or more alarm messages selected from a list comprising: Alarm; Pre Alarm; Fault; Fire; Common Fault; Fault; High Level Alarm; Low Level Alarm; Critical Alarm; Intruder Alarm; Silence; Reset; Isolated; Restored; General Fault; and System.

   23. An alarm system in accordance with any preceding claim, wherein said at least one variable defining the alarm object state comprises a variable indicative of the identity of the originating sensor.

   24. An alarm system in accordance with any preceding claim, wherein the alarm object state is defined by a plurality of variables.

   25. An alarm system in accordance with claim 24, wherein said plurality of variables comprise a variable indicative of a state of the originating sensor.

   26. An alarm system in accordance with claim 24 or claim 25, wherein said plurality of variables comprise at least one variable indicative of a location of the Ongnahng sensor.

   27. An alarm system substantially as hereinbefore described with reference to the accompanying drawings.