FR3000341A1 - Systeme de traitement de donnees dans un environnement ubiquitaire - Google Patents

Abstract

La présente invention concerne un système de traitement de données comprenant une pluralité de terminaux (1a, 1b, 1c) connectés via un réseau de communication (20), caractérisé en ce qu'au moins deux desdits terminaux (1 a, 1 b, 1 c) comprennent chacun un module de traitement de données (11) configuré pour mettre en œuvre un moteur de traitement d'événements pour : - le traitement de données d'acquisition provenant d'au moins un module d'acquisition de données (13a, 13b) connecté au module de traitement de données (11) du terminal (1a, 1b, 1c), - la génération, à partir de données d'acquisition, de données représentatives de l'occurrence d'au moins un événement, - la transmission de données représentatives de l'occurrence d'un d'événement à un serveur de publication d'événements (4) adapté pour retransmettre les données représentatives de l'occurrence d'un d'événement à au moins un autre desdits terminaux (1a, 1b, 1c). La présente invention concerne également un procédé, un produit programme d'ordinateur et un moyen de stockage à cet effet.

Description

DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine des objets communicants. Plus précisément, elle concerne un système de traitement de données représentatives d'événements, et plus précisément, de données représentatives de l'occurrence d'un événement. ETAT DE L'ART Les « objets communicants » sont un type de dispositifs informatiques qui comprennent des moyens de connexion réseau (une carte SIM, une antenne \Ni-Fi, etc.) et sont aptes à interagir de façon autonome avec d'autres objets ou serveurs en particulier via Internet. On nomme cette extension d'Internet à des dispositifs physiques l'Internet des Objets (« Internet of Things », loT) La multiplication du nombre de ces objets communicants engendre la production d'une grande quantité de données asynchrones, appelées « événements ». Un événement se traduit par exemple par la réception d'une information concernant l'événement détecté, par exemple la réception d'une valeur de température mesurée suite au dépassement d'un seuil de température ou suite à une mesure effectuée par un capteur. Sur la base d'une telle information, un système gérant une flotte d'objets communicants, équipés de modules d'acquisition de données (capteurs par exemple), peut déclencher un traitement.

Ces systèmes sont prévus pour permettre l'extraction et la production d'informations pertinentes à partir des flots de données reçues, la génération d'informations à valeur ajoutée par agrégation, ou le déclenchement d'actions appropriées au contexte. Le traitement des évènements à grande échelle implique la mise en place de systèmes spécifiques, capables d'exploiter et d'absorber en temps réel une grande quantité d'informations.

