|
(11) | EP 1 544 824 A1 |
| (12) | DEMANDE DE BREVET EUROPEEN |
|
|
|
|
|||||||||||||||||||||||
|
||||||||||||||||||||||||
| (54) | Procédé de traitement de signaux pour système d'alarme |
| (57) La présente invention se rapporte à un procédé de traitement de signaux d'alarme
comprenant la réception d'un signal d'alarme et la transmission d'un message d'alarme
à l'utilisateur indiqué pour recevoir le message d'alarme. Le traitement du signal
d'alarme comporte différentes étapes dont notamment l'identification de l'utilisateur,
du type d'alarme, d'au moins un détecteur qui a déclenché le signal d'alarme et l'envoi
à l'utilisateur d'un message SMS indiquant le type d'alarme, la zone et le détecteur
qui a déclenché le signal d'alarme. |
[0001] La présente invention se rapporte à un procédé de traitement de signaux d'alarme comprenant la réception d'un signal d'alarme par un récepteur agencé pour recevoir les signaux d'alarme produits par chacun des systèmes d'alarmes placés à des endroits à protéger et la transmission par un transmetteur d'un message d'alarme à l'utilisateur indiqué pour recevoir le message d'alarme.
[0002] Généralement, dans l'état de la technique, les systèmes d'alarme protégeant les immeubles contre par exemple l'intrusion, le vol, l'incendie ou autre sont soit directement connectés au propriétaire via un moyen de communication quelconque pour l'informer uniquement du fait que le système d'alarme est déclenché, soit connectés à des centres de surveillance qui se chargent de contacter l'utilisateur des endroits à protéger ou les services compétents pour une intervention. Dans ce dernier cas, le centre de surveillance, en fonction du type d'alarme, peut éventuellement informer l'utilisateur de la zone touchée par le déclenchement et identifier quel détecteur a été déclenché (détecteur de contact, détecteur volumétrique, détecteur de fumée).
[0003] Un problème récemment apparu consiste en l'apparition d'une législation belge qui stipule que lorsqu'une alarme anti-vol se déclenche, les utilisateurs ne peuvent plus directement appeler la police sans avoir la confirmation que le système d'alarme s'est déclenché pour une raison valable. Jusqu'à présent, avec les systèmes d'alarme qui contactent directement l'utilisateur, l'utilisateur prend connaissance, s'il est joignable, que le système s'est déclenché et il doit réagir sans savoir exactement ce qui se passe. Il faut donc qu'il aille constater lui-même la situation ou la fasse constater par une connaissance, mais il ne peut contacter directement la police pour une intervention puisqu'il n'a pas eu de confirmation. Le système impliquant un centre de surveillance ne pose pas ce problème mais il coûte cher pour l'utilisateur et présente une mise en oeuvre fastidieuse. En outre, ce dispositif n'est pas à l'abri de la défaillance humaine, ni de celle du système d'alarme.
[0004] Un objectif de l'invention est de pallier ces inconvénients, en procurant un dispositif pour système d'alarme automatisé permettant d'obtenir une information directement sur le type d'alarme déclenché et sur la zone concernée.
[0005] En effet, l'invention procure un dispositif de traitement de signaux pour système d'alarme caractérisé en ce que le signal d'alarme reçu comporte une première partie d'identification de l'utilisateur, une deuxième partie indiquant le type d'alarme, et une troisième partie indiquant au moins un détecteur qui a déclenché le signal d'alarme, le signal reçu étant transmis pour traitement au serveur qui est associé à une base de données et relié audit transmetteur, lequel traitement comporte les étapes suivantes:
(a) identification par ledit serveur, sur base du contenu de la première partie dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler,
(b) identification par ledit serveur, sur base du contenu de la deuxième partie du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme,
(c) identification par ledit serveur, sur base du contenu de la troisième partie du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s),
(d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
(e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données,
(f) annexion au message d'alarme d'au moins un numéro d'utilisateur, prélevé à la première adresse, et envoi dudit message composé par ledit serveur au transmetteur
[0006] Dès lors, un message détaillé est automatiquement produit et envoyé à l'utilisateur et une fois que l'utilisateur est informé du déclenchement du système d'alarme, il peut savoir quel type d'alarme s'est produite (vol, incendie, défaillance,...) et la zone où cette dernière s'est produite. L'invention informant l'utilisateur de manière automatique, le coût est relativement faible (le prix fixé de la communication) et la mise en oeuvre est particulièrement simple.
[0007] Dans le cas où plusieurs détecteurs ont déclenché l'alarme (cambrioleur qui se déplace d'un endroit à un autre, feu qui gagne plusieurs pièces,...) l'utilisateur reçoit plusieurs message d'alarme. Le fait de recevoir plusieurs messages écarte généralement la défaillance d'un système d'alarme et permet d'apporter une confirmation de la pertinence de l'alarme.
[0008] Selon une réalisation préférentielle de l'invention, le procédé de traitement de signaux d'alarme selon l'invention comprend un serveur prévu pour recevoir du récepteur et envoyer audit transmetteur une information, à intervalles prédéterminés, sur le fonctionnement dudit système d'alarme, lequel transmetteur communique l'information auxdits utilisateurs. L'utilisateur peut être dès lors informé en permanence à intervalles réguliers que son système d'alarme est opérationnel ou défaillant. En effet, un autre problème majeur de l'état de la technique est que lorsque le système d'alarme est défaillant, l'utilisateur s'en rend souvent compte lorsqu'il est trop tard, c'est à dire après un cambriolage ou après un incendie. Certains systèmes d'alarme fonctionnant par l'intermédiaire d'un centre de surveillance réalisent sur demande un test de ligne pour vérifier le fonctionnement du système d'alarme de l'endroit à protéger. Malheureusement, à nouveau, ce système est lourd à mettre en oeuvre et l'utilisateur n'est pas à l'abri d'une défaillance humaine ou d'un oubli. Le procédé selon l'invention permet de prévenir ces désagréments en obtenant une information directement sur le fonctionnement du système d'alarme par des tests à intervalles réguliers dont la durée varie selon les desiderata de l'utilisateur.
[0009] Généralement, la connexion entre le système d'alarme et le récepteur est une ligne classique PSTN, cette ligne PSTN est utilisée par le système d'alarme pour envoyer un signal au récepteur. Dans le cas d'une alarme telle qu'un cambriolage pendant lequel le voleur déclenche plusieurs détecteurs de mouvement et/ou de contact, le serveur est prévu pour bloquer le décrochage après un nombre maximum d'appel pour éviter que l'utilisateur soit inondé de message pour la même intrusion et qu'il doive assumer les frais d'un grand nombre d'appel. De préférence, le nombre de décrochage est limité à cinq appels du système d'alarme vers le serveur.
[0010] Le procédé de traitement de signaux est, en outre, caractérisé en ce que le serveur peut annexer le numéro de l'utilisateur en fonction du type d'alarme, c'est à dire qu'en fonction du type d'alarme, le serveur peut être programmé pour envoyer le message à un ou plusieurs utilisateurs en particulier. Par exemple, dans le cas d'un signal d'alarme incendie, le système enverra un message à l'utilisateur et aux pompiers, dans le cas d'une défaillance , le système enverra un message à l'utilisateur et à l'installateur, etc.
[0011] Les systèmes d'alarmes existant fonctionnent selon des protocoles propres, en fonction de leur programmation et de leur fabrication qui peuvent être plus ou moins différents selon les cas. Le dispositif de traitement de signaux pour système d'alarme selon l'invention, pour pouvoir être adaptable sur une grande variété de système d'alarme, doit pouvoir décoder une grande gamme de signaux d'alarmes. Il est préférable que le récepteur puisse fonctionner au moins selon les protocoles standards SIA et de préférence, il fonctionnera selon d'autres protocoles existants. Dès lors, dans le but d'obtenir un dispositif de traitement de signaux pour système d'alarme polyvalent, le récepteur procuré est un récepteur multi-protocole.
[0012] Le dispositif de traitement de signaux pour système d'alarme est caractérisé en ce que les utilisateurs sont informés dudit déclenchement de l'alarme ou dudit fonctionnement du système par SMS, MMS, message vocal, courrier électronique, via un opérateur-serveur SMS, ou des combinaisons de ceux-ci.
[0013] D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture du mémoire descriptif fait en référence aux dessins annexés donnés à titre d'exemples non limitatifs et dans lesquels:
la figure 1 est une représentation générale du procédé de traitement de signaux d'alarme selon l'invention,
la figure 2 est une représentation détaillée du fonctionnement du serveur,
la figure 3 est une vue détaillée du fonctionnement du système régissant le récepteur,
la figure 4 est une vue détaillée du fonctionnement du système de vérification des tests de ligne.
[0014] La figure 1 est une représentation du procédé de traitement de signaux d'alarme selon l'invention. Le procédé comprend la réception d'un signal d'alarme généré par un système d'alarme existant chez un utilisateur (1). La réception est réalisée par un récepteur de préférence multi-protocole (2). Le signal d'alarme reçu via la connexion (10) entre le système d'alarme et le récepteur, de préférence, une ligne PSTN (10) est traité par le serveur (3) qui identifie grâce à une base de donnée qui lui est associée le numéro de l'utilisateur, le type d'alarme, la zone de déclenchement et les détecteurs ayant déclenché le signal d'alarme. Le serveur (3), comme expliqué ci-dessous, compose un message et annexe au message l'information du destinataire du message. Le serveur (3) transmet le message au transmetteur (4) qui transmet le message reçu à l'utilisateur par exemple, soit par SMS (5), MMS (5), message vocal (5) , courrier électronique (6), un opérateur-serveur SMS (7), ou tout autre moyen de communication et combinaisons de ceux-ci. Selon le mode de réalisation, dans la base de données, l'information correspondant au numéro d'utilisateur peut comprendre le numéro de GSM de l'utilisateur (5), celui d'une tierce personne et par exemple le numéro de l'installateur (8) de l'alarme pour qu'il soit prévenu en cas d'une défaillance du système ou le numéro des pompiers (9) ou de toute autre autorité compétente (service de gardiennage ou autre) en cas d'incendie ou autre respectivement.
[0015] La figure 2 est une représentation détaillée du fonctionnement du serveur (3), le serveur reçoit un signal provenant du récepteur multi-protocole qui comporte trois parties (P1, P2, et P3), la base de données associée au serveur comporte au moins trois tables (p1, p2, p3) dans lesquelles les informations correspondant aux adresses des trois parties du signal se trouvent. Le serveur traite le signal reçu en trois parties du récepteur selon les étapes suivantes
(a) identification par ledit serveur, sur base du contenu de la première partie (P1) dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse (A1) indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler (21),
(b) identification par ledit serveur, sur base du contenu de la deuxième partie (P2) du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse (A2) indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme (22),
(c) identification par ledit serveur, sur base du contenu de la troisième partie (P3) du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse (A3) indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s) (23),
(d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
(e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses (A1, A2, A3) et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données ( 22 et 23),
(f) annexion au message d'alarme d'au moins un numéro d'utilisateur (21), prélevé à la première adresse (A1), et envoi dudit message composé par ledit serveur au transmetteur
[0016] La figure 3 représente une vue détaillée du fonctionnement du système régissant le récepteur. Lorsqu'un signal d'alarme arrive au récepteur, celui-ci signale à un ordinateur ou au serveur qu'il y a un appel entrant "RING" (31). Si l'ordinateur ou le serveur est prêt (autorisation de l'utilisateur ou pas, panne, ...), il envoie la commande "HANG-UP" (32), le récepteur décroche et signale au système d'alarme sa présence "HANDSHAKE" (33). Le système d'alarme envoie les données, le récepteur transfère les données pour leur traitement à l'ordinateur ou au serveur, si les données sont correctes, l'ordinateur ou le serveur envoient une acceptation "ACK" (34) au récepteur, si les données sont incorrectes, l'ordinateur ou le serveur envoient une non acceptation "NACK" (35) au récepteur. L'acceptation peut dépendre de divers facteurs, tels que par exemple, le nombre de signaux reçus du même utilisateur (en regardant dans la base de données EVENTS, le système peut savoir combien d'appel ont été reçus), le fait que l'utilisateur ait été identifié en tant que tel auparavant, ou lors de la déviation vers un autre récepteur (panne, entretien, mise à jour). Le récepteur signale son état "KISS OFF" (36) si les données sont correctes, c'est à dire si le récepteur a reconnu le protocole et "NO KISS OFF" (37) si les données sont incorrectes. Le récepteur décide alors suivant son état de la transmission de raccrocher "END" (35) ou de ne pas raccrocher "CONTINUE" (38) . Tous les événements sont stockés dans une table de la base de données "EVENTS". Les nouveaux événements sont stockés dans une catégorie "NEW EVENT". Dès lors, que ce soit pour un test de ligne ou pour une alarme réelle qu'un signal du système d'alarme est envoyé, il est traité par le récepteur de la même manière. Seul le traitement par le serveur et l'information de l'utilisateur sont différents. Dans le cas d'un signal d'alarme réel, le traitement du signal a été décrit ci-dessus lors de la description de la figure 2. Dans le cas d'un test de ligne, le signal est traité comme illustré à la figure 4.
[0017] Dans le but de pouvoir assurer à l'utilisateur que le système d'alarme est bien fonctionnel, le système d'alarme envoie à des intervalles réguliers des signaux signifiant que le système est opérationnel. Le récepteur reçoit les informations selon le protocole décrit à la figure 3 et ces données sont stockées dans une des tables de la base de données. Le système de vérification des tests de ligne comprend au moins un ordinateur (41), de préférence trois (41, 42, 43) et de manière plus préférentielle au delà de trois. Le système vérifie si une transmission de signaux signifiant que le système est opérationnel a bien été effectué endéans le délais imparti (44). Si c'est oui (45), un signal est envoyé à un ordinateur pour signaler que tout fonctionne et/ou à la base de données (47). Si c'est non (46), le système vérifie s'il est capable d'envoyer un message (48) dans la base de données EVENTS. Si c'est oui, (49), le système envoie un message de panne (51) ou de défaillance (51) dans la base de données et l'envoi est pris en charge par le serveur et le transmetteur. Si c'est non (50), le système signifie à l'ordinateur qu'il ne peut pas envoyer le message à la base de données. Dans cette réalisation préférentielle, le nombre d'ordinateur présent dans le système de vérification du fonctionnement du système d'alarme est de trois (41, 42, 43). Dans le cas où un ordinateur tombe en panne ou est éteint (par exemple 41 ), tout le procédé est transféré vers un autre ordinateur (42 ou 43) qui prend en charge tous les tests de ligne du premier ordinateur (41). Dans le cas ou le premier (41) et le second ordinateur (43) sont défaillants, tout le procédé est transféré vers un troisième ordinateur (43) qui prend en charge tous les tests de ligne du premier (41) et du second ordinateur (42).
[0018] Néanmoins, le procédé selon l'invention exposé ci-dessus est donné à titre d'exemple non limitatifs, par exemple, dans une réalisation préférentielle, il existera plusieurs serveurs selon la technologie maître-esclave qui peuvent être délocalisés pour des raisons de sécurité notamment et tous les ordinateurs utilisés dans le procédé pourront être au moins dédoublés, de même que le récepteur et le transmetteur.
| Traduction des commandes et des légendes dans les figures. | |
| SMA REC | Récepteur du procédé de traitement de signaux d'alarme selon l'invention |
| GROUP X | Groupe X |
| JOB X | Tâche X |
| Line Ringing | Appel entrant |
| Receiver OK? | Récepteur prêt? |
| Transfert line to other receiver | Transfert de la ligne vers un autre récepteur |
| Handshakes | connexion |
| no | non |
| yes | oui |
| Protocol frame OK? | Données correctes? |
| NO-KISS-OFF | non acceptation |
| KISS OFF | acceptation |
| STORE TO EVENTS TABLE | enregistre dans la table des événements de la base de données |
| Line test Job 1 | Test de ligne, tâche 1 |
| Line test Job 2 | Test de ligne, tâche 2 |
| Line test Job 3 | Test de ligne, tâche 3 |
| HANG-UP | Commande décrocher |
| RING | Commande appel entrant |
(a) identification par ledit serveur, sur base du contenu de la première partie dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler,
(b) identification par ledit serveur, sur base du contenu de la deuxième partie du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme,
(c) identification par ledit serveur, sur base du contenu de la troisième partie du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s),
(d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
(e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données,
(f) annexion au message d'alarme d'au moins un numéro d'utilisateur, prélevé à la première adresse, et envoi dudit message composé par ledit serveur au transmetteur
Revendications modifiées conformément à la règle 86(2) CBE.
(a) identification par ledit serveur, sur base du contenu de la première partie dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler,
(b) identification par ledit serveur, sur base du contenu de la deuxième partie du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme,
(c) identification par ledit serveur, sur base du contenu de la troisième partie du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s),
(d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
(e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données,
(f) annexion au message d'alarme d'au moins un numéro d'utilisateur, prélevé à la première adresse, et envoi dudit message composé par ledit serveur au transmetteur
et en ce que ledit serveur est prévu pour recevoir, à intervalles prédéterminés, du récepteur et envoyer audit transmetteur une information, sur le fonctionnement dudit système d'alarme, lequel transmetteur communique l'information auxdits utilisateurs.