FR2899005A1 - Vehicle e.g. tramcar, locating method for validating e.g. ticket with barcode, involves determining vehicle position data at given instant from global positioning system data and predetermined data associated to route traveled by vehicle - Google Patents

Abstract

The method involves determining vehicle position data at a given instant from global positioning system (GPS) data and predetermined data associated to a route traveled by the vehicle on a transport network. Data relative to behavior of the vehicle is calculated, where the data includes a distance traveled by the vehicle, speed and acceleration of the vehicle and parameter of displacement of the vehicle with respect to a determined position. Independent claims are also included for the following: (1) a method for validating a ticket (2) a device for validating the ticket.

Description

METHOD AND DEVICE FOR LOCATING A VEHICLE

  The present invention relates to a method and a device for locating a vehicle.

  The invention finds application in public and private transport networks and in urban and interurban environments.

  The present invention is particularly applicable to all means of transport that travel on a transport network such as, for example, a bus, a train, a subway, a tram, a boat, a ferry, a trolleybus, etc.

  It is known to locate vehicles traveling on a transport network, in particular, to provide information associated with vehicles to users of the network.

  For this purpose, a control center is used which receives in real time information emitted by a vehicle concerning its position at a given moment. The central control can send information such as the scheduled time of passage of the vehicle for display at a stop network or in the vehicle.

  The present invention applies more particularly to toll systems on board a public transport vehicle, such as, for example, a bus, a coach, a train, a subway or a tram to enable the validation of a title of transport.

  A ticket is what allows a user to use public transport services, such as a bus, a metro or a train. A ticket generally includes means for storing quantifiable validity data of the ticket representing, for example, a pre-paid amount of money, or data representing a number of permitted geographical areas and / or an expiry date. according to the payment made. This data relates to one or more contracts for the use of a transport service. A ticket incorporating means for recording validity data may be based on different technologies: a paper ticket with a magnetic strip, a ticket containing bar codes, a chip / memory card that can be read with or without contact with the device. validation, a chip token ...

  In validation equipment on a public transport vehicle, it is important to know the location of the vehicle because there are tariff zones corresponding to the different geographical areas through which the vehicle passes. To allow a user a route in one or more geographical areas, the validity data recorded on the title presented by the user must authorize a trip in the zone or the corresponding tariff zones.

  In the current state of the art, information concerning trunks is provided to the driver console installed in the vehicle. The console driver may or may not be equipped with a GPS receiver. At the start of a race, the driver selects the number of the line and the number of the race he wishes to perform. Depending on whether the driver console is equipped with a GPS receiver or not, the location of the vehicle is determined in an assisted manner if the GPS receiver is present and if the GPS reception is correct or manually if there is no GPS receiver or if the GPS reception is not correct.

  The location of the vehicle is then transmitted by the driver console to the validation equipment installed in the vehicle. A major disadvantage of known systems of this type is that the bus driver is obliged to intervene to enter information about the line. and the race served by the vehicle and to check or seize throughout the race the location of the vehicle with the risk that this may include in terms of the attention of the driver vis-à-vis the environment of the vehicle. To this end, the invention relates to a method for locating a vehicle traveling on a transmission network, characterized in that it includes a step for automatically determining, without driver intervention of the vehicle, position data of the vehicle at a given instant. given from the GPS data and pre-determined data associated with a route potentially served by the vehicle on the transmission network.

  The invention makes it possible to provide on-board validation equipment on board a vehicle traveling on a transport network, the necessary and sufficient data to guarantee a correct pricing of the journey made by a passenger as well as an exact location on the race served. by the vehicle to enable the implementation of a tariff system based on geographical data, for example number of areas crossed, number of kilometers traveled, number of sections borrowed, etc., and the subsequent development of statistics on attendance network lines.

  In addition, the location of the vehicle on the network makes it possible to inform the passengers of the information concerning the progress of the vehicle on its course such as the time to arrive at the next stop, the identification of the next stop and the time to reach the terminus etc. In preferred embodiments, one and / or the other of the following provisions is also used:

  data relating to the behavior of the vehicle are calculated, these data comprising one or more of the following parameters: the displacement (dX, dY) of the vehicle relative to the last determined position, the distance (d) traveled by the vehicle, the heading of the vehicle , the speed (v) of the vehicle and the acceleration (g) of the vehicle; the location of the vehicle comprises a step for applying algorithmic acceleration mechanisms based on a table comprising the positions and behaviors of the vehicle and on a table allowing a rapid calculation of the heading of the vehicle; vehicle position data is determined with respect to a network depot from vehicle position data and data characterizing the perimeter of the depot; determining when the vehicle is in a data transfer zone in which data can be transferred between the vehicle and a central station from the vehicle position data and the vehicle position data relating to a depot; Determining position data of the vehicle with respect to at least one station of the transport network from the position data (X, Y) and data associated with the routes potentially served by the vehicle; identifying the line of the network on which the vehicle is traveling automatically from vehicle position data relating to a depot and vehicle position data relating to at least one station of the network; the race (routes and times) automatically served by the vehicle is identified from the position data of the vehicle relating to a depot, the vehicle position data relating to at least one station of the network, and the current time (t); - Update the history of the races of the vehicle on the network, the history of the races including GPS coordinates and the time of passage to points characteristic of the courses already served by the vehicle. This makes it possible to optimize the autonomous localization algorithm. the vehicle position is extrapolated in the areas not covered by the GPS automatically from position data and data relating to the behavior of the vehicle, data relating to the race served by the vehicle, and historical data collected during previous races of the vehicle.

  The invention also relates to a method for validating a ticket on a given route, characterized in that it comprises a step of locating a vehicle according to one of the methods described above, a step of reading the recorded data. on the ticket and a step of verifying the validity of the ticket according to the data recorded on the ticket and the position data (X, Y) of the vehicle.

  The invention also relates to a device for a vehicle for validating a ticket, characterized in that it comprises a reader for reading data on a ticket; means for locating the geographical area in which the validation device is located at a given moment; and a processor associated with the reader for locating the vehicle according to one of the methods described above to check whether the read data corresponds to a valid transport ticket.

  The validation device may comprise means for transmitting and / or receiving the radio signals for sending data to a central system located outside the vehicle, and / or for receiving data from said central system.

  The locating means are for example a positioning device of the GPS type.

  Other characteristics and advantages of the present invention will appear better on reading the description which follows, given by way of illustration and in no way limitative with reference to the appended figures in which:

  Figure 1 is a schematic view of a partial plan of a bus network; FIG. 2 is a schematic view of a location equipment according to a first embodiment of the invention; Figure 3A is a schematic view of a locating equipment according to a second embodiment of the invention; Figure 3B is a schematic view of a ticket validation device according to the second embodiment of the invention; FIG. 4 schematizes the main modules of the method for locating a vehicle according to one embodiment of the invention; FIG. 5 illustrates the positioning and behavior module of the vehicle according to the embodiment of the invention; FIG. 6 schematizes a position extrapolation method according to the embodiment of the invention; FIG. 7 schematizes a method for calculating the intermediate points according to the embodiment of the invention; FIG. 8 illustrates the locating module of a vehicle relating to a deposit according to the embodiment of the invention; FIG. 9 schematizes the method for locating the vehicle at a deposit according to the embodiment of the invention; FIG. 10 illustrates the location module of the data loading perimeters according to the embodiment of the invention; FIG. 11 illustrates the location module of the data unloading perimeters according to the embodiment of the invention; FIG. 12 illustrates the vehicle location module in the perimeter of a station of a transport network according to the embodiment of the invention; FIG. 13 schematizes the method for locating a vehicle in the perimeter of a station of a transport network according to the embodiment of the invention; FIG. 14 schematizes the method for locating a vehicle in the perimeter of a station of a transport network according to the embodiment of the invention; FIG. 15 illustrates the identification module of the race served by a vehicle traveling on a transport network according to the embodiment of the invention; and Figure 16 illustrates the history module of the race served by a vehicle on a transport network according to the embodiment of the invention.

  In the following, the invention will be described in the particular case of a bus transport network, for example, but said invention would apply similarly to all types of public and private transport network and to all means of transport such as a train, a metro, a tram, a trolleybus, a boat a ferry etc.

  In the description, the term "race" refers to the pre-programmed route followed by a transport vehicle and defined by the following data: number of the line, number of the race, date and time of the race, list of stops (or stations), hours of passage at the various stops, "station" means a stop served by a transport vehicle on a transmission line, "route" means the route between two stations and a line is defined as a route a predefined transport network.30 Figure 1 shows very schematically and as an example a partial plan of a bus network. The portion of the network shown in FIG. 1 shows three lines of the network designated respectively by the references L1, L2 and L3. Each line, L1, L2 and L3, comprises N stations S1 ... SN_1, SN and comprises two paths of opposite directions, T1 and T2, between a starting station or a depot D1, D2 or D3, located at one end of the line L1, L2 or L3 and an arrival station or depot D1, D2 or D3 located at the other end of the line L1, L2 or L3. The possible "paths" or "paths" between two stations S1 and S2 of the line L1 are designated P1, P2 and P3.

  Of course, in reality, the number of lines of a transport network is much greater than three and is generally of the order of several tens.

  A bus 10 which serves the line L1 of the network moves from the station of the departure or depot Dl to the arrival station of the depot D3 via the intermediate stations S1 to SN_1 of the line L1. The circle 12 in broken lines, represents the perimeter of a deposit D1, the circle 14 designates the perimeter of a region of a station Sn and the circle 16 in phantom means the perimeter of a zone in which data can be transferred between the vehicle and a central station. Of course, the station S1 can be located at the depot D1, D2 or D3 and the station SN can be located at the depot D1, D2 or D3.

  At a given instant, the vehicle 10 traveling on the transport network has a position X, Y, a speed v, an acceleration g, and a heading C. FIG. 2 illustrates a bus 20 equipped with a device that makes it possible to locate the bus and validate a ticket, according to one embodiment of the invention. The bus 20 is equipped with a GPS receiver 22

  (English acronym for Global Positioning System), validation devices 25 and centralized equipment 21, sometimes called a concentrator which deals with the management of all the devices 25. The GPS receiver 22 makes it possible to supply data representing the location of the vehicle and data representing the GPS coverage quality, as well as the date and time to a processor disposed in the centralized equipment 21. The validation devices 25 receive information necessary for the validation of the tickets and made available by the centralized equipment 21. Validation devices 25 are connected to the centralized equipment 21 via a data link, for example an Ethernet link, RS485, etc. The centralized equipment 21 is equipped with a radio communication system for communicating with a server located outside the vehicle, for example at the depot of buses or at a central office. The information regarding the location of the bus 20 and the information received from the over-the-air repository are transmitted to the validators 25 by the concentrator 21 through the data link.

  Another embodiment of vehicle location equipment and validation of tickets, according to the invention is described with reference to Figures 3a and 3b.

  A bus 30 is equipped with ticket validation devices.

  Each validation device 35 comprises a GPS-based spatial tracking module 32 equipped with a receiving antenna, a ticket reader 34 associated with a processor 341, a radiocommunication module 36 and a connector that connects the validation device. to the feed (not shown) of the vehicle 30.

  The processor is configured to locate the bus according to the locating method which will be described in the following.

  The ticket reader 34 is adapted to read the information recorded on a memory card-type ticket, with or without contact with the card, in order to check the validity of the ticket and authorize a given route on a transport network. . In order to remotely read a memory card-type ticket, the reader includes a transmission-reception circuit adapted to cooperate remotely with a suitable memory card, preferably by radio, infra-red or acoustic link. The reader 34 is adapted in a manner known in addition to subtracting from the ticket a quantity corresponding to the desired course of travel in the case where the data recorded on the ticket are quantifiable, for example when the data represent a sum of money prepaid by the user.

  Of course, in the context of the invention, the ticket reader 34 may be arranged in a manner known elsewhere for reading one or more of the following forms of tickets: paper ticket with magnetic strip, ticket containing codes bars, chip token, etc. Such readers are well known in the state of the art.

  The radio communication module 36 allows the communication between the validation device 35 and a central station located on the ground according to the IEEE 802-11 protocol, or any other protocol based on a wireless technology. In this manner, the validation device 35 has the capability of communicating with the ground central station to offload activity data including travel data from the passengers having used the bus 30 at the end of service and charging at the beginning. new operational data such as new software versions, parameters related to tariff evolutions and blacklisted transport tickets, etc.

  In another embodiment of the invention, the validation device may be equipped with a rechargeable battery. This battery can be connected to the power supply of the bus so that it can recharge slowly when the bus is operational and it can be adapted to go into activity when the contact of the bus is cut.

  Figure 4 schematizes the main components or modules of the vehicle location algorithm used by the processor to locate the bus 10, 20 or 30 according to a first embodiment of the invention. The location algorithm according to a first embodiment comprises data processing modules M1 to M7. The method determines the position of the bus 10, 20 or 30 at a given time from the data provided by the GPS receiver and predetermined data associated with the routes potentially served by the bus 10, 20 or 30. module M1 makes it possible to determine the current position (X, Y) of the bus 10, 20 or 30 as well as its behavior from the GPS location data and the GPS data indicating the quality of the GPS reception. It allows at any time to provide the position and behavior data to one or more of the other modules M2 to M7 of the algorithm. The module M2 locating the bus at a depot makes it possible to indicate to one or more modules whether the bus 10, 20 or 30 is at a depot as well as the movements of entry and exit of the depot from the data of position of the bus. This module makes it possible to determine vehicle position data at a depot. The module M3 locating the data loading perimeters makes it possible to indicate to the other modules whether the bus 10, 20 or 30 is in a data loading perimeter as well as the input and output movements of a loading perimeter from the position data of the bus and the position data of the bus relating to a depot. The module M4 locating the data unloading perimeters makes it possible to indicate to the other modules whether the bus 10, 20 or 30 is in a data unloading perimeter as well as the entry and exit movements of an unloading perimeter. from the bus position data and position data of the depot bus 10, 20 or 30. The M5 module located in the perimeter of a station makes it possible to indicate to the other modules the stop at a given station as well as the movements of entry and exit of the perimeter of the station from the position data of the bus. 10, 20 or 30 and race history data of the network. The M6 race identification module provides the other modules with the number of the race followed by the bus 10, 20 or 30 and the list of probable stations as long as the race is not clearly identified, from the data position of the bus 10, 20 or 30 relating to the depot and position data of the bus 10, 20 or 30 relating to a station of the network. That is to say the route served by the vehicle The module M7 History of the race allows to provide the other modules the history of each race performed by the bus 10, 20 or 30. This information relates to the departure times of each race, arrival times at stations, GPS coordinates of stops, intermediate points (changes of direction), losses and recoveries of GPS coverage. The processor 241 or 341 implementing the algorithm receives the following input parameters: the definition of the lines potentially served by the bus 10, 20 or 30; - the definition of the lists of possible routes on each of the lines, in English services patterns; the definition of the theoretical travel time between each station of a given course, in English time patterns; the definition of races (programmed race associated with a given pattern service and a given time pattern); the list of stations (stops) served by the vehicles and their contact details; GPS location and reception quality indication; and the date and time.

  The input parameters can be provided in other presentations but this does not change the principles of the algorithm, eg the definition of races can be provided in a form equivalent to that presented at bus stops.

  The parameters output from the algorithm include one or more of the following: the current position of the bus 10, 20 or 30 of transport; - the indication that the bus 10, 20 or 30 is in the perimeter of the loading points of the data; the indication that the bus 10, 20 or 30 leaves a depot; the indication of the number of the race ensured by the bus 10, 20 or 30; - the indication that the bus 10, 20 or 30 is within the perimeter of a station; an indication that the bus 10, 20 or 30 is leaving the perimeter of a station; the indication that bus 10, 20 or 30 arrives at the depot; the indication that the bus 10, 20 or 30 is in the data unloading perimeter; and the history of the races carried out by the bus 10, 20 or 30 with information relating to the stations, the timetables, the intermediate points marking the course such as the changes of direction, the points of loss and recovery of the GPS coverage etc.

  FIG. 5 illustrates in more detail the positioning and behavior module M1 of the bus 10, 20 or 30. The module M1 is designed to process data received from the GPS device 11, and to provide data representative of the positioning (X , Y) and the behavior of the bus 10, 20 or 30, as well as the date and time. The data representative of the behavior of the bus 10, 20 or 30 may indicate a bus stop 10, 20 or 30 or a change of direction. The positioning data (X, Y), the date and time, and the behavior indications of the bus can be provided to one or more other modules M2 to M7 of the algorithm.

  The input parameters of the M1 module are mainly the GPS data provided by the GPS receiver 22 or 32 (X, Y, Z coordinates, date and time and Q reception quality indication) and the race history. The race history includes data characteristic of the races served by the bus.

  The M1 module is able to operate in several modes of operation, depending on the information provided by the GPS receiver.

  A first mode of operation - non-localized mode is adopted by the module M1 at startup after powering up the bus. A second mode of operation - normal GPS coverage mode - is adopted by the module when the GPS receiver provides the position of the bus (X, Y) with acceptable reception quality (Q). A third mode of operation - Insufficient GPS coverage mode - is adopted by the module when the GPS coverage information indicates a loss of GPS coverage and the GPS receiver is no longer able to provide the position of the bus ie the quality Q is not acceptable.

  The M1 module uses algorithmic acceleration mechanisms based on a table memorizing the positions and behaviors of the bus and on a table allowing a quick calculation of the course of the bus. The bus position and behavior storage table includes at least the following fields: The current position of the bus (X, Y) and an indication of the quality of the position data (safe, where the quality of reception Q is acceptable, extrapolated, where Q reception quality is not acceptable); Displacements relative to the previous position (dX, dY); The distance traveled from the previous position (d); The estimated current speed (v) of the bus; The acceleration / deceleration factor of the bus (g); - The heading of the bus (heading) and an indication of the reliability of this heading; and a time indication for detecting the bus stop. The table is a table comprising N rows (N being configurable) and is FIFO (first in, first out) type. In order to allow a quick calculation of the course of the bus, a table is created with 90 elements representing the 90 degrees possible. The ratio dY / dX as well as the signs of the values dX and dY must make it possible to quickly determine the angle of displacement in the repository. Non-Localized Mode When powering on the bus, the module initializes the tables associated with the acceleration mechanisms and waits for reception of positioning information from the GPS receiver. As soon as a positioning information is received with a satisfactory Q index, the module stores the information in the position and behavior table and switches to the normal GPS coverage mode. Normal GPS coverage mode On acquisition of a new positioning information (X, Y) of the bus, it is checked whether the quality Q of the received information is good. If the positioning information X, Y is judged to be of good quality, the module looks at whether a displacement has occurred relative to the past position. If no movement has been observed, a counter of the duration of the observed stop is incremented. If the counter reaches a value N> 5 seconds (settable), the module M1 can signal to the other modules that the bus is stopped (or has just stopped). If a displacement has been observed, the new position (X, Y) of the bus is stored and the relative displacements (dX, dy) of the bus, the distance traveled (d), the speed (v), are calculated. heading, as well as acceleration / deceleration (g) observed. The current position (X, Y) of the bus can be provided to the other modules M2 to M7.

  In this mode of operation the algorithm must also determine the course changes of the bus and provide this information to feed the race history (GPS coordinates and timing of intermediate points). The algorithm for calculating the intermediate points will be described in more detail below. If the positioning information (x, y) is judged to be of insufficient quality (Q), the module extrapolates the current position of the bus to provide it to the other modules and switches to the insufficient GPS coverage mode. The position extrapolation algorithm will be described in more detail below. Inadequate GPS coverage mode In this operating mode, the M1 module extrapolates every second the probable position of the bus from the information stored in the table of positions and behaviors of the bus and from the history of the races. made by the bus. The position extrapolation algorithm will be described in more detail below. In this mode, the M1 module manages a table of entry points of GPS coverage loss areas. This table contains at least the following information: a unique reference of the entry point of the GPS coverage loss areas; the coordinates of the entry point - The n of the races passing through this entry point (if identified) - The references of the N possible exit points The M1 module also manages a table of exit points of the areas of loss of GPS coverage . This table contains at least the following information: - a unique reference of the exit point the coordinates of the exit point - the n of the runs passing through this exit point (if identified) The unique reference of entry points and points of exit output is assigned by this module and stored in the race history. The passage of the bus through these entry and exit points is stored in the history (characteristic point). The dynamic data relating to each race (heading, speed, time, etc.) are also stored in the history and are exploited by the algorithm for extrapolating the position described above.

  On receipt of a positioning information of the bus deemed to be of good quality, the module erases the table of positions and behaviors of the bus, records the new position in the table and transmits this new position to the other modules. Then the module goes into normal GPS coverage mode.

