NO336942B1 - Arrangement of units to form a monitoring system. - Google Patents

Abstract

The invention relates to a systematic arrangement of units for handling and transmitting alarms. Alarm events are detected in local alarm systems. The associated alarm information can be transmitted, via a considerable number of different communication options, to central monitoring stations which have the task of monitoring and updating the local alarm systems. The systematic arrangement of devices has a considerable number of different ways to ensure both the secure transmission of alarm messages and the delivery of said messages to the intended recipient.

Description

Building monitoring system

Background

In today's world, there is a great need for various monitoring functions. This could be monitoring the transport of valuable items (to prevent theft) or monitoring the transport of prisoners (to prevent escape) or monitoring shops and properties. The latter can cover everything from detecting break-ins and fires, to establishing when a type of goods is empty in a vending machine. From devices with fixed telephone lines to vehicles that communicate via wireless devices (for example mobile phones), a number of different systems can be used for monitoring. One problem that can arise is the intentional disruption, modification, recording, re-transmission or other manipulation of an alarm signal by a criminal. Messages may even be subject to interference from natural sources, or the "communication devices" may simply suffer from a malfunction. It therefore pays to establish how well the communication equipment is working and whether it is suffering from interference or is not, for any other reason, able to contact an alarm center or any other receiving system, such as a stock control system for vending machines.

Among the desirable characteristics of a monitoring system are reliability and the ability to handle various forms of disturbances. The latter can be anything from natural disturbances (for example, repairs to the local computer network) to deliberate attempts to disrupt signals. Other desirable characteristics of surveillance systems are: simple and cost-effective installation; maintenance using a minimum of resources; that the communication system is secure against tapping and manipulation; and, a limited communication bandwidth.

EN 50136:1998 (the industry standard) highlights several characteristics of an alarm system. An important factor is the transmission time, i.e. the time it takes for a signal from a local alarm system to reach an alarm centre. This time should of course be as short as possible. It is an advantage if the system can detect unauthorized exploitation of a device and can alarm or give a message about such exploitation, so that it cannot occur without being noticed. That accessibility should be as great as possible is, of course, also important. Having redundant transmission paths reduces the possibility of messages reaching their destinations. Other important factors in an alarm system are the possibilities to monitor, control and compile statistics on: service interruptions; how often and when units have been out of service; the length of transfer times; and, other interesting details. The standard also deals with the security of information and signals as regards, as mentioned above, the manipulation of messages and other forms of interference with signals.

From US 5,027,383 there is known an alarm monitoring system for alarm communication consisting of a local alarm system, where various sensors are connected to the local alarm system, where the local alarm system is configured to send status messages to monitoring stations via a derived communication channel which can be wireless or via a telephone line , with the possibility that the monitoring station can check whether there is a fault in one of the communication channels.

US 2003151501 Al describes a security system that enables remote tracking and monitoring with the possibility of configuring a local device and remote control of door locks.

Description

The present invention is based on an arrangement of units to form a system for monitoring alarms. This system comprises many different parts. Some of these include known solutions, others include new solutions. The combination of these parts forms a unique whole that solves many of the problems described above.

The system includes: parts that enable secure communication and that use redundant alternative paths; and, control functions that prevent the system from being affected by intentional disturbance and, similarly, ensure that it functions satisfactorily even when subjected to natural interruptions, such as maintenance on parts of the system.

The system has the additional advantage that the software used by its parts can, in many cases, be updated in a way that does not require a service technician to visit the parts' physical locations. Updating is effected by a server that communicates from a distance with the devices in question. This means that several changes and new orders in a customer assignment can be administered and executed centrally. Similarly, the system can be continuously updated in a fast and efficient manner as and when software improvements become available. A local alarm system can thus be updated externally via one of the communication units. This may involve updating the software in different parts of the local alarm system (for example detectors), the central unit and the communication units. This has the advantage that mass maintenance and updating can be carried out without the need for someone to visit the local system or for devices to be sent in for checks and updates.

Similarly, the system has the advantage of secure communication. Communication security is ensured through a number of different, advanced encryption algorithms that prevent communications from being tapped or destroyed without detection. These encryption algorithms are compiled from so-called open encryption standards, but in a way that is specific to systems.

Each and every device in the system can contain a unique identifiable code that gives the device its identity. The purpose of this code is to prevent the unauthorized exchange of a device with a tampered device. The code is encrypted and not publicly available.

The monitoring system further comprises an advanced control system to optimally distribute the traffic load by, for example, allowing certain video streams to be sent over certain channels to certain devices, while other destinations, with more limited bandwidth resources, can receive still images at different time intervals. It is also the case that advanced transport protocols ensure that the traffic load is limited as much as possible, so that no unnecessary information creates disorder in the communication paths.

The monitoring system comprises a number of different local alarm systems which have alarm functions and devices for forwarding alarm messages to one or more alarm centres. The local ones

the alarm systems can process information from several alarm types. Alarm here means a broad term that includes everything that is popularly referred to as an alarm (for example theft alarm, fire alarm and personal attack alarm) to information regarding stock, temperature, system status, images and positioning data. When the local alarm system detects an alarm case, it has the task of sending an alarm message to an alarm centre. This signal can be sent in a number of different ways using different communication methods. Examples of this include: Internet, landline devices that call the alarm center when there is an alarm; and various ways of using a wireless device for communication. When, using one of these methods, the alarm message reaches the alarm center, a judgment is made as to what action should be taken to handle the alarm message. This can be anything from sending someone to the scene, trying to make contact via another communication device or alerting the police. Information and alarm signals can of course also be sent to systems other than the alarm centre, for example customer systems.

Nowadays, different communication paths can be used when handling alarm signals. An Internet connection is one possible method. This is based on a device being connected to the Internet via, for example, cable, ADSL, ISDN, a mobile network, a fiber network, etc. The device has two-way communication between alarm centers and the local alarm system, as well as other connected systems. This communication method detects a possible break in the connection. However, there may be cases where an additional communication path is needed as a reserve. For example, problems may arise with network congestion or with repair work that breaks the standard connection.

A so-called "ringing unit" (eng: "ringing unit") is one known way of processing alarm signals. Here, the system automatically calls the alarm center when an alarm is triggered in the local alarm system. The call can be made via the fixed telephone network or via a wireless call over a mobile network. This widely used system lacks the ability to alert the alarm center if the communication path is broken by, for example, physical cutting of the fixed line or disturbance/interruption of the message to the wireless device.

Swedish patent application SE0002743 describes a system comprising a method for monitoring an object via a wireless connection. This system detects any breaks in the connection. To indicate its status, a wireless device transmits messages randomly or when triggered by events. In the absence of messages from the wireless device, the receiving server, after an automatic evaluation, sends an alarm to the alarm center. A message may have been tampered with on purpose; its absence triggers an alarm. This invention requires a receiving server and a technical modification of the wireless device. The need to modify the wireless device is a disadvantage of this method.

Swedish patent application SE0200639 describes a further way of using a wireless connection to monitor an object. In SE0200639, a programmable SIM card is inserted into a wireless device. A configuration server can configure this card to send messages, via GPRS, to an alarm. This card can be configured by an alarm receiving unit.

The monitoring system in accordance with the present patent application may include all these communication possibilities individually or in different combinations. Each and every one of the individual possibilities has its weaknesses. By combining these choices and integrating them into a system, many of their individual problems can be solved.

In the present invention, additional communication control has been introduced into the monitoring system. It is a device for monitoring that a wireless device is working and able to transmit. The device includes a server that sends messages over a mobile network to the mobile devices to be monitored. If a delivery confirmation is not given for a message, the server automatically sends a connection failure alarm to a predetermined recipient or recipients. There is a free choice of communication methods for sending the alarm to the recipient. The recipient can, for example, be an alarm centre, operations center or an authorized person. One advantage of this communication control is that the mobile device does not need modification; all modifications are implemented at the central monitoring station, the server. This means that changing the number of monitored objects is quick and easy. No on-site installation is required; all technical modifications are implemented centrally in a server system. The communication control thus uses the "lost-connection" principle of SE0002743, but with the difference that the message is sent from the server to the wireless device, while in SE0200639, on the other hand, it is sent from the wireless device to the server or vice versa. If the wireless device is jammed, an alarm message is sent to one or more predetermined alarm receivers who, in turn, decide which actions are to be taken. An action can be anything from sending someone to the location, trying to establish contact via another communication device or waiting for a certain amount of time to see if contact is restored. The mobile device to be monitored can be part of a local system of objects that need to be monitored. Examples of these are: vehicles equipped with built-in mobile phones for remote service, technical alarms and robbery alarms or personal attack alarms. Even fixed installations, such as alarm systems for robbery, fire etc., and vending machines equipped with mobile phones for alarms and status reports (for example "stock replenishment required") are examples of such monitoring objects. Consequently, the existing device can be added to systems to increase safety/security when an internet connection is used. It can also form an adjunct to a fixed or mobile "ringer" system. Here it monitors that the devices work and that the messages are not disturbed.

