(19)
(11) EP 1 630 761 A1

(12) DEMANDE DE BREVET EUROPEEN

(43) Date de publication:
01.03.2006  Bulletin  2006/09

(21) Numéro de dépôt: 05356139.5

(22) Date de dépôt:  24.08.2005
(51) Int. Cl.: 
G08B 25/08(2006.01)
(84) Etats contractants désignés:
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR
Etats d'extension désignés:
AL BA HR MK YU

(30) Priorité: 25.08.2004 FR 0409088

(71) Demandeur: France Télécom
75015 Paris (FR)

(72) Inventeurs:
  • Carlier, Ludovic
    22300 Lannion (FR)
  • Savina, Bernard
    22300 Lannion (FR)
  • Liard, Samuel
    35131 Chartres de Bretagne (FR)

(74) Mandataire: Colombo, Michel et al
Cabinet Lavoix, 62 rue de Bonnel
69448 Lyon Cedex 03
69448 Lyon Cedex 03 (FR)

   


(54) Système et procédé d'appel automatique, moteur d'alerte et poste d'activation mis en oeuvre dans le système


(57) Ce système d'appel automatique d'un ensemble de récepteurs comporte un moteur d'alerte (4) apte à commander des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs. La procédure d'alerte est enregistrée dans un fichier (14) modifiable indépendamment du moteur d'alerte.




Description


[0001] La présente invention concerne un système et un procédé d'appel automatique, un moteur d'alerte et un poste d'activation mis en oeuvre dans le système.

[0002] Des systèmes connus comportent un moteur d'alerte apte à commander des appels vers des récepteurs en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs.

[0003] Ces systèmes sont particulièrement utiles pour alerter des personnes telles que, par exemple, des sauveteurs en cas d'accident.

[0004] Dans les systèmes connus, la procédure d'alerte est intégrée au code du moteur d'alerte et forme avec celui-ci un seul et même programme. Ainsi, si un utilisateur souhaite modifier la procédure d'alerte, le code du moteur d'alerte doit être modifié. Les systèmes connus sont donc difficiles à adapter aux souhaits de chaque utilisateur.

[0005] L'invention vise à remédier à cet inconvénient en proposant un système d'appel automatique facilement adaptable au souhait de chaque utilisateur.

[0006] L'invention a donc pour objet un système d'appel automatique dans lequel la procédure d'alerte est enregistrée dans un fichier modifiable indépendamment du moteur d'alerte.

[0007] Dans le système ci-dessus, la procédure d'alerte est enregistrée dans un fichier modifiable indépendamment du moteur d'alerte. Ainsi, lorsque seule la procédure d'alerte doit être changée il n'est pas nécessaire de modifier le code du moteur d'alerte.

[0008] Les modes de réalisation de ce système peuvent comporter une ou plusieurs des caractéristiques suivantes :
  • le moteur d'alerte est apte à commander l'exécution d'une nouvelle étape d'appel lorsqu'une condition associée à une transition anticipée est évaluée à vraie sans attendre la fin de l'exécution d'une étape d'appel précédente, et le moteur d'appel est également apte, après cette transition anticipée, à exécuter en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente,
  • la transition anticipée est définie dans la procédure d'alerte,
  • il comporte un automate d'appel, sous la commande du moteur d'alerte, apte à appeler chacun des récepteurs d'une liste de récepteurs et à envoyer des informations de suivi de l'état d'avancement des appels au moteur d'alerte, et le moteur d'alerte est apte à évaluer les conditions associées à des transitions définies par la procédure d'alerte en fonction de ces informations de suivi,
  • la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language),
  • le moteur d'alerte est apte à interpréter les balises contenues dans la procédure d'alerte,
  • la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente,
  • la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel,
  • le moteur d'alerte est apte à exécuter simultanément plusieurs étapes d'appel appartenant à des procédures d'alerte différentes,
  • le système comporte :
    • plusieurs procédures d'alerte enregistrées dans des fichiers modifiables indépendamment du moteur d'alerte, et
    • un poste d'activation de l'exécution d'une de ces procédures d'alerte raccordé au moteur par l'intermédiaire d'un réseau grande distance de transmission d'informations, ce poste étant apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte,
  • le poste est apte à transmettre au moteur d'alerte l'ensemble de la procédure d'alerte ou un identifiant d'une procédure d'alerte préenregistrée à exécuter, et, en réponse à la transmission du poste, le moteur d'alerte est apte à déclencher l'exécution de la procédure d'alerte transmise ou la procédure d'alerte préenregistrée correspondant à l'identifiant transmis.