Position extrapolation

  FIG. 6 schematizes the position extrapolation method according to one embodiment of the invention. By passing from the S2 station to the S5 station of the network, the bus 10, 20 or 30 enters a zone of non-GPS reception. The actual path of the bus between the entry point E1 in the GPS non-reception area 41 and the exit point E2 of the area is represented by the dashed line. The path extrapolated by the localization method is represented by the continuous line. At the exit E2 of the GPS non-reception zone 41, the position (X, Y) of the bus is rectified by GPS.

  The extrapolation algorithm has information stored in: ^ the table of positions and behaviors of the bus; ^ the entry point table of the GPS coverage loss areas; 30 ^ the table of exit points of areas of loss of GPS coverage; and ^ the history of the race (if it exists and if the race has been identified).

  If the race of the bus has been identified, we have the following elements: ^ At least, we have the service pattern of the race and the time pattern, which allows us to know where the next station is located and how long it is must to reach this station. ^ If the race history is available, additional information may be available such as the next characteristic point which may be: o An SN station located in the GPS coverage loss area; o An exit point from the GPS coverage loss area.

  This information will enable the bus 10, 20 or 30 to be positioned in the area of loss of GPS coverage 41. If no race has been identified, the following elements are available: The table of positions and behaviors of the bus; ^ The entry point table of GPS coverage loss areas; and 20 ^ The table of exit points of GPS coverage loss areas.

  If the El entry point does not exist in the entry point table of the GPS coverage loss areas, a new entry is created with an associated race number (race in progress). This 25 generic race number will need to be updated once the race has been identified.

  The extrapolation of the position of the bus will be made from the last record of the table of positions and behaviors of the bus (heading, 30 speed).

  If the entry point El exists, there are normally associated exit points. We take the first exit point from the list (or most likely that can be determined by other criteria such as the current date and time) and we use the last record of the table of positions and behaviors of the bus ( speed). The course of the bus being the straight line between the point of entry and exit.

  Calculation of Intermediate Points FIG. 7 schematizes the method for calculating the intermediate points according to one embodiment of the invention. Bus 10, 20 or 30 flows from station S2 to station S3 of the network through a crossroads C1 at an intermediate point (X, Y, dT). Arrow F1 represents the direction of movement of the bus before arriving at the Cl junction - the previous heading, and arrow F2 represents the direction of movement of the bus after the junction - the new heading.

  An intermediate point (X, Y, dT) corresponds to a junction or a significant change of course of a street. Intermediate points are managed in a table and are uniquely identified. These intermediate points are stored in the race history.

  The algorithm according to the embodiment of the invention has information stored in the table of positions and behaviors of the bus (positions and successive caps). The algorithm must detect: ^ stable headings which generally correspond to straight or near-right streets, ^ the transition from one stable heading to another and the midpoint which represents the intermediate point (or point of tipping course).

  The module M2 for locating the bus with respect to a depot will be described with reference to FIGS. 8 and 9. The module M2 is designed to process current position (X, Y) and hour H data received from the module M1. to indicate to the other modules if the bus is at the depot as well as the entrance and exit movements of the bus depot. This module makes it possible to determine position data of the vehicle with respect to a deposit. The input parameters of the M2 module are position and time data, power-on indication of the equipment, and perimeter data of the depots (Xd, Yd, Rd) where (Xd, Yd ) is the central position of the deposit and Rd is the radian of the deposit. FIG. 9 illustrates the perimeter D1 of the depot and the arrival circuit of a bus A1 at the depot and the departure circuit A2 of the depot. When turning on the bus or the validation device, it is necessary to know if the bus is located at the depot or if it is outside the depot, for example the bus may be waiting at the starting station of a race. If the bus is at the depot, you can indicate when the bus is leaving the depot. If the bus is outside the depot, you can indicate when the bus goes to the depot. In a transport network there can be several depots. The list of deposits and their characteristics are defined as parameters of the equipment.

  The module M3 for locating the loading perimeters will be described with reference to FIGS. 9 and 10. The module M3 locating the loading perimeters makes it possible to indicate to the other modules whether the bus is in a data loading perimeter as well as the movements entry and exit of a loading perimeter. This module makes it possible to determine vehicle position data with respect to a data transfer zone. The input parameters of the module M3 are data of position and current time, the indication that the bus is at deposit and data indicating that the bus is stationary as well as downtime.

  The M3 module is designed to process this data to indicate to other modules whether the bus is stopped in a data loading perimeter and to indicate the input and output movements of a loading perimeter. The data is loaded into the equipment over the air. Figure 10 illustrates the coverage perimeter Chi of the data loading antennas. The radio communication module of the bus allows communication between the validation equipment 35 and a central station located on the ground according to the IEEE 802-11 protocol or any other protocol based on wireless technology.

  When the bus 10, 20 or 30 is located at the depot D1, the module M3 can indicate that the bus has entered a data loading area Chi, that the bus stops in the loading area Chi and that the bus leaves the Chi loading area.

  There may be multiple loading areas at a depot. The list of depots and loading areas are defined as parameters of the equipment.

  The module M4 shown in FIG. 11 locating the unloading perimeters, illustrated in FIG. 11, makes it possible to indicate to the other modules whether the bus is in a Ch2 unloading perimeter of 30 data as well as the input and output movements. exit from a Ch2 unloading perimeter. This module works in the same way as the load perimeter location module described above. There may be several discharge zones Ch2 at a deposit D1. The list of depots and the unloading areas are defined as parameters of the equipment.

  Although FIG. 9 illustrates a data charging zone Chi which does not correspond to the discharge zone Ch2, in the variants of the invention the charging zone Chi and discharging Ch2 of the data can correspond to the same zone. The fact that the vehicle was already located at the depot or that the vehicle has just entered the depot makes it possible to discern loading and unloading.

  The module M5 for locating the bus in the perimeter of a station will be described with reference to FIGS. 12 to 14. The module M5 located in the perimeter of a station makes it possible to indicate to the other modules the stop at a station given as well as the movements of entry and exit of the perimeter of the station. This module makes it possible to determine position data of the vehicle with respect to at least one station of the network.

  The input parameters of the module are the common algorithm input data including the list of probable stations as well as the elements provided by the other modules such as, the current position and time, the identifier of the race served. by the bus (when known), the indication of stopping the bus for at least 5 seconds (adjustable parameter) and the history of the races.

  The module M5 is designed to process input data and to determine the information relating to the passage of the bus in the environment of a station Sn in particular, the entrance of the bus in the perimeter of the station Sn, stopping and / or passing the bus to a station and / or the exit of the bus from the perimeter of the Sn station. The module can indicate whether a vehicle has passed through a Sn station without stopping. FIG. 13 schematizes the elements for locating at a station Sn and includes the perimeter of a station PSn, the stop perimeter at a station PAn and the coordinates of the station Sn. The perimeter of the PSn station is defined by a radius circle of approximately 30m (adjustable parameter). The stop perimeter PAn at the station is defined by a radius circle of about 10m (adjustable parameter).

  This module uses algorithmic acceleration mechanisms based on a decomposition of the geographical area served in cells and on a location of each stop (station) Sn in this repository as shown in Figure 14. This decomposition in regular cells considers as negligible the projection errors.

  When powering on, the module M5 positions each of the stations Sn in the repository defined by its coordinates X0, Y0 (adjustable parameters). For each station, the module determines the X, Y membership cell in the repository. This will make it possible to compare the current position of the bus only with the coordinates of stations positioned in the same cell G1 that the bus or positioned in a neighboring cell G2 to G9.

  Then the module waits for a position information of the bus acquired via the GPS or extrapolated by the positioning module M1 of the bus. Upon receipt of bus position information, search is made for the G1 cell in which the bus is located and the relative position of the bus in the cell (North, North-East, East, East, South, Southwest, West, Northwest) to identify adjacent G2 to G9 cells to consider. If the bus was not previously positioned in the perimeter of a station, all Sn stations located in the same cell G1 as the bus and in the adjacent cells which are to be taken into consideration are searched. For each of the stations, the position of the bus is compared with the coordinates of each station. If '(dX' + dY2) 2 is less than the radius of the circle defining the perimeter of the PSn station, the module must signal the entry into the perimeter of the station PS ,,.

  If the bus was positioned beforehand in the PSn perimeter of a Sn station, and if the bus was not positioned beforehand in the PAn stop zone of the Sn station, we look at whether the bus has reached the stop perimeter PAn of the Sn station. If this is the case, we memorize the information.

  If the bus was previously positioned in the perimeter of a PSn station, and if the bus was previously positioned in the PAn stop perimeter of the Sn station, it is checked whether the bus is still within the perimeter of a station. stop at the Sn station. If the bus has left the stop zone PAn of the Sn station, and the bus has not stopped in the stop zone PAn of the Sn station, the other modules are notified that the bus is passed by the Sn station without stopping. On receipt of bus stop information (configurable duration), it is checked whether the bus had entered the PSn perimeter of a Sn station.

  If the bus was already in the station's perimeter, the other modules were informed that the bus stopped at Sn.

  Otherwise we look if the bus is in the perimeter PAn of the station Sn. If this is the case, the other modules are told that the bus stopped at Sn. Otherwise it is considered a stop of the bus probably due to traffic or traffic lights near the stopping area.

  If the race served by the bus has been identified, the algorithm uses the history of the race, including the precise coordinates of stops at each station. Indeed, for a given station Sn, the stopping areas of the vehicles will depend on the means of transport and the line served. As soon as the race is identified, the algorithm uses the GPS coordinates of the station stored in the race history in place of the generic coordinates of the station Sn. The race identification module M6 will be described with reference to FIG. 15. The module M6 makes it possible to identify the race served by a vehicle. The input parameters of the module M6 are the indication that the bus is in a depot, the indication that the bus is leaving a depot, the indication that the bus is outside a depot, the indication that the bus is stationary at the Sn station and the indication that the bus passed through the Sn station without stopping.

  On power up, the module acquires the current date and time (maintained locally), or waits for reliable date and time information from the GPS receiver.

  Following the acquisition of a reliable date and time, reliable location information of the bus vis-à-vis the (or) deposit (s) to which 25 (to) the bus can be attached.

  Following the receipt of the indication that the bus is leaving the depot, we create the potential shopping lists whose schedules are in line with the current date and time: List 1: races starting from the depot including the departure times are between -5mn and + 10mn compared to the current time (adjustable parameters) - List 2: races starting from the depot whose starting times are between + 10mn and + 30mn compared to the current time (adjustable parameters )

  Following the receipt of the indication that the bus is outside the depot, potential shopping lists are created whose schedules are in line with the current date and time: List 1: races starting from a terminus of which departure times are between -5mn and + 10mn compared to the current time (adjustable parameters) List 2: races starting from a terminus whose departure times are between + 10mn and + 30mn compared to the current time (adjustable parameters)

  During the first preparation of the lists 1 and 2, the first station S1 of each race is selected as the first station S1 to which the bus is likely to stop. Then the module waits for the stop or transit information of the bus to these potential stations.

  Upon receipt of the bus stop indication at the Sn station, the algorithm stores the stop at the station Sn and refines the lists 1 and 2 of potential races. Only the races serving the Sn station are maintained in these 2 lists, and the information relating to the next station Sn + 1 through which the bus is likely to pass and stop is updated.

  If no race of the lists 1 and 2 serves the station Sn, the module searches all the races likely to serve the station Sn in a relatively wide time range of -30mn to + 30mn (adjustable parameters) and enriches the list 1 with this new series of races.

  When only one and last race remains in the lists 1 and 2 after updating, the algorithm transmits to the other modules the identifier of the race served by the bus.

  When the bus stops at the last SN station of the race, the module creates new lists 1 and 2 of potential races whose schedules are in adequacy with the current date and time and likely to serve the same line in the return direction.

  On receipt of the indication of passage of the bus to the station Sn without stopping, the algorithm memorizes the passage but does not eliminate lists 1 and 2 the races likely to serve the station Sn (because the bus does not may not be stopped because no passenger has notified of his intention to get off or get on the bus). The information on the next Sn + 1 station through which the bus is likely to pass and stop is updated.

  The M7 race history module will be described with reference to FIG. 13. The M7 module makes it possible to memorize the characteristic data of the races served by the bus, namely: - Identification of the line served by the bus - Identification of the race served by the bus - Number of iterations of the bus on the same race Theoretical starting time of the race (according to the parameters received from the central system) Observed time of departure of the race, observed deviations (average, max +, max-) Data associated with the characteristic points of the race

  Characteristic Point Type: Stop Point (Station), Intermediate Point (Heading), Point of Loss of GPS Coverage, GPS Coverage Recovery Point

  If breakpoint type: Breakpoint identifier Breakpoint coordinates, observed deviations (average dX, average dY, dXmax +, dYmax +, dXmax-, dYmax-), Stop arrival time, deviations observed (mean, max +, max-) Travel time from previous stop, observed deviations 15 (average, max +, max-)

  If intermediate point type: Intermediate stopping point identifier Stopping time at intermediate point, observed deviations (average, max +, max-) Travel time from previous stop, observed deviations (mean, max +, max. )

  If type point of loss of GPS coverage: 25 Identifier of the point of loss GPS (determined by the positioning module) Travel time compared to the previous stop, observed deviations (average, max +, max-) 30 If type point of GPS coverage coverage: GPS recovery point ID (determined by the positioning module) Travel time relative to the associated GPS coverage loss point, observed deviations (mean, max +, max-) The advantages of the algorithm according to the embodiment described above are the following allows a correct pricing of the trip made by a passenger of the bus allows an exact location on the race served by the bus to allow the subsequent development of statistics on the attendance of lines provides passengers with information regarding the race - to indicate the next stop, the time at the next stop, the time to go to the depot avoids the intervention of the driver of the car bus.

  Note that the invention also applies to any equipment on board a transport means for which a location need on a set of predetermined course is necessary to allow this equipment to offer the expected service.