Furthermore, the surveillance system also includes the possibility of central storage of images from surveillance cameras at the local alarm systems. This has several advantages compared to local storage. It results in fuss-free procedures at the local level. No storage tapes, disks or the like are required for the local alarm system. In other words, local installations are simple and can be controlled from a distance. Another very important advantage of this is that, when the images are sent to a so-called "trusted party", the integrity of the monitored object is protected. Neither supervisors nor "colleagues" can supervise each other. There is no risk of surveillance images going astray from taxi companies, restaurants or shops. This can result in it being easier to get permission for camera surveillance. Correspondingly, security is increased when images are not stored locally. Furthermore, they can be monitored from a distance and thus play an active role in crime prevention, instead of being used as evidence after an incident.

The monitoring system also includes units for distance-based control functionality. These devices can open doors and gates from a distance, and determine whether a visitor is authorized, etc. Local systems can therefore be controlled from a distance from a central device.

Further characteristic features of the present invention are given in the patent claims.

Brief description of the figures

In the following, the present invention will be described with the help of an example embodiment which is illustrated with the help of 23 figures, where:

Figure 1 shows an overview of a monitoring system,

Figure 2 shows a flow diagram for an alarm in accordance with Figure 1,

Figure 3 shows an overview of part of a monitoring system. It includes an alarm and monitoring function for a wireless device, Figure 4 shows a flow diagram for an alarm in the part of the monitoring system shown in Figure 3,

Figure 5 shows a flow chart for monitoring and configuring a wireless device,

Figure 6 shows a schematic overview of part of the monitoring system,

Figure 7 is a schematic illustration of a variant for the monitoring of a wireless device,

Figure 8 gives an overview of how a server manages the traffic from surveillance cameras to different receivers, Figure 9 shows a variant of the monitoring system where the local alarm system 100 is a "small system", for example a residence, Figure 10 shows a flow chart for alarm events, door opening and image processing in such a part of the monitoring system as shown in Figure 9, Figure 11 shows a variant of the monitoring system where an alarm receiver includes one or more mobile devices, Figures 12 and 13 show a number of screens illustrating the sequence of events for an alarm in a mobile alarm receiver, Figure 14 shows a possible function (integrated into the monitoring system) for remote locking and opening of an alarm terminal, Figure 15 shows flow diagrams for three variants of how remote services, as in Figure 14, can work,

Figure 16 shows an example of a communication unit in the monitoring system,

Figure 17 provides an overview of a system solution for redundant Alive server groups,

Figure 18 gives an overview of functional elements in Alive server 230,

Figure 19 shows a synchronization service in the new system solution for redundant Alive server groups,

Figure 20 shows the synchronization service in detail,

Figure 21 provides an overview of functional elements in a redundant Alive server,

Figure 22 provides an overview of functional elements in a redundant Alive server, and

Figure 23 shows online alarm processing.

The 23 figures are used in the following description of a system.

Figure 1 shows a local alarm system 100 comprising different "alarm objects" 110, such as motion sensors 112.1, fire alarm 112.2, camera 113 and automata 111. A local alarm system (e.g. 100) can have different combinations of these alarm objects (e.g. 110). The alarm object 110 is in contact with a central unit 120. Communication can take place through fixed lines, Bluetooth or with a wireless network, such as WLAN. The central unit 120 is in turn in contact with various communication units 130. Each one of these communication units 130 can, individually or in combination, be integrated with the central unit. Communication between the central unit 120 and the communication units 130 can, for example, be over fixed lines, WAN, LAN, WLAN, MLAN or another communication channel. The figure shows examples of such communication units 130. These can be connected individually or together in different combinations. For example, the communication devices 130 may include an Internet device (e.g., 134), a wireless device (e.g., 131), a ring device (e.g., 132), and a device (e.g., 133) that is connected to a fixed network. Other communication devices can of course also be used. The figure shows four communication units 130.

The Internet device 134 communicates with the alarm and/or operations center 300 over TCP/IP. In the same way, it can communicate with other systems, for example an external alarm receiver 400 and a configuration server 250. As mentioned, communication here also takes place over TCP/IP.

A Multicom unit 133 is a unit that communicates over a fixed network (which, for example, has special nodes installed in national telecommunications centers) and can forward alarms to the alarm and/or operations center 300.

The PSTN calling unit 132 is a unit that uses the fixed telecommunications network to send alarms/information to the alarm and/or operations center 300.

The PSTN calling device 131 is a device that uses the fixed telecommunications network to send alarms/information to the alarm and/or operations center 300. By using wireless communication over a mobile network, the wireless device 131 can also communicate with the server 230 and the configuration server, for example 210.

The server 230 monitors that the wireless unit 131 in the local alarm system 100 is working. The server 230 can be mirrored. This provides continuity should one of the servers fail. This increases security. The server 230 communicates with the alarm receiver 400 and the alarm/operation center 300 and indicates the status of the wireless devices 131 that it monitors. The server 230 can also communicate with the configuration server 210. The configuration servers 210/250 communicate with the wireless device 131 or the internet device 134 to update and control the software in the local alarm system 100. Similarly, the configuration server 210 can communicate with the server 230 to determine which wireless devices 131 the server 230 must monitor and to which alarm receivers 400 and/or alarm/operation centers 300 it must send the results of its monitoring. The configuration server 250 can communicate with the server 240 to determine how to regulate Internet traffic from the local alarm system.

Customer processing units 220/260 have and receive information about which local alarm systems 100 are to be monitored, where monitoring is to be carried out and where communication units 130 are to send their alarm signals. In other words, which alarm/operation centers 300 process which local alarm systems 100 and which alarm receivers 400 should receive messages from these local alarm systems 100. Customer processing units 220/260 determine how the servers 230/240 should operate.

The server 240 regulates how traffic from the internet device 134 in the local alarm system is to be handled. For example, certain data may be sent to the alarm/operations center 300 and other data to the alarm receiver 400. It may also control the sending of an image from a surveillance camera 113 to any destination accessible via the Internet.

The monitoring device 200 is an umbrella name for the devices 210-260.

The alarm/operation centers 300 are facilities that receive alarms and information from the local alarm centers 100 and from the monitoring device 200. The alarm/operation center 300 determines which actions are to be taken in the various alarm situations that it may encounter.

The alarm receiver 400 is a device for customers, owners, security officers, etc. to monitor a local alarm system 100.

In this arrangement, the configuration servers 210 and 250 may be one individually shared unit, the customer processing devices 220 and 260 may be another, as may the servers 230 and 240. Figure 2 shows a flow diagram for an alarm in the monitoring system shown in Figure 1. The first the event is triggered by an alarm from a detector, machine or other alarm object in the alarm object 110. A signal is sent from this alarm object to the central unit 120. The signal can be sent via fixed networks, Bluetooth or other means of communication and can be a signal or the absence of a signal. The central unit 120 processes the signals, or the absence of signals, from the alarm object 110. Via the communication units 130, the alarm message is then sent to the alarm control/operation center 300 and/or the alarm receiver 400. Appropriate actions to handle the alarm are determined by the latter. The monitoring unit 200 can monitor that certain of the communication units 130 are working correctly, and if they do not, send a message to the alarm/operations center 300.

Figure 3 shows in more detail how the monitoring system monitors the wireless device 131.