[0009] L'invention a également pour objet un moteur d'alerte adapté pour être utilisé dans le système d'appel automatique ci-dessus.

[0010] L'invention a également pour objet un procédé d'appel automatique d'un ensemble de récepteurs, ce procédé comportant une étape de commande des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs. Le procédé comporte une étape d'enregistrement d'une procédure d'alerte dans un fichier modifiable indépendamment du module d'alerte. Le procédé peut également comporter une étape d'écriture de la procédure d'alerte en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language).

[0011] L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels :
  • la figure 1 est une illustration schématique de l'architecture d'un système d'appel automatique,
  • la figure 2 est une illustration du contenu d'un fichier dans lequel est enregistré une procédure d'alerte,
  • la figure 3 est un organigramme correspondant au contenu du fichier de la figure 2, et
  • la figure 4 est un organigramme d'un procédé d'appel automatique.


[0012] La figure 1 représente un système d'appel automatique désigné par la référence générale 2. Le système 2 comporte un moteur d'alerte 4 associé à un automate d'appel 6.

[0013] Le moteur 4 est apte à interpréter puis à exécuter simultanément une ou plusieurs procédures d'alerte. Le moteur 4 est, par exemple, réalisé à partir d'un calculateur programmable conventionnel apte à exécuter des instructions enregistrées sur un support d'enregistrement d'informations, lorsque ces instructions sont exécutées par le calculateur. A cet effet, le support d'enregistrement comporte des instructions pour l'exécution du procédé de la figure 4.

[0014] Les procédures d'alerte en cours d'exécution sont enregistrées dans une base de données 10 stockée dans une mémoire 12. La mémoire 12 comporte également des fichiers 14 comportant des procédures d'alerte préenregistrées, des listes d'appel préenregistrées et éventuellement des messages préenregistrés. Les procédures d'alerte, les listes d'appel et les messages préenregistrés sont associés respectivement à un identifiant de procédure d'alerte, un identifiant de liste d'appel et un identifiant de message.

[0015] Une procédure d'alerte définie des transitions conditionnelles entre des étapes d'appel. Les étapes d'appel sont des étapes lors desquelles une liste de récepteurs, correspondant, par exemple, à une liste d'appel préenregistrée, est appelée par l'automate d'appel 6. Les transitions conditionnelles définissent la ou les conditions permettant de passer d'une étape d'appel à la suivante. Ces transitions entre deux étapes d'appel sont exécutées ou non par le moteur 4 en fonction d'informations de suivi sur l'état d'exécution de l'étape d'appel courante. Un exemple de procédure d'alerte sera décrit plus en détail ci-dessous en regard des figures 2 et 3.

[0016] L'automate 6 est apte à appeler par l'intermédiaire d'un réseau grande distance 20 de transmission d'informations un ensemble 22 de récepteurs correspondant à une liste d'appels. Le réseau 20 est, par exemple, un réseau téléphonique RTC. L'ensemble 22 comporte, par exemple, un ou plusieurs téléphones 24, un ou plusieurs téléphones mobiles 26 et un ou plusieurs ordinateurs 28.

[0017] La liste d'appels utilisée par l'automate 6 comporte pour chacun des récepteurs de l'ensemble 22 les coordonnées qui permettent de le contacter par l'intermédiaire du réseau 20. Par exemple, la liste d'appel comporte le numéro de téléphone de chaque téléphone fixe 24 ou mobile 26 et l'adresse e-mail de l'utilisateur de chaque ordinateur 28.

[0018] L'automate 6 est propre à appeler les uns après les autres ou simultanément plusieurs des récepteurs dont les coordonnées sont dans la liste d'appel.

[0019] L'automate 6 est également propre à retourner au moteur 4 des informations de suivi d'appels représentant l'état d'avancement des appels à effectuer. Par exemple, en tant qu'information de suivi d'appel, l'automate 6 retourne au moteur 4 la liste d'appels dans laquelle chaque coordonnée de récepteurs est complétée par une information sur l'état d'avancement de l'appel vers ce récepteur. L'état d'avancement prend par exemple trois valeurs : « en cours », « échec », et « succès ». La valeur « en cours » signifie que l'appel est en cours d'exécution. La valeur « échec » signifie que le récepteur n'a pas pu être joint et la valeur « succès » signifie que le récepteur a été appelé avec succès.

