Brevet FR2955954A1 — publié le 20110805

SYSTEME DE GESTION DE SERVICES [0001 DOMAINE TECHNIQUE [0002] Un aspect de l'invention concerne un système de gestion de services. Le système peut être appliqué, par exemple, dans le domaine des transports publics par une autorité organisatrice de transports ou par un groupe d'exploitants. D'autres aspects de l'invention concernent un procédé pour gérer des services, et un programme d'ordinateur. [0003] ETAT DE LA TECHNIQUE ANTERIEURE [0004 Un système d'aide à l'exploitation et d'information voyageurs (SAEIV) doit offrir différentes fonctions relatives aux transport publics effectués par des 1 o exploitants pour le compte d'une autorité organisatrice de transports. Premièrement, ce système doit offrir des fonctions typiquement exigées par l'autorité organisatrice de transports comme l'information voyageurs à destination des usagers. En outre, le système doit apporter à un exploitant des outils lui permettant de gérer en temps réel son exploitation. Enfin, le système doit 15 permettre l'élaboration de rapports statistiques pouvant servir à l'évaluation de la tenue des exigences contractuelles formulées par l'autorité organisatrice de transports envers l'exploitant. [0005 Le livre intitulé « Les Systèmes d'Aide à l'Exploitation et à l'Information des Transports Publics Urbains de Surface » édité par le CERTU (ISBN : 2-11- 20 093141-8) aborde plusieurs questions. Où en est-on des évolutions des systèmes d'aide à l'exploitation des transports publics urbains de surface ? Comment se développe l'information des usagers qui lui est de plus en plus associée ? Qu'attend-on pour demain ? Le livre fait le point des évolutions et perspectives des Systèmes d'Aide à l'Exploitation et à l'Information (SAEI) des réseaux de surface 25 urbain. Il s'appuie pour cela sur une analyse bibliographique et sur la visite de 15 réseaux de transport public, dont trois étrangers. Le livre décrit les principes de conception et de réalisation des SAEI développés aujourd'hui, puis les retours d'expériences des réseaux visités, avec notamment les fonctionnalités mises en oeuvre, les difficultés rencontrées, la prise en compte de la qualité de service. Le 30 livre comprend une analyse des coûts d'investissement et d'exploitation de ces systèmes, une description de l'offre industrielle, et enfin quelques recommandations à l'intention des décideurs et praticiens. [0006] EXPOSE DE L'INVENTION [0007] Il existe un besoin pour un système permettant une gestion de services souple et efficace. [0008] Selon un aspect de l'invention, un système pour gérer des services, comprend : - une base de données saisies pour stocker un ensemble de données saisies définissant différents schémas de services pour une exploitation réalisant des services, - un module d'instanciation pour une instanciation à partir de l'ensemble de données saisies avec une périodicité propre à l'exploitation afin d'actualiser périodiquement un plan d'exploitation comprenant plusieurs schémas de services consécutifs pour l'exploitation, un nouveau schéma de services étant ajouté au plan d'exploitation et un schéma de services étant supprimé lors de d'une instanciation, et - une base de données de suivi pour stocker le plan d'exploitation. [000s] Un tel système permet de continuer un schéma de services à travers une instanciation. L'instanciation n'entraîne pas forcément une interruption. Le système permet donc une mise à jour régulière d'un plan d'exploitation tout en assurant une continuité dans la gestion des services. [0010] Un mode de réalisation de l'invention comprend avantageusement une ou plusieurs des caractéristiques supplémentaires suivantes, lesquelles sont décrites dans les paragraphes suivants. [0011] De préférence, le nouveau schéma de services que le module d'instanciation ajoute au plan d'exploitation est consécutif au schéma de services le plus récent dans le plan d'exploitation à actualiser. Le schéma de services que le module d'instanciation supprime du plan d'exploitation est le schéma de services le plus ancien dans le plan d'exploitation à actualiser. [0012] De préférence, dans un intervalle de temps en cours s'étendant de l'instanciation la plus récente jusqu'à la prochaine instanciation, le plan d'exploitation comprend : - un schéma de services central dont au moins une partie principale se trouve dans l'intervalle de temps en cours, et - un schéma de services en amont dont au moins une partie principale se trouve dans un intervalle de temps précédent s'étendant de l'instanciation qui précède immédiatement l'instanciation la plus récente jusqu'à l'instanciation la plus récente, - un schéma de services en aval dont au moins une partie principale se trouve dans un intervalle de temps suivant s'étendant de la prochaine instanciation jusqu'à l'instanciation qui suit immédiatement la prochaine instanciation. [0013] De préférence, le module d'instanciation effectue une instanciation par jour. [0014] De préférence, au moins deux schémas de services dans un plan d'exploitation se recouvrent partiellement. [0015] Un schéma de services peut avoir une durée différente de celle d'un autre 15 schéma de services. [0016] De préférence, la base de données saisies est agencé pour stocker un autre ensemble de données saisies définissant différents schémas de services pour une autre exploitation réalisant des services. Le module d'instanciation est agencé pour effectuer une autre instanciation à partir de l'autre ensemble de 20 données saisies avec une périodicité propre à l'autre exploitation afin d'actualiser périodiquement un autre plan d'exploitation pour l'autre l'exploitation. La base de données de suivi est agencée pour stocker l'autre plan d'exploitation. Ces caractéristiques supplémentaires permettent à chaque exploitant d'exploiter ses réseaux avec son propre cycle de vie. Plusieurs exploitants peuvent donc se 25 regrouper toute en conservant une autonomie de fonctionnement qui est synonyme de responsabilité et donc d'efficacité. Ainsi, les exploitants d'un groupe peuvent effectuer des travaux de type différent comme, par exemple, des dessertes urbaines, des dessertes interurbaines, et du ramassage scolaire, en utilisant le même système de gestion. 30 [0017] De préférence, le système comprend un module d'interaction agencé pour offrir : - un premier accès exploitant restreint à l'ensemble de données saisies et au plan d'exploitation mentionnés en premier, - un second accès exploitant restreint à l'autre ensemble de données saisies et à l'autre plan d'exploitation, et - un accès fédérateur pour accéder à l'un et l'autre ensemble de données saisies et à l'un et l'autre plan d'exploitation. [0018] De préférence, le système comprend un module d'analyse agencé pour effectuer une analyse globale de données relatives à la première exploitation et de données relatives à la seconde exploitation. [0019] De préférence, les services à gérer sont des services de transport en commun. [0020] Une description détaillée en référence à des dessins illustre l'invention brièvement exposée précédemment, ainsi que les caractéristiques supplémentaires identifiées précédemment. [0021] DESCRIPTION SOMMAIRE DES DESSINS • La figure 1 est un diagramme conceptuel illustrant une infrastructure pour des services de transport en commun. • La figure 2 est un diagramme fonctionnel illustrant un système d'aide à l'exploitation et d'information voyageurs. • La figure 3 est un diagramme temporel illustrant un schéma de fonctionnement du système d'aide à l'exploitation et d'information voyageurs. [0022] DESCRIPTION DETAILLEE [0023] La figure 1 illustre une infrastructure IFT pour des services de transport en commun qui couvrent typiquement un territoire donné. L'infrastructure IFT comprend une première et une seconde exploitation El, E2 de transport en commun effectuées respectivement par un premier et un second exploitant. La première exploitation El comprend, à titre d'exemple, deux réseaux de transport RT1, RT2. La seconde exploitation E2 comprend à titre d'exemple également deux réseaux de transport RT3, RT4. Un réseau de transport comprend un ensemble de lignes. Des correspondances peuvent exister entre deux réseaux de transport appartenant à une même exploitation. Des correspondances peuvent également exister entre deux réseaux de transport appartenant à deux exploitations différentes. [0024] La première exploitation El comprend différentes ressources pour effectuer des services de transport en commun au sein de cette exploitation. Il en va de même pour la seconde exploitation E2. Les ressources sont typiquement sous forme de véhicules V de transport en commun et des agents de conduite C. [0025] L'infrastructure IFT comprend des bornes d'information B qui peuvent être déployées au sein de la première et de la seconde exploitation E1, E2. Une borne d'information B présente aux voyageurs des informations relatives aux services de 1 o transport. Cette présentation peut être visuelle, auditive, ou audiovisuelle, et peut s'effectuer de façon interactive. [0026] Une infrastructure de communication RC permet la transmission de données au sein de l'infrastructure IFT pour les services de transport en commun. L'infrastructure de communication RC peut comprendre plusieurs réseaux de 15 communication comme, par exemple, un système radio privée ou opérée, un réseau de téléphonie fixe, un réseau de téléphonie mobile, et le réseau Internet. Ces réseaux peuvent être préexistants, c'est-à-dire, ils peuvent exister avant la mise en place de l'infrastructure IFT pour les services de transport en commun. [0027] L'infrastructure IFT pour les services de transport en commun comprend 20 un système d'aide à l'exploitation et d'information voyageurs SAEIV. Le système d'aide à l'exploitation et d'information voyageurs SAEIV reçoit des données relatives aux services de transport et transmet de telles données par l'intermédiaire de l'infrastructure de communication RC. Le système d'aide à l'exploitation et d'information voyageurs SAEIV comprend un ou plusieurs 25 serveurs informatiques munis d'un ensemble de modules de logiciel définissant des opérations. Ces opérations effectuées par le système d'aide à l'exploitation et d'information voyageurs SAEIV seront décrites dans ce qui suit en référence aux figures 2 et 3. [0028] L'infrastructure IFT pour les services de transport en commun comprend 30 en outre un poste de fédérateur PF, un premier poste d'exploitation PE1, et un second poste d'exploitation PE2. Un quelconque de ces postes peut être sous forme d'un ordinateur muni d'un logiciel d'interface permettant à ce poste d'accéder au système d'aide à l'exploitation et d'information voyageurs SAEIV en tant que client au sens technique. De préférence, le logiciel d'interface permet trois modes d'accès : un mode « fédérateur », un mode « premier exploitant », et un mode « second exploitant ». Le mode d'accès dépend typiquement d'une ou plusieurs données d'identification (en anglais : un login) spécifiées pour utiliser le logiciel d'interface afin d'interagir avec le système d'aide à l'exploitation et d'information voyageurs SAEIV. En effet, le poste de fédérateur PF illustré à la figure 1 symbolise un accès en mode « fédérateur » qui est typiquement réservé à une autorité organisatrice de transports ou à un groupe d'exploitants. Le premier et le second poste d'exploitation PE1, PE2 symbolisent respectivement un accès en mode « premier exploitant » et un accès en mode « second exploitant » qui sont respectivement réservés au premier et au second exploitant. [0029] Un voyageur peut posséder un ou plusieurs appareils de communication CP, PC tels que, par exemple, un téléphone portable CP ou un assistant numérique personnel PC. Le voyageur peut obtenir des informations relatives aux services de transport en commun au moyen d'un tel appareil de communication. Pour ce faire, une connexion est établie entre l'appareil de communication en question et le système d'aide à l'exploitation et d'information voyageurs SAEIV. [0030] La figure 2 illustre fonctionnellement le système d'aide à l'exploitation et d'information voyageurs SAEIV plus en détail. Le poste de fédérateur PF, le premier et le second poste d'exploitant PE1, PE2, les véhicules V appartenant à la première et la seconde exploitation E1, E2, et les appareils de communication CP, PC des voyageurs sont également représentés à la figure 2. [0031] Le système d'aide à l'exploitation et d'information voyageurs SAEIV comprend une interface de communication IF, un ensemble de modules d'interaction MSD, MIT, MIR, MMR, MED, MAS, une base de données saisies BD, un module d'instanciation IN, une base de données de suivi BS, et une base de données historique de suivi BH. L'ensemble de modules d'interaction comprend un module de saisie MSD, un module d'information voyageurs théorique MIT, un module d'information voyageurs temps réel MIR, un module de gestion temps réel MMR, un module d'enregistrement MED, et un module d'analyse statistique MAS. [0032] Un quelconque module mentionné dans ce qui précède peut être implémenté, par exemple, à l'aide d'un serveur en chargeant un ensemble d'instructions approprié dans celui-ci. Dans une telle implémentation à base de logiciel, l'ensemble d'instructions définit des opérations effectuées par le module concerné. Les opérations effectuées par les modules respectifs sont décrites dans ce qui suit. Les bases de données mentionnées dans ce qui précède sont typiquement implémentées à l'aide de l'espace mémoire présent dans un ou plusieurs serveurs, ou autres équipements informatiques. [0033] La base de données saisies BD comprend un ensemble de données saisies générales DG, un premier ensemble de données saisies Dl propre à la première exploitation E1, et un second ensemble de données saisies D2 propre à la seconde exploitation E2. La base de données de suivi BS comprend un premier ensemble de données de suivi Si propre à la première exploitation El et un second ensemble de données de suivi S2 propre à la seconde exploitation E2. De façon similaire, la base de données historique de suivi BH comprend un premier ensemble de données historiques de suivi H1 propre à la première exploitation E1 et un second ensemble de données historiques de suivi H2 propre à la seconde exploitation E2. [0034] Le système d'aide à l'exploitation et d'information voyageurs SAEIV fonctionne globalement comme suit. Le module de saisie MSD reçoit des données saisies par le premier exploitant et par le second exploitant respectivement dans le premier poste et le second poste d'exploitant PE1, PE2. Le module de saisie MSD stocke les données saisies par le premier exploitant dans la base de données saisies BD de façon à ce que ces données fassent partie du premier ensemble de données saisies D1 propre à la première exploitation E1. De même, le module de saisie MSD stocke les données saisies par le second exploitant de façon à ce que ces données fassent partie du second ensemble de données saisies D2 propre à la seconde exploitation E2. Les exploitants sont donc capables de saisir leurs données respectives de manière indépendante les uns des autres. [0035] Les données saisies par un exploitant, et stockées dans la base de données saisies BD, décrivent des services de transport à réaliser par l'exploitant concerné, des ressources mises en oeuvre à cette fin, et une organisation de ces ressources pour réaliser les services de transport. Les données saisies relatives aux services de transport comprennent typiquement des données définissant une topologie des lignes, des arrêts, et les dessertes des lignes. Les données saisies relatives aux services de transport peuvent également comprendre les données définissant des horaires des courses à réaliser selon les types de jours du calendrier. [0036] Les données saisies relatives aux ressources peuvent comprendre des données définissant des véhicules de transport en commun et des données définissant des agents de conduite. Les données saisies relatives à l'organisation des ressources peuvent comprendre plusieurs ensembles de données relatifs à des services véhicule et plusieurs ensembles de données relatifs à des services agent. Ces différents ensembles de données concernent typiquement différents schémas de services pour différents types de jour du calendrier. Un ensemble de données services véhicule définit des courses à faire par un véhicule de transport en commun pour un type de jour particulier du calendrier. Un ensemble de données services agent définit les courses, ou des morceaux de course, à faire par un agent de conduite pour un type de jour particulier du calendrier. [0037] Le module d'information voyageurs théorique MIT s'appuie sur les données saisies par les exploitants, qui se trouvent dans la base de données saisies BD, pour établir une information voyageurs théorique. L'information voyageurs théorique décrit les horaires des différents réseaux selon les différents types de jour du calendrier. L'information voyageurs théorique comprend des données à partir desquelles des fiches d'horaires peuvent être produites et qui peuvent nourrir un site Web destiné à fournir des informations relatives aux transports en commun. Par exemple, un voyageur peut consulter les fiches d'horaires au moyen d'un appareil de communication en se connectant à un serveur qui traite l'information voyageurs théorique. [0038] Le module d'information voyageurs théorique MIT permet à une autorité organisatrice de transports de constituer une information homogène et cohérente décrivant tous les horaires de ses réseaux qui peuvent être exploités par différents exploitants. De plus, le module d'information voyageurs théorique MIT permet de garantir que cette information soit toujours à jour car le module constitue l'information voyageurs théorique de façon automatique à partir de la base de données saisies BD. Par exemple, dès qu'un exploitant modifie un horaire, cette modification sera automatiquement et immédiatement prise en compte dans l'information voyageurs théorique. [0039] Le module d'instanciation IN effectue des instanciations à partir des données saisies dans la base de données saisies BD. Plus précisément, le module d'instanciation IN effectue une instanciation à partir du premier ensemble de données saisies Dl avec une périodicité propre à la première exploitation El. Cette périodicité sera appelée première périodicité d'instanciation dans ce qui suit. En outre, le module d'instanciation IN effectue une instanciation à partir du second ensemble de données saisies D2 avec une périodicité propre à la seconde exploitation E2. Cette périodicité sera appelée seconde périodicité d'instanciation dans ce qui suit. [0040] La première périodicité d'instanciation et la seconde périodicité d'instanciation peuvent être déphasées l'une de l'autre. Par exemple, une instanciation relative à la première exploitation El peut quotidiennement s'effectuer à deux heures du matin. Une instanciation relative à la seconde exploitation E2 peut quotidiennement s'effectuer à quatre heures du matin. Le module d'instanciation IN peut donc gérer différents cycles de vie propres à différentes exploitations. [0041] En effectuant une instanciation à partir du premier ensemble de données saisies Dl, le module d'instanciation IN actualise un premier plan d'exploitation pour la première exploitation El. Le premier plan d'exploitation ainsi actualisé est valable jusqu'à la prochaine instanciation, qui donne lieu à une nouvelle actualisation. De même, en effectuant une instanciation à partir du second ensemble de données saisies D2, le module d'instanciation IN actualise un second plan d'exploitation pour la seconde exploitation E2 qui est valable jusqu'à la prochaine instanciation. [0042] Le premier plan et le second plan d'exploitation, respectivement pour la première et la seconde exploitation El, E2, sont communément stockés dans la base de données de suivi BS. Le premier plan d'exploitation fait donc partie du premier ensemble de données de suivi Si propre à la première exploitation E1. Le second plan d'exploitation fait donc partie du second ensemble de données de suivi S2 propre à la deuxième exploitation. Le module d'instanciation IN met périodiquement à jour ces plans d'exploitation présents dans la base de données de suivi BS, chacun selon un rythme qui correspond respectivement à la première et la seconde périodicité d'instanciation. Le premier et le second ensemble de données de suivi S1, S2, respectivement propres à la première et la seconde exploitation E1, E2, peuvent donc avoir des différents cycles de vie. [0043] La figure 3 illustre un schéma de fonctionnement du système d'aide à l'exploitation et d'information voyageurs SAEIV et, en particulier, celui du module d'instanciation IN. La figure 3 est un diagramme temporel ayant un axe horizontal représentant le temps « t ». Aux instants Ti11, Ti12, Ti13, Ti14, le module d'instanciation IN effectue une instanciation pour la première exploitation El. Aux instants Ti21, Ti22, Ti23, Ti24, le module d'instanciation IN effectue une instanciation pour la seconde exploitation E2. [0044] Les instants Ti11, Ti12, Ti13, Ti14 reflètent la première périodicité d'instanciation et peuvent se trouver sur une grille de, par exemple, 24 heures. C'est-à-dire, le module d'instanciation IN effectue une instanciation par jour pour la première exploitation El. Ces instanciations s'effectuent à une heure du jour particulière. Les instants Ti21, Ti22, Ti23, Ti24 reflètent la seconde périodicité d'instanciation et peuvent se trouver sur une autre grille de 24 heures, qui est décalée par rapport à la grille caractérisant la première périodicité. C'est-à-dire, le module d'instanciation IN effectue également une instanciation par jour pour la seconde exploitation E2, mais ces instanciations s'effectuent à une autre heure du jour. Les instanciations pour la première exploitation El et celles pour la seconde exploitation E2 sont donc déphasées les unes par rapport aux autres. [0045] Un rectangle en tirets symbolise une définition temporaire du premier plan d'exploitation PLI qui s'applique à la première exploitation El. Cette définition temporaire du premier plan d'exploitation PLI illustré à la figure 3 comprend trois schémas de services V11, V12, V13. La définition temporaire du premier plan d'exploitation PLI illustré à la figure 3 résulte de l'instanciation effectuée à l'instant Ti12. La définition temporaire du premier plan d'exploitation PLI est valable jusqu'à la prochaine instanciation à l'instant Ti13. La définition temporaire du premier plan d'exploitation PLI illustré à la figure 3 est donc valable dans un intervalle de temps IT1 qui s'étend de l'instant Ti12 jusqu'à l'instant Ti13. [0046] Un autre rectangle en tirets symbolise une définition temporaire du second plan d'exploitation PL2 qui s'applique à la seconde exploitation E2. Cette définition temporaire du second plan d'exploitation comprend également trois schémas de services V21, V22, V23. La définition temporaire du second plan d'exploitation PL2 résulte d'une instanciation effectuée à l'instant Ti22. Cette définition temporaire est utilisée dans un intervalle de temps IT2 qui s'étend de cet instant Ti22 jusqu'à l'instant Ti23 auquel l'instanciation suivante est effectuée pour la seconde exploitation E2. [0047] De préférence, un plan d'exploitation comprend typiquement trois schémas de services consécutifs comme l'illustre la figure 3. Ceci s'applique lors d'un quelconque intervalle de temps en cours s'étendant entre l'instanciation la plus récente jusqu'à la prochaine instanciation. Plus précisément, le plan d'exploitation comprend un schéma de services central dont une partie principale 1 o se trouve dans l'intervalle de temps en cours. En outre, le plan d'exploitation comprend un schéma de services en amont dont au moins une partie principale se trouve dans un intervalle de temps précédent, qui s'étend de l'instanciation qui précède immédiatement l'instanciation la plus récente jusqu'à l'instanciation la plus récente. Le plan exploitation comprend un schéma de services en aval dont au 15 moins une partie principale se trouve dans un intervalle de temps suivant, qui s'étend de la prochaine instanciation jusqu'à l'instanciation qui suit immédiatement la prochaine instanciation. Par exemple, se référant au premier plan d'exploitation PLI illustrée à la figure 3, lors de l'intervalle de temps IT1, l'instanciation la plus récente a été effectuée à l'instant Ti12 et la prochaine instanciation sera effectuée 20 un instant Ti13. Lors de cet intervalle de temps IT1, le schéma de services central est V12, le schéma de services en amont est V11, et le schéma de services en aval est V13. [0048] Un schéma de services couvre un intervalle de temps ayant une durée, par exemple, compris entre 24 et 48 heures. La durée d'un schéma de services 25 peut être différente de celle d'un autre schéma de services. Les schémas de services peuvent se recouvrir partiellement comme l'illustre la figure 3. C'est-à-dire, les intervalles de temps couverts par les schémas de services ne correspondent pas forcément aux périodicités respectives des instanciations. Ceci permet d'éviter des interruptions ou des coupures dans les services de transport 30 en commun. [0049] Par exemple, l'intervalle de temps IT1 illustré à la figure 3 peut concerner un samedi d'une semaine ordinaire. Dans ce cas, l'intervalle de temps de l'instant Ti11 jusqu'à l'instant Ti12 concerne un vendredi d'une semaine ordinaire, et l'intervalle de temps de l'instant Ti13 jusqu'à l'instant Ti14 concerne un dimanche d'une telle semaine. Dans cette hypothèse, le schéma de services V11 est celui d'un vendredi d'une semaine ordinaire, et les schémas de services V12, V13 sont respectivement ceux d'un samedi et d'un dimanche d'une telle semaine. Le premier plan d'exploitation PLI tel qu'illustré à la figure 3 permet, dans l'intervalle de temps IT1 (le samedi), de continuer le schéma de services V11 de la veille (le vendredi) qui n'aurait pas encore fini. Ce plan d'exploitation illustré permet également, dans l'intervalle de temps IT1 (le samedi), de débuter le schéma de services V13 du lendemain (le dimanche). [0050] A l'instant Ti13, le premier plan d'exploitation PLI est actualisé. C'est-à-dire, la définition temporaire de ce plan PLI illustré à la figure 3 est remplacée par une nouvelle définition temporaire. Concrètement, le module d'instanciation IN supprime le schéma de services V11 qui est le plus ancien et qui a été complété à l'instant Ti13. Le module d'instanciation IN ajoute un nouveau schéma de services V14 qui débutera relativement peu après l'instant Ti14 où une nouvelle instanciation sera effectuée, ou qui débutera à cet instant Ti14. En effet, le nouveau schéma de services V14 ajouté au premier plan d'exploitation PLI à l'instant Ti13 est consécutif au schéma de services V13 le plus récent dans le premier plan d'exploitation PLI à actualiser. Le nouveau schéma de services V14 ajouté est celui pour le lendemain. La nouvelle définition temporaire du premier plan d'exploitation PLI comprendra donc les schémas de services V12, V13, V14, et s'appliquera dans un intervalle de temps de l'instant Ti13 jusqu'à l'instant Ti14. [0051] A l'instant Ti23, le second plan d'exploitation PL2 est actualisé de la même façon. Le module d'instanciation IN supprime le schéma de services V21 et ajoute un nouveau schéma de services V24. Le second plan d'exploitation PL2 ainsi actualisé s'appliquera dans un intervalle de temps de l'instant Ti23 jusqu'à l'instant Ti24. [0052] En se référant de nouveau à la figure 2, le module d'enregistrement MED reçoit des données de situation provenant des véhicules V de transport de voyageurs circulant dans l'infrastructure IFT illustrée à la figure 1. Les données de situation peuvent également provenir d'autres entités dans cette infrastructure IFT. En tout état de cause, les données de situation comprennent des informations relatives au déroulement réel des services de transport en commun par rapport au plan d'exploitation en cours. Ainsi, les données de situation peuvent indiquer un retard sur une ligne ou un autre problème de circulation. Les données de situation peuvent également indiquer des événements susceptibles de provoquer un problème de circulation, même avant que celui-ci se présente. Le module d'enregistrement MED enregistre les données de situation relatives à la première exploitation El dans le premier ensemble de données de suivi S1 propre à cette exploitation. De même, le module d'enregistrement MED enregistre les données de situation relative à la seconde exploitation E2 dans le second ensemble de données de suivi S2 propre à cette exploitation. [0053] Le module d'information voyageurs temps réel MIR s'appuie sur les données de suivi, qui se trouvent dans la base de données de suivi BS, pour établir une information voyageurs temps réel. Le module d'information voyageurs temps réel MIR peut comprendre une partie de diffusion automatique pour diffuser des informations de passage à un arrêt. Ces informations de passage peuvent indiquer les heures de passage des véhicules V réellement attendues ou les temps d'attente. Ces informations peuvent être accompagnées de l'information des lignes et des destinations des véhicules V. [0054] Le module d'information voyageurs temps réel MIR peut également comprendre une partie de programmation de messagerie pour diffuser des messages relatives à des perturbations ou à vocation générale. Un tel message peut être sélectionné dans une bibliothèque comprenant différents messages préenregistrés. Les messages peuvent être diffusés vers les véhicules V, les bornes d'information B aux arrêts, un serveur Internet, un serveur vocal, ou un serveur SMS. Les messages peuvent être diffusés selon une plage horaire ou une plage de dates. La diffusion peut être gérée, au moins partiellement, au moyen du poste de fédérateur PF qui peut appartenir à une autorité organisatrice de transport. De façon alternative, la diffusion peut être confiée aux exploitants. Dans ce cas, le premier et le second poste d'exploitant PE1, PE2 donneront accès à la partie de programmation de messagerie. [0055] L'information voyageurs temps réel peut, en quelque sorte, traverser différentes exploitations E1, E2 et peut s'échanger avec d'autres systèmes comme, par exemple, un autre système d'aide à l'exploitation et d'information voyageurs ou une centrale de mobilité, selon un protocole normalisé désigné par l'acronyme « SI RI ». Ce protocole permet de transmettre notamment des données relatives à des correspondances. Par exemple, une infrastructure de transports en commun peut comprendre un pôle d'échanges muni d'un panneau d'information. Dans ce cas, il convient d'annoncer les passages des véhicules desservant de différents réseaux, que ceux-ci soient exploités par un seul exploitant ou par plusieurs. [0056] Une autorité organisatrice de transports disposant du poste de fédérateur PF peut obtenir des informations susceptibles d'aider les voyageurs et à les renseigner. Pour ce faire, le module d'information voyageurs temps réel MIR peut 1 o établir ces informations à partir des données présentes dans la base de données de suivi BS. Ainsi, l'autorité organisatrice de transports peut répondre, par exemple, à un voyageur qui se plaint d'attendre à un arrêt, en lui communiquant l'heure estimée d'arrivée d'un véhicule en retard. Selon un autre exemple, l'autorité organisatrice de transports peut répondre à un voyageur qui se plaint du 15 fait qu'un véhicule n'est pas passé en lui communiquant les arrêts dont le système a constaté la desserte par le véhicule. [0057] De façon plus générale, l'autorité organisatrice de transports peut superviser les exploitations en temps réel et ainsi observer la qualité de service instantanée. L'autorité organisatrice de transports peut également recevoir des 20 signalements demandant une intervention comme, par exemple, un signalement de détresse. Ainsi, l'autorité organisatrice de transports peut assurer la sécurité des voyageurs et des agents de conduite. [0058] Le module de gestion temps réel MMR permet au premier exploitant et au second exploitant d'agir sur ses seuls réseaux, c'est-à-dire, les réseaux faisant 25 partie respectivement de la première et la seconde exploitation E1, E2. Le premier et le second exploitant peut donc gérer ses propres ressources respectivement par l'intermédiaire du premier poste d'exploitant PE1 et du second poste d'exploitant PE2, et au moyen du module de gestion temps réel MMR. Le module de gestion temps réel MMR permet à chaque exploitant de compenser 30 individuellement des aléas et d'assurer individuellement une bonne qualité de service tout en partageant le même système d'aide à l'exploitation et d'information voyageurs SAEIV. [0059] Par exemple, le module de gestion temps réel MMR peut fournir à chaque exploitant des informations relatives aux prises de services et les relèves de ses seuls agents de conduite. Le module de gestion temps réel MMR permet ainsi à l'exploitant de pallier les absences ou les retards d'agent par remplacement. Le module de gestion temps réel MMR peut également permettre à chaque exploitant d'intervenir sur les défaillances de ses seuls véhicules V par réparation ou remplacement. Le module de gestion temps réel MMR peut en outre permettre à chaque exploitant de surveiller l'occurrence d'aléa de la circulation susceptible de retarder ses propres courses, ou encore de déclencher des manoeuvres de 1 o régulation comme la suppression d'une course ou l'ajout d'un véhicule supplémentaire afin de partir tout de même à l'heure malgré un retard d'un véhicule. [0060] Le module d'analyse statistique MAS permet des analyses statistiques globales par l'intermédiaire du poste de fédérateur PF. Une analyse statistique 15 globale concerne typiquement l'ensemble des réseaux RT1-RT4 dans l'infrastructure IFT de transports en commun. Dans le cas où le poste de fédérateur PF est opéré par une autorité organisatrice de transport, les analyses statistiques globales permettent à l'autorité organisatrice de transports d'obtenir des données quantitatives relatives aux services de transport effectués par les 20 exploitants. [0061] Par exemple, le module d'analyse statistique MAS peut établir des données relatives aux kilomètres commerciaux parcourus et le temps passé pour parcourir ces kilomètres, ce qui permet d'établir une vitesse commerciale. Le module d'analyse statistique MAS peut également établir des données relatives à 25 la ponctualité et la régularité des dessertes réalisées par rapport aux horaires théoriques. Selon un autre exemple, le module d'analyse statistique MAS peut établir des données relatives à la fréquentation des lignes pour toute l'infrastructure IFT de transports en commun. [0062] Le module d'analyse statistique MAS peut appliquer une opération 30 d'analyse non-linéaire à toutes les données de suivi provenant de différents exploitants. L'opération « ECARTYPE » est un exemple d'une opération d'analyse non-linéaire. Une telle analyse globale est possible grâce au fait que différents ensembles de données propres à différentes exploitations sont stockés communément dans la base de données de suivi BS. [0063] Le module d'analyse statistique MAS permet également des analyses statistiques orientées exploitant. De telles analyses statistiques permettent au premier exploitant et au second exploitant d'obtenir des données statistiques relatives à leurs seuls réseaux. Pour ce faire, le module d'analyse statistique MAS établit des données statistiques relatives à la première ou à la seconde exploitation E1, E2 en réponse à une requête d'analyse statistique respectivement provenant du premier poste d'exploitant PE1 et du second poste d'exploitant PE2. Les données statistiques relatives à une exploitation peuvent être similaires aux données établies par une analyse statistique globale décrite dans ce qui précède, la différence étant qu'elles s'appliquent à l'exploitation seule. [0064] Les données statistiques relatives à une exploitation peuvent également concerner les ressources de l'exploitation en question et l'organisation de ses ressources pour réaliser les services de transport en commun. Par exemple, des données statistiques relatives aux temps de parcours peuvent servir pour ajuster des horaires théoriques. Des données statistiques relatives aux prises de service et les relèves peuvent servir pour détecter des retards systématiques. Des données statistiques relatives à une exploitation peuvent concerner le temps de travail des agents de conduite travaillant pour l'exploitant en question. Ces données statistiques peuvent également fournir des informations relatives au temps passé appelé « haut-le-pied » : le temps passé pour des déplacements non-commerciaux. Cela concerne par exemple un véhicule de transport de voyageurs qui se déplace d'un dépôt vers un début de ligne pour débuter un service. [0065] Le système d'aide à l'exploitation et d'information voyageurs SAEIV décrit dans ce qui précède et illustré à la figure 2, peut répondre aux besoins d'une autorité organisatrice de transports et un groupe d'exploitants. Dans le premier cas, le poste de fédérateur PF est opéré par l'autorité organisatrice de transports. Dans le second cas, le poste de fédérateur PF est opéré par le groupe d'exploitants. Dans ce second cas, le système d'aide à l'exploitation et d'information voyageurs SAEIV laisse une autonomie relativement grande à chaque exploitant du groupe. Les exploitants peuvent saisir leurs données de manière indépendante les uns des autres. Ainsi, chaque exploitant à la liberté de s'organiser au mieux pour réaliser les services de transport en commun sur les réseaux qu'il exploite. [0066] Le module de gestion temps réel MMR peut être agencé pour permettre deux modes de gestion : un mode de gestion « niveau groupe » et un mode de gestion « niveau exploitant ». Le mode de gestion « niveau exploitant » correspond au fonctionnement du module de gestion temps réel MMR décrit dans ce qui précède : chaque exploitant gère ses propres réseaux de façon indépendante. Dans le mode de gestion « niveau groupe », toutes les 1 o exploitations appartenant au groupe sont gérées de façon collective. Ce mode de gestion permet à un groupe d'améliorer sa productivité en mutualisant ses ressources de gestion, notamment les personnes physiques qualifiées pour intervenir dans la gestion de l'exploitation, Ces personnes physiques sont appelées « régulateurs ». Les deux modes de gestion peuvent être utilisés de 15 manière combinée. Par exemple, le mode de gestion « niveau exploitant » peut être appliqué en heures pleines : un régulateur se concentre typiquement sur une exploitation. Le mode de gestion « niveau groupe » peut être appliqué heures creuses où la charge de travail est la plus réduite : un régulateur peut travailler simultanément sur plusieurs exploitations. 20 [0067] REMARQUES FINALES [0068] La description détaillée en référence aux figures est simplement une illustration de l'invention. L'invention peut être réalisée de nombreuses façons différentes. Afin d'illustrer ceci, quelques alternatives sont indiquées sommairement. 25 [0069] L'invention peut être appliquée avantageusement dans de nombreux produits et procédés impliquant une gestion de services réalisés par différents exploitants. Le domaine des services de transport en commun est particulièrement visé par la présente invention, mais pas exclusivement. [0070] Il existe de nombreuses façons d'implémenter un système d'aide à 30 l'exploitation et d'information voyageurs selon l'invention. Le nombre d'exploitations peut être supérieur à deux. Par conséquent, la base de données saisies peut comprendre un nombre d'ensembles de données saisies supérieures à deux, chaque ensemble de données saisies étant propre à une exploitation particulière. De même, la base de données de suivi peut comprendre un nombre d'ensembles de données de suivi supérieur à deux, chaque ensemble de données de suivi étant propre à une exploitation particulière. Un logiciel d'interface pour un poste client peut comprendre autant de modes d'accès qu'il y a d'exploitants en supplément d'un mode d'accès fédérateur. [0071 Un schéma de services peut couvrir un intervalle de temps inférieur à un intervalle de temps entre deux instanciations successives. Par exemple, un schéma de services peut être inférieur à 24 heures. Dans ce cas, il se peut qu'il 1 o n'y ait pas de recouvrement entre deux schémas de services consécutifs dans un plan d'exploitation. [0072] Une périodicité d'instanciation relative à une exploitation peut être ponctuellement interrompue. Par exemple, une périodicité de 24 heures peut être interrompue afin qu'il y ait 23 heures ou 25 heures entre deux instanciations 15 successives. Ceci permet un passage de l'heure d'hiver à l'heure d'été ou un passage dans le sens inverse. [0073] L'expression « bases de données » doit être interprétée de façon large. Cette expression embrasse tout type d'entité informatique comprenant des données et permettant d'interroger ces données de façon globale et homogène. 20 [0074] Bien que les dessins montrent différentes entités fonctionnelles sous forme de différents blocs, ceci n'exclut nullement des implémentations où une seule entité physique effectue plusieurs fonctions, ou plusieurs entités physiques effectuent collectivement une seule fonction. A cet égard, les dessins sont très schématiques. Par exemple, se référant à la figure 2, la base de données de suivi 25 BS et la base de données historique de suivi BH peuvent former une seule base de données de suivi qui comprend des données de suivi en cours et des données de suivi historiques. Ces données peuvent être comprises dans une seule mémoire physique. Cette mémoire peut également comprendre la base de donnée saisies BD. 30 [0075] II existe de nombreuses entités fonctionnelles pouvant être implémentées au moyen de matériel (en anglais: hardware) ou de logiciel (en anglais: software) ou une combinaison de matériel et de logiciel. La description d'une implémentation sous forme de logiciel n'exclut nullement des implémentations sous forme de matériel, et vice versa. Des implémentations hybrides sont également possibles dans le sens où un système, ou une entité fonctionnelle comprise dans le système, comprend un ou plusieurs circuits dédiés ainsi qu'un ou plusieurs processeurs convenablement programmés. [0076] Les remarques qui précèdent montrent que la description détaillée en référence aux figures, illustre l'invention plutôt qu'elle ne la limite. Les signes de références n'ont aucun caractère limitatif. Les verbes « comprendre » et « comporter » n'excluent pas la présence d'autres éléments ou d'autres étapes 1 o que ceux listés dans les revendications. Le mot « un » ou « une » précédant un élément ou une étape n'exclut pas la présence d'une pluralité de tels éléments ou de telles étapes. REVENDICATIONS1. Système pour gérer des services, comprenant : - une base de données saisies (BD) pour stocker un ensemble de données saisies (Dl) définissant différents schémas de services pour une exploitation (El) réalisant des services, et - un module d'instanciation (IN) pour une instanciation à partir de l'ensemble de données saisies (Dl) avec une périodicité propre à l'exploitation (El) afin d'actualiser périodiquement un plan d'exploitation (PLI) comprenant plusieurs schémas de services consécutifs (V11, V12, V13) pour l'exploitation (El), un nouveau schéma de services (V14) étant ajouté au plan d'exploitation (PLI) et un 1 o schéma de services (V11) étant supprimé lors de d'une instanciation. - une base de données de suivi (BS) pour stocker le plan d'exploitation (PLI). 2. Système pour gérer des services selon la revendication 1, dans lequel le module d'instanciation (IN) est agencé de façon à ce que : - le nouveau schéma de services (V14) qui est ajouté au plan d'exploitation 15 (PLI) est consécutif au schéma de services (V13) le plus récent dans le plan d'exploitation (PLI) à actualiser, et à ce que - le schéma de services (V11) qui est supprimé du plan d'exploitation (PLI), est le schéma de services le plus ancien dans le plan d'exploitation (PLI) à actualiser. 20 3. Système pour gérer des services selon l'une quelconque des revendications précédentes, dans lequel dans un intervalle de temps en cours s'étendant de l'instanciation la plus récente jusqu'à la prochaine instanciation, le plan d'exploitation (PLI) comprend : - un schéma de services central (V12) dont au moins une partie principale se 25 trouve dans l'intervalle de temps en cours (Ti12, Ti13), et - un schéma de services en amont (V11) dont au moins une partie principale se trouve dans un intervalle de temps précédent (Ti11, Ti12) s'étendant de l'instanciation qui précède immédiatement l'instanciation la plus récente jusqu'à l'instanciation la plus récente, 20un schéma de services en aval (V13) dont au moins une partie principale se trouve dans un intervalle de temps suivant (Ti13, Ti14) s'étendant de la prochaine instanciation jusqu'à l'instanciation qui suit immédiatement la prochaine instanciation. 4. Système pour gérer des services selon l'une quelconque des revendications précédentes, dans lequel le module d'instanciation (IN) est agencé pour effectuer une instanciation par jour. 5. Système pour gérer des services selon l'une quelconque des revendications précédentes, dans lequel au moins deux schémas de services (V11, V12) dans un 1 o plan d'exploitation (PLI) se recouvrent partiellement. 6. Système pour gérer des services selon l'une quelconque des revendications précédentes, dans lequel un schéma de services (V11) a une durée différente de celle d'un autre schéma de services (V12). 7. Système pour gérer des services selon l'une quelconque des revendications 15 précédentes, dans lequel : - la base de données saisies (BD) est agencé pour stocker un autre ensemble de données saisies (D2) définissant différents schémas de services pour une autre exploitation (E2) réalisant des services, et - le module d'instanciation (IN) est agencé pour effectuer une autre 20 instanciation à partir de l'autre ensemble de données saisies (D2) avec une périodicité propre à l'autre exploitation (E2) afin d'actualiser périodiquement un autre plan d'exploitation (PL2) pour l'autre l'exploitation (E2), - la base de données de suivi (BS) est agencée pour stocker l'autre plan d'exploitation (PL2). 25 8. Système pour gérer des services selon la revendication 7, comprenant un module d'interaction (MAS) agencé pour offrir : - un premier accès exploitant restreint à l'ensemble de données saisies (D1) et au plan d'exploitation (PLI) mentionnés en premier, - un second accès exploitant restreint à l'autre ensemble de données saisies 30 (D2) et à l'autre plan d'exploitation (PL2), etun accès fédérateur pour accéder à l'un et l'autre ensemble de données saisies (D1, D2) et à l'un et l'autre plan d'exploitation (PLI , PL2). 9. Système pour gérer des services selon l'une quelconque des revendications 7 et 8, comprenant un module d'analyse (MAS) agencé pour effectuer une analyse 5 globale de données relatives à l'une et l'autre exploitation (E1, E2). 10. Système pour gérer des services selon l'une quelconque des revendications précédentes, dans lequel les services à gérer sont des services de transport en commun.