One configuration of the monitoring system is for the central unit to use a PSTN paging unit 132 in combination with a wireless unit 131. The normal path for alarms and messages is from the local alarm system 100, through the PSTN paging unit 132 to the alarm/operation center 300. The calling unit contacts the alarm/ the operations center 300 when there is an alarm. This represents no problems given that the alarm path has not been broken by, for example, physical cutting of the line. This prevents the calling unit from contacting the alarm/operations center 300, which remains unaware that contact has been lost.

By adding wireless device 131 and, on top of this, monitoring device 200 (the latter comprising the configuration server 210, the customer processing device 220 and the server 230), the wireless device 131 can be monitored and the alarm center 300 can receive information indicating the degree of functionality of the local the alarm system 300.

Via a message signal to the wireless device 131, the wireless device 131 is monitored by the server 230. The wireless device 131 returns a delivery confirmation for the message signals from the server 230. If the confirmation is not received, the server 230 can send a report to the alarm/operations center 300 and /or take other necessary action. Theoretically, the PSTN 132 can be monitored by calling from the alarm/operations center 300. However, given the limitations of acceptable practicality and cost, calls can only be made a few times in each 24-hour period. With the monitoring of the wireless device 131, the frequency is several times per minute. The wireless device thus adds increased security. Figure 4 shows a flow diagram for an alarm in the part of the monitoring system shown in Figure 3. The first event is the triggering of an alarm by a detector, automat or other alarm object in the alarm object 110. A signal is sent from this alarm object to the central unit 120 The signal can be sent via fixed networks, Bluetooth or other means of communication and can be a signal or the absence of a signal. The central unit 120 processes the signals, or the absence of signals, from the alarm object 110. The central unit 120 determines how to forward the alarm to the alarm/operation center 300. In the described configuration, it can use the PSTN 132 (a calling unit using a fixed network) and/or wireless unit 131 to forward the signal to the alarm control/operation center 300. The central unit 200 can request confirmation that the alarm message has been received. If delivery confirmation is not given, it can try again via the device it previously used for the alarm attempt and/or via the other device. The server 230 monitors the wireless device 131 from a distance by sending it (continuously or at intervals) message signals. If the server 230 does not receive a uniquely identifiable delivery confirmation, it sends a report to the alarm/operations center 300. This, in turn, determines which action is to be taken. Figure 5 shows a flow diagram for the monitoring and configuration of a wireless device 131. The wireless device 131 sends a message, for example an SMS message, to the configuration server

210, and tells the server that it wants to be installed in the system. The configuration server 210 receives the message from the wireless device, processes the information that the wireless device 131 sent in the message and compares this with the information that the configuration server 210 has in its database. This is to determine if it is a valid call. If the configuration server 210

determines that it is a valid call, it sends a message to the wireless device 131. This message contains the necessary information for the wireless device to establish a communication channel with a server 230. Once the server 230 and the wireless device 131 have established a communication channel , the server 230 monitors that the wireless device 131 is operational and functioning. This monitoring can be effected both through the server 230, according to a scheme, whereby messages are sent to the wireless device 131 (with a request for delivery confirmation) and/or whereby the wireless device 131 sends messages, according to a scheme, to the server 230. If the server 230 loses contact with the wireless device 131, the server 230 sends a report to the alarm/operations center 300 and/or the alarm receiver 400. These in turn determine what action is necessary.

Figure 6 shows a schematic overview of the monitoring device 200. Its constituent elements can be located at different places and can communicate with each other over different networks. The role of the configuration servers 210/250 is to configure the various parts of the monitoring system. This can involve managing: how often surveys are to be sent and to whom; where alarms should go; where images are to be presented; and, to inform cameras how much bandwidth the receiver has available. The servers receive their instructions from customer processing devices 220/260. These handle the information that describes what the customer has ordered. This processing can be carried out through the device's network connections. If they need to communicate wirelessly, they can use the wireless device 270.

The server 230 monitors the wireless device 131 in the local alarm system. The server 240 takes care of the communication between the internet device 134 and the alarm/operations center 300. It also functions as a switch and controls traffic from the local alarm system to the various receivers. Figure 7 is a schematic overview of a variant of the monitoring of a wireless device 131. A wireless device 131 contains a programmable SIM card 131.1 which has a polling program (or a program that can control the device's - telephone's - computer part ), to enable programming of the configuration server 210 from a distance. There is a free choice of communication protocols (for example SMS) for this programming. Via the SMS card, the computer part can be programmed so that the wireless device sends messages to a server 230 and thus implements monitoring to check that the wireless device 131 is working. Alternatively, it can be programmed to accept inquiries from the server 230. In the absence of an inquiry or inquiry delivery confirmation, the server sends an alarm to the alarm/operations center 300. Figure 8 provides an overview of how a server 240 controls the traffic from surveillance cameras 113.x to different receivers. These surveillance cameras 113.x can be arranged at different places and in different systems. From surveillance camera 113.1, an image or video data stream is sent over the Internet, for example.

The server 240 determines which recipient(s) the image/video data streams will be sent to. The server 240 also determines the quality and update frequency with which the images will be sent to each of the recipients. Accordingly, one receiver may receive a video stream while another may receive individual still images at certain intervals. The image/video stream receiver may be a central image storage unit 500, the alarm/operation center 300, the alarm receiver 400, or any other selected receiver. The central image storage unit 500 stores digital images and video streams from various cameras.

Even small "systems", such as homes and small businesses, need secure and monitored alarm transmission. Figure 9 shows a possible design of a monitoring system where the local alarm system 100 is a home, for example. The home is equipped with an alarm transmitter which can be a wireless device 131. The alarm transmitter has the ability to transmit alarm messages of several different categories, for example theft, fire, etc. The alarm transmitter is also able to transmit images, sound and data. One or more detectors 112 and one or more cameras 113 are also arranged in/near the home. There is direct communication with an alarm center 300, such as a police station or SOS Alarm.

The owner of the property / customer 400 can, via his/her own receiver (which can be a mobile phone, hand-held PC or other device with equivalent characteristics), receive information messages in the form of alarms and status reports on whether the connection is working.

Communication can, for example, be via a mobile network 600 such as GSM, GPRS, etc. By using encryption and firewalls, the communication is kept separate from the public part of these networks. Other communication methods can of course also be used. The owner of the property, the customer 400, can alternatively also receive information via the Internet and a desktop computer at another location, for example at work. The advantage of using the mobile network is flexibility.

Monitoring that the alarm connection is working can be carried out in the same ways as described earlier in the present application. Alarm transmission channels and monitoring channels are both checked to determine the extent to which the connection is active or broken.

In this way, a user always has full insight into the alarm transmission status. If there is a break-in or other incident, an alarm is of course sent directly. If, for any reason, the alarm system loses contact with the alarm center 300, the alarm center becomes aware of this at the end of the time period set by the user. This makes it possible to make the necessary

act quickly, before serious damage occurs.

If any door in the home is equipped with an electrically actuated or motorized type lock, the owner can, thanks to the monitoring system, also open the door for others without being at home themselves. Transmission of images to the customer's/property owner's 400 receiver enables control of whether the correct person has been admitted. This solves, among other things, the problem of letting in workers when the owner cannot be at home. A further possibility would be to let the owner see different interior images of his/her house or apartment on the screen of a mobile phone, for example.

Figure 10 shows a flow diagram for alarm events, door opening and image recording in a system as in Figure 9.

Alarms

Detector 112 and camera 113 have registered an alarm. Via the wireless device 131 and the mobile network 600, the central unit 120 (or equivalent) sends an alarm to the server 230. The server 230 forwards the alarm to the alarm center 300 or, via an Internet TCP/IP connection and mobile network 600, to the alarm receiver 400 (the customer/ the property owner). The alarm center 300 and the alarm receiver 400 (the customer/property owner) have now received an alarm message from the detector 112 and images from the camera 113.

Opening of doors (cf. alarms)

The doorbell connected to the door 114 and the camera 113 have both been activated. Via the wireless unit 131 and the mobile network 600, the central unit (or equivalent) sends the signal to the server 230. The server 230 forwards the signal to the alarm receiver 400 (the customer/property owner). The alarm receiver 400 (the customer/property owner) has now received the signal from door 114 and images from camera 113.

Via the mobile network 600, the alarm receiver (the customer/property owner) sends an "open door" command to the server 230. The server checks authorization and, if this is in place, the signal is relayed (via the mobile network 600, wireless unit 131 and central unit 120) to the door 114. The door is now opened, for example by a motorized lock.