[0020] Un poste 30 d'activation de l'exécution d'une procédure d'alerte par le moteur 4 est raccordé au moteur 4 par l'intermédiaire du réseau 20. Ce poste 30 permet à un utilisateur de sélectionner la procédure d'alerte que le moteur 4 doit exécuter. A cet effet, le poste 30 est, par exemple, apte à transmettre un identifiant d'une procédure d'alerte préenregistrée dans l'un des fichiers 14 au moteur 4. Ici, il est également apte à transmettre au moteur 4 une procédure d'alerte enregistrée localement. A cet effet, le poste 30 est raccordé à une mémoire 32 contenant une ou plusieurs procédures d'alerte 34.

[0021] Le poste 30 est également adapté pour qu'un utilisateur puisse sélectionner un message à diffuser à l'ensemble des récepteurs. De façon similaire à ce qui a été décrit pour la procédure d'alerte, le poste 30 est apte à transmettre au moteur 4 un identifiant d'un message préenregistré dans la mémoire 12 et/ou à transmettre au moteur 4 le message à diffuser aux récepteurs par l'intermédiaire du réseau 20. Le message transmis au moteur 4 est, par exemple, préenregistré dans la mémoire 32.

[0022] Le poste 30 est, par exemple, réalisé à partir d'un ordinateur conventionnel équipé d'un navigateur Internet pour communiquer avec le moteur 4.

[0023] Le système 2 comporte aussi un serveur Internet 40, un poste de consultation distant 42 et un module de saisie 44.

[0024] Le serveur 40 est adapté pour permettre le suivi à distance du déroulement d'une procédure d'alerte. Pour cela, il est raccordé à l'automate 6 de manière à recevoir les informations de suivi d'appel et adapté pour rendre celles-ci consultables à partir du poste 42. Typiquement, le poste 42 est un ordinateur équipé d'un navigateur Internet.

[0025] Le module 44 est destiné à la saisie et l'enregistrement dans les fichiers 14 de nouvelles procédures d'appel, listes d'appel ou messages. La réalisation de ce module 44 est conventionnelle.

[0026] A titre d'exemple pour simplifier l'illustration, le moteur 4, l'automate 6, le serveur 40 et le module 44 sont implantés dans un seul et même serveur informatique raccordé à la mémoire 12.

[0027] La figure 2 représente un exemple de procédure d'alerte contenu dans l'un des fichiers 14 et la figure 3 représente sous la forme d'un organigramme la procédure d'alerte de la figure 2.

[0028] Pour simplifier la configuration du système 2, les procédures d'appel sont écrites en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language). Plus précisément, a titre d'exemple, la procédure d'appel a été ici écrite en utilisant le langage XML (Extensible Markup Language).

[0029] Chaque procédure d'alerte est encadrée entre une balise ou marqueur d'ouverture < Model > et une balise ou marqueur de fermeture </Model>.

[0030] Des balises < DiffusionStage > et < /DiffusionStage > placées entre les balises < Model > et < /Model > définissent respectivement le début et la fin de la définition d'une étape d'appel.

[0031] La balise < DiffusionStage > peut comporter zéro, un ou deux attributs. Le premier attribut « entry » signifie que cette étape d'appel est un point d'entrée de la procédure d'alerte lorsqu'on lui affecte la valeur « True ». Dans ce cas là, le moteur 4 commence par exécuter cette étape d'appel. Le second attribut qui porte le nom de « StageName » définit le nom de l'étape. Par exemple, ici, cinq étapes d'appel sont définies dans cette procédure d'alerte. Elles sont respectivement nommées « TermBoss », « PersoBoss », « Team member », « PersoMember » et « Rescue Team ». Ces étapes portent, dans l'ordre, les références numériques 66 à 70 dans la figure 3.

[0032] Ensuite, la définition d'une étape d'appel comporte au moins une balise < DiffusionList > permettant d'identifier la liste d'appel à utiliser lors de cette étape. Cette balise < DiffusionList > comporte à cet effet un attribut « name » permettant de définir le nom de la liste d'appel. Par exemple, la balise suivante :