Claims (14)

  1. A method of locating a vehicle (10; 20; 30) traveling on a transport network characterized in that it comprises a step for automatically determining, without driver intervention of the vehicle, position data (X, Y). ) of the vehicle at a given time from the GPS data and pre-determined data associated with a route potentially served by the vehicle (10; 20; 30) on the transport network.   2. Method according to claim 1, characterized in that it further comprises a step for calculating data relating to the behavior of the vehicle (10; 20; 30), these data comprising one or more of the following parameters: displacement (dX , dY) of the vehicle relative to the last determined position, the distance (d) traveled by the vehicle, the heading of the vehicle, the speed (v) of the vehicle and the acceleration (g) of the vehicle.   3. Method according to any one of claims 1 or 2, characterized in that the location of the vehicle comprises a step for applying algorithmic acceleration mechanisms based on a table comprising the positions and behaviors of the vehicle and on a table allowing a quick calculation of the vehicle heading   4. Method according to any one of the preceding claims, characterized in that it further comprises a step for determining vehicle position data with respect to a repository (D1; D2; D3) of the network from the data of position (X, Y) of the vehicle and data characterizing the perimeter of the deposit (D1; D2; D3).   A method according to any one of the preceding claims, characterized in that it further comprises a step for determining when the vehicle (10; 20; 30) is in a data transfer area into which data can be transferred. between the vehicle (10; 20; 30) and a central station from the vehicle position data and vehicle position data relating to a deposit (D1; D2; D3).   6. Method according to any one of the preceding claims, characterized in that it further comprises a step for determining vehicle position data with respect to at least one station (Sn) of the transport network from the data of position (X, Y) and data associated with the routes potentially served by the vehicle (10; 20; 30).   7. Method according to any one of the preceding claims, characterized in that it further comprises a step for identifying the line of the network (L,) on which the vehicle travels automatically from the vehicle position data relating to a depot (D1; D2; D3) and vehicle position data relating to at least one station (Sn) of the network   8. Method according to any one of the preceding claims, characterized in that it further comprises a step for identifying the race (routes and schedules) served by the vehicle automatically from the vehicle position data relating to a deposit, vehicle position data relating to at least one station of the network, and the current time (t).   9. Method according to any one of the preceding claims, characterized in that it further comprises a step for updating the history of the races of the vehicle on the network, the race history including GPS coordinates and time crossing points of the routes already served by the vehicle.   The method according to any one of the preceding claims, characterized in that it further comprises a step for extrapolating the position of the vehicle in the areas not covered by the GPS automatically from position data and relative data. the behavior of the vehicle, data relating to the race served by the vehicle, and historical data collected during previous races of the vehicle.   11. A method for validating a ticket on a given route, characterized in that it comprises a step of locating a vehicle (10; 20; 30) according to a method according to any one of the preceding claims, a step of reading the data recorded on the ticket and a step of verifying the validity of the ticket according to the data recorded on the ticket and the position data (X, Y) of the vehicle (10; 20; 30).   12. Device for vehicle, validation (35) of a ticket characterized in that it comprises: a reader (34) for reading data on a ticket; location means (32) for the geographic area in which the validation device is located at a given time; and a processor (341) associated with the reader (34) for locating the vehicle (10; 20; 30) according to a method according to any one of claims 1 to 10 and for checking whether the read data corresponds to a valid transport ticket .   13. Validation device (35) according to claim 12, characterized in that it further comprises means for transmitting and / or receiving (36) radio signals to send data to a central system located outside the vehicle, and / or to receive data from said central system.   14. Validation device (35) according to claims 12 or 13, characterized in that the locating means (32) comprise a GPS-type positioning device.