Image recording

Via the mobile network 600, the alarm receiver 400 (the customer/property owner) sends a "take picture" command to the server 230. The server checks authorization and, if this is in place, the signal is passed on (via the mobile network 600, wireless unit 131 and central unit 120) to the camera 113. The images from this camera can now be viewed.

The camera can also be connected directly to the wireless device 131 or to the internet device 134 or to an ordinary, commercial internet connection.

Figure 11 shows another variant of the monitoring system, where an alarm receiver 400 comprises one or more mobile units 450. This variant may be suitable for a "guard group". In other words, it can be suitable for use where the scheme forms, for example, a "guard group". In this case, the guard group acts as a mobile alarm center, where the guard is the primary alarm receiver. On the technical side, a server system receives logs and distributes alarms. The server system also monitors and logs other events, such as delivery confirmations, reports, reference timings, etc. In this variant, the traditional alarm center 300 is the secondary alarm receiver. Via the server system, the owner 400 of the alarm system can have information sent to his/her mobile phone, computer, etc.

When there is an alarm, the server system logs and formats the alarm information for the mobile device and (as determined by the programmed conditions in relation to mission type, position, etc.) forwards this to the "correct" guard. The server system monitors and controls the process. Alarms can be sent simultaneously to several guards in the area. Whoever signs off first is given the mission (and it is canceled for the other guards). Fire and emergency alarms must be acknowledged within 30 seconds and other alarms within 75 seconds. If there is no receipt, the alarm is secondarily sent to an alarm centre, for example SOS Alarm.

The guard carries a mobile device for reception, delivery confirmation (receipt) and reporting. There is also access to all other forms of data support. The mobile device has a fast and simple touch-screen interface and can be equipped with a uniquely identifiable code that identifies the device in question.

Figures 12 and 13 show a number of screens illustrating the sequence of events in the mobile device.

The mobile alarm receiver 450 can of course be used in combination with all other possible variants of the monitoring system.

Figure 14 shows a possible function (integrated into the monitoring system) for locking and opening an alarm terminal assuring, distance-based configuration.

An alarm terminal can be configured for certain properties and cannot then be modified without authorization. At the same time, there is a need to allow, for example, service technicians to carry out service 410 from a distance, that is, it must be possible to connect from a distance and to change settings, change programs, etc. However, this must never happen without the alarm terminal-" the owner" 400 actively consents to this.

The problem can be solved by configuring the alarm terminal: to have, in its "normal state", all interactive inputs and ports closed; and only allowing outbound communication (for example in connection with an alarm) to be initialized from within the terminal.

When distance-based access is required, the "owner" 400 uses an encrypted and digitally signed message to identify "himself" to the alarm terminal. This message consents and opens the terminal for distance-based access for a specified period of time, such as 15 minutes.

At the end of this time, the terminal automatically closes the opened port. By using a new, encrypted and digitally signed message, it is possible to close the terminal manually.

The messages for opening and closing can be sent via another risk-free carrier, such as SMS, whereby a procedure in the terminal only accepts correctly coded and signed messages.

Here it is also possible to use a dedicated TCP/IP network 620, which is a network that is kept separate from the common internal one network.

Figure 15 shows flowcharts for three variants of how distance-based service, as shown in Figure 14, can be carried out. Other variants are of course also possible. Distance-based service can be performed via a mobile network in the following way. Distance-based service 410 wants to perform distance-based service on the central unit 120. Via the mobile network 600, a connection is established with the server 230. This checks whether the customer 421 is open for distance-based service via the mobile network 600. If the line is open for distance-based service, the connection is continued via the mobile network 600 and the wireless unit 131, to the central unit 120. Distance-based service can now be performed. The opening for the connection is closed either manually on completion or automatically after 15 minutes.

Variant two shows a flow diagram for one way, in which distance-based service can be performed via a fixed network. Distance-based service 410 wants to perform distance-based service on the central unit 120. Via a dedicated TCP/IP network 620, a connection is established with the server 240. This checks whether the customer 420 is open to distance-based service via the mobile network 600 and the server 230. If the line is open for distance-based service, the connection is forwarded (via dedicated TCP/IP network 620 and Internet device 134) to central unit 120. Distance-based service can now be performed. The opening for the connection is either closed manually on completion of the distance-based service or automatically after 15 minutes.

Variant three shows a flow diagram for another way in which distance-based service can be performed via a fixed network. Distance-based service 410 wants to perform distance-based service on the central unit 120. Via dedicated TCP/IP network 620, a connection is established with server 240. This checks whether the customer 420 is open to distance-based service via TCP/IP network 610 and server 230. If line is open for distance-based service, the connection is forwarded (via dedicated TCP/IP network 620 and the Internet device 134) to the central unit 120. Remote service can now be performed. The opening for the connection is closed either manually on completion of the distance-based service or automatically after 15 minutes.

Figure 16 shows an example of a communication unit 130 and its constituent elements. The device has interfaces for different communication possibilities and contains, for example, functions that enable it to work both as a fixed and a wireless IP terminal.

Redundancy and security are important functionalities in the monitoring system. The following describes one way to ensure this.

It has been judged that the solution described below satisfies the requirements that are stipulated and given concrete form in detail in part 1.1.1. To exemplify the basic principle of the proposed solution, several exemplifying application examples are given in sections 1.6 and 1.7.

Definitions

Server cluster A collection of servers in which failover support has been implemented.

Failover means that if one server in the cluster goes down, one or more servers will

in the cluster manage its workload and jobs.

Alive server cluster A server cluster in which, at one or more physical locations, failover support has been implemented for Alive functionality. Failover means that if one server goes down, one or more servers in the cluster will handle its area of responsibility (terminals and alarm states).

1. 1 Description of proposed system architecture

The proposed solution:

Places the decision regarding redundancy switching with the terminal. This reduces the complexity of the system solution.

Modifies the server system solution with a dedicated (non-redundant) configuration server and any number of Alive servers handling terminals and alarm receivers. Each Alive server 230/240 can be located anywhere, but requires IP access to all the other Alive servers in the Alive cluster, as well as to the configuration server and the web access server (see Figure 7).

Simplifies the database structure in the Alive servers 230/240 so that it only handles status changes and does not store log information/statistical information that is not used. This includes removing the terminal log, the terminal alarm log and the system log from MSATB and ACTB, and thus reducing the amount of data that is written for logging purposes in the database. Can be written to a file so that, for debugging purposes, all the log files from all Alive servers can be compiled for database analysis.

In this solution, the configuration server does not need to be up for the system to function. However, it needs to be up for any modifications in the configuration of the system or an individual terminal.

The basic idea of the proposal is the introduction of a list of IP addresses for Alive servers. This is fed into the terminals and the choice of working (eng: live) server is then given to each terminal. Compared to the present terminal, the difference is that instead of a unique configuration IP address and a unique Alive server address, there is a list of possible IP addresses that can be used for communication with the system. A terminal can use any of the IP addresses for communication and the choice to change servers when contact is not achieved with a server is made by the terminal itself. These servers are used both for downloading configurations and for Alive messages, that is, there is no longer any difference between the different messages.

Implementation of the terminal is simple. When communication fails with one server (an IP number), the terminal moves on to the next IP number on its list. The terminal is provided from the start with a factory-configured list. However, when using new software, loaded remotely, it can be modified to support new lists.

For this to work, all the servers in the specific terminal's "area of responsibility" (the list) must know which server is handling the terminal in the past.

1.1.1 Alive Server 230/240

Below is an overview of the proposed modification of the Alive server.

Figure 18 shows that large parts of the present Alive server implementation can be retained. The new function that synchronizes all the Alive servers in the cluster is described in more detail in section 1.1.2.

The functions shown in figure 18 are briefly described in the table below.

5

It still remains a choice whether each logical server should be split between two physical servers (one

communication server and one database server).

The arguments for placing everything in a single physical server are:

Cost savings (ie about half the amount per Alive server). Savings on

server hardware and an MS 2000 server license.

Simplified maintenance. Because the number of physical servers in the system is reduced, installation/upgrade/backup and system maintenance are simplified.

