FR3070777A1 - Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe - Google Patents

Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe Download PDF

Info

Publication number
FR3070777A1
FR3070777A1 FR1854994A FR1854994A FR3070777A1 FR 3070777 A1 FR3070777 A1 FR 3070777A1 FR 1854994 A FR1854994 A FR 1854994A FR 1854994 A FR1854994 A FR 1854994A FR 3070777 A1 FR3070777 A1 FR 3070777A1
Authority
FR
France
Prior art keywords
service
incident
data
platform
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1854994A
Other languages
English (en)
Inventor
Cyril Labi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mytechtrip
Original Assignee
Mytechtrip
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mytechtrip filed Critical Mytechtrip
Priority to PCT/FR2018/052116 priority Critical patent/WO2019043332A1/fr
Publication of FR3070777A1 publication Critical patent/FR3070777A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0267—Fault communication, e.g. human machine interface [HMI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0769—Readable error formats, e.g. cross-platform generic formats, human understandable formats

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Automation & Control Theory (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé (PI) et une plateforme (10) de gestion d'incidents d'un service produisant et diffusant une information pertinente (MU, MU1, MUj, MUm) à des usagers dudit service lors d'une occurrence d'une perturbation de ce dernier. Une telle information (MU, MU1, MUj, MUm) est élaborée par ladite plateforme (10) sous la forme d'un message d'information et transmise (N2), à des moments opportuns, à des moyens de diffusion ou de sortie (OD1, ODj, ODm) appropriés. L'invention concerne en outre un système de gestion d'incidents d'un service comportant en outre un ou plusieurs générateurs (20, IG1, IGi, IGn) de données d'incidents ou d'exploitation dudit service (DIS1, DISi, DISn) coopérant (N1) avec ladite plateforme (10).

Description

Procédé de gestion de perturbations de service, plateforme mettant en œuvre ledit procédé et système associé
L'invention concerne le domaine des plateformes de
gestion d'incidents ou de perturbations de services
offerts à des usagers.
L'essor des technologies du numérique a conduit à
démultiplier les services innovants offerts au grand public ou à des acteurs privés. La diversification des moyens de communication, ou plus généralement des interfaces de restitution ou de sortie de contenus graphiques et/ou sonores mis à la disposition de chacun d'entre nous, tels que les téléphones ou les tablettes intelligents, a en outre suscité une exigence croissante quant à la quantité mais aussi à la pertinence des informations en lien avec un service offert à des usagers.
Pour les prestataires de service, satisfaire le besoin de ses clients ou des usagers devient chaque jour davantage complexe. En effet, avec le développement et l'essor des services proposés, les attentes et exigences des clients ou usagers sont de plus en plus élevées.
A titre d'exemples non limitatifs, lesdits usagers souhaitent, voire même exigent :
- de la réactivité dans la diffusion d'une information directement compréhensible par lesdits usagers, notamment dans le cadre d'une situation de perturbation d'un service ;
- une évolutivité d'une telle information pour que celle-ci soit en adéquation avec l'évolution des incidents ou perturbations ;
- une teneur ou plus généralement le contenu de message d'information adaptée, en adéquation avec une disparité croissante de media d'affichage ou plus généralement de media de sortie d'informations selon un mode graphique et/ou sonore;
- une cohérence de l'information diffusée via différents moyens de communication, quelle que soit la localisation d'un usager ;
- une information pertinente dans la description des impacts sur la prestation de service découlant d'un incident ;
- une proposition d'une ou plusieurs alternatives pour surmonter ou atténuer les conséquences d'un incident de service.
De telles attentes ne sont généralement pas satisfaites ou ne le sont que très partiellement selon le service concerné.
Par exemple, dans le cadre d'une application en lien avec le transport de passagers, une telle gestion d'incidents du réseau de transport demeure essentiellement humaine. Généralement, quelques écrans ou haut-parleurs, dont la restitution est directement pilotée par un opérateur, se bornent à relater aux usagers un retard ou un incident à proximité des lieux d'attente de véhicules, par exemple sur un quai d'une gare ferroviaire ou routière. Les usagers doivent généralement se rapprocher de personnels de la société de transport concernée par l'incident, en espérant que ceux-ci soient disponibles ou accessibles et informés pour connaître la nature de l'incident et surtout les conséquences concrètes sur la continuité ou la discontinuité du service, voire pour identifier des solutions de repli. Il en résulte une grande frustration, voire un mécontentement des usagers susceptible de détourner ces derniers du service. En outre, un usager ne peut généralement pas anticiper et trouver une solution alternative pour rallier une destination à une heure prévue, voire prévenir d'un retard d'une durée maîtrisée. Le personnel ou l'acteur d'un service peut par ailleurs se trouver parfois en première ligne et démuni face à de telles requêtes légitimes d'usagers.
A titre d'exemple d'application préféré mais non limitatif, l'invention sera décrite au travers d'un exemple d'application relatif au service de transport de passagers en milieu urbain. L'invention pourra toutefois s'appliquer à tout autre domaine d'application, nécessitant une analyse complexe d'incidents et une production d'informations à des humains via différentes modalités de restitution graphiques et/ou sonores.
L'invention permet de répondre à tout ou partie des inconvénients soulevés par les solutions connues. En offrant une solution améliorant la qualité et la pertinence de l'information communiquée à des usagers lors d'une occurrence d'une perturbation de service, l'invention offre à un prestataire de service des moyens :
- pour identifier les perturbations du service susceptibles d'intéresser directement les usagers ;
- pour produire et diffuser, avec une grande réactivité, une information pertinente, c'est-à dire répondant à un éventuel questionnement des usagers face à l'occurrence d'un incident de service via des supports ou media de diffusion appropriés et à des moments opportuns.
A cet effet, l'invention concerne un procédé de gestion d'incidents d'un service, ledit procédé étant mis en œuvre par une unité de traitement d'une plateforme de gestion d'incidents de service comportant outre ladite unité de traitement, une mémoire de données, des moyens de communication avec le monde extérieur, ladite mémoire de données et lesdits moyens de communication coopérant avec ladite unité de traitement.
Selon l'invention, les moyens de communication de ladite plateforme assurent une première liaison avec un générateur de données d'incidents ou d'exploitation du service et une deuxième liaison avec un moyen de sortie d'un message d'information. En outre, un tel procédé de gestion d'incidents d'un service comporte :
- une étape pour collecter une donnée d'incident ou d'exploitation du service émise par le générateur de données d'incidents ou d'exploitation du service ;
- une étape pour estimer une ou plusieurs conséquences d'un aléa d'exploitation du service et produire un ou plusieurs messages d'information unitaires associées à ces dernières une étape pour produire un message d'information à partir desdits un ou plusieurs messages d'information unitaires ;
- une étape pour provoquer une sortie dudit message d'information par le moyen de sortie de sorte qu'un usager dudit service perçoive la teneur dudit message d'information.
Selon un deuxième objet, l'invention concerne un produit programme d'ordinateur comportant des instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par un ordinateur, provoquent la mise en œuvre d'un tel procédé de gestion d'incidents d'un service conforme à l'invention.
Selon un troisième objet, l'invention concerne une plateforme de gestion d'incidents de service comportant une unité de traitement, une mémoire de données, une mémoire de programmes, des moyens de communication avec le monde extérieur, lesdites mémoires de données et de programmes et lesdits moyens de communication coopérant avec ladite unité de traitement, ladite mémoire de programmes comportant les instructions d'un produit programme d'ordinateur conforme à l'invention.
Enfin, l'invention concerne un système de gestion d'incidents d'un service comportant un ou plusieurs générateurs de données d'incidents ou d'exploitation dudit service, un ou plusieurs moyens de sortie d'un message d'information, lesdits générateurs et moyens de sortie coopérant avec une plateforme de gestion d'incidents de service conforme à l'invention.
D'autres caractéristiques et avantages apparaîtront plus clairement à la lecture de la description qui suit, se rapportant à un exemple de réalisation donné à titre indicatif et non limitatif, et à l'examen des figures qui l'accompagnent parmi lesquelles :
la figure 1 illustre un exemple de réalisation non limitatif d'une architecture fonctionnelle d'une plateforme de gestion d'incidents de service conforme à l'invention ;
la figure 2 présente un exemple de réalisation non limitatif d'un procédé de gestion d'incidents d'un service mis en œuvre par une telle plateforme selon l'invention ;
la figure 3 décrit un exemple de modélisation de données associées à un événement pour lequel un ou plusieurs messages peuvent respectivement être associés et formatés à un ou plusieurs conséquences pour les usagers d'un service ;
les figures 4A à 4D décrivent un exemple de production de messages d'informations destinées aux usagers durant les étapes d'apparition, du suivi et de fin d'occurrence d'un incident de service.
L'invention concerne un procédé et une plateforme mettant en œuvre ledit procédé, pour gérer un ou plusieurs incidents de service et pour traduire ces derniers en un ou plusieurs aléas d'exploitation, puis en une ou plusieurs conséquences pour les usagers et in fine en un ou plusieurs messages d'information pour ces derniers, suivis de la ou des meilleures modalités de restitution ou de sortie, de sorte que lesdits usagers perçoivent la teneur desdits messages d'information et pâtissent ainsi le moins possible d'un tel incident de service.
Comme l'indique à titre d'exemple de réalisation préféré mais non limitatif la figure 1, une plateforme de gestion d'incidents de service conforme à l'invention consiste à collecter et décoder des données d'incidents d'exploitation d'un service DIS1, DISi, DISn émanant respectivement de différents générateurs ou sources IG1, IGi, IGn, parmi une pluralité 20 de sources disponibles, telles que des capteurs disposés sur un réseau de transport de passagers par exemple, ou encore des systèmes d'aide à l'exploitation dudit service, voire directement par un opérateur via une interface homme-machine d'entrée ou de saisie, générant ainsi lesdites données d'incidents d'exploitation. De telles données peuvent être horodatées pour suivre l'évolution d'un incident et véhiculées par des messages de données transmis à une plateforme 10 de gestion d'incidents de service conforme à l'invention, via un premier réseau de communication ou liaison NI. Un tel réseau NI peut être simple ou pluriel et mettre en œuvre une ou plusieurs technologies et/ou protocoles de communication filaires ou sans fil, tels que, de manière non exhaustive, Internet, Sigfox, LoRa, ou plus généralement tout vecteur de communication permettant à deux objets électroniques d'échanger une information de nature technique.
Pour parvenir à traiter ces différentes données d'incident, l'invention s'appuie sur la mise en œuvre d'un ensemble PI de procédés de traitement de données d'exploitation et/ou d'incident du service, lesdites données d'exploitation et/ou d'incident DISI, DISi, DISn étant exploitées par une unité de traitement 11 d'une plateforme 10, par exemple sous la forme d'un ordinateur ou plus généralement d'un serveur informatique. Une telle unité de traitement 11 consiste en un ou plusieurs microprocesseurs et coopère via un ou plusieurs bus de communication, symbolisés par des flèches doubles en figure 1, avec une mémoire de données 12, consistant en une ou plusieurs entités physiques et/ou logiques, dont certaines peuvent être physiquement distantes de ladite unité de traitement 11. La mémoire de données 12 permet de sauvegarder par exemple toutes données de travail, des éventuels paramètres de fonctionnement de la plateforme, voire in finie le contenu d'un message d'information destiné aux usagers. L'unité de traitement 11 coopère en outre avec une mémoire de programmes 14, agencée pour stocker les instructions d'un programme d'ordinateur PG, dont l'exécution ou l'interprétation, par ladite unité de traitement 11, provoque la mise en œuvre d'un procédé PI de gestion des incidents de service conforme à l'invention. Pour collecter et décoder les données d'incidents DIS1, DISi, ... DISn respectivement véhiculées par des messages émis par les générateurs de données 20, IG1, IGi, ..., IGn, une plateforme 10 selon l'invention comporte en outre des moyens de communication 13 adaptés pour interagir avec lesdits générateurs ou sources de données d'incidents IGI, IGi, ..., IGn, via le premier réseau de communication ou liaison NI.
Les fonctions principales d'une telle plateforme 10, correspondant aux principales étapes fonctionnelles d'un procédé PI de gestion d'incidents d'un service conforme à l'invention, consistent notamment en :
- un premier bloc d'étapes 10-1 pour filtrer et regrouper des données d'incidents de service DISI à DISn afin de ne conserver qu'un corpus ou une sélection desdites données de service DIS susceptibles d'impacter les usagers du service, et traduire ledit corpus en un ou plusieurs impacts AE sur l'exploitation dudit service ;
- un deuxième bloc d'étapes 10-2 pour traduire le ou lesdits impacts d'exploitation AE préalablement estimé en conséquences CU pour les usager, de sorte à élaborer, à partir de messages unitaires associés auxdites conséquences, puis formater un ou plusieurs messages MU à destination des usagers, selon un ou plusieurs moyens ou media de communication
OD1,
ODj, ··· !
ODm, appropriés pour diffuser de tels messages ;
- un troisième bloc d'étapes 10-3 pour organiser et provoquer la restitution graphique et/ou sonore dudit ou desdits messages MU, en un ou plusieurs messages d'information MU1, MUj, ..., MUm adaptés auxdits différents media OD1, ODj, ..., ODm.
De tels media de communication OD1, ODj, ...ODm, parmi une pluralité 30 de media disponibles, peuvent consister un écran d'ordinateur, un panneau d'affichage public, un serveur de mise à disposition d'information via Internet, une borne d'informations de voyageurs (également connue sous l'abréviation BIV), un ordinateur personnel, un téléphone ou une tablette intelligente, etc. Une telle plateforme de gestion d'incidents de service 10 conforme à l'invention coopère avec de tels media 30 via un deuxième réseau de communication ou liaison N2, éventuellement similaire au premier réseau de communication NI, précédemment évoqué pour véhiculer les données d'incident de service DIS1 à DISn. En variante, lesdits premier et deuxième réseaux de communication NI et N2 peuvent ne constituer qu'un seul et même réseau de communication.
A titre d'exemple préféré mais non limitatif, l'invention va être décrite au travers d'un exemple d'application de transport de passagers. Elle pourrait s'appliquer à tout autre type de service dont un usager attend une aide concrète pour faire face ou contourner un incident de service.
Un exemple de réalisation détaillé d'un procédé PI de gestion d'incidents d'un service conforme à l'invention, mis en œuvre par une plateforme telle qu'illustrée par la figure 1, est à présent décrit en lien avec la figure 2.
Une telle plateforme 10 peut être décrite comme comportant trois modules fonctionnels principaux, correspondant respectivement aux trois principaux blocs d'étapes 10-1, 10-2 et 10-3 dudit procédé PI de gestion d'incidents d'un service, mis en œuvre par l'unité de traitement 11 de ladite plateforme 10.
Ainsi, un premier module fonctionnel ou un premier bloc d'étapes 10-1 est chargé de l'acquisition ou de la collecte et du traitement de données d'exploitation ou de service DIS1, DISi, ..., DISn, ainsi que de la détermination d'un référentiel d'un service, un tel premier module étant ci-après nommé « Operation monitoring services » selon une terminologie anglo-saxonne. Un deuxième module ou un deuxième bloc d'étapes 10-2 est chargé, quant à lui, de la création des événements usagers et de la mise en forme de messages prêts à être diffusés, respectivement liés aux conséquences (routage, attente, etc.) pour les usagers du service, ledit deuxième module étant ci-après dénommé « User information création services » selon une terminologie anglo-saxonne. Un troisième module ou un troisième bloc d'étapes 10-3 est chargé de la diffusion desdits messages à destination de supports de diffusion, ou de moyens de sortie OD1, ODj, ..., ODm adaptés ou de moyens de communication idoines, ledit troisième module étant dénommé « User information broadcasting services » selon une terminologie anglo-saxonne.
Selon ladite figure 2, un tel procédé PI de gestion d'incidents d'un service comporte principalement :
- un bloc d'étapes 10-1 pour collecter des données
DIS1, DISi, DISn, d'exploitation ou d'incident du service considéré, lesdites données DISI, DISi, DISn, étant produites par tout système 20 adapté coopérant avec ladite plateforme 10, ledit bloc d'étapes 10-1 consistant en outre à traduire, selon une ou plusieurs règles prédéterminées, d'une ou plusieurs desdites données d'exploitation ou d'incident du service en un aléa AE, ce dernier étant créé ou mis à jour, si celui-ci est d'actualité ;
- un bloc d'étapes 10-2 pour déterminer, selon un scénario prédéterminé, une ou plusieurs conséquences CU dans la délivrance du service auxdits usagers, à partir dudit aléa AE produit ou mis à jour au bloc d'étapes 10-1 et pour produire à partir de telles conséquences, un événement E selon un ou plusieurs scénarii prédéterminés, un tel événement E se traduisant par une sélection d'un ou plusieurs moyens de diffusion de messages, assortie d'une production d'un ou plusieurs messages d'information MU, formatés de manière prédéterminée selon le type de moyen de diffusion sélectionné ;
- un bloc d'étapes 10-3 pour provoquer la diffusion du ou des messages d'information MU produits par, ou sur, ledit ou lesdits moyens de diffusion ou de sortie OD1, ODj, ..., ODm sélectionnés pour restituer de manière sonore ou graphique des messages MU1, MUj, ..., MUm aux usagers. Un tel bloc d'étapes 10-3 (ou plus précisément l'étape 600 en lien avec la figure 2) pour provoquer la diffusion peut avantageusement être adapté pour que ladite diffusion soit « orchestrée » selon un protocole prédéterminé.
Comme l'indique, de manière avantageuse, l'exemple d'un procédé PI selon l'invention illustrée par la figure 2, une étape 100, du premier bloc d'étapes 10-1, de collecte 100 de données d'incident ou d'exploitation de service DIS1, DISi, DISn peut faire l'objet d'une procédure d'enregistrement desdites données dans la mémoire de données 12 de la plateforme 10. Une telle opération d'enregistrement peut notamment comporter un horodatage de ladite collecte des données d'incidents ou d'exploitation du service. Un historique des opérations peut ainsi être constitué et consulté sur demande. En outre, lesdites données peuvent être respectivement associées à des périodes de validité données. Dans le cadre d'une application de transport de passagers, une telle étape 100 peut par exemple consister à enregistrer des données d'exploitation décrivant un tracé d'une ligne et/ou des points d'arrêt sur une telle ligne.
Ladite étape 100 consiste, préalablement à une phase d'enregistrement de telles données d'incident ou d'exploitation en mémoire de données, à décoder lesdites données d'incidents ou d'exploitation collectées et à les « normaliser » afin que celles-ci puissent être conjointement examinées ou traitées plus tard. Une telle étape de normalisation ou de formatage se traduit par une fonction appelée couramment « connecteur » dans le jargon informatique. Ainsi, une plateforme selon l'invention dispose, par programmation, d'un modèle prédéterminé de toute donnée d'exploitation ou d'incident au regard d'un référentiel prédéterminé pour un service concerné. Avantageusement, une telle plateforme 10 peut être agencée pour s'adapter à tout type de flux de données et/ou de technologies répondant à des modèles de communication de types requête/réponse, abonnement/notification ou traitement par lots (« batch » selon une terminologie anglo-saxonne) comme par exemple, un « web service », une importation de fichier, une trame selon le protocole TCP (« Transmission Control Protocol » selon une terminologie anglo-saxonne, ou littéralement en français « protocole de contrôle de transmissions ») tel que décrit dans le document RFC7931 de l'IETF (Internet Engineering Task Force » selon une terminologie anglo-saxonne). Une telle étape 100 peut avantageusement exploiter des normes de communication du domaine métier visé, par exemple dans le domaine du transport, SIRI (« Service Interface for Real time Information », selon une terminologie anglo-saxonne, définissant un protocole d'échange d'informations en temps réel), NeTEx (Network Exchange selon une terminologie anglo-saxonne, pour échanger des informations en lien avec le Transport selon un format de document de type XML « Extensible Markup Language », selon une terminologie anglo-saxonne), GTFS (« General Transit Feed Spécification » selon une terminologie anglo-saxonne, spécifiant les flux relatifs aux transports en commun), pour faciliter une intégration avec des systèmes 20 fournisseurs de données DIS.
Un tel bloc d'étapes 10-1 peut en outre comporter une étape 200 de filtrage, c'est-à-dire de sélection desdites données DIS1, DISi, ..., DISn, pour ne conserver qu'un sousensemble de données d'intérêt, voire encore pour regrouper et « prioriser » certaines données d'exploitation et/ou d'incident acquises. Une telle sélection peut être paramétrée, voire personnalisée selon le service considéré, par exemple selon le réseau de transport urbain d'une ville particulière, par le chargement d'instructions de programme idoine venant enrichir le programme PG enregistré dans la mémoire de programmes 14. De la même manière, l'étape 300, du premier bloc d'étapes 10-1, consiste à déterminer les impacts sur les usagers, induits par lesdites données sélectionnées DIS, sous la forme d'un aléa d'exploitation AE, éventuellement assorti d'une donnée caractérisant un niveau d'urgence ou de criticité. Cette destination résulte de la mise en œuvre d'instructions de programme d'ordinateur ou de règles, permettant de modéliser et de générer ledit aléa d'exploitation AE, si possible automatiquement à réception d'une donnée d'incident ou d'exploitation particulière DIS. Le programme PG, et donc le procédé PI, peuvent donc éventuellement être enrichis ou modifiés selon le service concerné.
Par exemple, dans le domaine d'application préféré du transport de passagers, une stratégie d'aléa peut définir que si plusieurs actes de régulation « Courses supprimées » sont reçus d'un système d'aide à l'exploitation (en l'espèce un type particulier de générateur de données d'exploitation du service) impactant un même itinéraire de ligne, sur une plage glissante de cinq minutes, alors il est possible de regrouper les aléas induits par lesdits actes de régulation sous la forme d'un seul aléa « Courses supprimées » associé à une priorité faible.
Selon l'exemple du procédé PI de gestion d'incidents d'un service conforme à l'invention, décrit notamment en lien avec la figure 2, celui-ci comporte un deuxième bloc d'étapes 10-2 pour produire des messages MU à destination des usagers à partir du ou desdits aléas d'exploitation AE produits en 10-1.
Ledit deuxième bloc d'étapes 10-2 consiste ainsi en une première étape 500 pour produire un ou plusieurs évènements usagers E sous la forme de messages MU, élaborés selon un exemple décrit ultérieurement avec la figure 3, et prêts à être diffusés. Préalablement à l'étape 500, le procédé PI comporte une étape 400 pour, à partir d'aléa(s) d'exploitation AE et à partir de scénarios d'événements prédéterminés ou d'aléas types, éventuellement paramétrables et/ou personnalisables via des règles, sous la forme par exemple d'instructions de programme ou de scripts, mémorisées en mémoire de programmes 14, une ou plusieurs conséquences CU sont créées, chacune étant associée à un message unitaire MUU constituant une partie ou une zone d'un tel message usager MU constitué à l'étape 500, lesdits messages MUU et MU étant éventuellement formatés pour mettre en exergue telle ou telle chaîne de caractères, par exemple.
L'invention prévoit en effet, que l'étape 500 s'appuie sur un ou plusieurs modèles de message, généralement mémorisés soit en mémoire de données 12, soit en mémoire de programmes 14. Une sélection de modèles de message peut être mise en œuvre à l'étape 500 selon la nature de l'événement E généré à l'étape 400. Ainsi, à titre d'exemple non limitatif, l'étape 500 peut générer un ou plusieurs messages MU à partir d'un modèle de message prédéterminé contenant un texte, par exemple sous la forme de chaîne (s) de caractères alphanumériques, une mise en forme éventuelle, précisant une ou plusieurs couleurs desdits caractères, la ou les polices desdits caractères, des accentuations de caractères, etc., une ou plusieurs conditions et/ou une ou plusieurs variables contextuelles, de telles conditions ou variables contextuelles consistant non limitativement en :
- un type de contenu pris en charge, selon un langage de balisage par exemple tel que le langage HTML (« HyperText Markup Language »r selon une terminologie anglo-saxonne), un simple texte, un contenu sonore et/ou visuels, etc. par un ou plusieurs moyens de diffusion ou de sortie 30 ;
- une ou plusieurs langues prises en charge ;
- un nombre de lignes d'affichage sur un support ;
- un nombre maximal de caractères autorisés par ligne d'affichage ;
- une liste ou un type de caractères autorisés ou interdits ;
- des caractéristiques déterminant un défilement éventuel dudit message MU lors de sa future diffusion ;
- une prise en charge ou non de fichiers multimédias éventuellement associés (formats vidéo, image,
De manière avantageuse, l'invention prévoit qu'une plateforme 10 de gestion d'incidents de service, puisse comporter un composant ou une fonction de pré-affichage pour qu'un opérateur de ladite plateforme 10 puisse effectuer des simulations d'affichage et/ou d'écoute de messages sur un ou plusieurs supports de diffusion ou de sortie 30, avant la diffusion réelle sur sites, de futurs messages MU survenant après un réel incident de service.
Le bloc étape 10-2 d'un procédé PI conforme à l'invention peut en outre être adapté (notamment l'étape 400), de sorte que la plateforme 10 présente alors, par la mise en œuvre dudit procédé PI, un module fonctionnel que nous pourrions nommer « Situation poiicy engine » selon une terminologie anglo-saxonne. Une telle adaptation permet à ladite plateforme 10, plus précisément à son unité de traitement 11, de sélectionner automatiquement, parmi une pluralité de scenarii possibles, un scénario d'événements le plus pertinent, selon le ou les aléas d'exploitation AE produits précédemment. Ainsi, il devient possible de grouper plusieurs événements autour d'une même cause, en l'espèce un aléa d'exploitation pour les usagers, et de déterminer si une diffusion de messages d'information MU automatique est requise ou non. De la même manière, une telle étape 400 peut être agencée pour déterminer une ou plusieurs conséquences usager CU, corollaires aux impacts directement induits par un aléa d'exploitation AE produit par le premier bloc d'étapes 10-1.
Également, l'invention prévoit en outre que l'étape 500 du deuxième bloc d'étapes 10-2 puisse déterminer un ou plusieurs moyensn supports ou media de diffusion ou de sortie OD1, ODm, parmi la pluralité de media 30 disponibles, et/ou un ou plusieurs lieux ou périmètres géographiques de diffusion de messages MU selon l'aléa ou le type d'aléa d'exploitation AE produit en 10-1. Ainsi, les messages MU associés à un événement E peuvent être formatés en conséquence, comme nous l'étudierons ultérieurement en lien avec un exemple de modélisation de message illustré par la figure 3.
Lorsqu'une pluralité de messages est affectée à un événement E ou qu'une pluralité d'événements sont produits à l'étape 400, cette dernière, voire l'étape 500, peut comporter une phase d'analyse de la validité des messages prêts à être diffusés en termes de format et de fonds au regard de messages usager MU, d'ores et déjà en cours de diffusion et de restitutions sonore et/ou graphique.
Le troisième module fonctionnel offert par une plateforme 10 conforme à l'invention, par la mise en œuvre du bloc d'étapes 10-3, en l'espèce l'étape 600, du procédé PI illustré à titre d'exemple non limitatif par la figure 2, est chargé de maîtriser la diffusion et la restitution ou sortie sonore et/ou graphique de messages MU produits par le bloc d'étapes 10-2 précédemment décrit, par les moyens ou media de restitution ou de sortie OD1, ODj, ..., ODm parmi la pluralité des moyens de sortie 30 disponibles. Cette fonction se traduit tout d'abord par une orchestration de la restitution ou sortie sonore et/ou graphique des messages MU - on entend par « orchestration » une synchronisation, un séquençage, une ou plusieurs durées de restitution, un bouclage, etc. desdits messages MU. Une telle restitution ou sortie de messages MU sousentend également une fonction de type « connecteur », miroir de celle offerte par l'étape 100 permettant de « connecter » la plateforme 10 aux générateurs de données d'exploitation et d'incidents 20. Cette deuxième fonction « connecteur » permet de lier ladite plateforme 10 aux moyens ou media de diffusion 30. Ainsi, l'étape 600 consiste en outre à encoder les messages MU pour adapter ces dernier automatiquement à tout type de flux ou à toute technologie, répondant par exemple aux modèles de communication de types requête/réponse, abonnement/notification ou « batch », dotant ainsi une plateforme 10 de gestion d'incidents de service conforme à l'invention d'un connecteur fonctionnel conforme aux normes de communication du domaine métier visé, par exemple dans le domaine du transport de passagers, SIRI ou GTFS.
Selon ledit exemple d'application préféré en lien avec le transport de passagers, la figure 3 décrit un exemple de structure de données produites à l'étape 400 et associées à une événement E conduisant au formatage prédéterminé d'un message MU selon l'invention.
Ladite figure 3 illustre qu'un événement E est associé à une ou plusieurs conséquences CUr, CUi, CU2, CU3, CUZ, ces dernières pouvant se dérouler en une ou plusieurs phases PHx, parmi lesquelles une phase initiale, une phase courante lors de l'occurrence dudit événement, et une phase de clôture ou de fin d'occurrence lors du terme dudit événement E.
Chaque phase PHx est associée à une sélection d'un ou plusieurs moyens 30 de diffusion ou de sortie de message, un périmètre d'impact, d'un ou plusieurs messages unitaires, préalablement formatés selon le ou les type(s) de moyens de diffusion sélectionnés. Un message MU peut, à l'instar de la description de l'exemple illustré par la figure 3, être associé à la conséquence récapitulative CUr et comporter un texte, mais également une ou plusieurs conditions et autres variables contextuelles. Il peut en outre, tel un message « enveloppe », comporter une ou plusieurs zones de texte, en l'espèce sur la figure 3, les zones ZI à Zw, chaque zone pouvant comporter une ou plusieurs plages de texte TXT et/ou un ou plusieurs messages unitaires MUU-CUi, MUU-CU2, MUU-CU3, MUU-CUZ respectivement associés aux conséquences CUi, CU2, CU3, CUZ de l'événement E.
Pour illustrer la mise en œuvre d'une plateforme de
gestion d'incidents de service, telle que la plateforme 10
décrite en lien avec la figure 1 et mettant en œuvre un
procédé de gestion des incidents d'un service conforme à l'invention, tel que le procédé PI illustré par la figure 2, étudions un exemple d'application en lien avec le transport de passagers dans la ville de Marseille, France, en liaison avec les figures 4A à 4D.
Un tel exemple découlant de la mise en œuvre par une plateforme 10 d'un procédé PI conformes à l'invention et respectivement illustrés par les figures 1 et 2, vise à diffuser, par un medium de restitution ou de sortie graphique du type navigateur de page Internet, disponible sur tout ordinateur personnel connecté à Internet, un message MU destiné aux usagers des transports publics de la ville de Marseille, lié à un événement E découlant d'un incident de personne survenu sur le Boulevard Chave.
Ledit exemple illustre le fait que le contenu du message MU évolue au gré de l'évolution de la situation ou configuration du réseau de transport concerné. Les figures 4A à 4D décrivent ainsi respectivement quatre moments ou phases distincts et successifs, durant lesquels une information destinée aux usagers est produite, et dont la diffusion par Internet a été provoquée par la mise en œuvre dudit procédé PI par une plateforme 10, lesdits plateforme 10 et procédé PI étant conformes à la présente invention.
En liaison avec la figure 4A, un incident dit « boulevard Chave » se produit. Un service partiel sur la ligne de tramway Tl est saisi par l'exploitant délivrant une donnée d'incident ou d'exploitation DIS1. Une première étape génère un événement E découlant dudit incident et dont la structure est telle que celle décrite par la figure 3 à titre d'exemple non limitatif. Ledit événement E et la teneur d'un message MU automatiquement produit, dès l'apparition dudit événement E, par ledit procédé sont décrits en lien avec la figure 4A. Un premier message récapitulatif MU, associée à la phase courante, référencée PHI en figure 4A, de la conséquence récapitulative CUr va être élaboré puis diffusé et restitué graphiquement sur tout ordinateur connecté à Internet, voire sur des bornes d'informations voyageurs éventuellement connectées à Internet. Ledit message récapitulatif MU destiné aux usagers est constitué par trois zones Zl, Z2 et Z3. La première zone Zl comporte une zone de texte TXT1, sous la forme d'une chaîne de caractères alphanumériques, mentionnant « Aujourd'hui, ligne Tl : accident de personne
- Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : ». Une deuxième zone Z2 dudit message récapitulatif MU consiste en le message unitaire MUU-CUi associée à la phase en cours, PHI en figure 4A, de la conséquence CUi. Ledit message unitaire
MUU-CUi comporte une zone de « Interruption entre les stations
Pierre. Trois stations desservies texte mentionnant
Noailles et Eugène
Camas, George, Jean
Martin ». Enfin, une troisième zone Z3 composant le message récapitulatif MU consiste en une zone de texte TXT3 précisant : « Veuillez nous excuser pour la gêne occasionnée ».
La teneur globale d'un message MU prêt à être restitué à tout usager est donc :
« Aujourd'hui, ligne Tl : accident de personne Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : Camas, George, Jean Martin.
Veuillez nous excuser pour la gêne occasionnée ».
Quelques minutes plus tard, une opportunité de contournement, illustrée en lien avec la figure 4B, est identifiée par l'exploitant du réseau de transport de passagers de la ville de Marseille. En effet, une déviation sur la ligne de bus 72 est saisie par l'exploitant et génère une nouvelle donnée d'exploitation du service DIS2.
Une nouvelle conséquence CU2 est alors produite en lien avec ladite ligne de bus 72 en complément de la première conséquence CUi associée à la ligne de tramway Tl, à l'instar de la situation décrite par la figure 4A.
La plateforme 10 selon l'invention prend en considération cette alternative et génère automatiquement la situation illustrée par la figure 4B.
Ainsi, un tel événement E se décline en deux conséquences distinctes CUi et CU2 sur des éléments du réseau de transport différents. Lesdites conséquences peuvent être associées à une conséquence récapitulative CUr. Les trois conséquences CUr, CUi et CU2 peuvent ainsi générer trois messages, respectivement un message récapitulatif MU pour la conséquence CUr et des messages unitaires MUU-CUi et MUU-CU2, pour les deux autres. Un tel message récapitulatif MU est formaté pour être restitué graphiquement par un navigateur internet. Comme l'indique la figure 4B, ledit message récapitulatif MU, associée à la phase courante PHI de la conséquence récapitulative CUR, est constitué de quatre zones ZI à Z4. Lesdites zones ZI et Z4 du messaqe récapitulatif selon la figure 4B sont identiques respectivement aux zones ZI et Z3 du message MU en lien avec la figure 4A. La deuxième zone Z2 du message récapitulatif selon la figure 4B consiste en le message unitaire MUU-CUi associé à la phase en cours PHI de la conséquence CUi. Ledit message unitaire MUU-CUi précise un texte identique à celui-ci exprimé en lien avec les message unitaire MUU-CUi de la figure 4A. En revanche, ledit message récapitulatif comporte une zone supplémentaire, la zone Z3, pour mentionner la teneur du message unitaire MUU-CU2 associé à la phase en-cours PHI de la conséquence CU2 en lien avec la ligne de bus 72. Ledit message unitaire MUU-CU2 précise alors « Bus 72 : Déviation en direction du terminus Métro Rond Point du Prado par rue George. Arrêt non desservi : Sakakini Chave ».
Ledit message récapitulatif MU selon la figure 4B mentionne donc une information destinée aux usagers telle que :
« Aujourd'hui, ligne Tl : accident de personne Boulevard Chave. Cet incident nous oblige à modifier l'itinéraire de la ligne comme suit : Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : Camas, George, Jean Martin.
Bus 72 : Déviation en direction du terminus Métro Rond Point du Prado par rue George. Arrêt non desservi : Sakakini Chave.
Veuillez nous excuser pour la gêne occasionnée ».
Quelques minutes plus tard, la perturbation évolue, comme illustré par la figure 4C. Un retour progressif à un niveau de service normal s'amorce. La déviation sur la ligne de bus 72 est terminée. La conséquence CU2 est alors concernée par la phase de fin PH2. De nouvelles données d'exploitation DIS3 ont été collectées et une nouvelle itération dudit procédé PI permet de générer un nouveau message récapitulatif MU.
Ce nouveau message MU informe les usagers qu'une modification des itinéraires des lignes est possible. Lesdits usagers ont alors une parfaite connaissance des conséquences et peuvent ainsi réagir à la perturbation courante. Nous pouvons constater, en lien avec la figure 4C, que l'une des deux conséquences CU2 découlant de l'incident, c'est-à-dire en l'espèce, l'impact sur la ligne de bus 72 est en passe de se résorber. Une information en lien avec le retour à la normale de ladite ligne 72 peut ainsi être propagée. Un message unitaire
MUU-CU2 associé à la phase de fin PH2 de ladite conséquence CU2 est à présent intégré dans le message récapitulatif MU en lieu et place du message unitaire MUU-CU2 associé à la phase courante illustrée par la figure 4B.
Quelques minutes plus tard, la perturbation évolue davantage. La ligne de tramway Tl recouvre elle-aussi un fonctionnement normal. Globalement, le réseau de transport recouvre donc un service normal. Un message récapitulatif MU associé à la phase de fin PH2 de la conséquence récapitulative CUr est alors produit, puis diffusé, comme l'indique la figure 4D. Un tel message MU ne comporte qu'une zone ZI comportant un champ de texte TXT mentionnant « Aujourd'hui, lignes Tl et 72 : accident de personne Boulevard Chave - fin de perturbation ».
Grâce à l'invention, les usagers ont pu suivre l'évolution de la perturbation du service de transport. Informés en temps réel des impacts sur le réseau de transport, des opportunités de contournement d'une perturbation de service, puis de la fin de ladite perturbation, les usagers peuvent s'organiser et ne pas subir totalement un tel incident.

Claims (4)

1. Procédé (PI) de gestion d'incidents d'un service, ledit procédé (PI) étant mis en œuvre par une unité de traitement (11) d'une plateforme de gestion d'incidents de service (10) comportant outre ladite unité de traitement (11), une mémoire de données monde des moyens de communication (13,15) extérieur, ladite mémoire de données avec le lesdits moyens de communication (13,15) coopérant avec ladite unité de traitement (11), ledit procédé (PI) étant caractérisé en ce que :
les moyens de communication (13) de ladite plateforme (10) assurent une première liaison données d'incidents ou d'exploitation du service (DISI, DISi, DISn) et une deuxième liaison
ODj, ODm) d'un message d'information (MU, MU1,
MUj, MUm) ;
ledit procédé (PI) comporte :
une étape (100, 10-1) pour collecter une donnée d'incident ou d'exploitation du service (DISI,
DISi, DISn) émise par le générateur de données d'incidents ou d'exploitation du service une étape (300, pour estimer une ou plusieurs conséquences du service et produire un ou plusieurs messages d'information unitaires (MUU-CUi, MUUCUz) associées à ces dernières ;
une étape (500, 10-2) pour produire un message d'information (MU) à partir desdits un ou plusieurs messages d'information unitaires (MUU-CUi, MUU-CUZ) ;
une étape (600, 10-3) pour provoquer une sortie dudit message d'information (MU) par le moyen de sortie (30, OD1, ODj, ODm) de sorte qu'un usager dudit service perçoive la teneur dudit message d'information (MU, MU1, MUj, MUm).
2. Produit programme d'ordinateur (PG) comportant des instructions de programme qui, lorsqu'elles sont exécutées ou interprétées par un ordinateur (10), provoquent la mise en œuvre d'un procédé (PI) de gestion d'incidents d'un service selon la revendication précédente.
3. Plateforme (10) de gestion d'incidents de service comportant une unité de traitement (11), une mémoire de données (12), une mémoire de programmes (14), des moyens de communication (13, 15) avec le monde extérieur, lesdites mémoires de données et de programmes (12, 14) et lesdits moyens de communication (13, 15) coopérant avec ladite unité de traitement (11), ladite plateforme de gestion d'incidents d'un service (10) étant caractérisée en ce qu'elle comporte dans la mémoire de programmes (14), les instructions d'un produit programme d'ordinateur (PG) selon la revendication précédente.
4. Système de gestion d'incidents d'un service comportant un ou plusieurs générateurs (20, IG1, IGi, IGn) de données d'incidents ou d'exploitation dudit service (DIS1, DISi, DISn), un ou plusieurs moyens de sortie (30, OD1, ODj, ODm) d'un message d'information (MU, MU1, MUj, MUm), lesdits générateurs et moyens de sortie coopérant (NI, N2) avec une plateforme (10) de gestion d'incidents de service conforme à la revendication précédente.
FR1854994A 2017-09-01 2018-06-08 Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe Withdrawn FR3070777A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/FR2018/052116 WO2019043332A1 (fr) 2017-09-01 2018-08-29 Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762553449P 2017-09-01 2017-09-01
US62553449 2017-09-01

Publications (1)

Publication Number Publication Date
FR3070777A1 true FR3070777A1 (fr) 2019-03-08

Family

ID=65560480

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1854994A Withdrawn FR3070777A1 (fr) 2017-09-01 2018-06-08 Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe

Country Status (1)

Country Link
FR (1) FR3070777A1 (fr)

Similar Documents

Publication Publication Date Title
US10367866B2 (en) Systems and methods for automation fallback
US10462534B2 (en) Methods and apparatus for centralized and decentralized alert messaging
US9667581B2 (en) Computer-implemented system and method for notifying users upon the occurrence of an event
US8510660B2 (en) Method and system for tagging content
JP2010503915A (ja) ピアツーピア・メディア配布システムおよび方法
US20160173825A1 (en) Real-Time Visual Customer Support Enablement System and Method
FR3070777A1 (fr) Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe
WO2019043332A1 (fr) Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe
KR102492022B1 (ko) 다중 채널 네트워크의 컨텐츠 관리 방법, 장치 및 시스템
US20220377114A1 (en) Controlled environment secure media streaming system
US11134310B1 (en) Custom content service
EP1195029A1 (fr) Procede et systeme de messagerie
KR102492014B1 (ko) 다중 채널 네트워크의 컨텐츠 관리 방법, 장치 및 시스템
CN111831937A (zh) 一种数据处理方法、装置以及计算机存储介质
EP2141882A1 (fr) Système et procédé pour la diffusion d'un contenu multimédia via un réseau de télécommunication
FR3005181A1 (fr) Generation d'un document multimedia personnalise relatif a un evenement
EP3899747A1 (fr) Procédé et structure de signalement d'incident
FR2955955A1 (fr) Systeme de gestion de services
FR2855629A1 (fr) Systeme d'actualisation de documents multimedias
FR2972321A1 (fr) Procede et systeme de generation et de mise a jour de donnees structurees destinees a des terminaux multimedia
FR2887356A1 (fr) Dispositif electronique autonome pour site de commerce electronique
WO2001003025A1 (fr) Installation de transmission interactive de donnees multimedia
FR2899707A1 (fr) Procede d'analyse d'une page web

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

ST Notification of lapse

Effective date: 20210206