signifie que la liste des récepteurs à appeler lors de l'étape d'appel est contenue dans le fichier portant le nom « list1 ».

[0033] Ensuite, la définition d'une étape d'appel peut comporter la définition d'une ou plusieurs transitions conditionnelles ou non vers une autre étape d'appel. Par exemple ici, la procédure d'alerte comporte des balises d'ouverture < BeforeEndDiffusion > et des balises de fermeture < /BeforeEndDiffusion > entre lesquelles sont définies des transitions anticipées vers d'autres étapes d'appel. Plus précisément, ces balises < BeforeEndDiffusion > présentent la particularité de définir une transition anticipée qui permet au moteur 4 d'exécuter l'étape suivante sans pour autant arrêter l'exécution de l'étape précédente. De telles transitions anticipées entre deux étapes sont représentées par des lignes en pointillés dans la figure 3. A titre d'illustration, la procédure d'alerte comporte une transition conditionnelle anticipée 70 entre les étapes 66 et 68 et une transition conditionnelle anticipée 71 entre les étapes 67 et 68.

[0034] La définition des transition 70 et 71 est placée entre une balise < Transition > d'ouverture et une balise < /Transition > de fermeture. La balise < Transition > comporte un attribut nommé « StageName » destiné à indiquer vers quelle étape d'appel la transition doit être effectuée si une condition est évaluée à vraie. Par exemple, la balise suivante :


signifie que la transition s'effectuera vers l'étape d'appel 68.

[0035] La condition qui déclenche le franchissement de la transition est placée entre les balises < Transition > et < /Transition >. Ici, cette condition est encadrée par une balise d'ouverture < If > et une balise de fermeture < If/ >. La balise placée entre les balises < If > et < If/ > définit la condition pour laquelle la transition conditionnelle est activée. Ici, à titre d'exemple, la condition est que au moins un appel d'une liste d'appels doit avoir été réalisé avec succès pour que la transition vers l'étape suivante soit activée.

[0036] Cette condition correspond dans la figue 2 à la balise signe < AfLeastOne nbAppel = « 1 » typeAppel = « success » fromList = « List1 » >. Cette balise comporte trois attributs. Le premier attribut nommé « nbAppel » spécifie le nombre d'appel. L'atttribut « typeAppel » spécifie l'état d'avancement de l'appel et l'attribut « fromList » spécifie le nom de la liste d'appel concernée.

[0037] Plus précisément, ici, la transition 70 est franchie lorsqu'un récepteur de la liste « List1 » a été appelé avec succès et la transition 71 est franchie lorsqu'un récepteur de la liste « List2 » a été appelé avec succès.

[0038] Les procédures d'alerte comportent aussi des transitions non conditionnelles qui sont systématiquement exécutées lors de l'exécution de la procédure d'alerte.

[0039] Ces transitions non conditionnelles ne sont pas associées à une condition. Ici, elles sont définies par une balise d'ouverture < AfterDiffusion > et de fermeture < /AfterDiffusion >. Ces transitions correspondent à une transition systématique vers une étape d'appel suivante à la fin de l'exécution de l'étape d'appel précédente. Entre les balises < AfterDiffusion > et < /AfterDiffusion >, la balise < Transition > est utilisée pour définir le nom de l'étape d'appel suivante vers laquelle la transition s'effectue. Ici la procédure d'alerte définit deux de ces transitions non conditionnelles, représentées par des traits pleins 72, 73 sur la figure 3.

[0040] Enfin, la procédure d'alerte de la figure 2 comporte une étape 75 d'attente de commande définie entre des balises < ContrôleStage > et < /ContrôleStage >. La balise < ContrôleStage > comporte les mêmes attributs que ceux de la balise < DiffusionStage >. Par exemple, dans le cas particulier de la figure 2, l'étape 75 s'appelle « In case of pb » et correspond à un second point d'entrée de la procédure d'alerte.

[0041] Lors de l'étape 75, le moteur 4 n'effectue aucune action et attend simplement que la condition associée à la transition 74 soit évaluée à vrai.