The arguments for continuing to use the "distributed solution" between server-front/ server-back-end (communication server / database server) are: Hardware/configuration optimization. The communication server and the database server can

optimized in terms of hardware and configuration.

As the back-end IP is not exposed (depending on the network solution used in

the implementation), greater opportunities to secure the system against unauthorized access/holes.

Because each node in the cluster would become more efficient, the number of nodes in the cluster could be kept down. This would serve the synchronization traffic, which increases with the number of cluster nodes in the system.

Based on the arguments above, the argument for continued front-end/back-end deployment appears to have merit, where funding and maintenance/operational time permit.

1.1.2 Synchronization Service

The synchronization of terminal status data in each Alive server is necessary to enable all the servers in the system to handle any terminal that chooses to select a server for its communication.

Furthermore, in order for the configuration of system parameters and unique terminal parameters (which are activated in the configuration server database) to be updated and reflected in the Alive servers, there must also be a synchronization function for these parameters. The difference between this and the previous one is that here the configuration server is the master and the only server that can implement changes to parameters in the system.

To handle the two functionality requirements mentioned above, a synchronization service (installed on all Alive servers, the configuration server and the web access server in the system) is implemented. The synchronization service establishes an outgoing TCP session (and keeps the session alive) with all the servers in the system, and implements a listener for incoming TCP sessions from all the servers in the system.

For the synchronization service to function satisfactorily, all servers in the system must have good time synchronization. Good time synchronization is a critical parameter for the synchronization service when it has to determine when/if status update should take place.

Figure 19 shows that each Alive server in the cluster has one (heartbeat-monitored) client session with each Alive server in the cluster (except itself). This session is used to update terminal status changes.

In addition, each Alive server has one client session with the configuration server and the web access server, which, in order for it to present terminal status via MSATB or ACTB, also receives terminal status changes.

The configuration server also has a client session with each Alive server in the cluster. The session is used to send configuration updates (these can only be sent from the configuration server) and terminal management commands.

Figure 20

This synchronization service, terminal congestion synchronization service, shall include:

A "status update send" function responsible for sending out "update terminal status" messages (for terminals whose status changes in this server) to all other servers in the redundant cluster.

The "status update send" function sets up an outgoing TCP session (which is heartbeat-monitored if no status update is required) with each addressable

server's "status update reception" in the Alive cluster. A configuration file (or equivalent) that provides:

- The IP addresses of Alive servers

- The IP address of the configuration server

- The IP address of the web access server

A "status update receive" function responsible for listening and setting up outgoing sessions with configured Alive servers in the redundant cluster.

The "status update receive" function is heartbeat monitored and is implemented as a TCP listener that accepts sessions from all addressable (configured) "status update sending" servers in the Alive cluster.

A "status update logic" function that implements the logic of the synchronization service and which is the function that receives: 1) Indication from Alive analysis when a terminal's status changes and generates a message out to the "status update send" function. The logic function is also responsible for keeping track of status update failures for one or more servers. When a session can be established, it repeats status information for this terminal to the server(s).

2) Incoming heartbeat messages from all the servers in the server solution.

3) Incoming "update terminal status" messages from other servers. It then updates databases in accordance with the received information. 4) Incoming "update terminal configuration" and "update system configuration" messages from the configuration server. It then updates the database in accordance with the received information. 5) Incoming "send terminal message" messages from the configuration server. It ensures that the message is sent from an active server.

The logic function is also responsible for re-establishing connections with all servers in the cluster and the configuration server and the web access server.

The communication between "status-update-sending" clients and "status-update-receiving" servers shall use TCP (session maintained) and a new application-specific protocol used for information exchanges that offers the following message types:

1.1.3 Terminal and System Configuration Information

The following information is classified as terminal and/or

system configuration information and can only be modified in the configuration server. This server's synchronization service then ensures that changes are distributed to the other servers in the system. Global system parameters:

Service Levels

Roaming lists

Refrain from cutting I astete programs and re ver sions

Alarm center configurations

Alive server lists (note: new list management vital for redundancy)

Unique parameters for each terminal in the system:

Installation parameters (MAC, IMEI, SIMSERIAL, MSISDN)

Configured service level

Configured roaming list

Configured software version

Alarm port settings (activation and input type, connection with alarm center) MLAN settings (IP settings, port configuration)

N M E A push conf iguration

New configurations and updating/modification of existing configuration information in the configuration server are carried out as before, using the existing MSATB API. Apart from the addition of Alive server list handling, this API does not require any modification in terms of configuration parts. Extension of the API may also be necessary for redundancy checking and monitoring/operational statistics in relation to such checking.

As in the present solution, MSAWEB/MSATB is used for changing a terminal's configuration and/or the system configuration. All changes are made to the configuration server's database. The synchronization service then ensures that the change is sent out and updated in all Alive servers in the system.

1.1.4 Terminal status information

The information below is classified as terminal status information and must be synchronized each time the status changes. It is grouped into the following classes:

- Global status change time

- Connection status

- Outgoing message status

- Alarm status (alarm input status, alarm code, alarm time, alarm center rec.lD)

- Crypto Status (Key ID/Secret)

- Responsible server

<GlobalStatusChangeTime> indicates the last date/time when any of the parameters were changed. Each status class also has its own update time parameter (class status change time) for this purpose.

<Connection Status> indicates the terminal's connection status (Alive analysis) - see the table below. This status information is already in the existing database.

<Outgoing MessageStatus> is a modified version of the current outgoing message queue. The modification adds the status that a certain type of messages must be sent until the corresponding delivery confirmation is received from the terminal. This is to enable handling of configuration updates, new terminal software downloads, etc. in the new redundancy solution without having to synchronize the existing message queue in the database.

<AlarmStatus> indicates the alarm status of the eight alarm inputs and the connection alarm.

<KryptoNøkkelStatus> always contains the last valid encryption information in the form "key ID" and "crypto secret".

<ResponsibleServer> indicates which server in the cluster is responsible for the relevant terminal. Each one of these groups of messages has its own time column, in which

<ClassStatusChangeTime> is logged so that the synchronization service logic can process decisions based on valid terminal status when several different statuses have occurred due to the error conditions that can occur when the synchronization service between different servers has not worked.

Each terminal is identified by an individual ID. This is the unique key for each terminal in the database. Each change in a unique status parameter is logged with the valid time (this requires that all servers in the system are time synchronized) so that, in special cases, it is possible to handle the error conditions that may occur. Each status parameter can have the values shown below.

1.1.5 Configuration Server

Below is an overview of the proposed new Configuration Server feature. This exists as a logical part of the present system, but it cannot be separated (which is possible in the new system solution) and it cannot handle terminal communication to this server.

Figure 21 shows that the configuration server uses exactly the same database as the Alive server, but with the difference that the configuration server is the (only) entity that creates and modifies the content of the terminal and the system configuration. Furthermore, it receives a copy of the terminal status by passively listening to terminal status updates received by the server synchronization service. The terminal status database is used to enable the system administrator to obtain all current terminal statuses via MSATB. Unlike the Alive server, the configuration server has no communication interface with terminals and alarm receivers. Instead, it provides the MSATB API for managing the system's terminals.

In order for the new operator functions provided in Server v2.6.x to be handled in the new system architecture, it must be possible for the server synchronization service to handle the configuration server's ability to send terminal-unique messages to the on-premises server. This is done with the "send terminal message request" type message.

The table below briefly describes the functions required in the configuration server shown in Figure 21.

1.1.6 Web Access Server

Below is an overview of the proposed new Web Access Server feature. This exists as a logical part of the present system, but it cannot be separated (which is possible in the new system solution). It is being completely restructured for customer access. At the same time, as no configuration is possible from this server, security is increased.

Figure 22 shows that the web access server uses exactly the same database as the Alive server (with the addition of a new table for handling terminal history). It receives a valid copy of the terminal status by passively listening to terminal status updates received by the server synchronization service. From the configuration server it also receives a valid copy of the current terminal configuration.

Unlike the present Alive server, the web access server has no communication interface with terminals and alarm receivers. For customer management of the system's terminals, it only offers the ACTB API.

