WO2019043332A1 - 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
WO2019043332A1
WO2019043332A1 PCT/FR2018/052116 FR2018052116W WO2019043332A1 WO 2019043332 A1 WO2019043332 A1 WO 2019043332A1 FR 2018052116 W FR2018052116 W FR 2018052116W WO 2019043332 A1 WO2019043332 A1 WO 2019043332A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
data
incident
platform
message
Prior art date
Application number
PCT/FR2018/052116
Other languages
English (en)
Inventor
Cyril LABI
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
Priority claimed from FR1854994A external-priority patent/FR3070777A1/fr
Application filed by Mytechtrip filed Critical Mytechtrip
Publication of WO2019043332A1 publication Critical patent/WO2019043332A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/55—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for traffic information

Definitions

  • the invention relates to the field of platforms for managing incidents or disturbances of services offered to users.
  • said users wish, or even require:
  • the invention will be described through an example of application relating to the passenger transport service in an urban environment.
  • the invention may, however, apply to any other field of application, requiring a complex analysis of incidents and production of information to humans via different modes of graphic and / or sound reproduction.
  • the invention makes it possible to meet all or some of the disadvantages raised by the known solutions.
  • the invention provides a service provider with:
  • the invention relates to a method for managing incidents of a service, said method being implemented by a processing unit of a service incident management platform comprising, in addition to said processing unit, a data memory, means of communication with the outside world, said data memory and said communication means cooperating with said processing unit.
  • the communication means of said platform provide a first link with a data generator of incidents or exploitation of the service and a second link with an output means of an information message.
  • a service incident management method comprises:
  • the invention relates to a computer program product comprising program instructions which, when executed or interpreted by a computer, cause the implementation of such an incident management method. a service according to the invention.
  • the invention relates to a service incident management platform comprising a processing unit, a data memory, a program memory, means of communication with the outside world, said data and program memories. and said communication means cooperating with said processing unit, said program memory including the instructions of a computer program product according to the invention.
  • the invention relates to an incident management system of a service comprising one or more data generators of incidents or exploitation of said service, one or more means for outputting an information message, said generators and output means cooperating with a service incident management platform according to the invention.
  • FIG. 1 illustrates a nonlimiting exemplary embodiment of a functional architecture of a service incident management platform according to the invention
  • FIG. 2 presents a nonlimiting exemplary embodiment of an incident management method of a service implemented by such a platform according to the invention
  • FIG. 3 describes an example of modeling of data associated with an event for which one or more messages can respectively be associated and formatted with one or more consequences for the users of a service
  • FIGS. 4A to 4D describe an example of producing user information messages during the appearance, tracking, and termination stages of a service incident.
  • the invention relates to a method and a platform implementing said method, for managing one or more service incidents and for translating them into one or more operational hazards, then into one or more consequences for the users and ultimately into one or more consequences.
  • FIG. Service incident management consists in collecting and decoding data of operating incidents of a service DIS1, DISi, DISn emanating respectively from different generators or sources IG1, IGi, IGn, among a plurality of available sources, such as sensors arranged on a passenger transport network, for example, or systems for assisting with the operation of said service, or even directly by an operator via a man-machine interface input or input , thereby generating said operating incident data.
  • Such data may be time stamped to follow the evolution of an incident and conveyed by data messages transmitted to a service incident management platform 10 according to the invention, via a first communication network or link NI.
  • Such an NI network may be simple or plural and implement one or more technologies and / or wired or wireless communication protocols, such as, in a non-exhaustive manner, the Internet, Sigfox, LoRa, or more generally any communication vector allowing two electronic objects to exchange information of a technical nature.
  • the invention In order to manage these different incident data, the invention relies on the implementation of a set PI of operating data processing methods and / or service incident, said operating data and / or incident DISI, DISi, DISn being operated by a processing unit 11 of a platform 10, for example in the form of a computer or more generally of a computer server.
  • a processing unit 11 consists of one or more micro ⁇ processors and cooperates via one or more bus communication, symbolized by double arrows in Figure 1, with a data memory 12, consisting of one or more physical and / or logical entities, some of which may be physically remote from said processing unit 11.
  • the data memory 12 allows save for example all work data, any operating parameters of the platform, or even the content of an information message intended for users.
  • the processing unit 11 further cooperates with a program memory 14, arranged to store the instructions of a computer program PG, the execution or interpretation of which, by said processing unit 11, causes the implementation implementation of a service incident management method PI according to the invention.
  • a platform 10 according to the invention further comprises communication means 13 adapted to interact with said generators or incident data sources IGl, IGi, IGn, via the first communication network or NI link.
  • DISn in order to keep only a corpus or a selection of said DIS service data likely to impact the users of the service, and translate said corpus into one or more impacts AE on the operation of said service; a second block of steps 10-2 for translating said AE operation impact (s) previously estimated into CU consequences for the users, so as to elaborate, from unit messages associated with said consequences, and then format one or more MU messages to destination of the users, according to one or more means or communication media OD1, ODj, ODm, suitable for broadcasting such messages;
  • Such communication media OD1, ODj, ... ODm, among a plurality of available media may consist of a computer screen, a public display panel, an information delivery server via the Internet, a passenger information terminal (also known as BIV), personal computer, smart phone or tablet, etc.
  • a service incident management platform 10 in accordance with the invention cooperates with such media 30 via a second communication network or link N2, possibly similar to the first communication network NI, previously mentioned to convey the incident data. from service DIS1 to DISn.
  • said first and second communication networks NI and N2 may constitute one and the same communication network.
  • the invention will be described through an example of passenger transport application. It could apply to any other type of service from which a user expects concrete help to cope with or circumvent a service incident.
  • FIG. 2 A detailed embodiment of an incident management method PI of a service according to the invention, implemented by a platform as illustrated by FIG. 1, is now described with reference to FIG. 2. .
  • Such a platform 10 may be described as comprising three main functional modules, respectively corresponding to the three main step blocks 10-1, 10-2 and 10-3 of said service incident management method PI, implemented by the processing unit 11 of said platform 10.
  • a first functional module or a first step block 10-1 is responsible for the acquisition or collection and processing of operating or service data DIS1, DISi, DISn, as well as the determination of a repository of a service, such a first module being hereinafter called “Operation monitoring services” according to an English terminology.
  • a second module or a second block of steps 10-2 is responsible, for its part, the creation of user events and the formatting of messages ready to be broadcast, respectively related to the consequences (routing, waiting, etc.. ) for users of the service, said second module being hereinafter referred to as "user information creation services" according to an English terminology.
  • a third module or a third block of steps 10-3 is responsible for broadcasting said messages to broadcast media, or output means OD1, ODj, ODm adapted or appropriate communication means, said third module being called "User information broadcasting services" according to Anglo-Saxon terminology.
  • such an incident management method PI of a service mainly comprises:
  • step block 10-1 further comprising translating, according to one or more predetermined rules, one or more of said operating or incident data. service in an AE hazard, the latter being created or updated, if it is current;
  • a block of steps 10-2 for determining, according to a predetermined scenario, one or more consequences CU in delivering the service to said users, from said hazard AE produced or updated in step block 10-1 and for produce from such consequences an event E according to one or more predetermined scenarios, such an event E being reflected in a selection of one or more means of broadcast of messages, together with a production of one or more MU information messages, formatted in a predetermined manner according to the type of broadcast medium selected;
  • Such a block of steps 10-3 (or more precisely the step 600 in connection with FIG. 2) to cause the diffusion can advantageously be adapted so that said diffusion is "orchestrated" according to a predetermined protocol.
  • a step 100, of the first step block 10-1, of collecting incident data 100 or DIS1, DISi, DISn service operating can be subject to a procedure for recording said data in the data memory 12 of the platform 10.
  • a recording operation may include in particular a time stamp of said collection of data. incident or service data.
  • a history of operations can be created and consulted on request.
  • said data can be respectively associated with given periods of validity.
  • a step 100 may for example consist of recording data. of operation describing a plot of a line and / or stopping points on such a line.
  • Said step 100 consists, prior to a recording phase of such data incident or exploitation in data memory, to decode the collected incident or operating data and to "normalize” them so that they may be jointly examined or processed later.
  • a standardization or formatting step results in a function commonly called "connector” in computer jargon.
  • a platform according to the invention has, by programming, a predetermined model of any operating data or incident with respect to a predetermined reference for a service concerned.
  • a platform 10 can be arranged to adapt to any type of data flow and / or technologies responding to communication models of the request / response, subscription / notification or batch processing ("batch”) types.
  • Such a step 100 can advantageously exploit communication standards of the targeted business domain, for example in the field of transport, SIRI ("Service Interface for Real Time Information", according to an English terminology, defining an exchange protocol of information in real time), NeTEx (Network Exchange according to a terminology Anglo-Saxon, for exchanging information related to the Transport according to an XML type of document format - "Extensible Markup Language", according to an English terminology), GTFS ("General Transit Feed Specification" according to English terminology specifying public transport flows) to facilitate integration with DIS data providers.
  • SIRI Service Interface for Real Time Information
  • NeTEx Network Exchange according to a terminology Anglo-Saxon, for exchanging information related to the Transport according to an XML type of document format - "Extensible Markup Language", according to an English terminology
  • GTFS General Transit Feed Specification
  • Such a block of steps 10-1 may further comprise a step 200 of filtering, that is to say selection of said data DIS1, DISi, DISn, to keep only a subset of data of interest or even to consolidate and "prioritize" certain operating and / or incident data acquired.
  • a selection can be parameterized or even customized according to the service in question, for example according to the urban transport network of a particular city, by the loading of appropriate program instructions for enriching the PG program stored in the program memory 14.
  • step 300, of the first block of steps 10-1 consists of determining the impacts on the users, induced by said selected data DIS, in the form of an operating random event AE, possibly accompanied by a data characterizing a level of urgency or criticality.
  • a hazard strategy may define that if multiple "Deleted Races" regulation acts are received from an operating aid system (in this case a particular type of service operating data generator) impacting the same line route, over a sliding range of five minutes, then it is possible to group the hazards induced by said regulatory acts in the form of a single hazard. "Deleted Races" associated with a low priority.
  • the method PI incident management of a service comprises a second block of steps 10-2 to produce MU messages to destination of the users from the said AE operating randomness (s) produced in 10-1.
  • Said second block of steps 10-2 thus consists of a first step 500 for producing one or more user events E in the form of MU messages, developed according to an example described later in FIG. 3, and ready to be broadcast.
  • the method PI comprises a step 400 for, from alea (s) operating AE and from predetermined event scenarios or random types, possibly configurable and / or customizable via rules, for example in the form of program instructions or scripts, stored in program memory 14, one or more consequences CU are created, each associated with a unit message MUU constituting a part or a zone of such MU user message formed in step 500, said MUU and MU messages being optionally formatted to highlight such and such string of characters, for example.
  • step 500 relies on one or more message templates, generally stored either in data memory 12 or in program memory 14.
  • a selection of message templates can be implemented. in step 500 according to the nature of the event E generated in step 400.
  • step 500 can generate one or more messages MU from a predetermined message template containing text, for example in the form of alphanumeric character string (s), possible formatting, specifying one or more colors of said characters, font (s) of said characters, character accentuations, etc., one or more conditions and / or one or more contextual variables, such conditions or contextual variables consisting of, but not limited to:
  • HTML HyperText Markup Language
  • HTML HyperText Markup Language
  • a service incident management platform 10 may include a component or a pre-display function for an operator of said platform 10 to perform display simulations and / or listening to messages on one or more broadcast media or output 30, before the actual broadcast on sites, future MU messages occurring after a real service incident.
  • the step block 10-2 of a method PI according to the invention can also be adapted (in particular step 400), so that the platform 10 then has, by the implementation of said method PI, a functional module that we could name "Situation policy engine" according to an English terminology.
  • a functional module that we could name "Situation policy engine” according to an English terminology.
  • Such an adaptation enables said platform 10, more precisely its processing unit 11, to automatically select, from among a plurality of possible scenarios, a most relevant event scenario, according to the AE operating randomness or errors previously produced.
  • a step 400 may be arranged to determine one or more consequences CU user, corollaries to the impacts directly induced by an AE operating hazard produced by the first step block 10-1.
  • step 500 of the second step block 10-2 may determine one or more media or broadcast media or output means OD1, ODm, among the plurality of available media, and or one or more geographic locations or perimeters of MU broadcast according to the hazard or type of AE operating hazard produced in 10-1.
  • the MU messages associated with an event E can be formatted accordingly, as will be discussed later in connection with an exemplary message modeling illustrated in FIG.
  • step 500 may comprise a phase of analysis of the validity of the messages ready. to be broadcast in terms of format and funds with regard to user messages MU, already being broadcast and sound and / or graphics renditions.
  • the third functional module offered by a platform 10 according to the invention by the implementation of the block of steps 10-3, in this case step 600, of the process PI illustrated by way of non-limiting example by FIG. 2 is responsible for controlling the broadcasting and the audio or graphic output or output of MU messages produced by the step block 10-2 previously described, by the means or media for output or output OD1, ODj, ODm among the plurality of output means 30 available.
  • This function is translated first of all by an orchestration of the restitution or sound output and / or message graphics MU - "orchestration" means synchronization, sequencing, one or more playback times, loopback, etc. said MU messages.
  • Such a return or output of MU messages also implies a "connector" type function, mirror of that offered by step 100 to "connect” the platform 10 to the operating and incident data generators 20.
  • This second "connector” function makes it possible to link said platform 10 to the broadcast media or media 30.
  • the step 600 furthermore consists in encoding the MU messages to adapt them automatically to any type of stream or to any technology, responding for example communication models of the request / response, subscription / notification or "batch" types, thus providing a service incident management platform 10 according to the invention with a functional connector that complies with the communication standards of the business domain targeted, for example in the field of passenger transport, SIRI or GTFS.
  • FIG. 3 describes an example of a data structure produced in step 400 and associated with an event E leading to the predetermined formatting of a message MU according to the invention. .
  • FIG. 3 illustrates that an event E is associated with one or more consequences CUR, CUI, CU2, CU3, CU Z , the latter being able to take place in one or more PHx phases, among which an initial phase, a current phase during the occurrence of the said event, and a closing or end of occurrence phase at the end of the said event E.
  • Each PHx phase is associated with a selection of one or more broadcast or message output means, an impact perimeter, or one or more unitary messages, previously formatted according to the type (s) of means of communication. selected broadcast.
  • a message MU can, like the description of the example illustrated in Figure 3, be associated with the summary result CUR and include a text, but also one or more conditions and other contextual variables.
  • zones ZI to Zw each zone possibly comprising one or more text ranges TXT and / or one or several MUU-CUi, MUU-CU 2 , MUU-CU 3 , MUU-CUz unit messages respectively associated with the consequences CU 1 , CU 2 , CU 3 , CU Z of the event E.
  • Such an example resulting from the implementation by a platform 10 of a method PI according to the invention and respectively illustrated by FIGS. 1 and 2, is intended to broadcast, by a rendering medium or graphic output of the browser type of Internet page, available on any personal computer connected to the Internet, a MU message intended for users of public transport the city of Marseille, linked to an E event resulting from an incident on Chave Boulevard.
  • FIGS. 4A to 4D thus describe respectively four distinct and successive moments or phases, during which information intended for the users is produced, and whose dissemination via the Internet has been caused by the implementation of said PI method by a platform 10, said platform And method PI being in accordance with the present invention.
  • an incident called "Boulevard Chave” occurs.
  • a partial service on the tram line T1 is entered by the operator delivering a DIS1 incident or operating data.
  • a first step generates an event E arising from said incident and whose structure is such as that described in Figure 3 by way of non-limiting example.
  • Said event E and the content of a message MU automatically produced, as soon as said event E appears, by said method are described in connection with FIG. 4A.
  • a first summary message MU, associated with the current phase, referenced PHI in FIG. 4A, of the summary consequence CUR will be developed and then broadcast and graphically rendered on any computer connected to the Internet, or even on passenger information terminals possibly connected to the Internet. .
  • Said summary message MU intended for the users consists of three zones ZI, Z2 and Z3.
  • the first zone ZI comprises a text box TXT1, in the form of an alphanumeric character string, mentioning "Today, line T1: accident of person - Chave Boulevard. This incident requires us to change the route of the line as follows: ".
  • a second zone Z2 of said summary message MU consists of the unit message MUU-CUi associated with the current phase, PHI in FIG. 4A, of the consequence CUi.
  • Said MUU-CUi unit message includes a text box mentioning "Interruption between Noailles stations and Eugene Pierre. Three stations served: Camas, George, Jean Martin.
  • a third zone Z3 composing the MU summary message consists of a text box TXT3 specifying: "Please excuse us for the inconvenience".
  • a circumvention opportunity illustrated in connection with Figure 4B, is identified by the operator of the passenger transport network of the city of Marseille. Indeed, a deflection on the bus line 72 is entered by the operator and generates a new operating data of the DIS2 service. A new consequence CU2 is then produced in connection with said bus line 72 in addition to the first consequence CUi associated with the tramway line T1, like the situation described in FIG. 4A.
  • the platform 10 according to the invention takes into account this alternative and automatically generates the situation illustrated by FIG. 4B.
  • Such an event E has two distinct consequences CU 1 and CU 2 on different elements of the transport network. Said consequences can be associated with a summary result CUR.
  • the three consequences CUR, CUI and CU2 can thus generate three messages, respectively a summary message MU for the consequence CUR and unit messages MUU-CUi and MUU-CU2, for the two others.
  • Such a summary message MU is formatted to be rendered graphically by an internet browser.
  • said summary message MU associated with the current phase PHI of the summary consequence CUR, consists of four zones Z1 to Z4. Said zones ZI and Z4 of the summary message according to FIG. 4B are respectively identical to the zones ZI and Z3 of the message MU in connection with FIG. 4A.
  • the second zone Z2 of the summary message according to FIG. 4B consists of the unit message MUU-CUi associated with the current phase PHI of the consequence CUi.
  • Said MUU-CUi unit message specifies a text identical to this one expressed in connection with the MUU-CUi unit message of FIG. 4A.
  • said summary message includes an additional zone, the zone Z3, to mention the content of the unit message MUU-CU2 associated with the current phase PHI of the consequence CU2 in connection with the bus line 72.
  • Said unit message MUU -CU2 specifies "Bus 72: Deviation towards the terminus Metro Rond Point Prado Street George. Stop not served: Sakakini Chave ".
  • Said summary message MU according to FIG. 4B thus mentions information intended for the users such as:
  • Bus 72 Deflection towards the metro terminus Rond Point Prado by George Street. Stop not served: Sakakini Chave.
  • This new message MU informs the users that a modification of the routes of the lines is possible. Said users then have a perfect knowledge of the consequences and can thus react to the current disturbance.
  • a unitary message MUU-CU2 associated with the end phase PH2 of said consequence CU2 is now integrated in the summary message MU in place of the unit message MUU-CU2 associated with the current phase illustrated in FIG. 4B.
  • a summary message MU associated with the end phase PH2 of the summary consequence CUR is then produced and then broadcast, as shown in FIG. 4D.
  • Such a MU message contains only a zone ZI comprising a text field TXT mentioning "Today, lines T1 and 72: person accident Boulevard Chave - end of disturbance".
  • the users have been able to follow the evolution of the disruption of the transport service. Informed in real time of the impacts on the transport network, opportunities to bypass a service disruption, and then the end of the disruption, users can organize themselves and not totally suffer such an incident.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (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 média d'affichage ou plus généralement de média 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 média 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 micro¬ processeurs 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, IGl, 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 IGl, 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 média 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 média OD1, ODj , ODm.
De tels média de communication OD1, ODj , ...ODm, parmi une pluralité 30 de média 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 média 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é « Opération 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 sous- ensemble 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'alea(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 », 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, etc . ) .
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 policy 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 média de diffusion ou de sortie OD1, ODm, parmi la pluralité de média 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 média 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 sous- entend é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 média 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 médium 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 ZI, Z2 et Z3. La première zone ZI 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 texte mentionnant « Interruption entre les stations Noailles et Eugène Pierre. Trois stations desservies : 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 message 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

REVENDICATIONS
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
(12), des moyens de communication (13,15) avec le monde extérieur, ladite mémoire de données (12) et 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 (NI) avec un générateur (20, IG1, IGi, IGn) de données d'incidents ou d'exploitation du service (DIS1, DISi, DISn) et une deuxième liaison (N2) avec un moyen de sortie (30, OD1, 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 (20, IGI, IGi, IGn) ;
■ une étape (300, 400, 10-2) pour estimer une ou plusieurs conséquences (CUi, CUz) d'un aléa d'exploitation (AE) du service et produire un ou plusieurs messages d'information unitaires (MUU-CUi, MUU- CUz) 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) .
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.
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 .
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.
PCT/FR2018/052116 2017-09-01 2018-08-29 Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe WO2019043332A1 (fr)

Applications Claiming Priority (4)

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

Publications (1)

Publication Number Publication Date
WO2019043332A1 true WO2019043332A1 (fr) 2019-03-07

Family

ID=63840876

Family Applications (1)

Application Number Title Priority Date Filing Date
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

Country Status (1)

Country Link
WO (1) WO2019043332A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015049801A1 (fr) * 2013-10-04 2015-04-09 株式会社日立製作所 Système de guidage de passagers et procédé de guidage de passagers

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015049801A1 (fr) * 2013-10-04 2015-04-09 株式会社日立製作所 Système de guidage de passagers et procédé de guidage de passagers

Similar Documents

Publication Publication Date Title
US20200153676A1 (en) Accessing content
US9385984B2 (en) Computer-implemented system and method for notifying users upon the occurrence of an event
JP2010503915A (ja) ピアツーピア・メディア配布システムおよび方法
EP1168693A1 (fr) Procédé de distribution d'informations audiovisuelles et système de distribution d'informations audiovisuelles
CN105122817A (zh) 用于媒体分布和管理的系统和方法
EP2043010A1 (fr) Dispositif d'indexage automatique de contenus
FR2843515A1 (fr) Procede de mise en page de messages multimedias
EP1696670A2 (fr) Signal de données de modification d'une scène graphique, procédé et dispositif correspondants
EP1646239A1 (fr) Procédé et système de transmission d'un message vidéo vers un poste de télévision
EP2187321B1 (fr) Procédé et dispositif d'édition d'un objet représenté dans une page web
WO2019043332A1 (fr) Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe
FR3070777A1 (fr) Procede de gestion de perturbations de service, plateforme mettant en oeuvre ledit procede et systeme associe
FR2816143A1 (fr) Procede de diffusion de masse selective d'une annonce dans un reseau de telecommunication, terminal pour mise en oeuvre
EP1997040A1 (fr) Procédé, dispositif et système de gestion d'informations structurées au sein d'une scène graphique
EP1793605A1 (fr) Procédé de fourniture sur demande de menus interactifs à des terminaux couplés à un réseau de communication
FR3067540A1 (fr) Procede d'information et un procede de diffusion a un terminal de communication d'un utilisateur, gestionnaire d'informations et diffuseur
WO2001095577A1 (fr) Procede de transmission d'un message entre deux ordinateurs relies a un reseau et systeme de messagerie correspondant
FR2930662A1 (fr) Procede de securisation d'une scene evolutive, dispositif, signal et programme d'ordinateur correspondants, procede de mise a jour d'une scene evolutive, dispositif et programme d'ordinateur correspondants
EP2820821B1 (fr) Procede et dispositif de mise a disposition d'au moins une donnee de communication
EP2141882A1 (fr) Système et procédé pour la diffusion d'un contenu multimédia via un réseau de télécommunication
WO2010122057A1 (fr) Systeme integre de supervision et de commandement
FR3005181A1 (fr) Generation d'un document multimedia personnalise relatif a un evenement
EP2869586A1 (fr) Procédé de traitement d'au moins un contenu audiovisuel supplémentaire, dispositif et programme d'ordinateur associés
WO2020128252A1 (fr) Procédé et structure de signalement d'incident
EP1848176A1 (fr) Procédé de transformation de données non supportées par un terminal, serveur, programme d'ordinateur et signal correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18786005

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18786005

Country of ref document: EP

Kind code of ref document: A1