En effet la quantité de données considérée ici est potentiellement très importante, un objet communicant, équipé de modules d'acquisition de données, devant parfois détecter ou générer jusqu'à 500 000 évènements par seconde. Il est connu de gérer les événements en mettant en oeuvre une remontée des informations depuis des capteurs des objets communicants vers un serveur « backend » (serveur d'arrière-plan) centralisé, par le biais d'éléments réseaux de niveau intermédiaire appelés « passerelles ». Les données sont stockées en base, au fur et à mesure de leur obtention. Des analyses de données sont effectuées a posteriori pour déterminer les actions appropriées à mettre en oeuvre. Les actions à déclencher sont configurées par le biais de règles d'analyses d'outils implémentés sur le serveur « backend ». Cette stratégie s'avère problématique dès que le nombre d'objets communicants augmente : une quantité exponentielle d'information non pertinente est remontée au serveur « backend », les temps de réponse ne sont plus garantis à cause du risque de files d'attente de traitement des événements détectés et donc des déclenchements d'actions à effectuer sur la base de ces événements, entraînant un risque de surcharge des réseaux et des ressources de traitement de la base de données pouvant aller jusqu'à une panne complète. Pour résoudre ces difficultés, il a été proposé d'implanter dans le serveur backend un système de traitement d'événements. Ce système est par exemple conforme à la technologie CEP (« Complex Event Processing », en français « Traitement des Evénements Complexes »). Il s'agit d'une solution de traitement de flux d'évènements par filtrage, agrégation, tri, et reconnaissance de motif (« pattern matching »). Cette approche, représentée sur la figure 1, peut être vue comme l'utilisation d'une base de données « inversée », où au lieu d'obtenir une donnée stockée en base de données comme dans un système classique, des règles de traitement sont configurées pour le moteur : l'occurrence d'un événement va alors entraîner le déclenchement d'une ou plusieurs actions selon ce qui a été défini dans une ou des règles de traitement configurées. Cette technologie permet en outre de modifier dynamiquement les règles configurées pendant le fonctionnement du moteur, sans devoir pour cela arrêter ce moteur et le redémarrer. Des senseurs remontent des informations vers le serveur backend, par le biais d'éléments réseaux de niveau intermédiaire, appelés « passerelles » (ici les terminaux la, lb et 1c). Les évènements sont traités au fil de l'eau par le système centralisé de traitement d'événements, qui réagit en fonction de règles de traitement définies et des propriétés de chaque évènement.

Le système de traitement d'événements garantit théoriquement le temps de réponse au niveau du serveur backend, mais ce n'est pas vrai au niveau des objets communicants (perte de réactivité en cas d'engorgement des réseaux). De plus le risque de surcharge existe toujours pour des grosses flottes d'objets communicants.

Il serait souhaitable de disposer d'une solution de gestion d'objets communicants qui garantisse les performances d'analyse, la pertinence des données stockées et le temps de réaction, et ce quelle que soit la taille des flottes d'objets communicants. PRESENTATION DE L'INVENTION La présente invention se rapporte ainsi selon un premier aspect à un système de traitement de données comprenant une pluralité de terminaux (1a, lb, 1c) connectés via un réseau de communication, caractérisé en ce qu'au moins deux desdits terminaux comprennent chacun un module de traitement de données configuré pour mettre en oeuvre un moteur de traitement d'événements pour : le traitement de données d'acquisition provenant d'au moins un module d'acquisition de données connecté au module de traitement de données du terminal, la génération, à partir de données d'acquisition, de données représentatives de l'occurrence d'au moins un événement, la transmission de données représentatives de l'occurrence d'un d'événement à un serveur de publication d'événements adapté pour retransmettre les données représentatives de l'occurrence d'un d'événement à au moins un autre desdits terminaux.

La présence de moteurs de traitement d'événements au niveau d'une pluralité de terminaux fait que le traitement des événements est distribué sur ces terminaux et non plus centralisé. Cela offre des performances élevées et réduit fortement tout risque de surcharge. Selon d'autres caractéristiques avantageuses et non limitatives : - les modules de traitement de données de chaque terminal sont configurés pour mettre en oeuvre un moteur (la présence d'un moteur sur chaque terminal garantit un traitement au plus près des données permettant une réduction significative des ressources de traitement nécessaire) ; - le moteur de traitement d'événements d'un terminal est configuré pour générer lesdites données représentatives de l'occurrence d'au moins un événement par application de règles de traitement configurées pour ledit moteur de traitement d'événement (les règles permettent de contrôler aisément le fonctionnement des moteurs de traitement d'événements) ; - les règles de traitement configurées pour un dit moteur de traitement d'événement sont modifiables par un utilisateur du terminal mettant en oeuvre le moteur de traitement d'événements (cela permet une personnalisation rapide et efficace des règles de moteurs de traitement d'événements) ; - le système comprend en outre un serveur répertoire connecté aux terminaux via le réseau, le serveur répertoire comprenant un module pour le stockage d'une définition de types d'événements, les moteurs des terminaux étant configurés pour transmettre des données représentatives de l'occurrence d'au moins un événement appartenant à l'un au moins des types d'événements définis (le serveur répertoire est un élément garantissant une communication fiable de données d'événements entre les terminaux) ; - lesdites données représentatives de l'occurrence d'au moins un événement comprennent des données publiques et des données privées, seules les données publiques représentatives de l'occurrence d'au moins un événement étant transmises au serveur de publication (cette distinction permet de réduire le volume de données transitant et ainsi de garantir la pertinence des données remontées dans le système) ; - le serveur de publication retransmet des données représentatives de l'occurrence d'au moins un événement à des terminaux en fonction d'abonnements souscrits par ces terminaux auprès du serveur de publication (le système de souscription/publication permet de s'affranchir de la nécessité de spécifier les destinataires de toute donnée publique émise par un terminal) ; - le système comprenant en outre un équipement connecté au réseau mettant en oeuvre une interface pour la gestion à distance d'un moteur de traitement d'au moins un des terminaux (cet équipement permet de gérer tous les terminaux ainsi qu'éventuellement le serveur répertoire pour une gestion commune et pratique de tout le système) ; - l'interface de l'équipement permet la configuration des règles de traitement configurées pour les modules de traitement de données des terminaux (l'équipement est capable de contrôler les règles de traitement de tous les moteurs, et donc de les gérer aussi simplement que s'il y en avait un seul centralisé). ; - chaque terminal est associé à un niveau hiérarchique et chaque donnée représentative de l'occurrence d'un événement est associé à un niveau de publication, le serveur étant configuré pour ne transmettre à un terminal que des données représentatives de l'occurrence d'un événement présentant un niveau de publication supérieur ou égal au niveau hiérarchique du terminal (ce mode par « niveaux » permet de filtrer les données échangées de sorte que les terminaux de plus haut niveau ne reçoivent que les données les plus importantes. Aucun terminal n'est donc submergé par des données inutiles) ; - chaque module d'acquisition de données est soit un capteur interne intégré à un terminal, soit un capteur externe directement connecté à un terminal (l'utilisation de capteurs nombreux et variés permet un apport conséquent de données et donc la gestion précise des évènements) ; Selon un deuxième aspect, l'invention concerne un procédé de traitement de données dans un système comprenant une pluralité de terminaux connectés via un réseau de communication, le procédé étant caractérisé en ce qu'au moins deux desdits terminaux comprennent un module de traitement de données configuré pour mettre en oeuvre des étapes de : réception de données d'acquisition depuis un module d'acquisition de données connecté au module de traitement de données ; traitement desdites premières données représentatives d'événements par un moteur de traitement d'événements de sorte à générer des données représentatives d'événements ; transmission desdites données représentatives d'événements à au moins un autre desdits terminaux via un serveur de publication. Ce procédé s'applique facilement de façon itérée, de sorte à augmenter progressivement la valeur ajoutée des données au fur et à mesure de leur circulation dans le système. On minimise donc au maximum la quantité de données non pertinentes transférées via le réseau, d'où un temps de réponse minimal dans tous les cas. Selon un troisième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le deuxième aspect de l'invention de traitement de données dans un système comprenant une pluralité de terminaux connectés via un réseau de communication. Selon un quatrième aspect, l'invention concerne un moyen de stockage lisible par un équipement informatique sur lequel on trouve ce produit programme d'ordinateur.

PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : la figure 1 précédemment décrite est un schéma d'un système connu ; la figure 2 est un schéma d'un mode de réalisation avantageux du système selon l'invention ; la figure 3 est un schéma d'un terminal mobile utilisé dans un mode de réalisation avantageux du système selon l'invention. DESCRIPTION DETAILLEE Architecture En référence à la figure 2, l'invention propose comme dans la figure 1 un système de traitement de données comprenant une pluralité de terminaux la, lb, lc connectés via un réseau de communication 20. Ces terminaux la, lb, lc peuvent être aussi bien des terminaux mobiles (1a, 1 b) que des terminaux fixes (1c). Dans le premier cas, il s'agit en général soit de smartphones, soit d'objets communicants incorporant les moyens de communication d'un smartphone, par exemple un véhicule comprenant une carte SIM et une antenne. Les terminaux mobiles la et lb sont connectés au réseau communicant 20 (lequel est en particulier Internet) via des réseaux sans fil (réseaux téléphoniques, réseaux \Ni-Fi, etc.) et des antennes 2a, 2b. En lien avec la figure 3, les terminaux 1 a, 1 b, lc peuvent comprendre un module de stockage de données 12 et un ou plusieurs modules 13a, 13b d'acquisition de données (en d'autres termes des capteurs).

Le système selon l'invention n'est limité à aucun choix ni configuration particulière de terminaux la, lb, lc, il suffit que ces derniers comprennent un module de traitement de données 11 (en particulier un processeur), et que ces modules de traitement de données 11 des terminaux la, lb, lc soient configurés pour échanger via le réseau 20 des données représentatives de l'occurrence d'au moins un événement.

Ces données représentatives de l'occurrence d'un événement peuvent être tout type de données véhiculant de l'information relative à l'occurrence ou non d'un événement. Ces données peuvent par exemple décrire des grandeurs physiques, des états d'objets, des paramètres de fonctionnement, des commandes, etc. Des exemples de telles données seront présentés plus loin.40 Principe de l'invention A la différence du système connu représenté sur la figure 1, dans lequel le système était centralisé au niveau d'un serveur dédié, le présent système propose que les modules de traitement de données 11 d'au moins deux desdits terminaux la, 1 b, lc soient configurés pour mettre en oeuvre chacun un moteur de traitement d'événements, par exemple un moteur conforme à la technologie CEP (« Complex Event Processing », pour « Traitement d'Evénements Complexes ») pour le traitement desdites données représentatives de l'occurrence d'au moins un événement et données d'acquisition reçues de modules d'acquisition.

De façon avantageuse, chaque terminal 1 a, 1 b, lc, aussi bien mobile que fixe, met en oeuvre son moteur de traitement d'événements. Le moteur de traitement d'événements intégré dans un terminal est connecté à un ou plusieurs modules d'acquisition de données 13a, 13b, qui fournissent des données à traiter à ce module de traitement d'événements. Ces modules d'acquisition de données 13a, 13b sont soit intégrés dans le terminal (13a), soit connectés à ce terminal (13b). On note qu'il est possible qu'un terminal 1 a, 1 b, lc du système (typiquement un terminal fixe) ne soit directement connecté à aucun module d'acquisition de données 13a, 13b, mais le soit seulement via d'autres terminaux la, 1 b, 1 c. Un module d'acquisition de données 13a, 13b est typiquement un capteur (capteur de température, par exemple) ou un détecteur (détecteur de mouvement, par exemple). Les données générées par un module d'acquisition 13a, 13b qui sont transmises à un module de traitement 11 sont nommées dans ce document « données d'acquisition ». En d'autres termes, la présente invention propose une architecture de système dans lequel des moteurs de traitement d'événements sont implémentés à tous les niveaux de granularités, y compris dans les niveaux au plus « proche » des données, c'est-à-dire là où les données d'acquisition sont obtenues, et non seulement à un niveau central. Cela permet une réactivité sensiblement augmentée et une bien meilleure répartition de la charge de traitement. Le risque de surcharge est écarté. Cette architecture modifie en profondeur la circulation des données dans le système. Dans l'art antérieur selon la figure 1, les terminaux la, 1 b, 1 c ne servaient que de « passerelles » remontant les données d'acquisition vers le serveur central qui s'occupaient de leur traitement, et le cas échéant faisait redescendre d'autres données. Il n'y avait en outre jamais de transmission de données représentatives de l'occurrence d'un événement d'un terminal à un autre. Dans le système selon l'invention, chaque terminal la, 1 b, lc est capable de prétraiter les données d'acquisition, et d'émettre des données représentatives de l'occurrence d'au moins un événement à destination d'autres terminaux la, 1 b, lc. Les données d'acquisition se distinguent en effet des données représentatives de l'occurrence d'un événement en ce qu'elles sont brutes, et pas encore échangeables entre moteurs de traitement d'événements. Les mécanismes d'échange de données seront décrits en détail plus loin.

Chaque moteur de traitement d'événements d'un terminal la, lb, lc est en effet configuré pour générer des données représentatives de l'occurrence d'au moins un événement à partir de données représentatives de l'occurrence d'autres évènements reçues par le module de traitement de données 11 du terminal 1 a, 1 b, lc, en fonction de règles de traitement d'événements configurées pour un module de traitement de données 12 du terminal la, lb, lc. Les règles de traitement configurées sont avantageusement propres à un module de traitement de données 12 : elles sont donc potentiellement distinctes des règles de traitement configurées pour un autre module de traitement de données 11 d'un autre terminal la, lb, lc. Ces règles de traitement sont en outre modifiables, donc personnalisables, par un utilisateur du terminal intégrant le module de traitement de données 12. Comme expliqué précédemment, chacune des règles de traitement est définie d'une part, par un ou des événements à détecter, un tel événement est par exemple : la réception par le moteur de données d'acquisition ou bien le fait que des données d'acquisition reçues par le moteur de données d'acquisition vérifient une ou plusieurs conditions (franchissement de seuils, détection de motifs, apparition de liens, etc.), et d'autre part, par la ou les actions à déclencher lorsque le ou les événements définis ont été détectés. Une action déclenchée est par exemple la génération, à partir des données d'acquisition reçues par le moteur, de nouvelles données représentatives de l'occurrence d'un événement : par exemple, suite à la réception de données d'acquisition constituées par une mesure de température, le moteur génère une information représentative de l'occurrence de l'événement « Seuil de température dépassé » lorsque la mesure de température reçue est supérieure à un seuil.

Selon un autre exemple, une action déclenchée est le déclenchement d'une fonction : un appel de Web Service, un envoi de données ou une autre action de communication, etc. Dans un cas particulier, une action déclenchée est la transmission des données d'acquisition reçues par le moteur. Ces règles (également appelées requêtes), sont généralement formulées dans le langage EPL (« Event-Processing Language », langage de traitement d'événements), langage possédant une syntaxe similaire à celle du langage SQL (« Structured Query Language », langage de requête structuré) qui est le langage normalisé pour effectuer des opérations sur des bases de données relationnelles. De nombreux moteurs de traitement d'événements sont connus de l'homme du métier, et le système selon l'invention n'est limité à aucun en particulier. De façon préférée, on choisit le moteur EsperTM, disponible dans un cadriciel (« framework », selon la terminologie anglo-saxonne) JavaTM et compatible avec le langage EPL (ou le moteur NEsperTM, équivalent à EsperTM mais disponible dans un cadriciel .NETTm).

Echanges de données Le système comprend en outre, comme l'on voit sur la figure 2, un serveur de publication 4 connecté aux terminaux la, 1 b, lc via le réseau 20 pour la mise en oeuvre desdits échanges de données représentatives de l'occurrence d'au moins un événement.

Ce serveur 4 met en oeuvre un mécanisme de type publication/souscription (« Publish/Subscribe ») dans lequel ce ne se sont pas les terminaux « émetteurs » (publisher) qui décident des terminaux « destinataires » (subscriber) pour les données qu'ils émettent. Dans ce mécanisme, chaque terminal la, 1 b, 1c peut s'abonner auprès du serveur de publication 4 pour des catégories prédéfinies de données (typiquement les données représentatives d'un ou plusieurs événements donnés), et le serveur de publication 4 retransmet les données émises par les terminaux la, lb, 1c en fonction des abonnements souscrits par ces terminaux la, 1 b, lc. Les données représentatives de l'occurrence d'au moins un événement sont transmises par exemple sous la forme de flux de données.

Les données d'acquisition et les données représentatives de l'occurrence d'au moins un événement sont soit des données privées, soit des données publiques. Les données privées sont traitées localement par le module de traitement et ne sont jamais transmises au serveur de publication, alors que les données publiques sont transmises au serveur de publication 4 pour être retransmises ensuite vers d'autres terminaux.

On note par ailleurs qu'il peut y avoir plusieurs niveaux de « publication » des données. Les données des premiers niveaux n'étant remontées qu'à quelques terminaux du même niveau hiérarchique, alors que des données à haut niveau de publication peuvent être retransmises de façon globale. De façon générale, on peut considérer que chaque terminal la, lb, 1c est associé à un niveau hiérarchique et chaque donnée représentative de l'occurrence d'un événement est associé à un niveau de publication, le serveur (4) étant configuré pour ne transmettre à un terminal la, lb, lc que des données représentatives de l'occurrence d'un événement présentant un niveau de publication supérieur ou égal au niveau hiérarchique du terminal la, lb, lc. Les « niveaux hiérarchiques » et « niveaux de publication » sont choisis entre 1 et n, n étant le niveau maximum. Les données privées sont typiquement celles associées à des processus métiers à l'intérieur d'une entreprise. Par exemple, une donnée GPS de localisation d'un camion d'une flotte de véhicule peut être une donnée « privée » utilisée dans la gestion de la flotte. Une valeur de mesure générée par un capteur de température à l'intérieur d'une usine peut être une donnée privée, traitée spécifiquement pour évaluer un suivi de la chaîne du froid dans l'usine par exemple, mais une valeur de mesure générée par un capteur de température situé sur le toit d'une usine peut être une donnée publique et donc mise à disposition de terminaux souscripteurs d'abonnement pour ce type d'information. En référence à la figure 3, l'exemple de terminal la représenté est un smartphone comprenant un capteur interne 13a (par exemple un module de localisation) et connecté à un capteur externe 13b (par exemple un capteur de température). Il est à noter que les capteurs externes 13b ne sont pas forcément associés à un terminal la, lb, lc : il peut s'agir par exemple de capteurs fixes, distincts de tout terminal la, lb, lc, qui transmettent des informations à chaque terminal la, lb, lc qui passe à proximité, par exemple via Bluetooth. Les données d'acquisition (par exemple des coordonnées GPS et des températures dans notre exemple) que ces capteurs 13a, 13b remontent au module 11 de traitement de données du terminal la peuvent être converties en données représentatives de l'occurrence d'un événement (qui dans ce cas est la réception de ces données d'acquisition). Ces données représentatives de l'occurrence d'un événement sont par exemple des données privées qui vont être générées et traitées par le moteur de traitement d'événements du module 11 sans être retransmises à d'autres terminaux 1 b, lc.

En revanche, d'autres données représentatives de l'occurrence d'un événement que le moteur de traitement d'événements du module 11 va générer (par exemple des données représentatives d'un événement du type « Attention, températures négatives dans le secteur X)(X » que le moteur de traitement d'événements aura généré en réaction à des données de position et de température) sont par exemple publiques et sont donc transmises à destination des autres terminaux 1 b, lc (du moins ceux abonnés) via le serveur de publication 4. Le prétraitement possible par la présence de moteurs de traitement d'événements au niveau local permet de n'avoir à transmettre que les données publiques, c'est-à-dire les données pertinentes pour les autres terminaux, et donc de réduire sensiblement le volume de données à échanger. Des terminaux ne sont plus encombrés avec des données non pertinentes, et cela améliore encore d'autant la répartition de la charge de traitement. Répertoire de types et interface de gestion De façon préférée, le système comprend en outre un serveur répertoire 3 connecté aux terminaux la, lb, lc via le réseau 20. Le serveur répertoire 3 comprend un module pour le stockage d'une liste définissant un ensemble de types d'événements, les moteurs de traitement d'événements des terminaux la, lb, lc étant configurés pour générer des données représentatives de l'occurrence d'au moins un événement de façon conforme auxdits types d'événements définis. Une valeur de mesure générée par un capteur de température correspond par exemple à un type d'événement « température » caractérisé par une localisation GPS de la zone de prise de température, une valeur de température et l'unité de mesure utilisée. Ce répertoire 3 définit un vocabulaire commun à tous les moteurs de traitement d'événements déployés, de sorte à avoir des données représentatives de l'occurrence d'au moins un événement qui soient cohérentes entres elles, et donc échangeables facilement. Les données sont en effet en particulier échangées sous forme de messages comprenant des champs pouvant être complétés par des paramètres. Le répertoire 3 décrit la structure d'un squelette d'un tel message.

Par ailleurs, le système comprend avantageusement un équipement 5 connecté au réseau 20 mettant en oeuvre une interface pour la gestion des moteurs de traitement d'événements des terminaux la, lb, 1 c. Cet équipement 5 peut être un poste de travail dédié comme un des terminaux 1 a, 1 b, lc.

L'équipement 5 peut accéder aux modules 12 de stockage de données des terminaux la, lb, lc de façon à configurer lesdites règles de traitement d'événements stockées sur ces modules de traitement de données 12. Cela permet une mise à jour simultanée de tous les moteurs aussi simplement que si le système avait compris un seul moteur de traitement d'événements comme dans l'art antérieur (figure 1).

Pour cela, le module de stockage de données 12 reçoit des messages. Par exemple, pour ajouter une règle écrie via la console de l'équipement 5, on l'envoie à un service permettant de faire du « push » vers le terminal la, lb, lc. Le message est relayé au terminal la, 1 b, lc dont le module de traitement de données 11 interprète le message d'ajout de règle et effectue cette ajout à chaud.

Cette configuration des règles peut consister en une modification des conditions associées à une règle, ou une modification d'une action à déclencher liée à la règle. Il est également possible de supprimer ou rajouter une règle complète. L'équipement 5 peut également le cas échéant accéder au serveur répertoire 3 afin de gérer les types d'événements : définir de nouveaux types d'événements, modifier des types d'événements par ajout ou suppression de caractéristiques, ou supprimer des types d'événements. L'équipement 5 permet également de gérer aisément l'intégration ou la suppression d'un terminal la, lb, lc dans le système. Procédé Selon un deuxième aspect, l'invention concerne un procédé de traitement de données dans un système comprenant une pluralité de terminaux la, 1 b, lc connectés via un réseau de communication 20. Comme expliqué précédemment, au moins deux desdits terminaux la, 1 b, lc comprennent un module de traitement de données 11 configure pour mettre en oeuvre des étapes de : réception de données d'acquisition (par exemple générées par les capteurs 13a, 13b) ; traitement desdites données d'acquisition par un moteur de traitement d'événements (de type CEP) de sorte à générer des données représentatives de l'occurrence d'au moins un événement ; transmission desdites données représentatives de l'occurrence d'au moins un événement à au moins un autre desdits terminaux la, lb, lc.

La transmission des deuxièmes données se fait via le serveur de publication 4.

Le procédé peut être mis en oeuvre de façon itérée de sorte à générer des nouvelles (deuxièmes) données à partir des données générées, et ainsi de suite. Il est ainsi possible de prévoir une pluralité de « couches » de traitement de façon à obtenir une information ayant de plus en plus de valeur ajoutée au fur et à mesure que l'on « s'éloigne » des capteurs. Il est à noter que des deuxièmes, troisièmes (etc.) données peuvent être générées au sein du même terminal la, 1 b, lc à condition que les règles de traitement d'événements de ce terminal le permettent. Ce procédé s'applique facilement de façon itérée, de sorte à augmenter progressivement la valeur ajoutée des données au fur et à mesure de leur circulation dans le système.

Exemple Dans un exemple, le système selon la figure 2 est celui d'une compagnie de transport. Les terminaux la et lb sont deux « camions communicants », et le terminal lc est un serveur de la compagnie, abonné à des données provenant du système de surveillance.

Lorsque ce serveur lc reçoit des données publiques représentatives d'un événement de pollution (par exemple « taux d'ozone supérieur au niveau d'alerte »), il génère des données publiques représentatives d'un événement « Circulation en mode pollution » (par exemple il peut être prévu que certain quartiers soient évités, que la vitesse limite soit abaissée, etc.), transmises via le serveur de publication 4 aux camions la, 1 b. Il est souhaitable que les camions soient abonnés aux flux de données d'événements de type « circulation ». Les moteurs de traitement d'événements des camions 1 a, lb reçoivent ces données publiques, ainsi que des données privées (par exemple géolocalisation) provenant de capteurs, et les traitent. Alors, si l'un des camions la, lb est dans une zone qui devient interdite en cas de pollution, il va générer des données représentatives d'un événement « Zone interdite, livraison interrompue et retour au dépôt », données publiques renvoyées au serveur de publication 4. Cet événement peut être notifié publiquement au-delà de la seule compagnie de transport de sorte à avertir d'autres usagers de la route de la présence de cet incident.

Produit programme d'ordinateur Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur les modules de traitement de données 11 des terminaux la, 1 b, 1c) d'un procédé selon le deuxième aspect de l'invention de traitement de données dans un système comprenant une pluralité de terminaux 1 a, 1 b, lc connectés via un réseau de communication 20, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les modules de stockage de données 12 des terminaux la, 1 b, 1c) sur lequel on trouve ce produit programme d'ordinateur.40

Claims (13)

1. REVENDICATIONS1. Système de traitement de données comprenant une pluralité de terminaux (1a, 1 b, 1c) connectés via un réseau de communication (20), caractérisé en ce qu'au moins deux desdits terminaux (1a, 1 b, 1c) comprennent chacun un module de traitement de données (11) configuré pour mettre en oeuvre un moteur de traitement d'événements pour : le traitement de données d'acquisition provenant d'au moins un module d'acquisition de données (13a, 13b) connecté au module de traitement de données (11) du terminal (1a, lb, 1c), la génération, à partir de données d'acquisition, de données représentatives de l'occurrence d'au moins un événement, la transmission de données représentatives de l'occurrence d'un d'événement à un serveur de publication d'événements (4) adapté pour retransmettre les données représentatives de l'occurrence d'un d'événement à au moins un autre desdits terminaux (1a, 1 b, 1c).
2. 2. Système selon la revendication 1, dans lequel le moteur de traitement d'événements d'un terminal (1a, 1 b, 1c) est configuré pour générer lesdites données représentatives de l'occurrence d'au moins un événement par application de règles de traitement configurées pour ledit moteur de traitement d'événement.
3. 3. Système selon la revendication 2, dans lequel les règles de traitement configurées pour un dit moteur de traitement d'événement sont modifiables par un utilisateur du terminal mettant en oeuvre le moteur de traitement d'événements.
4. 4. Système selon l'une des revendications précédentes, comprenant en outre un serveur répertoire (3) connecté aux terminaux (1a, 1 b, 1c) via le réseau (20), le serveur répertoire (3) comprenant un module pour le stockage d'une définition de types d'événements, les moteurs des terminaux (1a, 1 b, 1c) étant configurés pour transmettre des données représentatives de l'occurrence d'au moins un événement appartenant à l'un au moins des types d'événements définis.
5. 5. Système selon l'une des revendications précédentes, dans lequel lesdites données représentatives de l'occurrence d'au moins un événement comprennent des données publiques et des données privées, seules les données publiques représentatives de l'occurrence d'au moins un événement étant transmises au serveur de publication (4).
6. 6. Système selon l'une des revendications précédentes, dans lequel le serveur de publication (4) retransmet des données représentatives de l'occurrence d'au moins unévénement à des terminaux (1a, 1 b, 1c) en fonction d'abonnements souscrits par ces terminaux (1a, 1 b, 1c) auprès du serveur de publication (4).
7. 7. Système selon l'une des revendications précédentes, comprenant en outre un équipement (5) connecté au réseau (20) mettant en oeuvre une interface pour la gestion à distance d'un moteur de traitement d'au moins un des terminaux (1a, 1 b, 1c).
8. 8. Système selon les revendications 2 et 7 en combinaison, dans lequel l'interface de l'équipement (5) permet la configuration des règles de traitement configurées pour les modules de traitement de données (11) des terminaux (1a, 1 b, 1c).
9. 9. Système selon l'une des revendications précédentes, dans lequel chaque terminal (1a, 1 b, 1c) est associé à un niveau hiérarchique et chaque donnée représentative de l'occurrence d'un événement est associé à un niveau de publication, le serveur (4) étant configuré pour ne transmettre à un terminal (1a, 1 b, 1c) que des données représentatives de l'occurrence d'un événement présentant un niveau de publication supérieur ou égal au niveau hiérarchique du terminal (1a, 1 b, 1c).
10. 10. Système selon l'une des revendications précédentes, dans lequel chaque module d'acquisition de données (13a, 13b) est soit un capteur interne (13a) intégré à un terminal (1a, 1 b, 1c), soit un capteur externe (13a, 13b) directement connecté à un terminal (1a, 1 b, 1c).
11. 11. Procédé de traitement de données dans un système comprenant une pluralité de terminaux (1a, 1 b, 1c) connectés via un réseau de communication (20), le procédé étant caractérisé en ce qu'au moins deux desdits terminaux (1a, 1 b, 1c) comprennent un module de traitement de données (11) configuré pour mettre en oeuvre des étapes de : réception de données d'acquisition depuis un module d'acquisition de données (13a, 13b) connecté au module de traitement de données (11); traitement desdites premières données représentatives d'événements par un moteur de traitement d'événements de sorte à générer des données représentatives d'événements ; transmission desdites données représentatives d'événements à au moins un autre desdits terminaux (1a, 1 b, 1c) via un serveur de publication (4).
12. 12. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon la revendication 11 de traitement de données dans un système comprenant une pluralité de terminaux (1a, 1 b, 1c) connectés via un réseau de communication (20).
13. 13. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédéselon la revendication 11 de traitement de données dans un système comprenant une pluralité de terminaux (1a, 1 b, 1c) connectés via un réseau de communication (20).