Retaining the ability to download valid position and terminal log history via ACTB requires the following new extensions: A push service, MSA Wireless Data Push, for non-alarm based data such as, for example, Alive position, fleet (eng: fleet) and, where relevant, transparent data from the terminal's serial ports). This push service can also be connected to push the information directly to the customer. However, it must always be configured to push configured data (eg Alive position) to the web access server and service described immediately below.

A unique table in the Alive data database that is updated by a new service, the MSA Wireless Data Push Receiver, which listens to all push services in the cluster.

The table below briefly describes the functions required in the configuration server shown in Figure 21.

1.1.7 Online alarm processing

The online system and the connection of Wireless to this system have shown that the proposed solution can be handled when multiple node addresses are allowed in the system. The solution is then that all the servers in an Alive server cluster use the same node address in outgoing communication to the Online network (see figure 23).

One new feature that needs to be handled is the fact that alarm confirmations from the Online network will be routed to any Alive server in the cluster, regardless of which server the alarm was sent from. This means that the online service/alarm analysis at the server must also handle incoming delivery confirmations to terminals for which the server is not responsible. The terminal's status change is updated via the synchronization service, but, as the terminal is still managed by the active server, without any change in the "responsible server" status parameter.

5.1.8 Alarm handling in SOS-Access version 2 XML

Alarm handling in servers for terminals configured to send alarms over the SOS V2 interface is not affected by the redundancy solution. This is because the interface requires delivery confirmation within 10 seconds of a session being established. Consequently, delivery confirmation will always come to the sender (the active server).

All the servers are thus configured to send SOS V2 alarm messages over TCP/IP to the same IP. SOS only needs to open the firewall for the IP addresses of all the Alive servers in the cluster. This is because the interface requires delivery information within 10 seconds of a session being established. Consequently, delivery confirmation will always come to the sender (the active server).

5.1.9 Alarm handling in MSA Wireless Push (~SOS V3)

Alarm handling in servers for terminals configured to send alarms over the MSA Wireless Push interface (eng: MSA Wireless Push) is not affected by the redundancy solution. This is because all servers are configured to send Wireless Push alarm messages over TCP/IP. Alarm acknowledgment always occurs in the established session and, consequently, a transmitted alarm will always be sent back to it

active server.

Unfortunately, the current implementation of alarm receivers is affected, as receivers must: 1) Handle TCP sessions coming in from all Alive servers in the cluster. Consequently, for all the Alive servers in the cluster, openings must also be made in their firewalls. 2) Implement outgoing (client) heartbeat sessions with all the Alive servers in the cluster.

1.1.10 SMS proxy server

Not affected by the redundancy solution.

1.1.11 Terminal Specific Commands

The modifications needed in the terminal application are not considered to be that extensive and the algorithm for redundancy switching can be described, in a simplified way, as follows: Loaded at the time of manufacture, the terminal has a standard (default) list of allowed Alive servers (IP- addresses) in the application.

To retrieve the time (if it does not get this from the optional GPS module), the terminal initially contacts the first server in this list. If contact is not established, a cursor will move over the list of active servers and the terminal will attempt to retrieve the time from the new IP address.

Once the terminal has obtained the time, it uses the active server (pointer in the file) for all Alive-related IP communications, ie:

Key exchanges (RSA encrypted)

Alive messages (AES encrypted)

Time synchronization messages (time client).

Any SMS message that is sent always uses the active server IP.

If the terminal's TCP/IP transmission of any of the above-mentioned messages fails, the terminal tries a further N times (N is a configurable parameter, as a suggestion N = 1). The terminal then moves one step forward in the server IP list and uses this IP for all Alive-related communication. If the cursor is at the end of the list, it starts again with the first IP address in the list.

Before enabling SMS transmission, a terminal that has been configured to use SMS as its secondary bearer waits for, say, its first attempt, to try a new IP address using GPRS. As noted earlier, the SMS transmission uses the IP address currently indicated in the list.

The file list marker should be stored in the flash memory. Consequently, if the terminal loses power or is restarted, it will restart against the most recently used server IP. This is to avoid generating unnecessary synchronization traffic in the Alive cluster.

1. 2 Handling load balancing

Depending on needs and necessities, as each server will be able to send a "switch server" message to individual terminals, this system solution enables different types of balancing.

Load balancing can thus be implemented in one or more of the following ways:

- The number of terminals to be handled by a server is exceeded and the server chooses to force (arbitrarily or in a predetermined way) terminals to switch to new servers. - Load monitoring information can be built into the heartbeat synchronization message sent to all servers. This will allow logic in each server to dynamically distribute the load by forcing (arbitrarily or in a predetermined manner) terminals to servers with loads that are reported as low.

To enable a server to force a terminal to switch servers, a new message must be introduced in the application protocol sent from server to terminal. It will give the new IP address to which the terminal will switch.

1. 3 Fault monitoring and automatic redundancy switching

A new logical feature that can be introduced with this solution includes an improved monitoring function regarding Alive server services and log files. The new function can automatically decide to close a server when it shows errors and, at the same time, load balance the terminals that used this server (ie split the load among the other servers in the cluster). The error can then be rectified "offline", without affecting the functionality of the terminals.

As before, this feature can be implemented using a third program. It is most simply implemented by closing all relevant services on the relevant server when the monitoring system triggers a serious error status. This closure will cause all terminals and alarm receivers that worked against the affected server to be taken over by another server in the cluster.

Implementation requires both a review/analysis of the events and also documentation of the Alive server log messages that trigger the events. In certain cases, implementation may require stored procedures and changes/improved error messages from services.

1. 4 Migration of existing TOR terminals

To enable the introduction of this redundancy solution, it must be possible to update existing TOR terminals to new software that supports the new redundancy solution (the update would, of course, also have to be implemented). Although no details have been specified, this is not believed to present any problem. The amount of new code required to handle redundancy switching in terminals is relatively small. The following is one way migration of existing terminals to the new redundancy solution can be implemented: 1. The new, redundant server architecture is installed and put into operation in parallel with the existing Alive servers that handle the existing terminals. 2. Terminal data and configuration data are exported (manually) from the existing Alive servers. To ensure that no status changes occur during the relocation period, which should be possible to keep relatively short, the Alive server system is stopped. 3. A script specially adapted for migration purposes is used for the import of the old format. This brings the entire server architecture into operation. One of the alive servers in the cluster is mapped as the "old" alive server. 4. New software that supports the new Alive server list and redundancy management in the terminal is downloaded remotely.

5. The new redundancy solution is now active.

1. 5 Alarm analysis in a redundant system

It has been judged that, if so stipulated, all four proposed alarm analysis types (see below) can be handled in the proposed redundancy solution. As only one of the four variants (loss of ISP) is implemented in the present server software, this will however require additional, newly developed software.

Connection alarm analysis based on network information from the operator (cell ID/local area).

Connection alarm analysis based on information from reference terminals.

Configuration of terminals to be included in analyses.

Filtering out connection alarms caused by loss of ISP.

1. 6 Use cases - normal operation

1.6.1 Terminal Boot

The steps in a normal sequence for starting up a terminal in an existing Aliveserver cluster system are given below.

Import of terminal data

Using a terminal import tool, the terminal's installation parameters are imported (from the production database) to the configuration server.

Configuring the terminal in the configuration server

Other terminal configuration parameters (service level, MLAN settings, alarm port settings, NMEA push, roaming list) are set up in the configuration server. The Alive cluster to be used by the relevant terminal is also specified here. On completion, the configuration is confirmed, the term i na I status is activated and the configuration server's synchronization service sends an update of the terminal configuration to all the Alive servers in the cluster. All these servers are set as "not responsible" for the terminal. More precisely, to indicate that in the present state no server is responsible for the terminal, the "responsible server" is set to <0.0.0.0>;1970-01-01 00:00:00".

Opening for initial key exchange

At a given time (eg triggered by a Prisma/MSA web operator), the terminal is opened (from the configuration server) for the initial key exchange. The configuration server mirrors this configuration change to all "included" servers. For security reasons, this window, which is where the terminal is allowed to perform a key exchange, should be kept as short as possible.

The terminal retrieves the time