[0042] La condition associée à la transition 74 est définie par la balise < MessageEqual messageName = « messageEtat » value = « Intervention »/ >. Cette balise signifie que la transition est franchie lorsqu'un message reçu dont le nom est spécifié par l'attribut « messageName » prend la valeur spécifiée par l'attribut « value ». Dans la procédure d'alerte de la figure 2 décrit ici, le message reçu doit porter le nom de « messageEtat » et prendre la valeur « intervention » pour que la transition soit franchie. Cette transition est représentée par le trait 74 sur la figure 3.

[0043] Le fonctionnement du système 2 va maintenant être décrit en regard de la figure 4 dans le cas particulier où la procédure d'alerte à exécuter est celle de la figure 2.

[0044] Initialement, un opérateur du système 2 écrit, lors d'une étape 100, en utilisant le module 44, la procédure d'alerte de la figure 2 en langage XML et en utilisant les balises prédéfinies. Une fois la procédure d'alerte écrite, celle-ci est enregistrée, lors d'une étape 102, dans un fichier 14 stocké dans la mémoire 12.

[0045] Lors d'une étape 103, l'opérateur saisie et enregistre dans la mémoire 12 une ou plusieurs listes d'appel et un ou plusieurs messages à diffuser.

[0046] Lorsque cela s'avère nécessaire, une demande d'intervention est envoyée, lors d'une étape 104 par le poste 30 au moteur 4. Lors de cette demande d'intervention, la ou les procédures d'alerte à exécuter sont sélectionnées lors d'une opération 106. Plus précisément, l'opération 106 est réalisée soit en transmettant du poste 30 au moteur 4 un identifiant d'une procédure d'alerte préenregistrée soit en transmettant au moteur 4 la procédure d'alerte à exécuter elle-même. Toujours lors de l'étape 104, le message à diffuser aux différents récepteurs est sélectionné lors d'une opération 108. De façon similaire à l'opération 106, le message à diffuser est sélectionné soit en transmettant un identificateur d'un message préenregistré à partir du poste 30 vers le moteur 4 soit en transmettant à partir du poste 30 le message à diffuser.

[0047] En réponse à une demande d'intervention, le moteur 4 interprète, lors d'une étape 110, le contenu des fichiers 14 correspondant aux procédures d'alerte sélectionnées lors de l'étape 104. Cette étape comporte notamment une opération 112 d'enregistrement dans la base de données 10 des étapes des procédures d'alerte sélectionnées. Les listes d'appel référencées par les procédures d'appel sélectionnées sont également enregistrées dans la base de données 12 lors d'une opération 114.

[0048] Ensuite, le moteur 4 exécute en parallèle, lors d'une étape 120, l'ensemble des procédures d'appel enregistrées dans la base de données 10. Par exemple, dans le cas particulier de la procédure d'alerte de la figure 2, le moteur 4 commence par exécuter simultanément les étapes 66 et 75.

[0049] Plus précisément, lors de l'étape 66, conformément à ce qui est indiqué dans la procédure d'alerte, le moteur 4 transmet, lors d'une opération 122, la liste d'appel « list1 » à l'automate 6 et commande cet automate 6 pour que celui-ci commence à appeler les différents récepteurs dont les coordonnées sont contenues dans cette liste.

[0050] A intervalles réguliers, lors d'une opération 124, le moteur 4 interroge l'automate 6 et l'automate 6 retourne les informations de suivi d'appel au moteur 4.

[0051] Le moteur 4 évalue, lors d'une opération 126, les différentes transitions conditionnelles en tenant compte des informations de suivi les plus récemment reçues. Si la condition associée à l'une de ces transitions conditionnelles est évaluée à « vraie » alors le moteur 4 commence à exécuter l'étape suivante dans la procédure d'alerte. Par exemple, dés que le moteur 4 est informé par l'automate 6 que l'un des récepteurs de la liste « list1 » a été appelé avec succès, il commence à exécuter l'étape d'appel 68 tout en continuant d'exécuter l'étape d'appel 66.

[0052] Lorsqu'une étape d'appel est terminée, le moteur 4 commence à exécuter, si elle existe, l'étape d'appel suivante désignée par la balise < AfterDiffusion >. Par exemple, à la fin de l'étape 66 le moteur 4 procède automatiquement à l'exécution de l'étape d'appel 67.

[0053] Le moteur 4 évalue aussi lors d'une opération 130 les transitions conditionnelles permettant de sortir d'une étape d'attente de commande.

