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. SYSTEM FOR SERVICE MANAGEMENT [0001 TECHNICAL FIELD [0002] One aspect of the invention relates to a service management system. The system can be applied, for example, in the field of public transport by a transport authority or a group of operators.
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 [000n Il existe un besoin pour un système permettant une gestion efficace de services réalisés par plusieurs exploitants. [0008] Selon un aspect de l'invention, un système pour gérer des services, comprend : - une base de données saisies pour stocker communément : - un premier ensemble de données saisies définissant différents 1 o schémas de services pour une première exploitation réalisant une partie des services, et un second ensemble de données saisies définissant différents schémas de services pour une seconde exploitation réalisant une autre partie des services, - un module d'instanciation pour effectuer : 15 - une instanciation à partir du premier ensemble de données saisies avec une périodicité propre à la première exploitation afin d'actualiser périodiquement un premier plan d'exploitation pour la première exploitation, et - une instanciation à partir du second ensemble de données saisies avec une périodicité propre à la seconde exploitation afin d'actualiser périodiquement 20 un second plan d'exploitation pour la seconde exploitation, la périodicité propre à la première exploitation pouvant différer de celle propre à la seconde exploitation, et - une base de données de suivi pour stocker communément le premier plan d'exploitation et le second plan d'exploitation. 25 [0009i Dans le domaine des transports publics, un tel système permet à une autorité organisatrice de transports d'avoir une appréhension globale, notamment dans le cas où plusieurs exploitants exploitent plusieurs réseaux dont l'autorité est en charge. Par exemple, l'autorité organisatrice de transports peut efficacement obtenir des statistiques relatives à l'ensemble des réseaux indépendamment des 30 exploitants qui les exploitent. Cependant, chaque exploitant peut exploiter ses réseaux avec son propre cycle de vie. Un tel système permet également à plusieurs exploitants de se regrouper toute en conservant une autonomie de fonctionnement qui est synonyme à 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. [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, au moins un plan d'exploitation comprend plusieurs schémas de services consécutifs. [0012] De préférence, au moins deux schémas de services dans un plan d'exploitation se recouvrent partiellement. [0013] Un schéma de services peut avoir une durée différente de celle d'un autre 15 schéma de services. [0014] De préférence, le module d'instanciation est agencé pour supprimer un schéma de service dans le plan d'exploitation lors d'une instanciation et pour ajouter un nouveau schéma de services dans le plan d'exploitation lors de cette instanciation. 20 [0015] De préférence, le système comprend un module d'interaction agencé pour offrir : - un premier accès exploitant restreint au premier ensemble de données saisies et au premier plan d'exploitation, - un second accès exploitant restreint au second ensemble de données 25 saisies et au second plan d'exploitation, et - un accès fédérateur pour accéder au premier ensemble et au second ensemble de données saisies et au premier plan et au second plan d'exploitation. [0016] 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 30 données relatives à la seconde exploitation. [0017] De préférence, les services à gérer sont des services de transport en commun. [ools] 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. [0019] 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. [0020] DESCRIPTION DETAILLEE [0021] 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 é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. [0022] 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. [0023] 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 transport. Cette présentation peut être visuelle, auditive, ou audiovisuelle, et peut s'effectuer de façon interactive. [0024] Une infrastructure de communication RC permet la transmission de données au sein de l'infrastructure IFT pour les services de transport en commun. Other aspects of the invention relate to a method for managing services, and a computer program. STATE OF THE PRIOR ART [0004] A system for operating assistance and passenger information (SAEIV) must offer various functions relating to public transport carried out by 1 o operators on behalf of an organizing authority of transport. First, this system must offer functions typically required by the transport authority such as passenger information to users. In addition, the system must provide an operator with tools to manage its operation in real time. Finally, the system must make it possible to produce statistical reports that can be used to evaluate the fulfillment of the contractual requirements formulated by the transport organizing authority towards the operator. [0005 The book entitled "Support Systems for the Exploitation and Information of Urban Public Surface Transport" published by CERTU (ISBN: 2-11- 20 093141-8) addresses several issues. Where are the evolutions of the support systems for the operation of urban surface public transport? How is the information of the users developed which is more and more associated? What are we waiting for tomorrow? The book reviews the developments and prospects of the Exploitation and Information Systems (SAEI) of urban surface networks. It is based on a bibliographic analysis and the visit of 15 public transport networks, including three foreigners. The book describes the principles of design and realization of the SAEI developed today, then feedback from the networks visited, including the features implemented, the difficulties encountered, taking into account the quality of service. The book includes an analysis of the investment and operating costs of these systems, a description of the industrial offer, and finally some recommendations for policy makers and practitioners. SUMMARY OF THE INVENTION [0006] There is a need for a system for the efficient management of services performed by several operators. [0008] According to one aspect of the invention, a system for managing services comprises: a database entered to store commonly: a first set of data entered defining different service diagrams for a first operation carrying out a part of the services, and a second set of data entered defining different service schemas for a second exploitation performing another part of the services, - an instantiation module for performing: - an instantiation from the first set of data entered with a periodicity specific to the first exploitation in order to periodically update a first exploitation plan for the first exploitation, and - an instantiation from the second set of data entered with a periodicity specific to the second exploitation in order to periodically update 20 a second exploitation plan for the second exploitation, the periodicity specific to the first exploitation, and - a monitoring database to commonly store the first exploitation plan and the second exploitation plan. [0009i In the field of public transport, such a system allows a transport authority to have a global apprehension, especially in the case where several operators operate several networks whose authority is in charge. For example, the transport authority can efficiently obtain statistics for all networks independently of the 30 operators who operate them. However, each operator can operate its networks with its own life cycle. Such a system also allows several operators to group together while maintaining an operating autonomy that is synonymous with responsibility and therefore efficiency. Thus, the operators of a group can perform different types of work such as, for example, urban services, interurban services, and school bus, using the same management system. An embodiment of the invention advantageously comprises one or more of the following additional features, which are described in the following paragraphs. Preferably, at least one operating plan comprises several consecutive service plans. [0012] Preferably, at least two service schemes in an operating plan partially overlap. [0013] A service scheme may have a duration different from that of another service scheme. Preferably, the instantiation module is arranged to delete a service schema in the operating plan during an instantiation and to add a new service schema in the operating plan during this instantiation. [0015] Preferably, the system comprises an interaction module arranged to offer: a first restricted operator access to the first set of data entered and the first operating plan, a second restricted operator access to the second set of data. 25 seizures and the second operating plan, and - unifying access to access the first set and the second set of data entered and the foreground and the second operating plan. Preferably, the system comprises an analysis module arranged to perform an overall analysis of data relating to the first operation and data relating to the second operation. [0017] Preferably, the services to be managed are public transport services. [Ools] A detailed description with reference to drawings illustrates the invention briefly described above, as well as the additional features identified above. [0019] SUMMARY DESCRIPTION OF THE DRAWINGS FIG. 1 is a conceptual diagram illustrating an infrastructure for public transport services. • Figure 2 is a block diagram illustrating a system of operating assistance and passenger information. • Figure 3 is a timing diagram illustrating a scheme of operation of the operating assistance system and passenger information. DETAILED DESCRIPTION [0020] FIG. 1 illustrates an IFT infrastructure for public transport services that typically cover a given territory. The IFT infrastructure comprises a first and a second operation El, E2 of public transport carried out respectively by a first and a second operator. The first exploitation El comprises, by way of example, two transport networks RT1, RT2. The second operation E2 also includes two transport networks RT3, RT4. A transport network comprises a set of lines. Matches can exist between two transport networks belonging to the same farm. Correspondences may also exist between two transport networks belonging to two different farms. The first exploitation El comprises different resources for carrying out public transport services within this operation. The same goes for the second exploitation E2. The resources are typically in the form of public transport vehicles V and C driving agents. The IFT infrastructure comprises information terminals B which can be deployed within the first and second operations E1. E2. An information terminal B provides travelers with information relating to transport services. This presentation can be visual, auditory, or audiovisual, and can be done interactively. An RC communication infrastructure allows the transmission of data within the IFT infrastructure for public transport services.
L'infrastructure de communication RC peut comprendre plusieurs réseaux de 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. [0025] L'infrastructure IFT pour les services de transport en commun comprend 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 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. [0026] L'infrastructure IFT pour les services de transport en commun comprend 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. [0027] 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. [0028] 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. [0029] 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. [0030] 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. [0031] 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. [0032] 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 1 o 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 15 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. [0033] Les données saisies par un exploitant, et stockées dans la base de 20 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 25 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. [0034] 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 30 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. [0035] 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 1 o 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 15 serveur qui traite l'information voyageurs théorique. [0036] 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 20 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. 25 [0037] 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. 30 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. [0038] 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 propre à différentes exploitations. [0039] En effectuant une instanciation à partir du premier ensemble de données saisies Dl, le module d'instanciation IN actualise un premier plan d'exploitation 1 o 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 15 prochaine instanciation. [0040] 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 S1 propre à la première exploitation E1. Le 20 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 25 données de suivi S1, S2, respectivement propre à la première et la seconde exploitation E1, E2, peuvent donc avoir des différents cycles de vie. [0041] 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 30 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. Les instanciations pour la première exploitation El et celles pour la seconde exploitation E2 sont déphasées les unes par rapport aux autres. Les instants Till, Ti12, Ti13, Ti14 reflètent la première périodicité d'instanciation et peuvent se trouver sur une grille de, par exemple, 24 heures. 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. Ces grilles sont donc décalées l'une par rapport à l'autre. [0042] 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 comprend trois schémas de services V11, V12, V13 consécutifs. La définition temporaire du premier plan d'exploitation PLI illustré à la figure 3 résulte d'une instanciation effectuée à l'instant Ti12. Cette définition temporaire est utilisée dans un intervalle de temps IT1 qui s'étend de cet instant Ti12 jusqu'à l'instant Ti13 auquel l'instanciation suivante est effectuée pour la première exploitation E1. [0043] 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 les 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. [0044] De préférence, un plan d'exploitation comprend typiquement trois schémas de services consécutifs comme l'illustre la figure 3. 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 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 en commun. [0045] 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 concernent 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). [0046] 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 a été complété à l'instant Ti3. Le module d'instanciation IN ajoute un nouveau schéma de services V14 qui débutera relativement peu après l'instant Ti4 où une nouvelle instanciation sera effectuée, ou qui débutera à cet instant Ti4. En effet, le nouveau schéma de services V14 ajouté au premier plan d'exploitation PLI à l'instant Ti13 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. [0047] 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. [0048] 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. The communication infrastructure RC may comprise a plurality of communication networks such as, for example, a private or operated radio system, a fixed telephone network, a mobile telephone network, and the Internet. These networks may be pre-existing, that is, they may exist prior to the implementation of the IFT infrastructure for transit services. [0025] The IFT infrastructure for public transport services includes a SAEIV operating assistance and passenger information system. The SAEIV operations and passenger information support system receives data on transport services and transmits such data via the RC communication infrastructure. The SAEIV operating and information support system includes one or more computer servers with a set of software modules defining operations. These operations carried out by the SAEIV operating assistance and passenger information system will be described in the following with reference to FIGS. 2 and 3. [0026] The IFT infrastructure for public transport services also comprises a FP federator station, a first PE1 operating station, and a second PE2 operating station. Any of these stations may be in the form of a computer equipped with an interface software allowing this station to access the SAEIV operating assistance and passenger information system as a customer in the technical sense. . Preferably, the interface software allows three access modes: a "federator" mode, a "first operator" mode, and a "second operator" mode. The access mode typically depends on one or more identification data (in English: a login) specified to use the interface software in order to interact with the operating and traveler information system. SAEIV. Indeed, the FP unifying station illustrated in Figure 1 symbolizes access in "federator" mode which is typically reserved for a transport authority or a group of operators. The first and the second operating station PE1, PE2 symbolize a "first operator" mode access and a "second operator" mode access respectively reserved for the first and second operators. A traveler can have one or more communication devices CP, PC such as, for example, a CP mobile phone or personal digital assistant PC. The traveler can obtain information relating to the public transport services by means of such a communication device. To do this, a connection is established between the communication device in question and the operating assistance system and SAEIV passenger information. [0028] Figure 2 functionally illustrates the SAEIV operating assistance and passenger information system in more detail. The FP federator position, the first and the second operator positions PE1, PE2, the vehicles V belonging to the first and the second exploitation E1, E2, and the communication devices CP, PC of the travelers are also represented in FIG. 2. The SAEIV operating assistance and passenger information system comprises an IF communication interface, a set of interaction modules MSD, MIT, MIR, MMR, MED, MAS, a database BD entries, an IN instantiation module, a BS tracking database, and a historical BH tracking database. The set of interaction modules comprises an MSD input module, a theoretical MIT traveler information module, a real time passenger information module MIR, a real-time management module MMR, a recording module MED, and a MAS statistical analysis module. Any module mentioned in the foregoing may be implemented, for example, using a server by loading an appropriate set of instructions therein. In such a software-based implementation, the set of instructions defines operations performed by the module concerned. The operations performed by the respective modules are described in the following. The databases mentioned above are typically implemented using the memory space present in one or more servers, or other computer equipment. The data entry database BD comprises a set of data entered general DG, a first set of data entered D1 specific to the first operation E1, and a second set of data entered D2 specific to the second operation E2. The tracking database BS comprises a first set of monitoring data Si specific to the first operation El and a second set of monitoring data S2 specific to the second operation E2. Similarly, the historical tracking database BH includes a first set of historical H1 tracking data specific to the first exploitation E1 and a second set of historical monitoring data H2 specific to the second exploitation E2. The SAEIV operating assistance and passenger information system generally works as follows. The MSD input module receives data 1 o entered by the first operator and by the second operator respectively in the first position and the second operator position PE1, PE2. The input module MSD stores the data entered by the first operator in the data base BD so that these data are part of the first set of data entered D1 specific to the first operation E1. Similarly, the MSD capture module stores the data entered by the second operator so that these data are part of the second set of data entered D2 specific to the second operation E2. Operators are therefore able to capture their respective data independently of each other. The data entered by an operator, and stored in the data base entered BD, describe transport services to be performed by the operator concerned, the resources implemented for this purpose, and an organization of these resources for carry out transport services. The data entered for transport services typically include data defining a topology of lines, stops, and line services. The data entered 25 relating to transport services may also include data defining race schedules to be made according to the types of calendar days. [0034] The resource-related data may include data defining transit vehicles and data defining driving agents. The data entered for the resource organization may comprise several data sets relating to vehicle services and several sets of data relating to agent services. These different data sets typically relate to different service schemas for different types of calendar days. A vehicle service data set defines races to be performed by a transit vehicle for a particular type of calendar day. An agent service data set defines the races, or race pieces, to be done by a driver for a particular day type of calendar. The theoretical traveler information module MIT relies on the data entered by the operators, which are in the database entered BD, to establish theoretical travel information. The theoretical travel information describes the schedules of the different networks according to the different types of day of the calendar. The theoretical travel information includes data from which time sheets can be produced and which can feed a website intended to provide information relating to public transport. For example, a traveler can view time sheets by means of a communication apparatus by connecting to a server that processes the theoretical traveler information. The theoretical information module MIT allows a transport authority to provide a consistent and consistent information describing all schedules of its networks that can be operated by different operators. In addition, the theoretical traveler information module MIT makes it possible to ensure that this information is always up-to-date because the module constitutes theoretical travel information automatically from the database entered BD. For example, as soon as an operator modifies a schedule, this change will automatically and immediately be taken into account in the theoretical travel information. [0037] The instantiation module IN performs instantiations from the data entered in the database entered BD. More precisely, the instantiation module IN performs an instantiation from the first set of data entered D1 with a periodicity specific to the first exploitation El. This periodicity will be called the first instantiation periodicity in what follows. In addition, the instantiation module IN performs an instantiation from the second set of data entered D2 with a periodicity specific to the second operation E2. This periodicity will be called the second periodicity of instantiation in the following. The first instantiation periodicity and the second instantiation periodicity may be out of phase with each other. For example, an instantiation relating to the first El farm can be done daily at two o'clock in the morning. An instantiation relating to the second operation E2 can be carried out daily at four o'clock in the morning. The instantiation module IN can therefore manage different life cycles for different farms. By performing an instantiation from the first set of data entered Dl, the instantiation module IN updates a first operating plan 1 o for the first exploitation El. The first exploitation plan thus updated is valid until at the next instantiation, which gives rise to a new update. Similarly, by performing an instantiation from the second set of entered data D2, the instantiation module IN updates a second operating plan for the second operation E2 which is valid until the next instantiation. The first plane and the second operating plane, respectively for the first and the second operation El, E2, are commonly stored in the tracking database BS. The first exploitation plan is therefore part of the first set of monitoring data S1 specific to the first exploitation E1. The second exploitation plan is therefore part of the second set of monitoring data S2 specific to the second exploitation. The instantiation module IN periodically updates these operating plans present in the tracking database BS, each according to a rhythm corresponding respectively to the first and the second instantiation periodicity. The first and the second set of tracking data S1, S2, respectively specific to the first and the second exploitation E1, E2, can therefore have different life cycles. FIG. 3 illustrates an operating diagram of the SAEIV operating aid and passenger information system and, in particular, that of the IN instantiation module. Fig. 3 is a timing chart having a horizontal axis representing time "t". At the instants Ti11, Ti12, Ti13, Ti14, the instantiation module IN performs an instantiation for the first operation El. At the instants Ti21, Ti22, Ti23, Ti24, the instantiation module IN performs an instantiation for the second operation E2. The instantiations for the first exploitation El and those for the second exploitation E2 are out of phase with each other. The instants Till, Ti12, Ti13, Ti14 reflect the first instantiation periodicity and can be on a grid of, for example, 24 hours. The instants Ti21, Ti22, Ti23, Ti24 reflect the second instantiation periodicity and can be on another 24-hour grid. These grids are therefore offset with respect to each other. A dashed rectangle symbolizes a temporary definition of the first PLI operating plan that applies to the first El operation. This temporary definition of the first PLI operating plan comprises three consecutive V11, V12, V13 service schemas. The temporary definition of the first PLI operating plan illustrated in FIG. 3 results from an instantiation performed at time Ti12. This temporary definition is used in a time slot IT1 which extends from this instant Ti12 to the instant Ti13 at which the following instantiation is performed for the first exploitation E1. Another dashed rectangle symbolizes a temporary definition of the second PL2 operating plan that applies to the second operation E2. This temporary definition of the second operating plan includes the V21, V22, V23 service schemas. The temporary definition of the second PL2 operating plan results from an instantiation performed at time Ti22. This temporary definition is used in a time interval IT2 which extends from this instant Ti22 to the instant Ti23 at which the following instantiation is performed for the second operation E2. Preferably, an operating plan typically comprises three consecutive service schemes as illustrated in FIG. 3. A service scheme covers a time interval having a duration, for example between 24 and 48 hours. The duration of a service schema may be different from that of another service schema. The service schemas may partially overlap as shown in Figure 3. That is, the time intervals covered by the service schemas do not necessarily correspond to the respective periodicities of the instantiations. This avoids interruptions or interruptions in public transportation services. For example, the time interval IT1 illustrated in Figure 3 may relate to a Saturday of an ordinary week. In this case, the time interval from the instant Ti11 to the instant Ti12 concerns a Friday of an ordinary week, and the time interval from the instant Ti13 to the instant Ti14 concerns a Sunday of such a week. In this case, the V11 service scheme is that of a Friday of an ordinary week, and the service plans V12, V13 are respectively those of a Saturday and a Sunday of such a week. The first PLI operating plan as shown in Figure 3 allows, in the time interval IT1 (Saturday), to continue the V11 service schedule of the day before (Friday) that would not have finished . This illustrated operating plan also allows, in the time interval IT1 (Saturday), to start the service schedule V13 the next day (Sunday). At the instant Ti13, the first PLI operating plan is updated. That is, the temporary definition of this PLI plane shown in Figure 3 is replaced by a new temporary definition. Concretely, the instantiation module IN deletes the V11 service schema which has been completed at time Ti3. The instantiation module IN adds a new V14 service scheme which will start relatively soon after the instant Ti4 where a new instantiation will be performed, or which will start at that instant Ti4. Indeed, the new V14 service scheme added to the first PLI operating plan at time Ti13 is the one for the next day. The new temporary definition of the first PLI operating plan will therefore include service schemes V12, V13, V14, and will apply in a time interval from the instant Ti13 to the time Ti14. At the instant Ti23, the second PL2 operating plan is updated in the same way. The IN instantiation module removes the V21 service schema and adds a new V24 service schema. The second PL2 operating plan thus updated will apply in a time interval of time Ti23 until time Ti24. Referring again to FIG. 2, the recording module MED receives situation data from the passenger transport vehicles V traveling in the IFT infrastructure illustrated in FIG. 1. The situation data can also be from other entities in this IFT infrastructure.
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. [0049] 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 1 o é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 15 des lignes et des destinations des véhicules V. [0050] 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 20 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 25 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. [0051] 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 30 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. [0052] 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 é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 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. [0053] 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 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. [0054] 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 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 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. [0055] 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'argent 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 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. [0056] 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 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 exploitants. [0057] 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 à 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. [0058] Le module d'analyse statistique MAS peut appliquer une opération 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. [0059] 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. [0060] Les données statistiques relatives à une exploitation peuvent également 1 o 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 15 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 20 voyageurs qui se déplace d'une remise vers un début de ligne pour débuter un service. [0061] 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 25 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 30 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. [0062] 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 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 1 o 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 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 15 creuses où la charge de travail est la plus réduite : un régulateur peut travailler simultanément sur plusieurs exploitations. [0063] REMARQUES FINALES [0064] 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 20 différentes. Afin d'illustrer ceci, quelques alternatives sont indiquées sommairement. [0065] 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 25 visé par la présente invention, mais pas exclusivement. [0066] II existe de nombreuses façons d'implémenter un système d'aide à 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 30 à 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. [0067] 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 n'y ait pas de recouvrement entre deux schémas de services consécutifs dans un plan d'exploitation. [0068] Une périodicité d'instanciation relative à une exploitation peut être ponctuellement interrompue. Par exemple, une périodicité de 24 heures peut être 1 o interrompue afin qu'il y ait 23 heures ou 25 heures entre deux instanciations successives. Ceci permet un passage de l'heure d'hiver à l'heure d'été ou un passage dans le sens inverse. [0069] 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 15 données et permettant d'interroger ces données de façon globale et homogène. [0070] 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 20 schématiques. Par exemple, se référant à la figure 2, la base de données de suivi 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 25 saisies BD. [0071] Il 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 30 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. [0072] 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 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. In any case, the situation data includes information relating to the actual progress of the public transport services compared to the current operating plan. Thus, situation data may indicate a delay on a line or other traffic problem. Situation data may also indicate events that may cause a traffic problem, even before it occurs. The recording module MED records the situation data relating to the first operation El in the first set of monitoring data S1 specific to this operation. Likewise, the recording module MED records the situation data relating to the second exploitation E2 in the second set of monitoring data S2 specific to this operation. The real-time passenger information module MIR relies on the tracking data, which are in the tracking database BS, to 1 o establish a real-time passenger information. The real-time passenger information module MIR may include an automatic broadcast portion for broadcasting stop information. This passing information can indicate the times of passage of vehicles V actually expected or waiting times. This information may be accompanied by the information of the lines and the destinations of the vehicles V. The real-time passenger information module MIR may also comprise a part of messaging programming for broadcasting messages relating to disturbances or delays. general vocation. Such a message can be selected from a library including various pre-recorded messages. The messages can be broadcast to vehicles V, information terminals B to stops, an Internet server, a voice server, or an SMS server. Messages can be broadcast in a time range or date range. The broadcast can be managed, at least partially, by the FP backbone station which may belong to a transport organizing authority. Alternatively, the distribution can be entrusted to the operators. In this case, the first and the second operator positions PE1, PE2 will give access to the messaging programming part. The real-time passenger information can, in a way, cross different farms E1, E2 and can be exchanged with other systems 30 such as, for example, another operating aid system and passenger information or a mobility center, according to a standardized protocol designated by the acronym "SI RI". This protocol makes it possible to transmit in particular data relating to correspondences. For example, a public transport infrastructure may include a hub with an information board. In this case, it is advisable to announce the passage of the vehicles serving different networks, whether these are operated by a single operator or by several. A transport organizing authority having the position of FP federator can obtain information that can help travelers and inform them. To do this, the real-time passenger information module MIR can establish this information from the data present in the tracking database BS. For example, the transport authority may respond to a traveler who complains of waiting at a stop, giving him the estimated time of arrival of a vehicle late. In another example, the transport authority may respond to a traveler who complains that a vehicle has not passed by communicating stops that the system found the service by the vehicle. More generally, the transport authority can supervise the real-time operations and observe the quality of instant service. The transport authority may also receive reports requesting an intervention such as, for example, a distress report. Thus, the transport authority can ensure the safety of passengers and drivers. The MMR real time management module allows the first operator and the second operator to act on its only networks, that is to say, the networks respectively part of the first and the second exploitation E1, E2. The first and second operators can therefore manage their own resources respectively via the first operator position PE1 and the second operator position PE2, and using the real-time management module MMR. The MMR real-time management module allows each operator to individually compensate for hazards and individually ensure a good quality of service while sharing the same operating assistance system and SAEIV passenger information. For example, the MMR real-time management module can provide each operator with information relating to the taking of services and the relays of his only driving agents. The real-time management module MMR thus enables the operator to compensate for absences or delays of money by replacement. The MMR real-time management module can also allow each operator to intervene on the failures of its only vehicles V by repair or replacement. The real-time management module MMR can furthermore allow each operator to monitor the occurrence of traffic hazards likely to delay his own races, or to trigger control maneuvers such as the suppression of a race or the addition of an additional vehicle to leave anyway on time despite a delay of a vehicle. The MAS statistical analysis module allows global statistical analysis via the FP backbone position. A global statistical analysis typically concerns all RT1-RT4 networks in the IFT public transport infrastructure. In the case where the FP federator position is operated by a transport organizing authority, the overall statistical analyzes allow the transport organizing authority to obtain quantitative data relating to the transport services performed by the operators. For example, the MAS statistical analysis module can establish data relating to the commercial kilometers traveled and the time spent to cover these kilometers, which makes it possible to establish a commercial speed. The statistical analysis module MAS can also establish data relating to the punctuality and the regularity of the services carried out compared to the theoretical schedules. In another example, the MAS statistical analysis module can establish line usage data for the entire IFT public transport infrastructure. The MAS statistical analysis module can apply a non-linear analysis operation to all the tracking data from different operators. The "STDEV" operation is an example of a non-linear analysis operation. Such an overall analysis is possible because different sets of data specific to different farms are commonly stored in the tracking database BS. The MAS statistical analysis module also allows operator oriented statistical analysis. Such statistical analyzes enable the first operator and the second operator to obtain statistical data relating solely to their networks. To do this, the statistical analysis module MAS establishes statistical data relating to the first or the second exploitation E1, E2 in response to a statistical analysis request respectively from the first operator position PE1 and the second workstation. operator PE2. Statistical data for an operation may be similar to the data established by an overall statistical analysis described above, the difference being that they apply to the operation alone. The statistical data relating to a farm may also relate to the resources of the farm in question and the organization of its resources for carrying out the public transport services. For example, statistical data relating to travel times can be used to adjust theoretical schedules. Statistical data on service outlets and relays can be used to detect systematic delays. Statistical data relating to an operation may relate to the working time of the driving agents working for the operator in question. These statistical data can also provide information on the so-called "up-to-the-minute" time spent: time spent on non-commercial trips. This is for example a 20-passenger transport vehicle that moves from a discount to an early start to start a service. The operating assistance system and passenger information SAEIV described in the foregoing and illustrated in Figure 2, can meet the needs of a transport authority and a group of operators. In the first case, the position of FP federator is operated by the transport organizing authority. In the second case, the position of FP federator is operated by the group of operators. In this second case, the SAEIV operating assistance and passenger information system leaves a relatively large autonomy for each operator in the group. Operators can enter their data independently of each other. Thus, each operator has the freedom to organize himself in the best way to carry out public transport services on the networks he operates. The real-time management module MMR can be arranged to allow two management modes: a management mode "group level" and a management mode "operator level". The "operator level" management mode corresponds to the operation of the real-time management module MMR described above: each operator manages his own networks independently. In the "group level" management mode, all the farms belonging to the group are managed collectively. This management method allows a group to improve its productivity by pooling its management resources, including qualified individuals to 1 o intervene in the management of the operation, These individuals are called "regulators". Both management modes can be used in combination. For example, the "operator level" management mode can be applied in peak hours: a controller typically focuses on a farm. The "group level" management mode can be applied in off-peak hours where the workload is the smallest: a controller can work simultaneously on several farms. FINAL REMARKS [0064] The detailed description with reference to the figures is merely an illustration of the invention. The invention can be realized in many different ways. In order to illustrate this, some alternatives are indicated briefly. The invention can be applied advantageously in many products and processes involving a management services performed by different operators. The field of public transport services is particularly targeted by the present invention, but not exclusively. There are many ways to implement an operating aid system and passenger information according to the invention. The number of farms can be greater than two. Therefore, the database entered can comprise a number of data sets entered greater than two, each set of data entered being specific to a particular operation. Similarly, the tracking database may include a number of tracking data sets greater than two, each tracking data set being unique to a particular operation. An interface software for a client station can include as many access modes as there are operators in addition to a unifying access mode. A service scheme may cover a time interval less than a time interval between two successive instantiations. For example, a service schema may be less than 24 hours. In this case, there may be no overlap between two consecutive service plans in an operation plan. An instantiation periodicity relating to an operation may be punctually interrupted. For example, a period of 24 hours may be interrupted so that there are 23 hours or 25 hours between two successive instantiations. This allows a transition from winter time to summer time or a passage in the opposite direction. The expression "databases" must be interpreted broadly. This expression embraces any type of computing entity including data and making it possible to interrogate these data globally and homogeneously. Although the drawings show different functional entities in the form of different blocks, this does not exclude implementations where a single physical entity performs several functions, or more physical entities collectively perform a single function. In this respect, the drawings are very schematic. For example, referring to Figure 2, the tracking database BS and the historical tracking database BH can form a single tracking database that includes ongoing tracking data and historical tracking data. This data can be included in a single physical memory. This memory may also include database 25 BD entries. There are many functional entities that can be implemented by means of hardware or software or a combination of hardware and software. The description of an implementation in the form of software does not exclude implementations in the form of hardware, and vice versa. Hybrid implementations are also possible in the sense that a system, or a functional entity included in the system, comprises one or more dedicated circuits as well as one or more suitably programmed processors. The foregoing remarks show that the detailed description with reference to the figures illustrates the invention rather than limiting it. The reference signs are in no way limiting. The verbs "understand" and "include" do not exclude the presence of other elements or steps other than those listed in the claims. The word "a" or "an" preceding an element or a step does not exclude the presence of a plurality of such elements or steps.