In order for the terminal to be able to communicate with the servers, a correct time must be used in the encryption storage unit. Consequently, once the terminal has started and established GPRS, it starts to retrieve the time using the simplified SNTP protocol that has been implemented. Here the terminal chooses to retrieve the time from the first server in its pre-configured list, (e.g. Al). If it is not successful in retrieving the time from this server, it goes to the next server on the list. Alternatively, if the terminal is equipped with a GPS module, it can get the time from this. Here it does not contact the server for past synchronization. To retrieve the time, the terminal does NOT need to be configured in the system. This is because the time server in each Alive server listens to time requests from any client and does not need any

reliability control of the terminal.

The terminal starts initial key exchange

When the terminal has obtained the time, it contacts the active server (the first in the list or one from which it obtained the time) and sends an RSA-encrypted key exchange message. If the terminal is started (from the configuration server) before it has been opened for key exchange, the server it contacts is unable to identify the terminal as valid. This is logged as an error in the system log/event log. After N (configurable parameter) failed transmissions of the application message, the terminal decides to move on to the next server in the pre-configured list. This procedure is repeated as long as there is no opening for key exchange.

New key and key ID for the terminal

The first server that receives the message from the terminal checks the "responsible server" terminal status parameter. If this is set to "0.0.0.0", the terminal's message is accepted and the server takes responsibility for the terminal by generating a key/key ID. This is sent to the terminal, the terminal status is updated with the new values and "responsible server" is set to the server's IP address.

The status change is triggered to the synchronization service. Using all the servers configured for use with the terminal, the synchronization service then sends the new terminal status to all the servers in the Alive cluster, the configuration server and the web access server.

Downloading the configuration

The terminal then continues to send messages to the active server. Since it initially lacks a configuration file, it starts downloading the configuration.

The terminal is now active and in operation.

1.6.2 Modification of terminal configuration

The steps in a normal sequence for modifying a terminal's configuration are given below.

Modifying a terminal's configuration

As with the present system, the operator modifies the terminal configuration (via MSAWEB or other interface) by accessing MSATB. If the terminal configuration is accepted, the information is updated in the configuration server.

Updating the configuration in the Alive cluster

The configuration server synchronization service sends a configuration modification update to all Alive servers. If the configuration modification requires the terminal to be updated (e.g. downloading a configuration or a message file), the synchronization service also triggers this by updating the terminal status with the relevant parameter in the <Outgoing MessageStatus> status class.

The Alive server sends messages to the terminal

Once the server responsible for the terminal in question has received the status change, it (in the absence of priorities) starts sending messages to the terminal. The messages relate to the requested configuration modification (eg downloading a new configuration). If, at this point, the terminal experiences problems establishing a connection with the active server, it moves on to the next one, which also has the same status parameter enabled (ie sending, for example, a download new configuration message to the terminal).

The terminal downloads the new configuration

When the terminal has downloaded the requested configuration modification, the responsible server updates the status change (removes the active parameter in

<OutgoingMessageStatus> status class). This is synchronized out to all the Alive servers, the configuration server and the web access server.

1.6.3 Operator Access

As in the current system, the operator logs in via MSAWEB, the Prisma customer management device or any other operator interface that uses MSATB to communicate with the configuration server.

The difference in the new redundant system is that the amount of information in the system log and the terminal log (and perhaps also the terminal alarm log) is smaller. Otherwise, most things are exactly as in the present MSAWEB/MSATB system. To enable configuration of the Alive server list, an addition must be made.

NOTE: Because certain logging functions are no longer supported in the new API and there is no new addition, the Prisma application that developed services for MSATB V2.5.2 (=V2.6.1) must update its applications.

1.6.4 Customer access

The customer logs in to the ACTB web service in the web access server. All data that is presented to the customer comes from a local, synchronized database in the web access server.

NOTE: Customers who have developed services for ACTB V2.5.2

(=V2.6.1) must update their applications. However, since the only effects on the API are the amount of data that can be returned and a reduction in certain input parameters, it is not judged that updating will require extensive work.

1.6.5 Provision and start-up of a new server

The steps in a normal sequence for starting a new server are given below.

Installation of Alive server software

The authorized person installs the software on the Alive server. The system installs basic configurations and a database without terminal and system data. In the database, a table (system-config.) indicating the database's last configuration update is set to 1970-01-01 00:00:00. This indicates that the database is missing all configuration data. In this state, all the communication services will not be activated on the new Alive server.

Updating system and terminal configurations in the new server

The new server's IP address is included in the list of Alive servers in the configuration server configuration of the synchronization service. When the configuration server synchronization service starts sending <Heartbeat> messages from the configuration server to the new Alive server, the response from this server will include the time/date of the last configuration status. Consequently, the configuration server's synchronization service will detect that all configuration data needs to be updated in the new server. The configuration server accordingly updates the new Alive server using <UpdateSystemConfiguration> and <UpdateTerminalConfiguration> messages. This populates the new server's database with the relevant configuration data. What the server is now missing is status information for all the terminals.

Update of synchronization services in the Alive cluster

All the synchronization services in the existing Alive server cluster will be updated with the new server's IP address. This causes all the servers to establish a client session with the new server. They begin by sending <Heartbeat> messages. The new server responds with a <Heartbeat> response message. This has a parameter that gives the time of the last update of status data from the active server (since the new server lacks previous status information, this will be 1970-01-01 00:00:00 for all cases). All servers in the cluster receive heartbeat responses and, by sending an <UpdateTerminalStatus> message, update the status of all terminals whose status change date/time is later than indicated. The new server receives <UpdateTerminalStatus> messages from all the servers in the cluster and, on the basis of the received data, updates its database.

Start of communication services on the new server

Then all communication services start on the new server. This is indicated in

The <Heartbeat> response message to the other servers in the cluster, of the "operational status" parameter now set to "operational".

If the "spread evenly" load balancing function is activated, the other servers in the cluster detect that the new server has no load. To even out the load balancing resulting from the introduction of the new server, they will gradually transfer terminals to the new server. If the load balancing does not take place, the new server is ready to handle terminals should problems arise with one of the other servers in the cluster.

Update of the Alive server list

Finally, the system's Alive server list is updated on the configuration server. This causes all the terminals to download a new Alive server list. Then all the communication services start on the new server. This is indicated in the <Heartbeat> responses to the other servers in the cluster by the "operational status" parameter now set to "operational". This enables the terminals to switch, in case of redundancy, to the new server.

1.6.6 Alarm sequence with Online as alarm receiver

The steps in a normal alarm sequence with Online as the alarm receiver are as given below.

Alarm at a terminal input

The relevant terminal sends an alarm message to Server A. The alarm message is received by server A, which updates the terminal's status in the database. This triggers a synchronized update with all the other servers in the cluster.

The alarm is sent to the Online network

Because all the Alive servers in the Alive cluster are identified by the same Online node number, the server to which the delivery confirmation is "routed" is totally random (the routing algorithm in the Online network). The server (server B) that receives the confirmation will, if it is not itself responsible for the terminal, handle the confirmation in the expected way.

The synchronization service updates server A's status

Using the <UpdateTerminalStatus> message, the synchronization service on server B updates all servers in the cluster (server A included) with the status change.

Server A returns a delivery confirmation to the terminal

Server a assimilates the status change and sends an alarm confirmation back to the terminal.

1.6.7 Taking an Alive server out of service

The steps of a normal sequence for taking an Alive server out of cluster operation are given below.

Termination of the server services

The operator stops the communication services (TCP/UPD/SMS) and the alarm services on the relevant server. At the next message, this will result in all the terminals that have access to this server switching (redundancy switching) to the following server on the list.

Verification of redundancy switching

On the terminal status list in any server (or via the interface in MSATB), the operator verifies that none of the configured terminals are any longer handled by the halted server. If the latter is not the case, the operator must wait until it is (can of course be automated if this is desired).

Update of the Alive server list

If there is only a short stop in the server's operation, it is probably unnecessary to update the Alive server list. For longer outages, the operator updates the Alive server list in the configuration server. This configuration change is mirrored to all Alive servers in the system. This ensures that it is downloaded to all terminals. All synchronization services will also be updated with this information and no communications will be sent to the stopped server.

1.6.8 Bring an Alive server back into service

The steps in a normal sequence when an Alive server is returned to service after a short period of maintenance without the Alive server list being updated (by removing the server from the list) are given below.

Start of synchronization services on the server