[0054] Par exemple, dans le cas de la procédure d'alerte de la figure 2, le moteur 4 teste à intervalles réguliers si un message nommé « messageEtat » a pris la valeur « Intervention ». Dans l'affirmative, le moteur 4 commence immédiatement à exécuter l'étape 70. Dans la négative, le moteur 4 continue d'attendre. La valeur du message nommé « messageEtat » est, par exemple, modifiable à partir du poste 30.

[0055] Ainsi, le moteur 4 suit pas à pas la procédure d'alerte définie dans un fichier 14 en testant régulièrement les conditions associées aux transitions conditionnelles et en franchissant ces transitions uniquement lorsque la condition associée est évaluée à « vraie ».

[0056] Plus précisément, le moteur d'alerte teste simultanément les conditions des transitions conditionnelles de toutes les procédures d'alerte actuellement exécutées en parallèle et commande également simultanément l'exécution de toutes les étapes d'appel actuellement actives et ceci indépendamment de la procédure d'alerte auxquelles ces transitions et/ou étapes appartiennent. Ainsi, le moteur 4 à lui seul est apte à exécuter simultanément plusieurs procédures d'alerte.

[0057] On notera qu'il est possible de modifier une procédure d'alerte sans modifier le fonctionnement du moteur 4. L'adaptation du fonctionnement du moteur 4 aux souhaits des clients est donc facilitée.

[0058] Grâce aux transitions anticipées, il est possible d'accélérer l'exécution d'une procédure d'alerte puisqu'il est possible de commencer l'exécution d'une nouvelle étape de cette procédure d'alerte sans attendre qu'une étape d'appel précédente soit finie.

[0059] L'utilisation d'un langage de description de contenu à balises simplifie la configuration du système 2 car ceci évite le recours à des étapes de programmation consistant à écrire puis à compiler un programme. Ces balises étant prédéfinies, l'utilisateur n'a pas besoin de connaître en détail le fonctionnement du moteur 4. Par ailleurs, l'utilisation de balises permettant de définir des étapes d'appel et des étapes d'attente de commande simplifie l'écriture de procédures d'alerte.

[0060] Le système 2 a été décrit ici dans le cas particulier où il ne comporte qu'un seul moteur d'alerte. En variante, il comporte plusieurs moteurs d'alerte identiques implantés dans le même ou dans des serveurs respectifs.

[0061] Les récepteurs peuvent être des machines ou être incorporés dans des machines quelconques. Dans ce cas, le message d'alerte peut être accompagné d'instructions de commande de cette machine. Ainsi, par exemple, le système peut être utilisé pour déclencher la mise en marche de caméras, de capteurs (par exemple des capteurs de température, de pression, de niveau ou encore des détecteurs de produits chimiques, etc...), ou de système de décontamination. Le système peut aussi être utilisé pour déclencher l'arrêt de machines sensibles, pour déclencher la déconnection d'éléments non vitaux d'un réseau, tel qu'un réseau de distribution d'électricité ou encore pour déclencher l'isolement d'objets dangereux ou sensibles.


Revendications

1. Système d'appel automatique d'un ensemble de récepteurs, ce système comportant un moteur d'alerte (4) apte à commander des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce que la procédure d'alerte est enregistrée dans un fichier (14) modifiable indépendamment du moteur d'alerte.
 
2. Système selon la revendication 1, caractérisé en ce que le moteur d'alerte (4) est apte à commander l'exécution d'une nouvelle étape d'appel lorsqu'une condition associée à une transition anticipée est évaluée à vraie sans attendre la fin de l'exécution d'une étape d'appel précédente, et en ce que le moteur d'appel est également apte, après cette transition anticipée, à exécuter en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente.
 
3. Système selon la revendication 2, caractérisé en ce que la transition anticipée (70, 71) est définie dans la procédure d'alerte.
 
4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte un automate d'appel (6), sous la commande du moteur d'alerte (4), apte à appeler chacun des récepteurs d'une liste de récepteurs et à envoyer des informations de suivi de l'état d'avancement des appels au moteur d'alerte, et en ce que le moteur d'alerte (4) est apte à évaluer les conditions associées à des transitions définies par la procédure d'alerte en fonction de ces informations de suivi.
 
5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language).
 
6. Système selon la revendication 5, caractérisé en ce que le moteur d'alerte (4) est apte à interpréter les balises contenues dans la procédure d'alerte.
 
7. Système selon la revendication 5 ou 6, caractérisé en ce que la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente.
 
8. Système selon l'une quelconque des revendications 5 à 7, caractérisé en ce que la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape (75) d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel.
 
9. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le moteur d'alerte est apte à exécuter simultanément plusieurs étapes d'appel appartenant à des procédures d'alerte différentes.
 
10. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le système comporte :

- plusieurs procédures d'alerte enregistrées dans des fichiers modifiables indépendamment du moteur d'alerte, et

- un poste (30) d'activation de l'exécution d'une de ces procédures d'alerte raccordé au moteur par l'intermédiaire d'un réseau grande distance de transmission d'informations, ce poste étant apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte.


 
11. Système selon la revendication 10, caractérisé en ce que le poste (30) est apte à transmettre au moteur d'alerte l'ensemble de la procédure d'alerte ou un identifiant d'une procédure d'alerte préenregistrée à exécuter, et en ce que, en réponse à la transmission du poste (30), le moteur d'alerte est apte à déclencher l'exécution de la procédure d'alerte transmise ou la procédure d'alerte préenregistrée correspondant à l'identifiant transmis.
 
12. Moteur d'alerte adapté pour être utilisé dans un système selon l'une quelconque des revendications précédentes, ce moteur d'alerte étant apte à commander des appels vers les récepteurs dudit ensemble, en suivant la procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce que le moteur d' alerte est apte à exécuter une procédure d'alerte enregistrée dans un fichier modifiable indépendamment du moteur d'alerte.
 
13. Poste d'activation adapté pour être utilisé dans un système selon la revendication 10 ou 11, caractérisé en ce que :

- le poste est raccordé au moteur d'alerte par l'intermédiaire d'un réseau grande distance de transmission d'informations, et

- le poste est apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte ainsi qu'a activer l'exécution de la procédure d'alerte sélectionnée.


 
14. Procédé d'appel automatique d'un ensemble de récepteurs, ce procédé comportant une étape (122) de commande des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce qu'il comporte une étape (102) d'enregistrement d'une procédure d'alerte dans un fichier modifiable indépendamment d'un moteur d'alerte propre à exécuter l'étape de commande.
 
15. Procédé selon la revendication 14, caractérisé en ce qu'il comporte une étape (100) d'écriture de la procédure d'alerte en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language).
 
16. Procédure d'alerte adaptée pour être mise en oeuvre dans un système conforme à l'une quelconque des revendications 1 à 11, cette procédure d'alerte étant exécutable par le moteur d'alerte propre à commander des appels vers des récepteurs, cette procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisée en ce que la procédure d'alerte est enregistrable dans un fichier (14) modifiable indépendamment du moteur d'alerte.
 
17. Procédure selon la revendication 16, caractérisée en ce qu'elle définit une transition anticipée qui, lorsqu'elle est évaluée à vraie permet au moteur d'alerte de commander l'exécution d'une nouvelle étape d'appel sans attendre la fin de l'exécution d'une étape d'appel précédente, de manière à ce que après cette transition anticipée, le moteur d'appel exécute en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente.
 
18. Procédure selon la revendication 16 ou 17, caractérisée en ce que les conditions associées à des transitions définies dans cette procédure d'alerte sont fonction des informations de suivi de l'état d'avancement des appels envoyés au moteur d'alerte par un automate d'appel.
 
19. Procédure d'alerte selon l'une quelconque des revendications 16 à 18, caractérisée en ce que la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language).
 
20. Procédure d'alerte selon la revendication 19, caractérisée en ce que la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente.
 
21. Procédure d'alerte selon la revendication 19 ou 20, caractérisée en ce que la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape (75) d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel.
 
22. Mémoire, caractérisée en ce qu'elle comporte une procédure d'alerte conforme à l'une quelconque des revendications 16 à 21.
 
23. Programme d'ordinateur, caractérisé en ce qu'il comporte des instructions pour l'exécution d'une procédure d'alerte conforme à l'une quelconque des revendications 16 à 21, lorsque ces instructions sont exécutées par un calculateur électronique.
 




Dessins













Rapport de recherche