The operator starts the synchronization service on the server. The configuration server starts updating the server. Detection from the <Heartbeat> response message that the time of the last configuration and terminal status update is much earlier than the last change (given that this happened while the server was down), all the other servers in the cluster also contribute to this update.

Start of communication services on the server

The operator waits until he/she has received an approved status (from the synchronization service) for the server that has been returned to service. This is provided by all the servers in the cluster that have updated the server with valid status information and the configuration server that has updated any configuration changes. Once the approved status has been received, the operator starts all communication services on the server. The server is now back in the redundancy cluster and can handle redundancy switching of the terminals in the system. If load balancing is enabled, other servers can detect (from <Heartbeat> information) that this server is idle, and, in accordance with the algorithm implemented for this type of load balancing, transfer some of their terminals to the idle server.

1. 7 Use cases - error handling

1.7.1 Error in a terminal's TCP connection with a server

Below is the sequence of events, step by step, when a terminal's message to an Alive server fails. This can happen when:

Access to the server is interrupted (ISP problems, firewalls, network errors).

Problems in the server environment prevent an incoming TCP session from being established.

All errors (except those given above) that cause the TCP connection to the active server to fail have the following pattern:

The terminal sets up a TCP session

This happens when the terminal retrieves the time or sends encrypted Alive messages to the server. For each encrypted message to be sent, the terminal takes the active IP address from the list (in its file system) of available servers in the Alive cluster. The terminal attempts to establish a TCP session with the given address, but fails when, due to one of the above conditions, the server does not respond.

The terminal changes the active server in its list

The terminal goes one step further (from server A to server B) in the list of allowed Alive servers and attempts to establish a TCP session with the indicated server.

The new server receives an encrypted message from the terminal

The new server (server B), with which the terminal communicates, decrypts the message. However, since the "served by date" status parameter is "server A" and the "served start time" status parameter indicates the "historical" time when server A "took over" the terminal, server B notices that the terminal not previously was its responsibility. For this terminal, server B updates, in its database, the "served by" status of "server B" and the "served start time" of <current UTC time>. The synchronization service ensures that this status change is mirrored to all servers in the Alive system (the Alive server cluster, the configuration server and the web access server). Server B has now taken over responsibility for the relevant terminal. If the synchronization service on server B does not have contact with the synchronization service on server A, the re-synchronization service in server B will ensure that server A is updated with this status when server A again establishes a client session with server B.

1.7.2 Synchronization service in server X loses contact with all other servers

What happens when a server in the cluster loses synchronization service contact with all other servers in the cluster, for example if the synchronization service is stopped or fails, or if internet access between the servers in the system is lost? There are two options in this situation: 1) The server automatically stops all communication services. This results in all the terminals that have access to this server switching (redundancy switching) to the next server on the list. 2) The server continues to handle all its terminals. This means that alarms/resets that come in from the Online system are not routed back, via the synchronization service, to the server.

Option 1 is the recommended option. A problem could certainly arise if only the synchronization services on all servers in the system were interrupted. This would result in a totally functional cluster solution suddenly ceasing to function as all the servers close their communication services. This means that the synchronization service, as an application, is a type of "single point of failure"

(eng: "single-point-of-failure"). However, it is considered unlikely that a failure in the application would not have been discovered during implementation and validation.

1.7.3 Synchronization service in server X loses contact with another server

What happens when a server in the cluster loses synchronization service contact with one of the other servers in the cluster, for example if the synchronization service on the other server is stopped or fails, or if internet access between the servers in the system is lost? The synchronization service continuously tries to re-establish the session with the other server. Once re-established, the <Heartbeat> function between two servers ensures that any status changes that occurred during the breach are updated between the two.

1.7.4 The data push service loses contact with the web access server

In this situation, customers are unable to retrieve valid terminal positions and are left with no log history during the breach. If this is considered to be critical, it is obvious that a function can be implemented to retrieve data and import this from the log files created locally on each Alive server in the cluster. However, this cannot be carried out if customers do not request it. Depending on how important this feature is considered to be, redundancy across two web access servers can be introduced. This spreads the risk of such a situation occurring.

1. 8 Identified Software Changes

To give an indication of the work required to implement the proposed redundancy solution, the two tables below provide an overview giving the scope of changes (or newly developed code). Most of the changes are in the newly developed functions of the server software. This is good in itself - validation is simplified when the amount of code and functions that would otherwise have to be changed can be kept to a minimum.

Terminal software changes

Server software changes

Claims (11)

1. Arrangement of devices to form a monitoring system comprising a number of local alarm systems (100) and a number of different monitoring stations (200), where the local alarm systems (100) each have the task of displaying, at their individual locations, the statuses of the various devices in the local system (100); whereby said local alarm systems (100) comprise devices for sending messages or other information regarding the statuses of the devices in the local alarm system (100) to one or more monitoring stations (200); wherein said messages or information are sent via synchronized servers (230, 240) over a number of different communication channels; whereby said monitoring station (200) comprises: - equipment (210) for distance-based checking of the extent to which each local alarm system (100) is able to send messages, - equipment (210) for distance-based configuration of the local alarm systems (100), - equipment (210, 250) for directing information flows from local alarm systems (100), and - equipment for distance-based control of locking devices at the local alarm stations, such as doors (114), gates, and whereby it is possible for a customer to control said locking devices; characterized in that at least one monitoring station (200) comprises a device (240) for traffic distribution which controls the traffic load from surveillance cameras (113.x) by sending images and/or video streams to various receivers, including a central image storage unit (500), an alarm/operations center (300) or an alarm receiver (400), with a resolution and update frequency adapted to the available bandwidth for the receiver (400). 2. Arrangement of units to form a monitoring system in accordance with patent claim 1, characterized in that the communication channels are fixed telephony, TCP/IP and mobile communication, either separately or in combination. 3. Arrangement of units to form a monitoring system in accordance with patent claim 1, characterized in that one or more monitoring stations (200) comprise at least one monitoring device (230) for wireless devices (131), where said monitoring device (230) sends messages, over a mobile network, to one or more wireless devices (131) in a local alarm system (100), where it is the case that a monitored wireless device (131) in a local alarm system (100) is considered to be able to send messages so as long as a uniquely identifiable response signal is received from there. 4. Arrangement of units to form a monitoring system in accordance with patent claim 1, characterized in that said traffic distribution device is provided with mathematical algorithms to compress said images and video streams (to occupy as little bandwidth as possible); and to determine to which recipients the images or video streams from the surveillance cameras (113.x) are to be sent. 5. Arrangement of units to form a monitoring system in accordance with patent claim 1, characterized in that said equipment (210) for distance-based configuration is able to update and/or install software in different units in a local alarm system (100), where the is possible for such update to be performed, using TCP/IP or other communication method to send configuration update. 6. Arrangement of units to form a monitoring system in accordance with one or more of patent claims 1 to 4, characterized in that each and every one of the units in the local alarm system (100) and in the monitoring stations (200) has a unique piece of digital information that identifies the device to which it belongs, and whereby there is also means of detecting whether a device with such a piece of identification information has been replaced. 7. Arrangement of devices to form a monitoring system in accordance with one or more of patent claims 1 to 6, characterized by the possibility of providing the messages that are sent between local alarm systems (100) and monitoring stations (200), and between the monitoring stations (200) themselves , a uniquely identifiable piece of identification information composed of information about the message and its sender, ensuring that if a message is altered in any way during its transmission, the identification information for such a message will not "match" (ie have the correct the profile for) the message. 8. Arrangement of units to form a monitoring system in accordance with one or more of patent claims 1 to 7, characterized in that communication in local alarm systems (100) is encrypted. 9. Arrangement of units to form a monitoring system in accordance with one or more of patent claims 1 to 8, characterized in that communication between a local alarm system (100) and monitoring stations (200) is encrypted, and correspondingly, the communication between different monitoring stations (200) is encrypted. 10. Arrangement of units to form a monitoring system in accordance with one or more of patent claims 1 to 9, characterized in that a monitoring station (200) comprises equipment for directing information streams to a mobile monitoring unit (450), such as a mobile guard equipped with a recipient. 11. Arrangement of units to form a monitoring system in accordance with one or more of patent claims 1 to 10, characterized in that a monitoring station (200) comprises means for blocking distance-based configuration of a local alarm system (100) by a customer.